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

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

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

4. 800-37
NIST SP : 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

5. 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)

6. – 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)

7. 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 , Guide for Applying the Risk Management Framework to Federal Information Systems, February 2010, Section 2.1.

8. Categorize the Information System
Required by FIPS 199: Standards for Security Categorization of Federal Information and Information Systems
Utilize NIST 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

9. Select Security Controls
Required by FIPS 200: Minimum Security Requirements for Federal Information and Information Systems
Utilizes NIST SP : 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 , ISSA Journal July 2009

10. 800-53
Controls are divided into three categories – Technical, Management, Operational
includes 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

11. Implement Security Controls
Relatively straightforward implementation of the security controls and information system development.
Utilize NIST SP to determine the security control requirements
Also use NIST SP A: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

12. Assess Security Controls
NIST SP A: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 controls.
Includes some derived requirements
New version – removes “mandate” to perform certain tests. Organization defines the level of testing.

13. 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)

14. 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!

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

16. 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!

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

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

19. Problems with NIST on Corporate Systems
NIST SP 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

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

21. 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?

22. 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”

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

24. 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?

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

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

27. Key NIST Documentation
– SSP
– Contingency Planning
–RMF
– Managing Risk
– Interconnections
– Controls
800-53A – Control Testing
– Data Categorization
– SDLC
– ICS (SCADA)
– Security Handbook
– Configuration Management
FIPS 199 – System Categorization
FIPS 200 – Control Selection