FISMA, NIST Style

1. 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 • Chad.andersen@noblis.org; cander14@gmu.edu

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 • http://csrc.nist.gov/

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

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

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

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 800-37, 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 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

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

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

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

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

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

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