An overview of the NIST Risk Management Framework ISA 652 Fall 2010 FISMA, NIST Style An overview of the NIST Risk Management Framework ISA 652 Fall 2010

About Me… Chad Andersen, CISSP, CAP Currently employed as a Senior Principal with Noblis, a non-profit consulting firm specializing in public interest technology consulting. Supporting a civilian agency’s OCIO, performing security program development, FISMA compliance activities First year MS ISA student, prior graduate work at VT (MS CS), undergrad from JMU (BS CS) Worked a variety of security-related projects from software development to PKI implementation Chad.andersen@noblis.org; cander14@gmu.edu

FISMA NIST was given the responsibility to develop the guidance documentation for implementing FISMA Two primary sources of documentation FIPS – Federal Information Processing Standards NIST Special Publication 800-series http://csrc.nist.gov/

800-37 NIST SP 800-37: Guide for Applying the Risk Management Framework to Federal Information Systems Currently Revision 1 Released February 2010 Defines the risk management framework (RMF) in the context of the SDLC. Significant change from pervious version of 800-37

800-37 Changes No more Certification and Accreditation (C&A). Now referred to as security control assessment and security authorization. Integrated DOD and Intelligence community needs into the process. NIST will replace Director of Central Intelligence Directive (DCID) 6/3 and DIACAP Intelligence Community Directive (ICD) 503 rescinds DCID 6/3 Maps closer to the SDLC than previous version Introduces new roles – Common Control Provider, Risk Executive (Function) No more Interim Authority to Operate (IATO) http://www.onpointcorp.com/documents/NIST_SP_800-37.pdf

800-37 – Roles Key Roles Authorizing Official (AO or DAA – Designated Approving Authority)/ AO Designated Representative (AODR) Chief Information Officer (CIO) Senior Information Security Officer (SISO, SAISO, ITSO, others…) System Owner (SO) Information System Security Officer (ISSO) Security Control Assessor (SCA) Risk Executive (Function) Common Control Provider (CCP)

800-37 Defines the 6 steps of the RMF Categorize the information system Select security controls Implement security controls Assess security controls Authorize information system Monitor security controls * NIST SP 800-37, Guide for Applying the Risk Management Framework to Federal Information Systems, February 2010, Section 2.1.

Categorize the Information System Required by FIPS 199: Standards for Security Categorization of Federal Information and Information Systems Utilize NIST 800-60 - Guide for Mapping Types of Information and Information Systems to Security Categories End result is a system categorization of High, Moderate, or Low across the security triad – Confidentiality, Integrity, Availability Overall categorization of the system is the high watermark of the CIA categorizations Determining the correct FIPS 199 is a CRITICAL step for a successful implementation

Select Security Controls Required by FIPS 200: Minimum Security Requirements for Federal Information and Information Systems Utilizes NIST SP 800-53: Recommended Security Controls for Federal Information Systems and Organizations Uses the FIPS 199 system categorization to drive the selection of the security controls. Uses the high watermark as the baseline for controls Allows for control tailoring, supplementing, and compensating Utilize common controls for cost savings Controls are defined in 17+1 families of controls Common Mistake is skipping the first half of the document and just utilizing the table in Appendix D. Section 3.3 includes very valuable information for success. AO acceptance is critical! Successful Security Control Selection Using NIST SP 800-53, ISSA Journal July 2009 http://www.noblis.org/NewsPublications/Publications/PublicationsandPresentations/Documents/ISSA0709_Using%20NIST%20SP%20800-53.pdf

800-53 Controls are divided into three categories – Technical, Management, Operational 800-53 includes 17 + 1 control families AC – Access Control AT – Awareness and Training AU – Audit and Accountability CA – Security Assessment and Authorization CM – Configuration Management CP – Contingency Planning IA – Identification and Authentication IR – Incident Response MA – Maintenance MP – Media Protection PE – Physical and Environmental Protection PL – Planning PS – Personnel Security RA – Risk Assessment SA – System and Services Acquisition SC – System and Communications Protection SI – System and Information Integrity PM – Program Management – Organizational level controls

Implement Security Controls Relatively straightforward implementation of the security controls and information system development. Utilize NIST SP 800-53 to determine the security control requirements Also use NIST SP 800-53A:Guide for Assessing the Security Controls in Federal Information Systems and Organizations, Building Effective Security Assessment Plans Can provide “derived requirements”. Dirty little secret of the control assessors (auditors). 800-53A is the basis for the test plan

Assess Security Controls NIST SP 800-53A:Guide for Assessing the Security Controls in Federal Information Systems and Organizations, Building Effective Security Assessment Plans Defines the security control test cases for all 800-53 controls. Includes some derived requirements New version – removes “mandate” to perform certain tests. Organization defines the level of testing.

Authorize Information System Develop and maintain a Plan of Action and Milestone (POA&M) for tracking and correcting deficiencies. Risk Executive (person or group) reviews the security assessment package and summarizes the risk posture Presents the risk posture to the AO for acceptance AO Acceptance of risk Authorization to Operate (ATO) – Document any limitations and authorization timeframe. Denial of Authorization to Operate (DATO)

Monitor Information System Perform Continuous Monitoring of the control implementation at least annually. Goal is to assess all controls at least once every three years Some controls may be organizationally mandated to be tested annually – Mostly technical controls or controls requiring annual updates Perform annual risk assessment updates Update System Security Plan (SSP) Update business continuity plan Perform regular vulnerability scanning, penetration testing as required by the organization Report results to the AO for continued risk acceptance Monitoring system changes is critical!

Keys to Success System Boundary Maintain documentation What are you including? Draw your boundary any way you like Implement appropriate boundary controls Interconnections – including neighboring components Maintain documentation SSP, component/software inventory Perform continuous monitoring activities continuously

Keys to Success AO Involvement AO can shut you down! Determining the FIPS 199 Categorization Selecting the Security Controls Tailoring/compensating the controls Budget Holders Authorize the system’s operations AO can shut you down!

Real World Pitfalls It’s just a documentation Exercise? Too much paperwork Never good enough Not enough funding Parent Organization Policies Poor interpretation of NIST guidance – Just ask Ron Ross Inspector General – Zero perceived organizational support, process improvement

Implementing FISMA on Corporate Systems Government acquisition regulations mandate any contractor system processing, storing, or transmitting government data must also follow FISMA and the NIST RMF. Rarely enforced, but on the books nonetheless. However, Government is starting to enforce for large, multi-use information systems, such as cloud computing. Requires contractors to develop a security authorization package, receive government authorization, and implement a security program compliant with NIST.

Problems with NIST on Corporate Systems NIST SP 800-37 Rev 1 states: “The role of authorizing official has inherent U.S. Government authority and is assigned to government personnel only.” Problems AO has budgetary responsibility AO has mission responsibility AO can shut a system down Most contractor systems are mixed – corporate and government data. Solution: Provide more authority to the Information Owner

Problems with NIST on Corporate Systems Multiple Agency Support – who authorizes a system if the contractor supports more than one agency? One agency? All agencies? Significant cost to both the contractor and the government Differing policies Will one agency accept another’s authorization? Will FBI accept an authorization from DOI or Agriculture? Likely not.

Problems with NIST on Corporate Systems Scope of system evaluation Personally identifiable information (PII) – only government provided or all “PII”? E-authentication – only for government services or all contractor systems? FIPS 199 – includes all data types or just government provided data types?

Problems with NIST on Corporate Systems Difficult or Impossible to implement controls Agencies have specific control requirements for their systems, such as use of CAC for authentication, that contractors just can’t implement. Other different technologies (audit, vulnerability scanner) that are organizationally mandated may drive cost and/or architecture changes. May require significant “waivers”

Problems with NIST on Corporate Systems FIPS 199/200 NIST method requires reviewing all data types to determine the level of protection required. Contractor systems may be the opposite – document the level of protection implemented then determine if the level is adequate for the government information to be processed. Data categorization may be contextual – high availability data on government systems may not be high availability if its used for different purposes on a contractor system.

Problems with NIST on Corporate Systems Roles AO – Government or Corporate? Who pays for “required” modifications to the corporate environment? Can the AO deny authorization to operate, therefore making the contractor unable to complete the work? Easy way to terminate a contract with cause? SO – Government or Corporate?

Problems with NIST on Corporate Systems Logistics Documentation formats. Multiple formats required for different agencies? Use of agency repository (CSAM) Distribution of corporate sensitive documentation Risk assessments Vulnerability scans Penetration test results POA&M Protection of information at the government site? How do you keep it away from other contractors? Protection as it moves through the parent organization OIG reviews – results posted to OIG web site? Continuous monitoring results

Problems with NIST on Corporate Systems Changes to NIST guidance required Possibly create an appendix or separate document to use when introducing contractor systems into the environment Development of rules for inter-agency re-use of authorizations Agency policy needs to be flexible when dealing with contractor systems Rules developed for OIG evaluation of contractor system -

Key NIST Documentation 800-18 – SSP 800-34 – Contingency Planning 800-37 –RMF 800-39 – Managing Risk 800-47 – Interconnections 800-53 – Controls 800-53A – Control Testing 800-60 – Data Categorization 800-64 – SDLC 800-82 – ICS (SCADA) 800-100 – Security Handbook 800-128 – Configuration Management FIPS 199 – System Categorization FIPS 200 – Control Selection