Security Impact Analysis (SIA)
A process to determine the effect(s) a change can cause to the security posture of a FISMA system
CMS Slack Channel- #security_community
What is a Security Impact Analysis (SIA)
A Security Impact Analysis (SIA) is an assessment that reviews how a proposed change can impact the security and privacy posture of a FISMA system. It is a mandatory process that is required for all system changes. The SIA maps directly to the CMS Acceptable Risk Safeguards (ARS) 5.0 Configuration Management (CM) Control.
Who completes the SIA
The SIA is initiated by the Information System Security Officer (ISSO) or a designated team member if an ISSO is not available. The ISSO will work with the System/Business Owner and other relevant CMS staff and contractors to complete the SIA.
What changes to a system require an SIA?
There are a number of changes that can impact a system. Below are the changes that would warrant the completion of a SIA.
- Changes to existing architecture, system, network, application, security boundary, or environment
- Changes made to environments below the production environment (PROD) that will eventually be implemented in PROD
- New data types, or new connection to data source, system, service, or association
- Software or service solutions that are new to the system; especially those that are new to CMS and have yet to be approved under any CMS ATO or FedRAMP
Note: NIST Special Publication 800-128 “Guide for Security-Focused Configuration Management of Information Systems” indicates that the change management process (and by extension, Security Impact Analysis) is not required for changes that are expressly noted as being excluded in each organization’s Configuration Management Plan (CMP). If an anticipated change has not been noted in your organization’s CMP, you will need to perform an SIA.
Events that require a SIA
NIST Special Publication 800-37 Rev 2 “Risk Management Framework for Information Systems and Organizations” defines a significant change as a change that is likely to affect the security or privacy posture of a system substantively. Significant changes to a system that may trigger an event-driven authorization action may include, but are not limited to:
- Installation of a new or upgraded operating system, middleware component, or application
- Modifications to system ports, protocols, or services
- Installation of a new or upgraded hardware platform
- Modifications to how information, including PII, is processed
- Modifications to cryptographic modules or services
- Changes in information types processed, stored, or transmitted by the system
- Modifications to security and privacy controls (e.g. identity and access management)
- Significant changes to the environment of operation that may trigger an event-driven authorization action may include, but are not limited to:
- Moving to a new facility
- Adding new core missions or business functions
- Acquiring specific and credible threat information that the organization is being targeted by a threat source
- Establishing new/modified laws, directives, policies, or regulations
Note: The examples of changes listed above are only significant when they represent a change that is likely to affect the security and privacy posture of the system.
What documentation is required?
The depth and intensity of your SIA varies significantly depending on the scope of the proposed change. Consider your SIA as a holistic process that will benefit the security of your system over time rather than a compliance exercise you must complete to move forward.
Your SIA may require limited documentation or it may be a detailed process that results in security testing, scans, and data reviews. Sometimes, information that surfaces about a system change during the SIA process can result in other documents and tests needing to be updated. This is part of the process required to keep your system secure.
Regardless of the significance of the change to a system, the analysis and outcomes must be documented. You can choose to utilize the Security Impact Analysis (SIA) Templatefor this purpose, or you can use a custom template that has been created for your system's specific needs. If you choose to use the generic CMS SIA Template, you will find it at the end of this page and will need to complete four sections:
Change information
A brief overview of information about the proposed change. The completion of this section will make identification easier for future record keeping/compliance efforts.
Technical representative information
The contact information for the ISSO or responsible party managing the system. The ISSO is the individual responsible for the completion of all actions related to the SIA even if a designated representative completes the paperwork on their behalf.
Trigger actions and events evaluation
An extensive list of “Trigger Events”. This section is the heart of the assessment. You will be prompted to answer a number of “yes or no” questions related to the change. To complete this section, you’ll need to review:
- The scope of the change
- The necessary updates or mitigation efforts
- The ARS controls impacted by the change
If the change you’re proposing is related to the installation of an application or tool that has been pre-approved by FedRAMP on cloud.cms.gov, much of this information will be provided for you there. You’ll often find much of this information on the website of the company that created the application. For further help in determining system risk for new applications, you can always reach out to your Cyber Risk Advisor (CRA) for guidance.
Recommendations for Business Owners
This final section provides a detailed list of the results of the SIA and recommendations from the ISSO to the System/Business Owner. SIA documentation may serve as a “to-do” list for ISSOs and System/Business Owners to make sure that documentation is updated appropriately, tests performed for identified controls, etc. It may also help justify further testing and potentially expensive processes to the Business Owner.
SIA outcomes
The SIA and associated documentation may highlight the need for future actions including:
- Communication with the Technical Review Board (TRB)
- Updates to security artifacts like the System Security and PrivacyPlan (SSPP), Information Security Risk Assessment (ISRA), Contingency Plan (CP), Privacy Impact Assessment (PIA), among others
- Determination if third party security testing will be required
- The potential requirement for a new Authority to Operate (ATO)
SIA documentation, if properly tailored, is also particularly useful for a DevSecOps environment where multiple changes may occur within a relatively short time-frame and the ISSO can reuse existing documentation to quickly make any updates necessary.
Security Impact Analysis (SIA) Template
SIA Template Instructions
This template provides a suggested methodology to help ISSOs assess the potential security impact of a change or changes to FISMA systems.Individual ISSOs may find it necessary to alter the template to meet their organizational needs.Workflow associated with this template is also dependent on organizational requirements.
This template consists of four sections.They are:
Section 1 – An overview of the proposed change.If this document is maintained for record keeping/compliance, the completion of this section will make identification easier in the future.
Section 2 – Information on who is performing the SIA if a technical representative of the ISSO is performing the assessment on behalf of the ISSO.If a technical representative of the ISSO has performed this assessment, they will forward it to the ISSO for discussion and review.It remains the ISSO’s responsibility to complete all appropriate actions.
Section 3 – An extensive list of “Trigger Events”, most of which are a decomposition of the boxes checked in Section 2. This section is the heart of the assessment.To complete this section:
- The assessor examines each event under “Scope of Change” (column 2).
- If an event is part of the potential change, enter a “Y” under “Impact Y/N” (column 1).
At this point, an elaboration of the events noted is included in the section “Summary of Security Impact/ Technical Overview/ Risks Identified”.This includes detailing the technical overview of the item and a description of the potential impact and risk.Where other data associated with the change is available such as scan information, references should also be included in this area.
Section 4 – The ISSO recommendation to the Business Owner on the overall status of the change and what actions are necessary.This section should function as a high-level summarization of the necessary activities determined in Section 3 “Mitigation or Necessary Updates” and “Summary of Security Impact/Technical Overview/Risks Identified”.
Note that the “Mitigation or Necessary Updates” area within Section 3 provides recommended actions.Actions may individually or as a group indicate the requirement for a new ATO.At this point, the ISSO may choose to consult with their Cyber Risk Advisor or Privacy Advisor prior to providing the recommendation of activities to the Business Owner and System Maintainer.
Though every change requires a SIA, organizations may utilize their own internal methods or processes that can automate or streamline the security analysis rather than using a formal SIA form.
These types of changes may include processes for configuration control such as vendor-provided security patches, updated antivirus signatures, creation, or deletion of users, replacement of defective peripherals, motherboard or hard drives, etc.Processes associated with similar functions, may have built-in security components or controls that may not require a formal SIA form.Any of these processes -- whether automated or manual -- must capture the elements needed to properly analyze the security impacts of the particular change. The ISSO may at any time require a formal SIA for any change.
The SIA document, when completed and shared with the Business Owner, can be used as a checklist to make sure that any work such as documentation changes are performed.
To create your SIA document, start with the following for a title:
<FISMA SYSTEM NAME> < PRODUCT/FEATURE NAME> <DATE OF RELEASE TO PROD>
Section 1: Change Information
| Add information in this column | |
|---|---|
| CR Number | |
| CR Submitter (Contact Information) | |
| System/Application/Tool | |
| Description of System Change (Detailed description that includes the Drivers for the change) |
|
Section 2: Technical Representative Information
If a technical representative of the ISSO is performing this assessment on behalf of the ISSO, please provide your contact information.
| Add information in this column | |
|---|---|
| Representative performing the SIA | |
| Title of Representative performing the SIA | |
| Date | |
| Phone | |
Section 3: Trigger Actions and Events Evaluation
Directions: Please complete the table below by indicating Y/N if a particular security event occurs and entering a description of the summary of security impacts/technical overview/risks identified. Highlight any rows where a possible significant change is detected. The ARS Controls impacted column is not all-inclusive.Note: this list is not all-inclusive.
| Impact? (Y/N) | Category | Scope of Change | Mitigation or Necessary Updates | ARS Controls Impacted | Summary of Security Impact/ Technical Overview/ Risks Identified |
|---|---|---|---|---|---|
| Mission/ Business requirements | New Users or New User Roles Added | ISRA updates, potential PIA update, CFACTS system description updates.
| AC-2, AC-6 | ||
| Mission/ Business requirements | Change in data collection, storage, sharing | PIA update. Potential SORN updates.
| AC-21, AP-1, AR-2, AR-8, DM-2, SE-1, TR-1, UL-1 | ||
Mission/ Business requirements | Cessation of mission or function. | Potential update to SSP, CFACTS system description updates. | Potential impact to multiple controls depending on nature of mission/function. | ||
Policy/ Standards | New revisions of ARS and CMS policy; or Issue or Update of NIST documents
| Updates to FISMA artifacts including SSP. | Potential impact to multiple controls depending on nature of the policy/ standards. | ||
| Laws, Regulations, Directives | New or Changed | Updates to FISMA artifacts including SSP. | Potential impact to multiple controls depending on nature of laws, regulations, directives. | ||
| System boundary | Interconnections and New connection to FISMA system or Service | Updates to ISA and MOU must occur. If not standard connection service/inheritance from another accredited FISMA system, SCA will be required.
Updates to FISMA artifacts must be made, including SSP, XLC/TLC System Slides, CFACTS Boundary information, etc | AC-4, CA-3, CA-9, PL-2, AC-3, AC-20, AU-2, AU-12, AU-16, CA-7, IA-3, SA-9, SC-7, SI-4 | ||
| System boundary | Architecture, Topology, Port/Protocol/Service change | Zone changes Implementation or inheritance of new services Updates to FISMA artifacts must be made, including SSP, XLC System Slides, CFACTS Boundary information, etc | CM-2, PL-2, PL-8, SA-3, CM-6, CM-8, CM-9, SA-10, PM-5, PM-7 | ||
| Security components | Identification, Authentication, Authorization
New methods for authentication and/or identifiers added
Migrations between Single Factor and MFA | New and modified control implementations must be tested. SCA required unless inheriting from existing FISMA system.
Updates to all FISMA artifacts must be made, including SSP, XLC/TLC System Slides, CFACTS Boundary information, etc | IA (all) | ||
| Security Components | Security Controls – Change in implementation standard or status | New and modified control implementations must be tested via existing security processes. All changes must be documented within the SSP and the Controls tab within CFACTS. Changes in controls that cause controls to no longer be “Satisfied” must be submitted as a POA&M and documented within the ISRA. | List specific controls changed
PL-2 (SSP) | ||
| User Interface | Updates to GUI including addition of new pages, new inputs | New pages must go through 508 testing, Static and Dynamic code analysis to determine no additional threats from XSS or other new vulnerabilities. | CM-2, CM-3, CM-4
SI-10 | ||
| New or Updated Hardware | Servers, Communication Devices | If the equipment is updated with similar vendor and models, then minimal testing may be needed. However, if they are new models or vendors, with different configurations and settings, then it is considered a significant change. Equipment will need to be hardened, and at minimum, have vulnerability and configuration scans performed on them. | CM-2, CM-3, CM-4, CM-6, CM-7
PL-2 (SSP)
HW/SW List
AC-19, SI-4
CP-2 | ||
| New or Updated Operating System | Change in Operating System | If the software is updated with similar vendor and versions, then minimal testing may be needed. However, if they are significantly different versions (i.e.., not an “incremental version update”) or different vendors, with different configurations and settings, then it is considered a significant change. Affected systems will need to be hardened and, at minimum, have vulnerability and configuration scans performed on them. | CM-2, CM-3, CM-4, CM-6, CM-7
RA-5 Vulnerability Scanning
CA-9(1) Compliance Checks
PL-2 (SSP)
HW/SW List
CP-2 | ||
| New or Updated Security Software | New Security Software or Perimeter Security Change | If the software is updated with similar vendor and versions, then minimal testing may be needed. However, if they are significantly different versions (i.e.., not an “incremental version update”) or different vendors, with different configurations and settings, then it is considered a significant change. Affected systems will need to be hardened and, at minimum, have vulnerability and configuration scans performed on them. | CM-2, CM-3, CM-4, CM-6, CM-7
RA-5 Vulnerability Scanning
CA-9(1) Compliance Checks
PL-2 (SSP)
HW/SW List
Potential impact to multiple controls depending on nature of software | ||
| Support Software | New Support Software
| If the software is updated with similar vendor and versions, then minimal testing may be needed. However, if they are significantly different versions (i.e.., not an “incremental version update”) or different vendors, with different configurations and settings, then it is considered a significant change. Affected systems will need to be hardened and, at minimum, have vulnerability and configuration scans performed on them. | CM-2, CM-3, CM-4, CM-6, CM-7 RA-5
PL-2 (SSP)
HW/SW List
Potential TRB review/approval | ||
| Vendor Patches | Software, Servers | Software patch updates that cause the baseline configuration, or security controls implementations, to change will need a re-authorization. All Software upgrades need to be tested pre-launch to prevent any issues. Affected systems will need to be hardened and, at minimum, have vulnerability and configuration scans performed on them. | CM-2, CM-3, CM-4
PL-2 (SSP)
HW/SW List |
| |
| System Boundary | Change to Logical Access Points | Vulnerability Scan is required | AC-17, AC-2, AC-3, AC-18, AC-19, AC-20,
CA-3, CA-7,
CM-8, IA-2, IA-3, IA-8, MA-4, PE-17, PL-4, SC-10, SI-4 | ||
| Vulnerability (New or Existing) | Attacks Developed | Risk Assessment update, additional work as required. New and modified control implementations must be tested as part of the Configuration (Change) Management processes. | RA-2, RA-3, CM-8, MP-4, SC-7, SI-2, CA-2, CA-7, CM-3, CM-5, CM-8, MA-2, IR-4, RA-5, SA-10, SA-11, SI-11 | ||
| Vulnerability (New or Existing) | Attacks Succeed Elsewhere | Risk Assessment update, additional work as required. New and modified control implementations must be tested as part of the Configuration (Change) Management processes. | RA-2, RA-3, CM-8, MP-4, SC-7, SI-2, CA-2, CA-7, CM-3, CM-5, CM-8, MA-2, IR-4, RA-5, SA-10, SA-11, SI-11 | ||
| Vulnerability (New or Existing) | Found (No Attacks Known) | Add to Risk Assessment. New and modified control implementations must be tested as part of the Configuration (Change) Management processes. | RA-2, RA-3, CM-8, MP-4, SC-7, SI-2, CA-2, CA-7, CM-3, CM-5, CM-8, MA-2, IR-4, RA-5, SA-10, SA-11, SI-11 | ||
| System boundary | New processing location(s) | A new processing location will need to go thru an re-authorization to ensure the system is secure from any issues or attacks | PE(family)
CM-2, CM-3, CM-4, CM-6, CM-7 | ||
| System boundary (environment) | Change or Addition of Hosting Infrastructure or Site | Full authorization of the GSS is required. New and modified control implementations (for applicable applications) must be tested as part of the Configuration (Change) Management processes. Application obtains a new/updated ATO. | PE(family)
CM-2, CM-3, CM-4, CM-6, CM-7 |
Section 3: Validation/Security Testing
Please provide validation/security testing process as they relate to the change or any additional testing being done pertaining to this specific change.
| Tool/Scan Type | (Y/N) | Testing Performed by | Testing /Method | Testing Frequency | Test Result Location | Notes |
|---|---|---|---|---|---|---|
| Compliance Scans | ||||||
| Vulnerability Scans | ||||||
| Dynamic WAPT Testing | ||||||
| Static WPT Testing | ||||||
| Optional | ||||||
| Optional |
Section 4: Overall Recommendation for Business Owners
Using the information collected in Section 3: “Mitigation or Necessary Updates” and “Summary of Security Impact/Technical Overview/Risks Identified”, please provide a recommendation to the Business Owner on the status of the change.
ISSO recommendation(s):
ISSO should indicate which of the following are recommended, and provide details using additional pages.
- Deploy to Production Environment without additional testing
- Undergo Targeted Third Party Security Testing
- Undergo SCA/CSRAP
- Require Business Owner Risk Acceptance to field to Production
- Apply for a new ATO
- Other (e.g. update documentation. Specify on following page)
Signed by:
_____________________________________________
System ISSO
_____________________________________________
Business Owner
Related documents and resources
Provides a federally-recognized and standardized security framework for all cloud products and services
Testing and documenting system security and compliance to gain approval to operate the system at CMS
RMH Chapter 5 provides information about the Configuration Management family of controls which determine the risk management requirements for CMS systems