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.
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.
There are a number of changes that can impact a system. Below are the changes that would warrant the completion of a SIA.
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.
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:
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.
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:
A brief overview of information about the proposed change. The completion of this section will make identification easier for future record keeping/compliance efforts.
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.
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:
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.
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.
The SIA and associated documentation may highlight the need for future actions including:
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.
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:
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:
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 |
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.
ISRA updates, potential PIA update, CFACTS system description updates.
Potential SORN updates.
New revisions of ARS and CMS policy; or Issue or Update of NIST documents
Potential impact to multiple controls depending on nature of the policy/
standards.
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
Implementation or inheritance of new services
Updates to FISMA artifacts must be made, including SSP, XLC System Slides, CFACTS Boundary information, etc
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
List specific controls changed
PL-2 (SSP)
CM-2, CM-3, CM-4
SI-10
CM-2, CM-3, CM-4, CM-6, CM-7
PL-2 (SSP)
HW/SW List
AC-19, SI-4
CP-2
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
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
New Support Software
CM-2, CM-3, CM-4, CM-6, CM-7
RA-5
PL-2 (SSP)
HW/SW List
Potential TRB review/approval
CM-2, CM-3, CM-4
PL-2 (SSP)
HW/SW List
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
PE(family)
CM-2, CM-3, CM-4, CM-6, CM-7
PE(family)
CM-2, CM-3, CM-4, CM-6, CM-7
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 |
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.
Signed by: