NIST it by that much. Using and Abusing the NIST 800 Series

1. NIST it by that much.Using and Abusing the NIST 800 Series

2. Adam Stone LBNL – University of California Managed Department of Energy Laboratory (fundamental, unclassified research). Regulatory Environment: Highly activated. 18 Cyber Security Audits in 24 months. C&A, OMB, NIST; GAO, IG, UC, Red Teams Stephen Lau UCSF – Dedicated health sciences campus Many National Institutes of Health and Veterans Administration researchers Regulatory environment: HIPAA, SB1386, FERPA, e-Discovery, etc. Both of us have seen NIST 800 Series being applied in a positive and negative fashion The NIST 800 Series can be your friend or your worst nightmare… Who We Are and Why We’re Here

3. How did we get here? Title 3 of the E-gov Act AKA FISMA

4. The Current Environment

5. Current Environment Continued… • What do DOE/OMB people see when they look out at the world? • But R&E typically looks different • Self Managed or Lightly Managed • Few lockdowns, default allow • User patch management • Mostly visible footprint networks • Open systems for collaboration • Users are smart and expect flexibility and autonomy. • Most systems are not very risky • Outsourced, centrally managed IT • Totally locked down desktops • Central patch management • Tiny visible footprint networks • Standardized OS and Software Load • Duplicative IT investments • Low Quality Project Management in IT • All Federal Systems are RISKY systems! What is the future of this disconnect?

6. What is NIST? • NIST - National Institute of Standards and Technology (www.nist.gov) • Part of the U.S. Department of Commerce • Establishes standards for U.S. federal government • Weights, measures, etc. • Previously concentrated on esoterica…. now given free reign over government information security • NIST has published a series of information security guidelines documents • Collectively known as “NIST 800 Series” • http://csrc.nist.gov/publications/nistpubs/ • Covers a wide spectrum of topics • Risk assessments, wireless security, encryption, telecommuting, etc.

7. Why Should I Care? • Many federal agencies are requiring “NIST compliant” security documentation for federally funded projects or for collaborations • National Institute of Health, Veterans Administration, Department of Defense, Department of Homeland security, etc. • Your colleagues, users, clients and funding sources may ask: • Is the resource you provide “NIST Compliant”? • Can you help me become “NIST Compliant”? • Information security documents may utilize NIST methodology in regards to “risk” and “controls” • Controls are security techniques that address a risk • e.g. passwords, firewalls, documentation • Requirement documents may ask you about “risk” and “controls” • The model is useful, even if the level of detail probably (definitely) exceeds that which is useful for most University/research environments.

8. What the NIST Documents Are Not • They should not be viewed as “checklists” to complete • They are not rules you must abide by • NIST documents contain many loopholes and generalities on purpose • “Compensating controls” (more on this in a bit). • “Residual risk” • “Risk acceptance” • Doing everything in the NIST documents won’t make you make secure • It’ll just kill a lot of trees and give you a false sense of security • They are not comprehensive nor complete • Some of the documents are woefully out of date Caveat emptor!

9. So What Are They Good For? • Useful as a model for approaching information security • Risk Based Model • What are the consequences of “bad things”? • low/medium/high risk • Controls and Compensating Controls • One size doesn’t fit all, different things can achieve the same result • Ideal for diverse distributed environments • Unified, consistent approach to information security • Common language and methodology • Good as reference guide and to ensure “covering of all bases” • See examples coming up…

10. FIPS 199 / SP 800-60 SP 800-37 SP 800-37 SP 800-53 / FIPS 200 Security Categorization System Authorization Security Control Monitoring Security Control Selection Defines category of information system according to potential impact of loss Selects minimum security controls (i.e., safeguards and countermeasures) planned or in place to protect the information system Continuously tracks changes to the information system that may affect security controls and assesses control effectiveness SP 800-53 / FIPS 200 / SP 800-30 Security Control Refinement Uses risk assessment to adjust minimum control set based on local conditions, required threat coverage, and specific agency requirements Determines risk to agency operations, agency assets, or individuals and, if acceptable, authorizes information system processing SP 800-18 SP 800-70 SP 800-53A / SP 800-37 Security Control Documentation Security Control Implementation Security Control Assessment In system security plan, provides an overview of the security requirements for the information system and documents the security controls planned or in place Implements security controls in new or legacy information systems; implements security configuration checklists Determines extent to which the security controls are implemented correctly, operating as intended, and producing desired outcome with respect to meeting security requirements Nistiverse

11. FIPS 199 / SP 800-60 SP 800-37 SP 800-53 / FIPS 200 SP 800-37 Security Categorization Security Control Selection System Authorization Security Control Monitoring Defines category of information system according to potential impact of loss Selects minimum security controls (i.e., safeguards and countermeasures) planned or in place to protect the information system Continuously tracks changes to the information system that may affect security controls and assesses control effectiveness SP 800-53 / FIPS 200 / SP 800-30 Security Control Refinement Uses risk assessment to adjust minimum control set based on local conditions, required threat coverage, and specific agency requirements Determines risk to agency operations, agency assets, or individuals and, if acceptable, authorizes information system processing SP 800-18 SP 800-70 SP 800-53A / SP 800-37 Security Control Documentation Security Control Implementation Security Control Assessment In system security plan, provides an overview of the security requirements for the information system and documents the security controls planned or in place Implements security controls in new or legacy information systems; implements security configuration checklists Determines extent to which the security controls are implemented correctly, operating as intended, and producing desired outcome with respect to meeting security requirements Nistiverse • Security Categorization (FIPS 199) • Confidentiality • Integrity • Availability • Low, Medium, High: High Water Mark

12. FIPS 199 / SP 800-60 SP 800-37 SP 800-53 / FIPS 200 SP 800-37 Security Categorization Security Control Selection System Authorization Security Control Monitoring Defines category of information system according to potential impact of loss Selects minimum security controls (i.e., safeguards and countermeasures) planned or in place to protect the information system Continuously tracks changes to the information system that may affect security controls and assesses control effectiveness SP 800-53 / FIPS 200 / SP 800-30 Security Control Refinement Uses risk assessment to adjust minimum control set based on local conditions, required threat coverage, and specific agency requirements Determines risk to agency operations, agency assets, or individuals and, if acceptable, authorizes information system processing SP 800-18 SP 800-70 SP 800-53A / SP 800-37 Security Control Documentation Security Control Implementation Security Control Assessment In system security plan, provides an overview of the security requirements for the information system and documents the security controls planned or in place Implements security controls in new or legacy information systems; implements security configuration checklists Determines extent to which the security controls are implemented correctly, operating as intended, and producing desired outcome with respect to meeting security requirements Nistiverse • Security Control Selection (800-53 Catalog) • The NIST Low, Medium, and High Baselines • Key Concept: Common Controls

13. Categories of Control

14. We don’t Just mean Shared authN.

16. FIPS 199 / SP 800-60 SP 800-37 SP 800-53 / FIPS 200 SP 800-37 Security Categorization Security Control Selection System Authorization Security Control Monitoring Defines category of information system according to potential impact of loss Selects minimum security controls (i.e., safeguards and countermeasures) planned or in place to protect the information system Continuously tracks changes to the information system that may affect security controls and assesses control effectiveness SP 800-53 / FIPS 200 / SP 800-30 Security Control Refinement Uses risk assessment to adjust minimum control set based on local conditions, required threat coverage, and specific agency requirements Determines risk to agency operations, agency assets, or individuals and, if acceptable, authorizes information system processing SP 800-18 SP 800-70 SP 800-53A / SP 800-37 Security Control Documentation Security Control Implementation Security Control Assessment In system security plan, provides an overview of the security requirements for the information system and documents the security controls planned or in place Implements security controls in new or legacy information systems; implements security configuration checklists Determines extent to which the security controls are implemented correctly, operating as intended, and producing desired outcome with respect to meeting security requirements Nistiverse • Refining the Controls: • Making Risk Based Judgments • Scoping • Compensating • Organization Defined Controls

17. Tailoring the Baseline

18. Scoping Guidance • Common security control-related considerations Common controls are managed by an organizational entity other than the information system owner. Organizational decisions on which security controls are viewed as common controls may greatly affect the responsibilities of individual information system owners. • Operational/environmental-related considerations Security controls that are dependent on the nature of the operational environment are applicable only if the information system is employed in an environment necessitating the controls. • Physical Infrastructure-related considerations Security controls that refer to organizational facilities (e.g., physical controls such as locks and guards, environmental controls for temperature, humidity, lighting, fire, and power) are applicable only to those sections of the facilities that directly provide protection to, support for, or are related to the information system. • Public access-related considerations Security controls associated with public access information systems should be carefully considered and applied with discretion since some security controls from the specified control baselines (e.g., identification and authentication, personnel security controls) may not be applicable to users accessing information systems through public interfaces. • Technology-related considerations Security controls that refer to specific technologies (e.g., wireless, cryptography, public key infrastructure) are applicable only if those technologies are employed or are required to be employed within the information system. Also • Policy/regulatory-related considerations Security controls that address matters governed by applicable laws, Executive Orders, directives, policies, standards, or regulations (e.g., privacy impact assessments) are required only if the employment of those controls is consistent with the types of information and information systems covered by the applicable laws, Executive Orders, directives, policies, standards, or regulations. • Security objective-related considerations Security controls that uniquely support the confidentiality, integrity, or availability security objectives may be downgraded to the corresponding control in a lower baseline (or appropriately modified or eliminated if not defined in a lower baseline) if, and only if, the downgrading action: (i) is consistent with the FIPS 199 security categorization before moving to the high water mark; (ii) is supported by an organizational assessment of risk; and (iii) does not affect the security-relevant information within the information system. Next 3 slides stolen from NIST

19. Compensating Security Controls • The organization selects a compensating control from NIST SP 800-53, or if an appropriate compensating control is not available in the security control catalog, the organization adopts a suitable compensating control; • The organization provides a complete and convincing rationale for how the compensating control provides an equivalent security capability or level of protection for the information system and why the related baseline security control could not be employed; and • The organization assesses and formally accepts the risk associated with employing the compensating control in the information system.

20. Organization-defined Parameters • Security controls containing organization-defined parameters (i.e., assignment and/or selection operations) give organizations the flexibility to define selected portions of the controls- to support specific organizational requirements or objectives. CP-9 INFORMATION SYSTEM BACKUP Control: The organization conducts backups of user-level and system-level information (including system state information) contained in the information system [Assignment: organization-defined frequency] and protects backup information at the storage location. Slide stolen from NIST

21. FIPS 199 / SP 800-60 SP 800-37 SP 800-53 / FIPS 200 SP 800-37 Security Categorization Security Control Selection System Authorization Security Control Monitoring Defines category of information system according to potential impact of loss Selects minimum security controls (i.e., safeguards and countermeasures) planned or in place to protect the information system Continuously tracks changes to the information system that may affect security controls and assesses control effectiveness SP 800-53 / FIPS 200 / SP 800-30 Security Control Refinement Uses risk assessment to adjust minimum control set based on local conditions, required threat coverage, and specific agency requirements Determines risk to agency operations, agency assets, or individuals and, if acceptable, authorizes information system processing SP 800-18 SP 800-70 SP 800-53A / SP 800-37 Security Control Documentation Security Control Implementation Security Control Assessment In system security plan, provides an overview of the security requirements for the information system and documents the security controls planned or in place Implements security controls in new or legacy information systems; implements security configuration checklists Determines extent to which the security controls are implemented correctly, operating as intended, and producing desired outcome with respect to meeting security requirements Nistiverse Documentation: The painful part. A broad scale look at the controls. The notion of common controls: where can application or subsystem owners turn to know what (if anything) is being provided centrally.

22. FIPS 199 / SP 800-60 SP 800-37 SP 800-53 / FIPS 200 SP 800-37 Security Categorization Security Control Selection System Authorization Security Control Monitoring Defines category of information system according to potential impact of loss Selects minimum security controls (i.e., safeguards and countermeasures) planned or in place to protect the information system Continuously tracks changes to the information system that may affect security controls and assesses control effectiveness SP 800-53 / FIPS 200 / SP 800-30 Security Control Refinement Uses risk assessment to adjust minimum control set based on local conditions, required threat coverage, and specific agency requirements Determines risk to agency operations, agency assets, or individuals and, if acceptable, authorizes information system processing SP 800-18 SP 800-70 SP 800-53A / SP 800-37 Security Control Documentation Security Control Implementation Security Control Assessment In system security plan, provides an overview of the security requirements for the information system and documents the security controls planned or in place Implements security controls in new or legacy information systems; implements security configuration checklists Determines extent to which the security controls are implemented correctly, operating as intended, and producing desired outcome with respect to meeting security requirements Nistiverse Implementation: Self Explanatory (and actually the important part)

23. FIPS 199 / SP 800-60 SP 800-37 SP 800-53 / FIPS 200 SP 800-37 Security Categorization Security Control Selection System Authorization Security Control Monitoring Defines category of information system according to potential impact of loss Selects minimum security controls (i.e., safeguards and countermeasures) planned or in place to protect the information system Continuously tracks changes to the information system that may affect security controls and assesses control effectiveness SP 800-53 / FIPS 200 / SP 800-30 Security Control Refinement Uses risk assessment to adjust minimum control set based on local conditions, required threat coverage, and specific agency requirements Determines risk to agency operations, agency assets, or individuals and, if acceptable, authorizes information system processing SP 800-18 SP 800-70 SP 800-53A / SP 800-37 Security Control Documentation Security Control Implementation Security Control Assessment In system security plan, provides an overview of the security requirements for the information system and documents the security controls planned or in place Implements security controls in new or legacy information systems; implements security configuration checklists Determines extent to which the security controls are implemented correctly, operating as intended, and producing desired outcome with respect to meeting security requirements Nistiverse Assessment: 800-53a (the mother of the mother of all checklists) Technical Testing and Auditing Artifacts

25. FIPS 199 / SP 800-60 SP 800-37 SP 800-53 / FIPS 200 SP 800-37 Security Categorization Security Control Selection System Authorization Security Control Monitoring Defines category of information system according to potential impact of loss Selects minimum security controls (i.e., safeguards and countermeasures) planned or in place to protect the information system Continuously tracks changes to the information system that may affect security controls and assesses control effectiveness SP 800-53 / FIPS 200 / SP 800-30 Security Control Refinement Uses risk assessment to adjust minimum control set based on local conditions, required threat coverage, and specific agency requirements Determines risk to agency operations, agency assets, or individuals and, if acceptable, authorizes information system processing SP 800-18 SP 800-70 SP 800-53A / SP 800-37 Security Control Documentation Security Control Implementation Security Control Assessment In system security plan, provides an overview of the security requirements for the information system and documents the security controls planned or in place Implements security controls in new or legacy information systems; implements security configuration checklists Determines extent to which the security controls are implemented correctly, operating as intended, and producing desired outcome with respect to meeting security requirements Nistiverse Authorization: Certify & Accredit Certify: This is working as described and is appropriate Accredit: It appears to be and the remaining risk is acceptable.

26. FIPS 199 / SP 800-60 SP 800-37 SP 800-53 / FIPS 200 SP 800-37 Security Categorization Security Control Selection System Authorization Security Control Monitoring Defines category of information system according to potential impact of loss Selects minimum security controls (i.e., safeguards and countermeasures) planned or in place to protect the information system Continuously tracks changes to the information system that may affect security controls and assesses control effectiveness SP 800-53 / FIPS 200 / SP 800-30 Security Control Refinement Uses risk assessment to adjust minimum control set based on local conditions, required threat coverage, and specific agency requirements Determines risk to agency operations, agency assets, or individuals and, if acceptable, authorizes information system processing SP 800-18 SP 800-70 SP 800-53A / SP 800-37 Security Control Documentation Security Control Implementation Security Control Assessment In system security plan, provides an overview of the security requirements for the information system and documents the security controls planned or in place Implements security controls in new or legacy information systems; implements security configuration checklists Determines extent to which the security controls are implemented correctly, operating as intended, and producing desired outcome with respect to meeting security requirements Nistiverse Continuous Monitoring: Is it working? Is it sufficient?

27. NIST at UCSF • UCSF conducting Campus-wide information security risk assessments • Divided Campus into “control points” • Risk categorization based upon NIST “low/medium/high” concept • Using NIST “controls” concept to make sure “all bases are covered” • e.g. access, physical security, documentation, user education, etc. • Developed our own “risk impacts” • Risks endemic to a University (not necessarily covered by NIST) • e.g. Campus Reputation • low – work unit impact • medium - department/school wide • high – national/international reputation of UCSF • Developed “suite of interview questions” • Same series of questions being asked across Campus • Same questions phrased differently • Sometimes get different answers based up phrasing

28. NIST at UCSF • Goal: Develop continual risk assessment of UCSF • Identify similar “high risks” facing entire Campus (target those) • Revisit risks assessments to see progress made (if any) • Consider availability of resources to address risk • Because that’s a risk in itself! • Goal II: Security plans based upon risk across entire Campus, subdivided into “control points” • Interim Results: • Have uncovered high risk areas not normally considered when focusing solely on “legal” requirements, e.g. SB1386, HIPAA • e.g. Animal research databases, hazardous chemicals information, politically sensitive databases

29. NIST @ LBL The documentation-heavy version. • Approximately 300 pages of security plans for five enclaves and supporting docs. • An interactive database for each control which allows each enclave owner to see how other people implement. • Extensive wikis for managing documentation requirements • C&A is (sadly) a hundreds of thousands of dollars effort. The documentation light version, • SCRAPs Enclaves as a way of thinking about risk.

31. Regulatory Outlook • More regulations are coming down the pipe • Increased mixing of a highly activated OMB/NIST regulatory machines with University rules and regulations. • Increasingly activated University internal auditors with interest in cyber security. • DHS and NSA are both interested in “helping” non-governmental networks. But Higher Ed is different. • Laws are becoming financially burdensome for sites • CA SB1386 requires notifications for exposure of personally identifiable information • Estimates are around $100.00/notice • e.g. 50,000 individuals to be notified == Big $$

32. Regulatory Outlook 2 • Collaborations with Government Research Entities are becoming more and more difficult: • NASA, NIH, National Laboratories, some FFRDCs (but not all) • Sharing data with government entities (VA, NIH, CDC) seems likely to get more and more difficult. • Ongoing government consolidation and security projects seem likely to negatively impact the interaction between Higher Ed and Government research: • Network consolidation • System lockdown • Movement of previously open information behind firewalls. • Expansion of the notion of “IT Project” subject to reporting controls.

33. The Big Takeaways • NIST is useful, take a graded approach. • It’s not a sacred text (nor is it intended to be) • Doing everything NIST wants you to do does not equal security, it just kills trees and annoys people (do the good parts). • If it doesn’t reflect reality, don’t write it down. • Holistic Risk Assessment is critical (and lacking) Once the rockets are up, who cares where they come down. That’s not my department, said Wernher Von Braun…

34. Wilson, Bureaucracy, What Government Agencies Do and Why They Do It. Whatever behavior will get an agency executive in trouble will get a manager in trouble; whatever gets a manager in trouble will get an operator in trouble…This means that even talented and motivated operators will not be free to violate rules that threaten their agency, even if the rule itself is silly. Many agency executives do not understand this. They are eager to deflect or mollify critics of their agencies. In their eagerness they suppose that announcing a rule designed to forbid whatever behavior led to the criticism actually will work. Their immediate subordinates, remote from field pressures (and perhaps eager to ingratiate themselves with the executives) will assure their bosses that the new rule will solve the problem. But unless the rule actually redefines the core tasks of the operators value, the rule will be seen as just one more constraint on getting the job done (or, more graphically, as "just another piece of chicken****")." Artifacts and policy that don’t kill the core task.

35. Contact Information Stephen Lau University of California, San Francisco Enterprise Information Security / OAAIS Email: stephen.lau@ucsf.edu Phone: +1 (415) 476-3106 PGP: 44C8 C9CB C15E 2AE1 7B0A 544E 9A04 AB2B F63F 748B Adam Stone Berkeley Lab Assoc. Liaison for IT (Policy & Assurance) Email: adstone@lbl.gov