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

• 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

Controls are divided into three categories – Technical, Management, Operational

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