Please enable JavaScript.
Coggle requires JavaScript to display documents.
NIST RMF (CONTROL IMPLEMENTATION (Develop the System Security Plan (SSP) -…
NIST RMF
- Develop the System Security Plan (SSP) - NIST SP 800-18
- Develop the Configuration Management Plan (CMP) - NIST SP 800-128
- Implement the Finally Selected Security Controls
- Contingency Plan (CP) - NIST SP 800-34
- Contingency Plan Test - NIST SP 800-84
- CATEGORIZATION - FIPS 199/SP 800-60 V2 R1 (Initiation Phase)
- After kick-off meeting, you conduct an Initial Risk Assessment to Identify System Threats, Vulnerabilities and Impact. You do this to support your system categorization efforts or to reach the overall categorization level for the system.
- At the end of the Initial Risk Assessment, you complete a Risk Assessment Report (RAR) This is the 2nd Deliverable in this phase
- Begin with a Kick-Off Meeting
-
- Finally, determine the System Category (LOW, MODERATE, HIGH) - NIST SP 800-60
- SECURITY CONTROL TESTING (NIST SP800-53A)
- Test Plan/Security Assessment Plan (SAP)
- Security Control Assessment(SCA)/Security Test and Evaluation (ST&E)+Report
- Test the controls for their adequacy and effectiveness. This is done by the SA&A analyst. This phase is basically the domain of external auditors. There are artifacts or deliverables to be created in this phase. See below.
- Security Assessment Report (SAR)/Plan of Action and Milestones (POAM)
- CONTROL SELECTION - FIPS 200/SP 800 - 53 Rev 4 (Initiation Phase)
- Tailor the Baseline Controls Selected to the System
-
- Select Baseline Controls based on the System Classification
-
-
- Remember: Federal Systems are categorized based on the potential impact levels of a breach to the Security Objectives (CIA) of the Information they store, process or transmit
- NIST PUBLICATION: SP 800-30 Rev 1 (Guide for conducting Risk Assessment) and SP 800-37 (Guide for Applying RMF to Federal Information Systems)
- Risk Assessment is conducted through Examination (Review, Observe, Walkthrough -R.O.W), Interview and Testing
- *Meeting Agenda includes: System/Authorization boundary, Documentation needed, FIPS 199 Security Categorization (SP800-60 Information Type), Security Assessment Key Milestones, Potential Assessment Dates, e-Auth Threshold Analysis/e-Auth Risk Assessments, PIA, CP and CP test dates*
- Support Roles:** System Owner, ISSO, Info Owner, AO, System Devs/Admins, SA&A Analyst
-
-
-- when the system collects, maintains or disseminates PII
-
(Analysis of the risk and impact of a system that handles PII, and how that PII is protected. Ensures handling conforms to applicable Legal, Regulatory, and Policy Requirements of Privacy)
-
- Per NIST SP 800-122, PTAs are used to determine if:
-
-
-
-
-
-- Required if the PII contained in the system is retrieved by a Personal Identifier (e.g SSN, DOB, an ID# that can be traced back to an individual)
-- Used to provide notice to members of the public that their Personal Information is being used by the agency
-
-- Agencies must submit an ICR and obtain an OMB Electronic Collection Approval (OMB Control Number) for an IT System b4 using the system to collect info from 10 or more members of the public
-
-
-
-
-
-
-
-
-
-
-
-
-- Selecting control based on e-authentication technical guidance (1 Factor, 2 Factor or Multi Factor)
-
-
-
Per OMB Memoradum 10-23, agencies are required to conduct a PIA, to ensure their use of 3rd Party Websites and Apps, protects Privacy
-
-- Examining the 3rd Party's Privacy Policy to evaluate the risk and to ensure the webiste/app is appropriate for the Agency's use
-- Providing an alert to users of agency websites for links that lead to a location other than the official government domain
-
-
-- The Initial Risk Assessment and any other applicable Deliverables/Artifacts should help you identify all the Information Types the System stores, processes, and/or transmits.
-- Categorize the System based on the overall High Water Mark of the various categories of the Information Types Identified
-
-
-
-
-- Identify controls that are "Not Applicable", "Common", "System Specific", or "Hybrid (e.g AT-2. Security Awareness Training can be owned by HR/System Owner)"
-
-
-- NIST 800-53 Rev 4 contains 26 control families (Technical, Management, Operational and Privacy)
--SA&A Analyst do not implement the recommended controls, but have other deliverables they need to complete. Implementation is done by a system engineer, admin, or a different team.
-- Implementation of recommended controls are done according to NIST Control Objectives/Requirements
-
-
- System Information Section (Description, Categorization, E-Authentication, System Diagram)
- Security Control Section (Describes the Security Controls that are in use or plan to be used to protect all aspects of the system)
- Terms used to describe statuses of Security Controls
-- "Implemented/In Place", "Partially Implemented", "Inherited", "Not Applicable"
-- Documents all the benchmark/baseline configurations for the system. (E.g benchmarks include DISA STIGs (DoD), CIS Benchmarks)
-
-
ii. Change Control Process: Defines changes to be made, how changes are requested, approved, and implemented
iii. Configuration Status Accounting: This is the recording and reporting of information needed to manage a system's configuration effectively (e.g
- approved configuration
- status of changes, deviations, and waivers,
- implementation status of approved changes etc)
iv. Configuration Verification and Audit: An independent review of system configuration for compliance with established requirements (e.g the US Government Configuration Baseline - USGCB or Federal Desktop Core Configuration - FDCC*
- Note: You can use scanning tools that are USGCB or FDCC compliant like NESSUS, SAINT, etc to help detect whether a system or software is implemented according to US Government requirements.
-
- Security Impact Analysis (SIA(CM-4))
-- An analysis performed to prior to a change to determine the security impact of the change, which controls the change will affect, the risk associated with the change etc.
- May include:
-- Reviewing Security Plans to understand Security Control requirements.
-- Reviewing System Design documentation to understand control implementation and how specific changes
-- Risk Assessment to understand impact of the changes and to determine whether additional controls are required after change.
- Risk Acceptance Memo/Waiver
-- A memo that must be created and approved, documenting risks or vulnerabilities to which a Security Control cannot be provided. This memo also contains the justification for accepting the risk and any compensating controls. Usually completed by System Owner or PM
- Plan B in case of an unplanned event
-- B4 creating a Plan B, an organization must perform a Business Impact Analysis (BIA) to identify and prioritize business units and assets
-- When performing BIA, you'll have to determine Recovery Point Objective (RPO) and Recovery Time Objective (RTO)
- Components/Phases of Contingency Plan
-
-
-
-
- After creating your CP, you'll need to test it.
-
-
-
-
- CP needs to tested at least annually or whenever there is a major change, for effectiveness. CP is a living document and needs to be updated often.
- After you test your CP, you'll have to complete an "After Action Report". This documents any changes to the CP
-
- System Interconnection (CA-3) Sp 800-47
- Interconnection Security Agreement (ISA)
- Memoradum of Understanding/Agreement (MOU/A)
-
- Incident Response/Handling (SP 800-62)