Ed Roback Chief, Computer Security Division April 4, 2005

1

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

and Other Government Initiatives

Ed RobackChief, 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 2002Federal security standards and guidelinesMinimum requirements; categorization standards, incident handling, NSS identification, …Advisory Board support

Cyber Security Research and Development Act of 2002Extramural research supportFellowshipsIntramural researchChecklistsNRC 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

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

Con

gres

s/ O

MB

– G

over

nm

ent-

wid

e p

olic

y/ov

ersi

ght

role

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

ISO IEC

ISOTC68

ISO/IEC JTC1

ITU IETF

Internet

Area

Opns & Mgmt Area

RoutingArea

Security

Area

Transport

Area

SC 2 SC 6

International

ETSI

EESSI

eEurope NESSIE Eurosmart

BSI JIS

Japan’sCryptographic

Technology EvaluationCommittee

ANSINational

Regional

X9, Inc. INCITS

M1B10 T3 T4X9F

SC 17 SC 27 SC 37

IEEE ICAO

Key Standards Organizations

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/nistpubs/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/nistpubs/index.html

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

18

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

20

Tested Products / Modules

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

FIPS Publication 199Low 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.

Guidance for Mapping Types of Information and Information Systems to FIPS Publication 199 Security Categories

SP 800-60

29

Security Categorization

FIPS Publication 199 Low Moderat

eHigh

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

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

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 employee’s identityIs strongly resistant to fraud, tampering, counterfeiting, and terrorist exploitationPersonal identity can be rapidly verified electronicallyIdentity tokens issued only by providers whose reliability has been established by an official accreditation process

37


•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


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

AffiliationCivilian

DoeJohn, G.

United States Government

Agency/Department

Department of Homeland Security

Issued

01/01/05Expires

01/01/08

Pay

O15

Federal Emergency Response Official

ColorPhotograph

Contact Chip

2.5

4.5

2.5 30.5

20

27

37

41.5

50

57.5

Zone 2 – NameArial 10pt Bold

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

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

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

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 DatabaseUnder the Cyber Security Research and Development Act, NIST is charged with developing security checklists. These checklists describe security settings for commercial IT products.

Operational EnvironmentEach 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.

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

DisclaimerThe 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 PublicationNSA Windows 2000 Security GuideDISA Windows 2000 Security Configuration GuideCIS 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 – 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

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

Contact Info

Ed RobackChief, Computer Security Division, NIST

E- : [email protected]: 301 975 2934

Web site: csrc.nist.gov

Ed Roback Chief, Computer Security Division April 4, 2005

Documents

Transcript of Ed Roback Chief, Computer Security Division April 4, 2005