• 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

A - Privacy Impact Assessment (PIA) (SP 800-122)

B - Privacy Threshold Analyses (PTA) (SP 800-122)

-- when the system collects, maintains or disseminates PII

-- before the electronic collection of PII for 10 persons or more - Paperwork Reduction Act(PRA)

(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)

Required:

• Per NIST SP 800-122, PTAs are used to determine if:

-- a system contains PII

-- a PIA is required

-- a SORN is required

-- any other Privacy Requirements apply to the Information System

C - System of Records Notice (SORN)

-- 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

D - Information Collection Request (ICR)

-- 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

• Agencies must:

-- Identify purpose of the collection

-- Develop a plan for use

-- Test the collection method via a pilot program

-- Estimate the paperwork burden

-- Publish a SORN

-- Specify whether response is voluntary

E - Electronic Authentication (SP 800-63)

-- Required when a system is accessible remotely

Involves the following:

-- Conducting a Risk Assessment of the System

-- Mapping identified risks to applicable assurance levels

-- Selecting control based on e-authentication technical guidance (1 Factor, 2 Factor or Multi Factor)

-- Validating the implemented control achieves the required assurance level

-- Periodically reassess the system to determine to technology refresh requirement

F - 3rd Party Websites/Application PIA

Per OMB Memoradum 10-23, agencies are required to conduct a PIA, to ensure their use of 3rd Party Websites and Apps, protects Privacy

This is includes:

-- 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

-- Disclosing use/involvement of embedded 3rd party applications on government website

-- Applying appropriate branding to distinguish agency's activities from nongovernment entities

-- 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

-- Reference NIST SP 800-60 Vol 1 and SP 800-60 Vol 2 Rev 1 Appendix C and D

-- Use NIST SP 800-53 Rev 4 as guide (See Appendix B)

-- This inital baseline control is considered a draft

-- Review the baseline controls with the ISSO/System Owner

-- 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)"

-- Finalize the control selection

-- Some organizations use the SANS/CIS TOP 20 Controls instead of NIST SP 800-53 Rev 4

-- 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

-- The SSP is the most important document in this phase

-- Contains 2 Major Sections

• 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)

• Includes:

i. Configuration Identification: System settings and baselines b4 deployment

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

-- Initiation Phase

-- Activation Phase

-- Recovery Phase

-- Reconstruction Phase

• After creating your CP, you'll need to test it.

• Types of CP Tests

-- Tabletop/Classroom Exercise

-- Simulated/Functional Exercise

-- Full Test/Partial Test/Parallel Test

• 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)

• Data Use Agreement (DUA)

• Incident Response/Handling (SP 800-62)