Security Impact Analysis (SIA) Template - CMS



Security Impact Analysis (SIA) TemplateWhat is a Security Impact Analysis (SIA)?The Security Impact Analysis is a process to determine the effect(s) a proposed change can cause to the security posture of a FISMA system. Conducting a SIA is a mandatory process for all changes. Per CMS Acceptable Risk Safeguards (ARS) 3.1 control CM-4: The organization analyzes changes to the information system to determine potential security and privacy impacts prior to change implementation.The depth and intensity of a SIA (along with associated documentation) varies directly with the scope of a proposed change. The SIA may require little time, or it may entail a detailed process, with security testing, scans, etc. The key “deliverable” of a SIA is to determine the impact the change can have on a system’s security posture. Documentation provides a secondary, but useful purpose.Results from the SIA must be shared with and acknowledged by the system’s Business Owner and System Maintainer.SIA PurposeThe SIA process articulates how changes to the system may affect the security posture of the system. Documentation chronicling the SIA provides insight to the development team, ISSO, Business Owner, and other key stakeholders.The SIA and associated documentation may highlight the need for future actions including:Communication with the Technical Review Board (TRB); Updates to Security Artifacts (SSP, ISRA, CP, PIA, etc);Determination if Third Party security testing will be required;The potential requirement for a new Authority to Operate (ATO).SIA documentation may serve as a “to-do” list for ISSOs 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 documentation, if properly tailored, is 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. SIA documentation may serve as evidence of system compliance.Examples of Changes Where an SIA is Appropriate 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 specifically noted as being excluded in each organization’s Configuration Management Plan (CMP). If there is an anticipated change not so noted in your organization’s CMP, perform a SIA.Event-Driven Triggers and Significant ChangesNIST 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 substantively affect the security or privacy posture of a system. 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 platformModifications to how information, including PII, is processed; Modifications to cryptographic modules or services;Changes in information types processed, stored, or transmitted by the system; orModifications 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; or 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.ReferencesNIST SP 800-37 Rev. 1 under Security Impact AnalysisCNSSI 4009-2015 (NIST SP 800-37 Rev. 1)NIST SP 800-137 under Security Impact Analysis (NIST SP 800-53)NIST SP 800-30 Rev. 1 under Security Impact Analysis (NIST SP 800-37)NIST SP 800-39 under Security Impact Analysis (NIST SP 800-37)NIST SP 800-53 Rev. 4 under Security Impact Analysis (CNSSI 4009)NIST SP 800-18 Rev. 1 under Security Impact Analysis (NIST SP 800-37)NIST SP 800-53A Rev. 4 under Security Impact Analysis (NIST SP 800-37)NIST SP 800-128 under Security Impact Analysis (CNSSI 4009 - Adapted) SIA Template InstructionsHow to use this document. 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, 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, reference 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 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 and the ISSO may at any time require a formal SIA for any change.Post change. This 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.<FISMA SYSTEM NAME> < PRODUCT/FEATURE NAME> <DATE OF RELEASE TO PROD>Section 1: Change Information ElementDescriptionCR NumberClick here to enter text.CR Submitter (Contact Information)Click here to enter text.System/Application/ToolClick here to enter text.Description of System Change(This must be a detailed description that includes the Drivers for the change)Click here to enter text.If applicable, provide the details of the change if the SIA is dependent on a Change Request (CR).ElementDescriptionCR NumberClick here to enter text.CR Submitter (Contact Information)Click here to enter text.Section 2: Technical Representative InformationIf a technical representative of the ISSO is performing this assessment on behalf of the ISSO, please provide your contact information. ElementDescriptionRepresentative performing the SIAClick here to enter text.Title of Representative performing the SIAClick here to enter text.DateClick here to enter text.PhoneClick here to enter text.EmailClick here to enter text.Section 3: Trigger Actions and Events EvaluationDirections: 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)CategoryScope of ChangeMitigation or Necessary UpdatesARS Controls ImpactedSummary of Security Impact/ Technical Overview/ Risks IdentifiedMission/ Business requirementsNew Users orNew User Roles AddedISRA updates, potential PIA update, CFACTS system description updates.AC-2, AC-6Mission/ Business requirementsChange in data collection, storage, sharingPIA update.Potential SORN updates.AC-21, AP-1, AR-2, AR-8, DM-2, SE-1, TR-1, UL-1Mission/Business requirementsCessation of mission or function.Potential update to SSP, CFACTS system description updates. Potential impact to multiple controls depending on nature of mission/function. Policy/StandardsNew revisions of ARS and CMS policy; or Issue or Update of NIST documentsUpdates to FISMA artifacts including SSP.Potential impact to multiple controls depending on nature of the policy/standards.Laws, Regulations, DirectivesNew or ChangedUpdates to FISMA artifacts including SSP. Potential impact to multiple controls depending on nature of laws, regulations, directives.System boundaryInterconnections and New connection to FISMA system or ServiceUpdates 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, etcAC-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-4System boundaryArchitecture, Topology, Port/Protocol/Service changeZone changesImplementation or inheritance of new servicesUpdates to FISMA artifacts must be made, including SSP, XLC System Slides, CFACTS Boundary information, etcCM-2, PL-2, PL-8, SA-3, CM-6, CM-8, CM-9, SA-10, PM-5, PM-7Security componentsIdentification, Authentication, AuthorizationNew methods for authentication and/or identifiers addedMigrations between Single Factor and MFANew 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, etcIA (all)Security ComponentsSecurity Controls – Change in implementation standard or statusNew 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 changedPL-2 (SSP)User InterfaceUpdates to GUI including addition of new pages, new inputsNew 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-4SI-10New or Updated HardwareServers, Communication DevicesIf 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-7PL-2 (SSP)HW/SW ListAC-19, SI-4CP-2New or Updated Operating SystemChange in Operating SystemIf 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-7RA-5 Vulnerability ScanningCA-9(1) Compliance ChecksPL-2 (SSP)HW/SW ListCP-2New or Updated Security SoftwareNew Security Software or Perimeter Security ChangeIf 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-7RA-5 Vulnerability ScanningCA-9(1) Compliance ChecksPL-2 (SSP)HW/SW ListPotential impact to multiple controls depending on nature of softwareSupport SoftwareNew 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-7RA-5PL-2 (SSP)HW/SW ListPotential TRB review/approvalVendor PatchesSoftware, ServersSoftware 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-4PL-2 (SSP)HW/SW ListSystem BoundaryChange to Logical Access PointsVulnerability Scan is requiredAC-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-4Vulnerability (New or Existing)Attacks DevelopedRisk 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-11Vulnerability (New or Existing)Attacks Succeed ElsewhereRisk 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-11Vulnerability (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-11System boundaryNew 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 attacksPE(family)CM-2, CM-3, CM-4, CM-6, CM-7System boundary (environment)Change or Addition of Hosting Infrastructure or SiteFull 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-7Section 3: Validation/Security TestingPlease 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 /MethodTesting FrequencyTest Result LocationNotesCompliance ScansVulnerability ScansDynamic WAPT TestingStatic WPT TestingOptionalOptionalSection 4: Overall Recommendation for Business OwnersUsing 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): Deploy to Production Environment without additional testing FORMCHECKBOX Undergo Targeted Third Party Security Testing FORMCHECKBOX Undergo SCA/ACT FORMCHECKBOX Require Business Owner Risk Acceptance to field to Production FORMCHECKBOX Apply for a new ATO FORMCHECKBOX Other (e.g. update documentation. Specify on following page) FORMCHECKBOX Business Owner Acknowledgement:Optional Diagrams/Images/Information Highlighting the Changes/NotesOn this page provide diagrams/images of the changes or embed into document to assist with understanding the scope of impacts. This can include updates versions of the XLC/TLC System Diagrams. This may also include any results from validation/security testing or a description of other ISSO recommendations. Recommendations not noted elsewhere can also be included here. ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download