Upload
aysel
View
29
Download
0
Embed Size (px)
DESCRIPTION
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. - PowerPoint PPT Presentation
Citation preview
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• [email protected]; [email protected]
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