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/ISS
A0709_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
–
–
–
–
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