1. 1 Securing U.S. Federal Information Systems and Beyond: NIST Activities and Other Government Initiatives Ed Roback Chief, Computer Security Division April 4, 2005

2. 2 Agenda Topics NIST Statutory Responsibilities & Other Key Assignments Overview of Current Projects High Visibility Projects New Projects

3. 3 NIST Statutory Security Mandates Federal Information Security Management Act of 2002 Federal security standards and guidelines Minimum requirements; categorization standards, incident handling, NSS identification, … Advisory Board support Cyber Security Research and Development Act of 2002 Extramural research support Fellowships Intramural research Checklists NRC study support Non-national security systems

4. 4 Other Key Security Assignments HAVA – Security of Voting Systems Homeland Security Presidential Directive #12

5. 5 Federal Security Roles Classified Systems A. National Security Systems – “Committee on National Security Systems” B. Intelligence Systems – Director of Central Intelligence Unclassified Systems NIST – standards, guidelines, security research (in-house and academic-industry partnerships) Federal Information Security Management Act of 2002 Cyber Security Research and Development Act of 2002 DHS – Day-to-day security alerts, operations, etc. National Cyber Security Division in IAIP NSF – Academic research support Cyber Security Research and Development Act of 2002 Congress/ OMB – Government-wide policy/oversight role

6. 6 No Standard Terminology Standards –Performance vs. interoperability –Market Dominant product “standards” –Voluntary Industry Consensus Standards (“formal”) –What’s a FIPS? (“Federal”) Applicability… Guidelines … Applicability of NIST Guidelines… “Best” Practices Procedures Policies

7. 7 ISOIEC ISOTC 68 ISO/IEC JTC1 ITU IETF Internet Area Opns & Mgmt Area Routing Area Security Area Transport Area SC 2 SC 6 International ETSI EESSI eEuropeNESSIEEurosmart BSIJIS Japan’s Cryptographic Technology Evaluation Committee ANSI National Regional X9, Inc. INCITS M1B10T3T4X9F SC 17SC 27SC 37 IEEE ICAO Key Standards Organizations

8. 8 NIST-CSD Research Projects Cryptography / E-Auth –Cryptographic Standards and Applications –Cryptographic Standards Toolkit –E-Authentication Security Testing –Cryptographic Module Validation Program –800-53A Validation Guideline Security Management and Guidance –Industry and Federal Security Standards –Security Management Guidelines –Agency Program Reviews Emerging Technologies –Checklists –Technical Security Guidelines –Government Smart Card Program –Mobile Device Security –Forensics –Access Control and Authorization Management –ICAT

9. 9 Recent Federal Security Standards FIPS 201, Personal Identity Verification for Federal Employees and Contractors FIPS 199, Standards for Security Categorization of Federal Information and Information Systems FIPS 198, Keyed-Hash Message Authentication Code FIPS 197, Advanced Encryption Standard Coming Soon… FIPS 200, Minimum Requirements for All Federal Systems* * Exact title TBD

10. 10 Recently Completed NIST Security Guidelines Draft 800-78, Cryptographic Algorithms and Key Sizes for Personal Identity Verification Draft 800-77, Guide to IPsec VPNs Draft 800-76, Biometric Data Specification for Personal Identity Verification Draft 800-73, Integrated Circuit Card for Personal Identity Verification 800-72, Guidelines on PDA Forensics November 2004 800-70, Draft 800-70, The NIST Security Configuration Checklists Program 800-68, Draft 800-68, Guidance for Securing Microsoft Windows XP Systems for IT Professionals: A NIST Security Configuration Checklist 800-67, Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher, May 2004 800-66, An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule, March 2005 Available at http://csrc.nist.gov/publications/nistpubs/index.html

11. 11 Recently Completed NIST Security Guidelines 800-65, Integrating Security into the Capital Planning and Investment Control Process, January 2005 800-64, Security Considerations in the Information System Development Life Cycle,October 2003 (publication original release date)(revision 1 released June 2004) 800-63, Electronic Authentication Guideline: Recommendations of the National Institute of Standards and Technology, June 2004 (publication original release date) (revision 1.0.1 released September 2004) 800-61, Computer Security Incident Handling Guide, January 2004 800-60, Guide for Mapping Types of Information and Information Systems to Security Categories, June 2004 800-59, Guideline for Identifying an Information System as a National Security System, August 2003 800-58, Security Considerations for Voice Over IP Systems, January 2005 DRAFT 800-57 Recommendation on Key Management 800-55, Security Metrics Guide for Information Technology Systems,July 2003 800-53, Recommended Security Controls for Federal Information Systems, February 2005 DRAFT 800-52, Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations Available at http://csrc.nist.gov/publications/nistpubs/index.html

12. 12

13. 13

14. 14

15. 15 Future Guidelines* Checklists and Configuration/Hardening Guides (DHS) Media Destruction/Sanitization (DHS) Risk Management (DHS) Incident Exercises (DHS) Malware (DHS) VOIP Forensics Handbook Sensor Deployment Penetration Testing & Vulnerability Management Technical Security Metrics Web Services IP/Telephony Convergence Trust frameworks RFID Embedded Systems Governance *funding permitting, except as noted

16. 16

17. 17

18. 18 Please consider submitting any practices you may have for inclusion in our site!

19. 19

20. 20 Tested Products / Modules

21. 21

22. 22

23. 23 3 High Visibility Projects FISMA Trilogy - #3 - Minimum Standards for all Federal Systems CSRDA - Checklists HSPD #12 - Personal Identity Verification

24. 24 Key NIST Tasks to Implement FISMA

25. 25 Categorization Standards FISMA Requirement  Develop standards to be used by federal agencies to categorize information and information systems based on the objectives of providing appropriate levels of information security according to a range of risk levels  Publication status: Federal Information Processing Standards (FIPS) Publication 199, “ Standards for Security Categorization of Federal Information and Information Systems ” Final Publication: December 2003 * * FIPS Publication 199 was signed by the Secretary of Commerce in February 2004.

26. 26 FIPS Publication 199  FIPS 199 is critically important to enterprises because the standard —  Requires prioritization of information systems according to potential impact on mission or business operations  Promotes effective allocation of limited information security resources according to greatest need  Facilitates effective application of security controls to achieve adequate information security  Establishes appropriate expectations for information system protection

27. 27 FIPS 199 Applications  FIPS 199 should guide the rigor, intensity, and scope of all information security-related activities within the enterprise including —  The application and allocation of security controls within information systems  The assessment of security controls to determine control effectiveness  Information system authorizations or accreditations  Oversight, reporting requirements, and performance metrics for security effectiveness and compliance

28. 28 Security Categorization FIPS Publication 199 LowModerateHigh Confidentiality The loss of confidentiality could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals. The loss of confidentiality could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals. The loss of confidentiality could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals. Integrity The loss of integrity could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals. The loss of integrity could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals. The loss of integrity could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals. Availability The loss of availability could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals. The loss of availability could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals. The loss of availability could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals. Guidance for Mapping Types of Information and Information Systems to FIPS Publication 199 Security Categories SP 800-60

29. 29 Security Categorization FIPS Publication 199 LowModerateHigh Confidentiality The loss of confidentiality could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals. The loss of confidentiality could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals. The loss of confidentiality could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals. Integrity The loss of integrity could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals. The loss of integrity could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals. The loss of integrity could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals. Availability The loss of availability could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals. The loss of availability could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals. The loss of availability could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals. Guidance for Mapping Types of Information and Information Systems to FIPS Publication 199 Security Categories SP 800- 60 Minimum Security Controls for High Impact Systems

30. 30 Mapping Guidelines FISMA Requirement  Develop guidelines recommending the types of information and information systems to be included in each category  Publication status: NIST Special Publication 800-60, “ Guide for Mapping Types of Information and Information Systems to Security Categories ” Final Publication: June 2004

31. 31 Minimum Security Requirements FISMA Requirement  Develop minimum information security requirements (management, operational, and technical security controls) for information and information systems in each such category  Publication status: Federal Information Processing Standards (FIPS) Publication 200, “ Minimum Security Controls for Federal Information Systems ” * NIST Deadline: December 2005 * NIST Special Publication 800-53, “ Recommended Security Controls for Federal Information Systems, ” February 2005, will provide interim guidance until completion of standard.

32. 32 Security Control Assessment FISMA Requirement  Conduct periodic testing and evaluation of the effectiveness of information security policies, procedures, and practices (including management, operational, and technical security controls)  Publication status: NIST Special Publication 800-53A, “ Guide for Assessing the Security Controls in Federal Information Systems ” Initial Public Draft: 2005

33. 33 Certification and Accreditation Supporting FISMA Requirement  Conduct periodic testing and evaluation of the effectiveness of information security policies, procedures, and practices (including management, operational, and technical security controls)  Publication status: NIST Special Publication 800-37, “ Guide for the Security Certification and Accreditation of Federal Information Systems ” Final Publication: May 2004

34. 34 Personal Identity Verification For Federal Employees and Contractors Meeting the Requirements of HSPD #12…

35. 35 General Objectives Common reliable identification verification for Government employees and contractors Reliable Identification Verification Government-wide - Interoperability - Basis for reciprocity

36. 36 Personal Identity Verification Requirements HSPD-12: Policy for a Common Identification Standard Secure and reliable forms of personal identification: Based on sound criteria to verify an individual employee’s identity Is strongly resistant to fraud, tampering, counterfeiting, and terrorist exploitation Personal identity can be rapidly verified electronically Identity tokens issued only by providers whose reliability has been established by an official accreditation process

37. 37 Personal Identity Verification Requirements Applicable to all government organizations and contractors To be used to grant access to Federally-controlled facilities and logical access to Federally-controlled information systems, to the maximum extent practicable Graduated criteria from least secure to most secure to ensure flexibility in selecting the appropriate security level for each application Not applicable to identification associated with national security systems To be implemented in a manner that protects citizens’ privacy

38. 38 Personal Identity Verification Requirements HSPD:Policy for a Common Identification Standard Departments and agencies shall have a program in place to ensure conformance within 4 months after issuance of FIPS Departments and agencies to identify applications important to security that would benefit from conformance to the standard within 6 months after issuance Compliance with the Standard is required in applicable Federal applications within 8 months following issuance

39. 39 Phased-Implementation Approach Two Parts to PIV Standard Part I – Common Identification and Security Requirements - HSPD #12 Control Objectives Examples: Identification shall be issued based on strong Government-wide criteria for verifying an individual employee’s identity The identification shall be capable of being rapidly authenticated electronically Government-wide - Identity Proofing Requirements (revised from October draft) - Effective October 2005 Part II – Common Interoperability Requirements - Specifications - No set deadline for implementation in PIV standard Migration Timeframe (i.e., Part I  II) - IAW HSPD #12, Implementation Plans for OMB before July 2005 - OMB approves agency plans and/or develops schedule directive - OMB developing implementation guidance for public review and comment

40. 40 Affiliation Civilian Doe John, G. United States Government Agency/Department Department of Homeland Security Issued 01/01/05 Expires 01/01/08 Pay O15 Federal Emergency Response Official Color Photograph Contact Chip 2.5 4.5 2.5 30.5 20 27 37 41.5 50 57.5 Zone 2 – Name Arial 10pt Bold 30.75 51.5 65.5 Reserved area. No printing is permitted in this area unless verified as printable area by card and/or printer manufacturers. Area for additional optional data. Agency- specific data may be printed in this area. See other examples for required placement of additional optional data elements. Note: In this example, Zone 9,11, and 13 are optional but shall be placed as depicted and therefore are not in the blue shaded area. Area likely to be needed by card manufacturer. Optional data may be printed in this area but may be subject to restrictions imposed by card and/or printer manufacturers. Zone 9 – Header

41. 41 The NIST Security Configuration Checklists Program for IT Products

42. 42 What is a Checklist? Often called lockdown guides, configuration guides, security guides, benchmark, hardening guides, STIGs, other terms A document or list of procedures to secure a system or application Implementation guides used to provide security controls to the information system Could include scripts, add-on templates, or executables

43. 43 Why Checklists Most products are insecure out of the box Most users need assistance in configuring security controls due to complexity of the technology Demand for easy-to-understand checklists for improving security Demand for checklists tailored to different environments, such as home, small office, enterprise, or higher security Checklists can have a large impact on security with relatively small upfront investment

44. 44 Tasking to NIST Cyber Security Research and Development Act of 2002 directs NIST to: –Develop, and revise as necessary, a checklist setting forth settings and option selections that minimize the security risks associated with each computer hardware or software system that is, or is likely to become widely used within the Federal Government. NIST would set priorities for development

45. 45 FISMA Legislation FISMA (section 3534(b)(2)(D)(iii)) requires each agency to determine minimally acceptable system configuration requirements and ensure compliance with them NIST is expected to assist agencies in guidance for developing configuration checklists and for sharing them

46. 46 NIST’s Response: Write guideline for developers and users Build the repository; populate with current checklists from NIST, NSA, DISA, CIS Get participation agreements from major developers Assist agencies in using the repository to share and acquire configuration checklists Work with vendors to begin including checklists with their products

47. 47 How Does the Program Work? Developers follow NIST guidance in creating checklists, e.g., targeted operational environments After submission to NIST and initial screening, checklists are publicly reviewed Issues are addressed, checklist is listed in repository and maintained by developer Developers can use our logo on their products Users can provide feedback to NIST and developers

48. 48 Operational Environments

49. 49 Security Checklists for Commercial IT Products About Checklists Search the Security Checklist Database Under the Cyber Security Research and Development Act, NIST is charged with developing security checklists. These checklists describe security settings for commercial IT products. Operational Environment Each security checklist describes the operational environment for which it is intended to be used. These generally specify levels consistent with the government wide security categorizations for information systems. Partners The checklists provided on this website are provided by a wide variety of vendors, government agencies, consortia, non-profit organizations, and user organizations. For a complete list, click here. NIST gratefully acknowledges their contributions and assistance in providing this security service. Disclaimer The contents of each checklist is the responsibility of the submitting organization. We encourage users to send comments on specific checklists to the appropriate author. Search By specific product name Microsoft Windows 2000 By security environment Enterprise By product type Operating System Results (list of checklists) NIST Windows 2000 Special Publication NSA Windows 2000 Security Guide DISA Windows 2000 Security Configuration Guide CIS Windows 2000 Guide – Level 2

50. 50 Developer Steps Overview Please consider submitting any checklists you may have for inclusion in our repository!

51. 51 Screening Checklists Prior to Public Review NIST screens for applicability, technical merit based on established criteria NIST posts candidates for public review Comments are provided to the developer Issues addressed by the developer before final posting of the checklist As necessary, NIST uses independent qualified reviewers

52. 52 Final Listing of Checklists on Repository After all issues get addressed, checklist is listed on repository NIST continues to receive user feedback, passes on to developer Checklist owner can use the logo on product material with conditions Users get advised to test and back up before applying checklists

53. 53 Checklist Maintenance NIST schedules a periodic review of the checklist with developer – typically 1 year If major update, then checklist is rescreened/resubmitted for public review NIST or checklist owner can decide to “delist” the checklist Or, checklist can be frozen, i.e., archived, but remain on repository

54. 54 NIST Checklist Program Logo To show participation in NIST Checklist Program and ownership of a checklist on repository Available to checklist producers who meet the NIST program requirements Producer must provide end-user checklist-related support Does not convey NIST endorsement

55. 55 CSRC.NIST.GOV

56. 56 Other Government Activities OMB Policy –Annual FISMA reporting –Policy on Implementation of New ID cards OMB – Security Line of Business DHS – NCSD –National Strategy to Secure Cyberspace DHS – S&T – Cyber NITRD Congress NSA – Educational Centers of Excellence PITAC report, “Cyber Security: A Crisis of Prioritization” CRS – “Creating a National Framework for Cybersecurity: An Analysis of Issues and Options” NIAP Review CNSS

57. 57 Conclusions Security is key to protecting the Homeland, cyberspace, critical infrastructures and Government/Private information and systems Division has critical national-level statutory responsibilities Division has proven track record in delivering needed/useful standards, testing programs and guidelines; High demand: Expectations on our program are considerable, particularly among Federal community for leadership and guidelines/standards NIST’s security role in standards, guidelines, testing, education can make a real difference!

58. 58 Contact Info Ed Roback Chief, Computer Security Division, NIST E- : Roback@nist.gov Tel: 301 975 2934 Web site: csrc.nist.gov