Securing U.S. Federal Information Systems and Beyond: NIST Activities and Other Government Initiatives

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
Agenda Topics

• NIST Statutory Responsibilities
• Other Key Assignments
• Overview of Current Projects
• High Visibility Projects
• New Projects

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
Other Key Security Assignments

• HAVA Security of Voting Systems
• Homeland Security Presidential Directive 12

5
Federal Security Roles
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
Classified Systems A. National Security Systems
Committee on National Security Systems B.
Intelligence Systems Director of Central
Intelligence
6
No Standard Terminology

• Standards
• Performance vs. interoperability
• Market Dominant product standards
• Voluntary Industry Consensus Standards (formal)
• Whats a FIPS? (Federal) Applicability
• Guidelines Applicability of NIST Guidelines
• Best Practices
• Procedures
• Policies

7
Key Standards Organizations
International
ICAO
IETF
ITU
IEEE
ISO
IEC
Internet Area
Opns Mgmt Area
Routing Area
Security Area
Transport Area
ISOTC 68
ISO/IEC JTC1
SC 6
SC 17
SC 27
SC 37
SC 2
Regional
ETSI
eEurope
NESSIE
Eurosmart
EESSI
ANSI
National
BSI
JIS
X9, Inc.
INCITS
Japans Cryptographic Technology
Evaluation Committee
M1
B10
T3
T4
X9F
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
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
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/nis
tpubs/index.html
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/nis
tpubs/index.html
12
(No Transcript)
13
(No Transcript)
14
(No Transcript)
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
(No Transcript)
17
(No Transcript)
18
Please consider submitting any practices you may
have for inclusion in our site!
19
(No Transcript)
20
Tested Products / Modules
21
(No Transcript)
22
(No Transcript)
23
3 High Visibility Projects

• FISMA Trilogy - 3 - Minimum Standards for all
  Federal Systems
• CSRDA - Checklists
• HSPD 12 - Personal Identity Verification

24
Key NIST Tasks to Implement FISMA
25
Categorization StandardsFISMA 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
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
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
Security Categorization
Guidance for Mapping Types of Information and
Information Systems to FIPS Publication 199
Security Categories
FIPS Publication 199 Low Moderate High
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.
29
Security Categorization
Guidance for Mapping Types of Information and
Information Systems to FIPS Publication 199
Security Categories
FIPS Publication 199 Low Moderate High
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.
Minimum Security Controls for High Impact Systems
30
Mapping GuidelinesFISMA 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
Minimum Security RequirementsFISMA 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
Security Control AssessmentFISMA 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
Certification and AccreditationSupporting 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
Personal Identity Verification For Federal
Employees and Contractors
Meeting the Requirements of HSPD 12
35
General Objectives

• Common reliable identification verification for
  Government employees and contractors
• Reliable Identification Verification
• Government-wide
• - Interoperability
• - Basis for reciprocity

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
  employees 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
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
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
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 employees 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
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.
30.5
2.5
51.5
30.75
Zone 9 Header
2.5
4.5
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.
20
Reserved area. No printing is permitted in this
area unless verified as printable area by card
and/or printer manufacturers.
27
37
41.5
Zone 2 NameArial 10pt Bold
50
57.5
65.5
41
The NIST Security Configuration Checklists
Program for IT Products
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
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
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
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
NISTs 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
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
Operational Environments
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 (l
ist 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
Developer Steps Overview
Please consider submitting any checklists you may
have for inclusion in our repository!
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
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
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
NIST Checklist Program Logo

• To show participation in NIST Checklist
  Programand 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
CSRC.NIST.GOV
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 ST 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
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

NISTs security role in standards, guidelines,
testing, education can make a real difference!
58
Contact Info

• Ed Roback
• Chief, Computer Security Division, NIST
• E- Roback_at_nist.gov
• Tel [phone]
• Web site csrc.nist.gov