US Department of Defense (DoD) contractors that handle Controlled Unclassified Information (CUI) are required to secure that CUI by implementing the National Institutes of Standards and Technology (NIST) 800-171 cybersecurity standard. DoD contractors and other members of the Defense Industrial Base (DIB) will be subject to the Cybersecurity Maturity Model Certification (CMMC), in which independent assessors will certify the contractors’ implementation of NIST 800-171. One of the cybersecurity safeguards in 800-171 — requirement 3.4.4 — requires DoD contractors to perform Security Impact Analysis (SIA) prior to all IT system changes. In this post, part of our continuing “What the heck is?” series, we explain what the heck a Security Impact Analysis is and describe how to execute an SIA. We also provide a downloadable SIA process guide that small business DIB members can implement to bolster their Security Impact Analysis capability and prepare to pass the CMMC assessment.
What does Security Impact Analysis mean?
The relevant NIST 800-171 safeguard for Security Impact Analysis (SIA) is control 3.4.4 (CMMC Practice CM.L2-3.4.4) in the Configuration Management family:
"Analyze the security impact of changes prior to implementation."
There is one Assessment Objective for this control called out by the 800-171A Assessment Standard, which essentially just restates the requirement:
CMMC assessors will use the Assessment Objective to determine if we properly perform SIA. The bottom line is that NIST and the DoD want contractors to establish an SIA process to demonstrate that the organization can make IT system changes in a controlled manner, without negatively impacting the security of the government information handled by the system.
Ok, so what the heck is a security impact analysis, what is the “system”, and what types of changes need to be analyzed? The answer to the second part of that question is relatively straightforward: the “system” includes all IT components that support the handling (processing, storing, transmitting) of CUI. This includes IT hardware, software, networking devices, cloud services, information, and the people that use those components. The DoD calls this the “covered” system, in that your IT system that handles CUI is subject to the DFARS 252.204-7012 requirement that necessitates the implementation of the 800-171 standard.
So we understand what “system” entails. Now, what sort of changes to your covered system require security impact analysis? The NIST guidance — e.g. the “Discussion” text in the 800-171 document — isn’t much help here, as it just keeps referring to “changes”. It’s up to us to determine what sorts of changes require impact analysis. (800-171 does refer to a companion document, 800-128 “Guide for Security-Focused Configuration Management of Information Systems”, but this document is a 99-page beast. We posted this blog to help small business staff save their eyeballs and avoid having to wade through NIST epics.)
We recommend keeping things as simple as possible, and stating in policy that “significant” system changes will require security impact analysis. What constitutes a significant system change? We’ll cover that in the section below. For now, let’s wrap up this section by exploring Security Impact Analysis. Simply put, SIA is when a group of stakeholders* at an organization determine:
- how a proposed system change will affect the security of the system and/or organization, and,
- what actions the organization will take to minimize those effects.
*If you’re not sure which stakeholders should be included, sounds like your organization needs to charter a Configuration Control Board (CCB). More to come on CCB in a future blog article, but for now you can download a template here and explore the Configuration Management Plan (CMP) portion on how to manage a CCB. (At Totem Technologies the CCB consists of only four individuals from the IT and security teams. We keep it simple. Starting to recognize a pattern?)
How small businesses can perform Security Impact Analysis (SIA)
SIA approach
Totem Technologies’ approach to Security Impact Analysis for NIST and CMMC compliance is adapted from the one recommended by the Centers for Medicare and Medicaid Services (CMS) for HIPAA covered entities. This aligns with our general philosophy that “if it’s good enough for the government, it should be good enough to pass a CMMC assessment.”
Essentially, the CMS approach requires the organization IT and security teams to determine, for each proposed system change, if that change is “significant” enough to “trigger” an SIA. And if so, to then execute the SIA. The approach revolves around consulting a table with a list of types of IT system changes that would trigger an SIA. This table also includes a list of actions the organization should take to reduce the security impact of that change. By filling out the table, executing the recommended actions, and documenting what has been done, the organization has successfully performed a Security Impact Analysis. A portion of that table is shown in the image below. The full table is included in our Security Impact Analysis (SIA) process guide template, which you can download below for free. (The SIA process is also covered in our more comprehensive System Security Plan (SSP), Security Engineering Process Guide (SEPG), and Configuration Management Plan (CMP) template, which you can download here. You read that correctly, you can get your hands on a document with three (3!) acronyms in the title, all for free!)
SIA process
For each proposed change, the organization configuration management stakeholders should meet to discuss that change and consult this table. Bear in mind the image above is just a snippet from the table. The full table is in the downloadable document template.
The table has four columns:
- Category
- Scope of Change
- Mitigations or Necessary Updates
- Control Families Impacted
The category column is mainly for reference; the other three columns are the most important.
The SIA process goes like this: if the proposed change matches the description in the “Scope of Change” column, then the change is “significant” and triggers a Security Impact Analysis. In that case, the organization must:
- provide a brief overview of the technical and risk aspects of the change
- execute the actions specified in the “Mitigations or Necessary Updates” column, and
- review and update the “Control Families Impacted” in the SSP.
If the proposed change does not match any of the triggering scopes, it’s not significant enough to warrant an SIA. Though, this does not necessarily mean that the change should not be tracked in the ticketing system and/or captured in your SSP. For example, making a change to your organization’s personnel onboarding/termination procedures may not be considered “significant” enough to trigger an SIA, but it probably needs to be described in your SSP since it pertains to one or more 800-171 controls, e.g. 3.9.2.
Note that this process does not adopt arbitrary “qualitative” impact designations such as “high”, “moderate”, or “low”. There are simply conditions that trigger actions.
It’s really pretty simple. Let’s explore some examples of how to do an SIA using this table.
Examples of SIA process
Let’s say your organization, in accordance with 800-171 control 3.13.2 (Secure architecture) is preparing to relegate all its printers and IoT devices to a separate Virtual Local Area Network (VLAN) to promote network segmentation (which is an attribute of secure IT architecture). IT creates a tracking ticket for this proposed change.
At the next weekly meeting the CCB compares the change ticket to the table. The CCB identifies a VLAN change as matching the “Architecture, Topology, Port/Protocol/Service change” scope shown in row #1 of the table above. This means a VLAN change is significant enough to trigger a SIA. The CCB makes some notes about the technical aspects of the change and identifies risks, such as potential for service outage during cutover, and VLAN exposure to network attacks.
Then the CCB directs the IT team (as required by the Mitigations and Necessary Updates column) to make any necessary firewall zone changes to support the new VLAN. The CCB then directs the security team to describe in the security documentation the new (or existing) services that the VLAN will support. The security team must also make any updates to the security artifacts, including system and boundary descriptions in the SSP and especially (as dictated by the Control Families Impacted column) the Configuration Management documentation.
Your organization is rolling out multifactor authentication (MFA) to its covered systems so it can comply with NIST control 3.5.3. IT creates a tracking ticket for this proposed change.
At the next weekly meeting the CCB compares the change ticket to the table. The CCB identifies an MFA implementation as matching the “Identification, Authentication, Authorization; New methods for authentication and/or identifiers added; Migrations between Single Factor and MFA” scope shown in row #2 of the table above. This means rolling out MFA is a significant enough change to trigger a SIA. The CCB makes some notes about the technical aspects of the change and identifies risks, such as the fact that MFA means some users may need technical training on how to use the MFA system.
Then the CCB directs the IT team (as required by the Mitigations and Necessary Updates column) to test the MFA to ensure it works properly and doesn’t affect other control implementations.
The CCB then directs the security team to make any updates to the security artifacts, including system and boundary descriptions in the SSP and especially (as dictated by the Control Families Impacted column) the Identification and Authentication documentation.
Your organization patches Windows workstations and servers monthly. If you download our template that has the full table, you’ll notice simply patching system components doesn’t match any of the triggering criteria. System patching is considered routine maintenance and not significant enough to trigger an SIA.
On the other hand, let’s say your organization is ready to upgrade all Windows 10 workstations to Windows 11. IT creates a tracking ticket for this proposed change.
At the next weekly meeting the CCB compares the change ticket to the table. The CCB identifies an MFA implementation as matching the “Change in Operating System” scope shown in the last row of the table above. This means updating an Operating System is a significant enough change to trigger a SIA. The CCB makes some notes about the technical aspects of the change and identifies risks, such as the fact that current Windows 10 hardening configurations may not be adequate for Windows 11.
Then the CCB directs the IT team (as required by the Mitigations and Necessary Updates column) to — since the OS versions are significantly different versions — harden the workstations and, at minimum, perform vulnerability and configuration scans on them.
The CCB then directs the security team to make any updates to the security artifacts, including system and boundary descriptions in the SSP and especially (as dictated by the Control Families Impacted column) the Configuration Management, Risk Management, and Security Assessment documentation.
Documenting the Security Impact Analysis for CMMC compliance
To ensure the Security Impact Analysis process is effective (and that the organization can pass a CMMC assessment!), the stakeholders must document the SIA process. The process documentation need not be lengthy; it can all be done within the IT ticket that captures the proposed change. In fact, that’s how we do it. We use Microsoft Planner as our IT ticketing and change management system, and it works great. We capture notes on the SIA process in the ticket itself. The image below shows an example of our ticket as we implement multifactor authentication on our workstations (the green boxed section contains notes on our SIA process):
There’s really not much to it, but with this simple process we’ve:
- Acknowledged the fact that MFA implementation has a security impact,
- Described the mitigations we will take to lessen that impact, and
- Updated our security documentation to describe the implementation and necessary security changes.
Your organization really doesn’t need to do more than that to implement 800-171 control 3.4.4. Don’t make Security Impact Analysis more complicated than it needs to be; CMMC doesn’t give you brownie points for complicated processes. That’s not to say you can’t edit the SIA process and/or table as you see fit; you certainly may. While we wouldn’t recommend deleting any of the triggers from the table, you can certainly add to or modify it to suit your organization’s needs.
Wrapping up
In this post we explained why the DoD requires contractors to perform Security Impact Analysis and we identified that we’ll be held accountable for doing so by the CMMC. We then explained what an SIA is and how small businesses can perform SIA simply. We also gave some examples of SIA, including one of our own, and make available for download a document that includes an SIA process description and the SIA trigger table.
SIA is a crucial part of good cybersecurity as well as CMMC compliance. Our CMMC Compliance Roadmap provides insight into the other steps small business DIB members will need to take to be considered “Cybersecurity DIB Ready”. We also talk about SIA and all things DFARS, NIST, and CMMC-related in our quarterly Workshops. We’d love to have you and/or your IT staff with us in the next one!
–Good Hunting!
Adam
