156
IIA Conference February 8, 2005 National Institute of Standards and Technology 1 The New FISMA Standards and Guidelines or Building More Secure Information Systems A Strategy for Effectively Applying the Provisions of FISMA Dr. Ron Ross & Dr. Stuart Katzke Computer Security Division Information Technology Laboratory

IIA Conference February 8, 2005 National Institute of Standards and Technology 1 The New FISMA Standards and Guidelines or Building More Secure Information

Embed Size (px)

Citation preview

IIA Conference February 8, 2005 National Institute of Standards and Technology 1

The New FISMA Standards and Guidelinesor

Building More Secure Information Systems A Strategy for Effectively Applying the Provisions of FISMA

Dr. Ron Ross

&

Dr. Stuart Katzke

Computer Security DivisionInformation Technology Laboratory

IIA Conference February 8, 2005 National Institute of Standards and Technology 2

Presentation Contents• Part I: Overview

– Setting the stage/motivation/background– NIST’s Federal Information Security Management Act

(FISMA) of 2002 Implementation Project: A Risk Management Framework (RMF)

• Part II: Details– FIPS 199: Security Categorization– Special Publication (SP) 800-60: Categories Mapping

Guidelines– SP 800-53: Security Control Selection

(Minimum/Baseline Controls)– The Development and Vetting of SP 800-53– SP 800- 37: Security Certification and Accreditation– SP 800- 53A: Security Control Assessment

IIA Conference February 8, 2005 National Institute of Standards and Technology 3

Part I: Overview

IIA Conference February 8, 2005 National Institute of Standards and Technology 4

The Information Age Information systems are an integral part of

government and business operations today

Information systems are changing the way we do business and interact as a society

Information systems are driving a reengineering of business processes in all sectors including defense, healthcare, manufacturing, financial services, etc.

Information systems are driving a transition from a paper-based society to a digital society

IIA Conference February 8, 2005 National Institute of Standards and Technology 5

The Protection Gap Information system protection measures have not

kept pace with rapidly advancing technologies

Information security programs have not kept pace with the aggressive deployment of information technologies within enterprises

Two-tiered approach to security (i.e., national security community vs. everyone else) has left significant parts of the critical infrastructure vulnerable

IIA Conference February 8, 2005 National Institute of Standards and Technology 6

The Global Threat Information security is not just a paperwork

drill…there are dangerous adversaries out there capable of launching serious attacks on our information systems that can result in severe or catastrophic damage to the nation’s critical information infrastructure and ultimately threaten our economic and national security…

IIA Conference February 8, 2005 National Institute of Standards and Technology 7

U.S. Critical InfrastructuresDefinition

“...systems and assets, whether physical or virtual, so vital to the United States that the incapacity or destruction of such systems and assets would have a debilitating impact on security, national economic security, national public health and safety, or any combination of those matters.”

-- USA Patriot Act (P.L. 107-56)

IIA Conference February 8, 2005 National Institute of Standards and Technology 8

U.S. Critical InfrastructuresExamples

Energy (electrical, nuclear, gas and oil, dams) Transportation (air, road, rail, port, waterways) Public Health Systems / Emergency Services Information and Telecommunications Defense Industry Banking and Finance Postal and Shipping Agriculture / Food / Water Chemical

IIA Conference February 8, 2005 National Institute of Standards and Technology 9

Critical Infrastructure Protection The U.S. critical infrastructures are over 90%

owned and operated by the private sector

Critical infrastructure protection must be a partnership between the public and private sectors

Information security solutions must be broad-based, consensus-driven, and address the ongoing needs of government and industry

IIA Conference February 8, 2005 National Institute of Standards and Technology 10

Threats to SecurityConnectivity

Complexity

IIA Conference February 8, 2005 National Institute of Standards and Technology 11

Key Security Challenges

Adequately protecting enterprise information systems within constrained budgets

Changing the current culture of:

“Connect first…ask security questions later”

Bringing standardization to: Information system security control selection and

specificationMethods and procedures employed to assess the correctness and effectiveness of those controls

IIA Conference February 8, 2005 National Institute of Standards and Technology 12

Why Standardization?Security Visibility Among Business/Mission Partners

Organization One

Information System

?

Determining the risk to the first organization’s operations and assets and

the acceptability of such risk

Business / MissionInformation Flow

The objective is to achieve visibility into prospective business/mission partners information security programs BEFORE critical/sensitive communications begin…establishing levels of security due diligence.

Determining the risk to the second organization’s operations and assets and

the acceptability of such risk

Organization Two

Information System

?Security Information

IIA Conference February 8, 2005 National Institute of Standards and Technology 13

NIST’s Federal Information Security

Management Act (FISMA) of 2002 Implementation

Project: a Risk Management Framework

(RMF)

IIA Conference February 8, 2005 National Institute of Standards and Technology 14

FISMA Implementation Project Drivers

Technical Legislative and Policy

IIA Conference February 8, 2005 National Institute of Standards and Technology 15

Project Drivers:Technical

NIST’s system security certification and accreditation (C&A) guidance aging (FIPS 102--1983)

Proliferation of C&A guidance FIPS 102 (NIST) DITSCAP (DoD) NIACAP (NSTISSC/NSS)

Attempt to achieve government-wide C&A convergence

Attempt to integrate new and existing guidance in a comprehensive risk management framework

IIA Conference February 8, 2005 National Institute of Standards and Technology 16

Project Drivers:Legislative and Policy

Public Law 107-347 (Title III)Federal Information Security Management Act of 2002

Public Law 107-305Cyber Security Research and Development Act of 2002

Homeland Security Presidential Directive #7Critical Infrastructure Identification, Prioritization, and Protection

OMB Circular A-130 (Appendix III)Security of Federal Automated Information Resources

IIA Conference February 8, 2005 National Institute of Standards and Technology 17

Security ChecklistsCSRDA Requirement

Develop and disseminate security configuration checklists and option selections that minimize the security risks associated with commercial information technology products that are, or are likely to become, widely used within federal information systems

Publication status:

NIST Special Publication 800-70, “The NIST Security Configuration Checklists Program”

Initial Public Draft: August 2004

IIA Conference February 8, 2005 National Institute of Standards and Technology 18

FISMA LegislationOverview

“Each federal agency shall develop, document, and implement an agency-wide information security program to provide information security for the information and information systems that support the operations and assets of the agency, including those provided or managed by another agency, contractor, or other source…”

-- Federal Information Security Management Act of 2002

IIA Conference February 8, 2005 National Institute of Standards and Technology 19

FISMA Tasks for NIST 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

Guidelines recommending the types of information and information systems to be included in each category

Minimum information security requirements (management, operational, and technical security controls) for information and information systems in each such category

IIA Conference February 8, 2005 National Institute of Standards and Technology 20

FISMA Implementation Project FISMA-related standards and guidelines tightly coupled to

the suite of NIST Management and Technical Guidelines

Described within the context of System Development Life Cycle (SDLC)

http://csrc.nist.gov/SDLCinfosec

IIA Conference February 8, 2005 National Institute of Standards and Technology 21

FISMA Implementation Project Standards and Guidelines (1)

New Standards and Guidelines FIPS Publication 199 (Security Categorization)

NIST Special Publication 800-37 (Certification & Accreditation)

NIST Special Publication 800-53 (Recommended Security Controls)

NIST Special Publication 800-53A (Security Control Assessment)

NIST Special Publication 800-59 (National Security Systems)

NIST Special Publication 800-60 (Security Category Mapping)

FIPS Publication 200 (Minimum Security Controls)

IIA Conference February 8, 2005 National Institute of Standards and Technology 22

FISMA Implementation Project Standards and Guidelines (2)

Existing Standards and Guidelines NIST Special Publication 800-30 (Risk Management )

NIST Special Publication 800-18 (Security Plan Development)

NIST Special Publication 800-64 (System Development Life Cycle)

NIST Special Publication 800-70 (Security Configuration Checklists)

IIA Conference February 8, 2005 National Institute of Standards and Technology 23

FISMA Implementation ProjectOverall Goals

Helping to achieve more secure information systems within the federal government by:

A better understanding of mission risks resulting from the operation of information systems

A standard approach for selecting baseline controls

More consistent, comparable and repeatable assessments of security controls in federal systems

More complete, reliable and trustworthy information to support authorizing officials—facilitating more informed accreditation decisions

IIA Conference February 8, 2005 National Institute of Standards and Technology 24

Managing Enterprise Risk Key activities in managing organizational-level

risk—risk to the organization resulting from the operation of an information system: Categorize the information system Select set of minimum (baseline) security controls Refine the security control set based on risk assessment Document security controls in system security plan Implement the security controls in the information system Assess the security controls (C&A) Determine agency-level risk and risk acceptability (C&A) Authorize information system operation (C&A) Monitor security controls on a continuous basis (C&A)

IIA Conference February 8, 2005 National Institute of Standards and Technology 25

FISMA Implementation Project:Risk Management Framework (RMF)

In system security plan, provides a an overview of the security requirements for

the information system and documents the security controls planned or in place

SP 800-18

Security Control Documentation

Defines category of information system according to potential

impact of loss

FIPS 199 / SP 800-60

Security Categorization

Selects minimum security controls (i.e., safeguards and countermeasures) planned or

in place to protect the information system

SP 800-53 / FIPS 200

Security Control Selection

Determines extent to which the security controls are implemented correctly, operating as intended, and producing desired outcome with respect to meeting security requirements

SP 800-53A / SP 800-37

Security Control Assessment

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

SP 800-37

System Authorization

Determines risk to agency operations, agency assets, or individuals and, if acceptable,

authorizes information system processing

SP 800-37

Security Control Monitoring

Continuously tracks changes to the information system that may affect security controls and

assesses control effectiveness

Implements security controls in new or legacy information systems; implements security configuration

checklists

Security Control Implementation

SP 800-64/SP 800-70

IIA Conference February 8, 2005 National Institute of Standards and Technology 26

Security Objectives

Confidentiality

“Preserving authorized restrictions on information access and disclosure, including means for protecting personal

privacy and proprietary information…” [44 U.S.C., Sec. 3542]

Integrity

“Guarding against improper information modification or destruction, and includes ensuring information non-

repudiation and authenticity…” [44 U.S.C., Sec. 3542]

Availability

“Ensuring timely and reliable access to and use of information…” [44 U.S.C., Sec. 3542]

IIA Conference February 8, 2005 National Institute of Standards and Technology 27

FIPS 199 Levels of Impact The level of impact is low if—

The event could be expected to have a limited adverse effect on agency operations (including mission, functions, image or reputation), agency assets, or individuals. The event causes a negative outcome or results in limited damage to operations or assets, requiring minor corrective actions or repairs.

The level of impact is moderate if— The event could be expected to have a serious adverse effect on agency

operations (including mission, functions, image or reputation), agency assets, or individuals. The event causes significant degradation in mission capability, places the agency at a significant disadvantage, or results in major damage to assets, requiring extensive corrective actions or repairs.

The level of impact is high if— The event could be expected to have a severe or catastrophic adverse

effect on agency operations (including mission, functions, image or reputation), agency assets, or individuals. The event causes a loss of mission capability for a period that poses a threat to human life, or results in a loss of major assets.

IIA Conference February 8, 2005 National Institute of Standards and Technology 28

Security Categorization

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.

Example: An Enterprise Information System

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

SP 800-60

IIA Conference February 8, 2005 National Institute of Standards and Technology 29

Security Categorization

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.

Example: An Enterprise Information System

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

IIA Conference February 8, 2005 National Institute of Standards and Technology 30

The Desired End StateSecurity Visibility Among Business/Mission Partners

Organization One

Information System

Plan of Action and Milestones

Security Assessment Report

System Security Plan

Determining the risk to the first organization’s operations and assets and

the acceptability of such risk

Business / MissionInformation Flow

The objective is to achieve visibility into prospective business/mission partners information security programs BEFORE critical/sensitive communications begin…establishing levels of security due diligence.

Determining the risk to the second organization’s operations and assets and

the acceptability of such risk

Organization Two

Information System

Plan of Action and Milestones

Security Assessment Report

System Security Plan

Security Information

IIA Conference February 8, 2005 National Institute of Standards and Technology 31

System Security Plan Prepared by the information system owner

Provides an overview of the security requirements for the information system and describes the security controls in place or planned for meeting those requirements

Contains (either as supporting appendices or as references) other key security-related documents for the information system (e.g., risk assessment, contingency plan, incident response plan, system interconnection agreements)

IIA Conference February 8, 2005 National Institute of Standards and Technology 32

RMF: Significant Features (1) Standard categorization method—based on

worst case impact to enterprise if compromise

Supports scalability and prioritization Level of effort commensurate with security

categorization Apply effort to highest impact systems first

Is generic Applies to all types of systems Focuses on the process for the selection,

implementation, & assessment of controls

IIA Conference February 8, 2005 National Institute of Standards and Technology 33

RMF: Significant Features (2)

Master control catalogue derived from many public and private sector sources: CC Part 2

ISO/IEC 17799

COBIT

GAO FISCAM

NIST SP 800-26 Self Assessment Questionnaire

CMS (healthcare)

D/CID 6-3 Requirements

DoD Policy 8500

BITS functional packages

IIA Conference February 8, 2005 National Institute of Standards and Technology 34

RMF: Significant Features (3)

• Minimum/ baseline controls for Low, Moderate, & High impact systems were selected from master control catalogue– Hierarchical– Increase in functionality

Assurance requirements Baseline dependent: one for each baseline Increase control developer/implementer's analysis and

evidence to demonstrate implementation quality, correctness, and confidence

IIA Conference February 8, 2005 National Institute of Standards and Technology 35

RMF: Significant Features (4) Assurance requirements are related to and

support control assessment approach Common security controls concept

Agency-wide (e.g., training, personal security) Site-wide (e.g., physical security, contingency

plan) Common subsystem (e.g., deployed at multiple

sites)

IIA Conference February 8, 2005 National Institute of Standards and Technology 36

RMF: Significant Features (5) C&A for low impact systems

Allows self assessment Scaled level of effort

Controls can be added to the control catalogue and new baselines developed to meet requirements of community-specific applications/systems SCADA/real-time processing Healthcare/HIPPA Financial/Sarbanes-Oxley

IIA Conference February 8, 2005 National Institute of Standards and Technology 37

RMF: Significant Features (6)• Possibility of becoming “due diligence” in

commercial and other sectors through:– Government critical infrastructure liaisons to

private sector counterparts (e.g., energy, financial, transportation)

– Extension of government security standards and requirements to systems operated on behalf of the federal government

• State and local governments

• Contractors and IT service providers

IIA Conference February 8, 2005 National Institute of Standards and Technology 38

Contact Information100 Bureau Drive Mailstop 8930

Gaithersburg, MD USA 20899-8930

Project Manager Administrative SupportDr. Ron Ross Peggy Himes(301) 975-5390 (301) [email protected] [email protected]

Senior Information Security Researchers and Technical SupportMarianne Swanson Dr. Stu Katzke (301) 975-3293 (301) 975-4768 [email protected] [email protected]

Pat Toth Arnold Johnson(301) 975-5140 (301) 975-3247 [email protected] [email protected]

Curt Barker Information and Feedback(301) 975-4768 Web: csrc.nist.gov/[email protected] Comments: [email protected]

IIA Conference February 8, 2005 National Institute of Standards and Technology 39

Part II: Details

• Security Categorization

• Categories Mapping Guidelines

• Security Control Selection

• Security Certification and Accreditation

• Security Control Assessment

• Desired End State/Conclusion

• Security Control Selection Vetting Process

IIA Conference February 8, 2005 National Institute of Standards and Technology 40

Security Categorization

FIPS 199: Standards for Security Categorization of Federal

Information and Information Systems

IIA Conference February 8, 2005 National Institute of Standards and Technology 41

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.

IIA Conference February 8, 2005 National Institute of Standards and Technology 42

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

IIA Conference February 8, 2005 National Institute of Standards and Technology 43

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

IIA Conference February 8, 2005 National Institute of Standards and Technology 44

Security Categorization

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.

Example: An Enterprise Information System

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

SP 800-60

IIA Conference February 8, 2005 National Institute of Standards and Technology 45

Categories Mapping Guidelines

SP 800-60: Guide for Mapping Types of Information and Information Systems to Security Categories,

IIA Conference February 8, 2005 National Institute of Standards and Technology 46

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

IIA Conference February 8, 2005 National Institute of Standards and Technology 47

SP 800-60

• Companion to FIPS 199

• Rationale by Identified Lines of Business

• Offers guidance on Special Factors to be considered in addressing system impact

IIA Conference February 8, 2005 National Institute of Standards and Technology 48

SP 800-60 Overview

• Types of information– Agency-common: administrative, management and support

information

– Mission-based: mission information and service delivery mechanisms

• Service delivery mechanisms provide policy, programmatic, and managerial foundation in support of Federal government operations

• Security attributes of information associated with mission-specific activities will often vary from agency to agency

IIA Conference February 8, 2005 National Institute of Standards and Technology 49

SP 800-60 Overview (concluded)

• Support services and management of resources functions are included in agency-common information types

• Services to citizens and modes of delivery types are included in mission-based information types

IIA Conference February 8, 2005 National Institute of Standards and Technology 50

Security Control Selection(Minimum/Baseline Controls)

NIST Special Publication 800-53: Recommended Security Controls for

Federal Information Systems “Building a National Consensus For Due Diligence in the Application

of Minimum Security Controls for Information Systems”

IIA Conference February 8, 2005 National Institute of Standards and Technology 51

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

Final Publication: December 2005* NIST Special Publication 800-53, “Recommended Security Controls for Federal Information Systems”

(Second public draft September 2004) will provide interim guidance until completion and adoption of FIPS Publication 200. Current draft out for public comment until November 30, 2004.

IIA Conference February 8, 2005 National Institute of Standards and Technology 52

Minimum Security Controls

Minimum security controls, or baseline controls, defined for low-impact, moderate-impact, and high-impact information systems—

Provide a starting point for organizations and communities of interest in their security control selection process

Are used in the context of the organization’s ongoing risk management process

IIA Conference February 8, 2005 National Institute of Standards and Technology 53

Security Categorization

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.

Example: An Enterprise Information System

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

SP 800-60

IIA Conference February 8, 2005 National Institute of Standards and Technology 54

Security Categorization

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.

Example: An Enterprise Information System

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

IIA Conference February 8, 2005 National Institute of Standards and Technology 55

Security Control Structure Functional requirements

Master Security Control Catalogue 17 Control Families Functional requirements for each control in

each family

Assurance requirements Dependent on the baseline the control is in Includes: Low, Moderate, High, and Additional

Assurance Requirements Supplementing the High Baseline

IIA Conference February 8, 2005 National Institute of Standards and Technology 56

Security Control StructureControl Requirements: Functional

Simplified structure consisting of three sections: Basic level security control statement Supplemental guidance Control enhancements

Example: Contingency Planning (CP) Family CP-7 Alternate Processing Site

IIA Conference February 8, 2005 National Institute of Standards and Technology 57

CP-7 ALTERNATE PROCESSING SITES

Control: The organization identifies an alternate processing site and initiates necessary agreements to permit the resumption of information system operations for critical mission/business functions within [Assignment: organization-defined time period] when the primary processing capabilities are unavailable.Supplemental Guidance: Equipment and supplies required to resume operations within the organization-defined time period are either available at the alternate site or contracts are in place to support delivery to the site.Control Enhancements:(1)     The alternate processing site is geographically separated from the primary processing site so as not to be susceptible to the same hazards.(2)     The organization identifies potential accessibility problems to the alternate processing site in the event of an area-wide disruption or disaster and outlines explicit mitigation actions.(3)     Alternate processing site agreements contain priority-of-service provisions in accordance with the organization’s availability requirements.(4)     The alternate processing site is fully configured to support a minimum required operational capability and ready to use as the operational site.

IIA Conference February 8, 2005 National Institute of Standards and Technology 58

Security Control BaselinesFunctional

Minimum Security ControlsLow Impact

Information Systems

Minimum Security ControlsHigh Impact

Information Systems

Minimum Security ControlsModerate Impact

Information Systems

Master Security Control Catalog

Complete Set of Security Controls and Control Enhancements

Baseline #1

Selection of a subset of security controls from the master catalog—consisting of basic level controls

Baseline #2

Builds on low baseline. Selection of a subset of controls from the

master catalog—basic level controls, additional controls, and

control enhancements

Baseline #3

Builds on moderate baseline. Selection of a subset of controls from the master catalog—basic

level controls, additional controls, and control enhancements

IIA Conference February 8, 2005 National Institute of Standards and Technology 59

Contingency Planning FamilyContingency Planning Policy & Procedures

CP-1 CP-1 CP-1

Contingency Plan CP-2 CP-2 (1) CP-2 (1)

Contingency Training Not Selected

CP-3 CP-3 (1) (2)

Contingency Plan Testing Not Selected

CP-4 (1) CP-4 (1) (2) (3)

Contingency Plan Update CP-5 CP-5 CP-5

Alternate Storage Sites Not Selected

CP-6 (1) CP-6 (1) (2) (3)

Alternate Processing Sites Not Selected

CP-7 (1) (2) (3)

CP-7 (1) (2) (3)

(4)Alternate Telecommunications Services

Not Selected

CP-8 (1) (2)

CP-8 (1) (2) (3)

(4)Information System Backup CP-9 CP-9 (1) CP-9 (1)

(2) (3)

Information System Recovery & Reconstitution

CP-10 CP-10 CP-10 (1)

IIA Conference February 8, 2005 National Institute of Standards and Technology 60

Security Control StructureControl Requirements: Assurance

Single assurance requirement for each baseline

Applies to each control in the baseline Low impact Moderate impact High impact

Additional assurance requirements for supplementing the high baseline

IIA Conference February 8, 2005 National Institute of Standards and Technology 61

Assurance Rational/approach Assurance: Specify developer and implementer actions

during system development process to ensure controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system

Assessment: Specify security control assessor’s actions during the testing and evaluation process to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system

IIA Conference February 8, 2005 National Institute of Standards and Technology 62

Assurance Requirements (1)

Low Baseline

Assurance Requirement: The security control is in effect and meets explicitly identified functional requirements in the control statement.

Supplemental Guidance: For security controls in the low baseline, the focus is on the control being in place with the expectation that no obvious errors exist and that, as flaws are discovered, they are addressed in a timely manner.

IIA Conference February 8, 2005 National Institute of Standards and Technology 63

Assurance Requirements (2)Moderate BaselineAssurance Requirement: The security control is in effect and meets

explicitly identified functional requirements in the control statement. The control developer/implementer provides a description of the functional properties of the control with sufficient detail to permit analysis and testing of the control. The control developer/implementer includes as an integral part of the control, assigned responsibilities and specific actions to ensure that when the control is implemented, it will meet its required function or purpose. These actions may include, for example, requiring the development of records with structure and content suitable to facilitate making this determination.

Supplemental Guidance: For security controls in the moderate baseline, the focus is on ensuring correct implementation and operation of the control. While flaws are still likely to be uncovered (and addressed expeditiously), the control developer/implementer incorporates, as part of the control, specific capabilities and produces specific documentation to ensure the control meets its required function or purpose

IIA Conference February 8, 2005 National Institute of Standards and Technology 64

Assurance Requirements (3)High BaselineAssurance Requirement: The security control is in effect and meets explicitly

identified functional requirements in the control statement. The control developer/implementer provides a description of the functional properties and design/implementation of the control with sufficient detail to permit analysis and testing of the control (including functional interfaces among control components). The control developer/implementer includes as an integral part of the control, assigned responsibilities and specific actions to ensure that when the control is implemented, it will continuously and consistently (i.e., across the information system) meet its required function or purpose and support improvement in the effectiveness of the control. These actions may include, for example, requiring the development of records with structure and content suitable to facilitate making this determination.

Supplemental Guidance: For security controls in the high baseline, the focus is expanded to require, within the control, the capabilities that are needed to support ongoing consistent operation of the control and continuous improvement in the control’s effectiveness. The developer/implementer is expected to expend significant effort on the design, development, implementation, and testing of the controls and to produce associated design and implementation documentation to support these activities. For security controls in the high baseline, this same documentation is needed by assessors to analyze and test the internal components of the control as part of the overall assessment of the control.

IIA Conference February 8, 2005 National Institute of Standards and Technology 65

Assurance Requirements (4)Additional Requirements Supplementing the High BaselineAssurance Requirement: The security control is in effect and meets explicitly

identified functional requirements in the control statement. The control developer/implementer provides a description of the functional properties and design/implementation of the control with sufficient detail to permit analysis and testing of the control (including functional interfaces among control components). The control developer/implementer includes as an integral part of the control, assigned responsibilities and specific actions to ensure that when the control is implemented, it will continuously and consistently (i.e., across the information system) meet its required function or purpose and support improvement in the effectiveness of the control. These actions include, for example, requiring the development of records with structure and content suitable to facilitate making this determination. The control is developed in a manner that supports a high degree of confidence that the control is complete, consistent, and correct.

Supplemental Guidance: The additional high assurance requirements are intended to supplement the minimum assurance requirements for the high baseline, when appropriate, in order to protect against threats from highly skilled, highly motivated, and well-financed threat agents. This level of protection is required for those information systems where the organization is not willing to accept the risks associated with the type of threat agents cited above.

IIA Conference February 8, 2005 National Institute of Standards and Technology 66

Minimum Baselines Low

For each family, appropriate controls selected from control catalogue Not all controls in family selected No enhancements Low Assurance Requirements

Moderate Includes all controls in Low baseline with (possibly) enhancements For each family, additional appropriate controls selected from control catalogue with

(possibly) enhancements Moderate Assurance Requirements

High Includes all controls in Moderate baseline with (possibly) additional enhancements For each family, additional appropriate controls selected from control catalogue with

(possibly) enhancements High Assurance Requirements

• High

IIA Conference February 8, 2005 National Institute of Standards and Technology 67

Security Control SelectionMinimum Requirements

• Begin with security categorization triple from security categorization standard (FIPS 199)

• Reduce triple to a single security category of Low, Moderate, or High Impact

• Select control baselines for the impact level • Apply tailoring guidance• Select minimum assurance requirement for the

impact level• Final set is input to security control refinement

(i.e., risk analysis process)

IIA Conference February 8, 2005 National Institute of Standards and Technology 68

Tailoring the initial baselines• Scoping Guidance Considerations

– Technology-related – Infrastructure-related – Public access-related – Scalability-related – Common security control-related– Risk-related /downgrading

• Organization-Defined Security Control Parameters

• Compensating Security Controls

IIA Conference February 8, 2005 National Institute of Standards and Technology 69

Requirements Traceability

Security ControlsSP 800-53 / FIPS 200

Security ControlsSP 800-53 / FIPS 200

Security ControlsSP 800-53 / FIPS 200

High Level Security Requirements

Derived from Legislation, Executive Orders, Policies, Directives, Regulations, Standards

Examples: HIPAA, Graham-Leach-Bliley, Sarbanes-Oxley, FISMA, OMB Circular A-130

What set of security controls, if implemented within an information system and determined to be effective, can show compliance to a particular set of security requirements?

Enterprise #1 Enterprise #2 Enterprise #3

IIA Conference February 8, 2005 National Institute of Standards and Technology 70

The Development and Vetting of SP 800-53

IIA Conference February 8, 2005 National Institute of Standards and Technology 71

Development Strategy First, develop mandatory security categorization

standards for federal information and information systems (FIPS 199)

Next, develop recommended (minimum) security controls for federal information systems as an 800-series guidance document (NIST SP 800-53)

Finally, develop mandatory (minimum) security control standards for federal information systems (FIPS 200)

IIA Conference February 8, 2005 National Institute of Standards and Technology 72

Consensus-Building ProcessNIST Special Publication 800-53 Employ extensive vetting process for Special

Publication 800-53 Three full published drafts of document Three public comment periods to obtain feedback from

the public and private sectors

Carefully assess feedback received during the public comment periods; incorporate material into publication, as appropriate

Provide sufficient time for organizations to become familiar with Special Publication 800-53 before transitioning to FIPS 200

IIA Conference February 8, 2005 National Institute of Standards and Technology 73

Special Publication 800-53 Formal and informal comments received from a

wide variety of constituencies in the public and private sectors including— Federal, State, and Local Governments Critical Infrastructure Entities (e.g., power companies,

telecommunications providers) Fortune 500 Companies Healthcare Providers Financial Industry Consortia (e.g., National Realtors Association) Private citizens

IIA Conference February 8, 2005 National Institute of Standards and Technology 74

Significant Comments Received over 800 comments on the initial public

draft of Special Publication 800-53 Comments indicated that—

Security controls contained too much implementation detail

Security control baselines (low, moderate, high) included too many controls for a minimum set

There was insufficient flexibility in the security control selection process for organizations to effectively apply the controls in specific operational environments

The “high-water mark” approach required organizations to employ unnecessary security controls

IIA Conference February 8, 2005 National Institute of Standards and Technology 75

NIST Response In response to the initial public comments, NIST

re-engineered Special Publication 800-53 Fundamental changes included—

Streamlining the security control structure and control content to focus on “token-level” requirements

Redesigning the security control enhancement approach to facilitate ease-of-use for organizations requiring additional security controls based on risk assessment

Incorporating scoping guidance to help organizations effectively apply the NIST guidance in specific operational environments

Reducing the number of security controls in the control baselines

IIA Conference February 8, 2005 National Institute of Standards and Technology 76

Significant Comments Received over 400 comments on the second public draft of Special Publication 800-53

Comments indicated that—There was overwhelming approval of the reengineered

approach and the simplification of the documentSecurity control baselines (low, moderate, high) still

contained too many controls for a minimum setThe scoping guidance needed to be strengthened to

added even greater flexibility in the security control selection and specification process

Organizations wanted the return of the security control classes (i.e., management, operational, and technical) which had been previously eliminated

IIA Conference February 8, 2005 National Institute of Standards and Technology 77

NIST Response In response to the second round of public

comments, NIST made a few minor modifications— Changes included—

Modifying the scoping guidance to allow organizations to eliminate security controls from the control baselines under strict terms and conditions consistent with FIPS 199 security categorizations

Adjusting the security control baselines again to facilitate cost-effective, risk-based application of security controls

Adding several new security controls to the control catalog; eliminating a few controls from the catalog

Expanding the security control mapping table to include DCID 6/3 and DoD 8500.2

IIA Conference February 8, 2005 National Institute of Standards and Technology 78

Key Milestones NIST Special Publication 800-53

Initial Public Draft (October 2003) Second Public Draft (September 2004) Final Public Draft (January 2005) Final Publication (February 2005)

FIPS 200 Initial Public Draft (Projected for May 2005) Second Public Draft (Projected for August 2005) Final Publication (Projected for December 2005)

IIA Conference February 8, 2005 National Institute of Standards and Technology 79

Summary Public vetting process proved extremely effective

and allowed NIST to build a truly consensus-based security guideline to serve both public and private sector needs

Extended development cycle and expanded public review periods allowed federal agencies to be better prepare for the transition to FIPS 200, when the security controls become mandatory

Increasing voluntary acceptance of NIST Special Publication 800-53 by the private sector will help provide greater information security for the nation’s critical infrastructure

IIA Conference February 8, 2005 National Institute of Standards and Technology 80

Certification and Accreditation (C&A)

NIST Special Publication 800-37Guide for the Security Certification and Accreditation

of Federal Information Systems

An Introductory Tutorial

IIA Conference February 8, 2005 National Institute of Standards and Technology 81

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

IIA Conference February 8, 2005 National Institute of Standards and Technology 82

Contents Introduction

The Fundamentals

The Process

Summary

IIA Conference February 8, 2005 National Institute of Standards and Technology 83

C&A Part I

Introduction

IIA Conference February 8, 2005 National Institute of Standards and Technology 84

National Policy

Office of Management and Budget Circular A-130,Management of Federal Information Resourcesrequires federal agencies to:

Plan for security

Ensure that appropriate officials are assigned security responsibility

Authorize system processing prior to operations and periodically, thereafter

IIA Conference February 8, 2005 National Institute of Standards and Technology 85

Security Controls

The management, operational, and technical controls (i.e., safeguards or countermeasures) prescribed for an information system to protect the confidentiality, integrity, and availability of the system and its information.-- [FIPS Publication 199]

IIA Conference February 8, 2005 National Institute of Standards and Technology 86

Key Questions What security controls are needed to adequately

protect an information system that supports the operations and assets of the organization?

Have the selected security controls been implemented or is there a realistic plan for their implementation?

To what extent are the security controls implemented correctly, operating as intended, and producing the desired outcome with respect to meeting information security requirements?

IIA Conference February 8, 2005 National Institute of Standards and Technology 87

Certification and AccreditationFISMA and OMB Requirements

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

IIA Conference February 8, 2005 National Institute of Standards and Technology 88

Purpose and ApplicabilitySpecial Publication 800-37

Provides guidelines for certifying and accrediting information systems supporting the executive agencies of the federal government

Applies to all federal information systems other than those systems designated as national security systems as defined in FISMA

Replaces Federal Information Processing Standards (FIPS) Publication 102

IIA Conference February 8, 2005 National Institute of Standards and Technology 89

Significant BenefitsSpecial Publication 800-37

Helping to achieve more secure information systems within the federal government by:

Enabling more consistent, comparable, and repeatable assessments of security controls in federal information systems

Promoting a better understanding of agency-related mission risks resulting from the operation of information systems

Creating more complete, reliable, and trustworthy information for authorizing officials—facilitating more informed accreditation decisions

IIA Conference February 8, 2005 National Institute of Standards and Technology 90

Information Security Programs

Question

How do security certificationand accreditation fit into an agency’s

information security program?

IIA Conference February 8, 2005 National Institute of Standards and Technology 91

Information Security Programs

Answer

Security certification and accreditationare important activities that support arisk management process and are anintegral part of an agency’s overall

information security program.

IIA Conference February 8, 2005 National Institute of Standards and Technology 92

Risk Management

Adversaries attack the weakest link…where is yours?

Risk assessment Security planning Security policies and procedures Contingency planning Incident response planning Physical security Personnel security Security assessments Security accreditation

Access control mechanisms Identification & authentication mechanisms (Biometrics, tokens, passwords) Audit mechanisms Encryption mechanisms Firewalls and network security mechanisms Intrusion detection systems Anti-viral software Smart cards

Links in the Security Chain: Management, Operational, and Technical Controls

IIA Conference February 8, 2005 National Institute of Standards and Technology 93

Managing Agency Risk Key activities in managing agency-level risk—risk resulting

from the operation of an information system:

Categorize the information systemSelect set of minimum (baseline) security controlsRefine the security control set based on risk assessmentDocument security controls in system security planImplement the security controls in the information systemAssess the security controls (C&A)Determine agency-level risk and risk acceptability (C&A)Authorize information system operation (C&A)Monitor security controls on a continuous basis (C&A)

IIA Conference February 8, 2005 National Institute of Standards and Technology 94

FISMA Implementation Project:Risk Management Framework (RMF)

In system security plan, provides a an overview of the security requirements for

the information system and documents the security controls planned or in place

SP 800-18

Security Control Documentation

Defines category of information system according to potential

impact of loss

FIPS 199 / SP 800-60

Security Categorization

Selects minimum security controls (i.e., safeguards and countermeasures) planned or

in place to protect the information system

SP 800-53 / FIPS 200

Security Control Selection

Determines extent to which the security controls are implemented correctly, operating as intended, and producing desired outcome with respect to meeting security requirements

SP 800-53A / SP 800-37

Security Control Assessment

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

SP 800-37

System Authorization

Determines risk to agency operations, agency assets, or individuals and, if acceptable,

authorizes information system processing

SP 800-37

Security Control Monitoring

Continuously tracks changes to the information system that may affect security controls and

assesses control effectiveness

Implements security controls in new or legacy information systems; implements security configuration

checklists

Security Control Implementation

SP 800-64/SP 800-70

IIA Conference February 8, 2005 National Institute of Standards and Technology 95

The Desired End StateSecurity Visibility Among Business/Mission Partners

Organization One

Information System

Plan of Action and Milestones

Security Assessment Report

System Security Plan

Determining the risk to the first organization’s operations and assets and

the acceptability of such risk

Business / MissionInformation Flow

The objective is to achieve visibility into prospective business/mission partners information security programs BEFORE critical/sensitive communications begin…establishing levels of security due diligence.

Determining the risk to the second organization’s operations and assets and

the acceptability of such risk

Organization Two

Information System

Plan of Action and Milestones

Security Assessment Report

System Security Plan

Security Information

IIA Conference February 8, 2005 National Institute of Standards and Technology 96

C&A Part II

The Fundamentals

IIA Conference February 8, 2005 National Institute of Standards and Technology 97

Security Accreditation

Official management decision given by a senior agency official to authorize operation of an information system and to explicitly accept the risk to agency operations (including mission, functions, image, or reputation), agency assets, or individuals, based on the implementation of an agreed upon set of security controls.

IIA Conference February 8, 2005 National Institute of Standards and Technology 98

Security Certification

Comprehensive assessment of the management, operational, and technical security controls in an information system, made in support of security accreditation, to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system.

IIA Conference February 8, 2005 National Institute of Standards and Technology 99

Key Roles Authorizing Official

Authorizing Official Designated Representative

Chief Information Officer

Senior Agency Information Security Officer

Information System Owner

Information System Security Officer

Certification Agent

User Representatives

IIA Conference February 8, 2005 National Institute of Standards and Technology 10

0

Authorizing Official Reviews and approves the security categorizations of

information systems

Reviews and approves system security plans

Determines agency-level risk from information generated during the security certification

Makes accreditation decisions and signs associated transmittal letters for accreditation packages (authorizing official only)

Reviews security status reports from continuous monitoring operations; initiates reaccreditation actions

IIA Conference February 8, 2005 National Institute of Standards and Technology 10

1

Designated Representative Selected by the authorizing official to coordinate and

carry out the necessary activities required during the security certification and accreditation process

Empowered to make certain decisions with regard to the: Planning and resourcing of the security certification and accreditation

activities

Acceptance of the system security plan

Determination of risk to agency operations, assets, and individuals

Prepares accreditation decision letter

Obtains authorizing official’s signature on the accreditation decision letter and transmits accreditation package to appropriate agency officials

IIA Conference February 8, 2005 National Institute of Standards and Technology 10

2

Chief Information Officer Designates a senior agency information security officer

Develops and maintains information security policies, procedures, and control techniques to address all applicable requirements

Trains and oversees personnel with significant responsibilities for information security

Assists senior agency officials concerning their security responsibilities

Coordinates with other senior agency officials, reporting annually to the agency head on the effectiveness of the agency information security program

IIA Conference February 8, 2005 National Institute of Standards and Technology 10

3

Senior Agency Information Security Officer

Serves in a position with primary responsibilities and duties related to information security

Carries out the Chief Information Officer responsibilities under FISMA

Possesses professional qualifications required to administer information security program functions

Heads an office with the mission and resources to assist in ensuring agency compliance with FISMA

IIA Conference February 8, 2005 National Institute of Standards and Technology 10

4

Information System Owner Procures, develops, integrates, modifies, operates or

maintains an information system

Prepares system security plan and conducts risk assessment

Informs agency officials of the need for certification and accreditation; ensures appropriate resources are available

Provides necessary system-related documentation to the certification agent

Prepares plan of action and milestones to reduce or eliminate vulnerabilities in the information system

Assembles final accreditation package and submits to authorizing official

IIA Conference February 8, 2005 National Institute of Standards and Technology 10

5

Information System Security Officer Serves as principal staff advisor to the system owner on

all matters involving the security of the information system

Manages the security aspects of the information system and, in some cases, oversees the day-to-day security operations of the system

Assists the system owner in: Developing and enforcing security policies for the information

system Assembling the security accreditation package Managing and controlling changes to the information system

and assessing the security impacts of those changes

IIA Conference February 8, 2005 National Institute of Standards and Technology 10

6

Certification Agent Provides an independent assessment of the system

security plan

Assesses the security controls in the information system to determine the extent to which the controls are:

Implemented correctly;

Operating as intended; and

Producing the desired outcome with respect to meeting the security requirements of the system

Provides recommended corrective actions to reduce or eliminate vulnerabilities in the information system

IIA Conference February 8, 2005 National Institute of Standards and Technology 10

7

User Representatives Represent the operational interests and mission needs of

the user community

Identify mission and operational requirements

Serve as liaisons for the user community throughout the system development life cycle

Assist in the security certification and accreditation process, when needed

IIA Conference February 8, 2005 National Institute of Standards and Technology 10

8

Other Supporting Roles Information Owner

Operations Manager

Facilities Manager

System Administrator

IIA Conference February 8, 2005 National Institute of Standards and Technology 10

9

Accreditation Boundaries

Uniquely assigning information resources to an Uniquely assigning information resources to an information system defines the security information system defines the security accreditation boundary for that systemaccreditation boundary for that system

Agencies have great flexibility in determining Agencies have great flexibility in determining what constitutes an information system and the what constitutes an information system and the resulting accreditation boundary that is resulting accreditation boundary that is associated with that systemassociated with that system

IIA Conference February 8, 2005 National Institute of Standards and Technology 11

0

Accreditation Boundaries If a set of information resources is identified as an If a set of information resources is identified as an

information system, the resources should generally information system, the resources should generally be under the same direct management controlbe under the same direct management control

Consider if the information resources being Consider if the information resources being identified as an information system—identified as an information system— Have the same function or mission objective and Have the same function or mission objective and

essentially the same operating characteristics and security essentially the same operating characteristics and security needsneeds

Reside in the same general operating environment (or in Reside in the same general operating environment (or in the case of a distributed information system, reside in the case of a distributed information system, reside in various locations with similar operating environments)various locations with similar operating environments)

IIA Conference February 8, 2005 National Institute of Standards and Technology 11

1

Large and Complex Systems

• System security plan reflects information system decomposition with adequate security controls assigned to each subsystem component

• Security assessment methods and procedures tailored for the security controls in each subsystem component and for the combined system-level controls

• Security certification performed on each subsystem component and on system-level controls not covered by subsystem certifications

• Security accreditation performed on the information system as a whole

Accreditation Boundary

SubsystemComponent

Local Area NetworkAlpha

SubsystemComponent

System Guard

SubsystemComponent

Local Area NetworkBravo

Agency General Support System

IIA Conference February 8, 2005 National Institute of Standards and Technology 11

2

Common Security Controls Common security controls are those controls that

can be applied to one or more agency information systems and have the following properties:

The development, implementation, and assessment of common security controls can be assigned to responsible officials or organizational elements (other than the information system owner)

The results from the assessment of the common security controls can be reused in security certifications and accreditations of agency information systems where those controls have been applied

IIA Conference February 8, 2005 National Institute of Standards and Technology 11

3

Common Security Controls Identification of common security controls is an

agency-level activity in collaboration with Chief Information Officer, senior agency information security officer, authorizing officials, information system owners, and information system security officers

Potential for significant cost savings for the agency in security control development, implementation, and assessment

IIA Conference February 8, 2005 National Institute of Standards and Technology 11

4

Common Security Controls Common security controls can be applied

agency-wide, site-wide, or to common subsystems and assessed accordingly—For example: Contingency planning Incident response planning Security training and awareness Physical and personnel security * Common hardware, software, or firmware **

* Related to the concept of site certification in certain communities** Related to the concept of type certification in certain communities

IIA Conference February 8, 2005 National Institute of Standards and Technology 11

5

Common Security Controls

Example: Moderate ImpactAgency Information Systems

Responsibility of Information System Owners

Common Security Controls

System Specific Security Controls

Responsibility of Designated Agency Official Other Than Information System Owner (e.g., Chief Information Officer, Facilities Manager, etc.)

• Common security controls developed, implemented, and assessed one time by designated agency official(s)

• Development and implementation cost amortized across all agency information systems

• Results shared among all information system owners and authorizing officials where common security controls are applied

• Maximum re-use of assessment evidence during security certification and accreditation of information systems

• Security assessment reports provided to information system owners to confirm the security status of common security controls

• Assessments of common security controls not repeated; only system specific aspects when necessary

IIA Conference February 8, 2005 National Institute of Standards and Technology 11

6

Accreditation Decisions

Authorization To Operate

Interim Authorization To Operate

Denial of Authorization to Operate

IIA Conference February 8, 2005 National Institute of Standards and Technology 11

7

Authorization to Operate Risk to agency operations, agency assets, or

individuals is deemed acceptable to the authorizing official

Information system is accredited without any significant restrictions or limitations on its operation

Authorizing officials may recommend specific actions be taken to reduce or eliminate identified vulnerabilities, where it is cost effective to do so

IIA Conference February 8, 2005 National Institute of Standards and Technology 11

8

Interim Authorization To Operate Risk to agency operations, agency assets, or

individuals is not deemed acceptable to the authorizing official, but there is an overarching mission necessity to place the information system into operation or continue its operation

Significant deficiencies in the security controls in the information system but the deficiencies can be addressed in a timely manner

Acknowledges greater risk to the agency for a limited period of time

IIA Conference February 8, 2005 National Institute of Standards and Technology 11

9

Interim Authorization To Operate Limited authorization to operate the information

system under specific terms and conditions established by the authorizing official

Information system is not accredited during the period of limited authorization to operate

At the end of the period of limited authorization, the information system should either meet the requirements for being authorized or not be authorized for further operation

IIA Conference February 8, 2005 National Institute of Standards and Technology 12

0

Denial of Authorization to Operate The residual risk to the agency’s operations or

assets is deemed unacceptable to the authorizing official

Information system is not accredited and should not be placed into operation—or for an information system currently in operation, all activity should be halted

Major deficiencies in the security controls in the information system—corrective actions should be initiated immediately

IIA Conference February 8, 2005 National Institute of Standards and Technology 12

1

Accreditation Package

System security plan

Security assessment report

Plan of action and milestones

IIA Conference February 8, 2005 National Institute of Standards and Technology 12

2

Accreditation Package Documents the results of the security certification

Provides the authorizing official with the essential information needed to make a credible risk-based decision on whether to authorize operation of the information system

Uses inputs from the information system security officer and the certification agent

IIA Conference February 8, 2005 National Institute of Standards and Technology 12

3

System Security Plan Prepared by the information system owner

Provides an overview of the security requirements for the information system and describes the security controls in place or planned for meeting those requirements

Contains (either as supporting appendices or as references) other key security-related documents for the information system (e.g., risk assessment, contingency plan, incident response plan, system interconnection agreements)

IIA Conference February 8, 2005 National Institute of Standards and Technology 12

4

Security Assessment Report Prepared by the certification agent

Provides the results of assessing the security controls in the information system to determine the extent to which the controls are: Implemented correctlyOperating as intendedProducing the desired outcome with respect to meeting

the system security requirements

Contains a list of recommended corrective actions

IIA Conference February 8, 2005 National Institute of Standards and Technology 12

5

Plan of Action and Milestones Prepared by the system owner

Reports progress made on current outstanding items listed in the plan

Addresses vulnerabilities in the information system discovered during certification, security impact analysis, or security control monitoring

Describes how the information system owner intends to address those vulnerabilities (i.e., reduce, eliminate, or accept vulnerabilities)

IIA Conference February 8, 2005 National Institute of Standards and Technology 12

6

Accreditation Decision Letter Constructed from information provided by the

information system owner in the accreditation package

Consists of: Accreditation decision Supporting rationale for the decision Specific terms and conditions imposed on the

system owner

The contents of security certification and accreditation-related documentation (especially information dealing with system vulnerabilities) should be marked and protected appropriately in accordance with agency policy.

IIA Conference February 8, 2005 National Institute of Standards and Technology 12

7

C&A Part III

The Process

IIA Conference February 8, 2005 National Institute of Standards and Technology 12

8

The Process Initiation Phase

Security Certification Phase

Security Accreditation Phase

Continuous Monitoring Phase

IIA Conference February 8, 2005 National Institute of Standards and Technology 12

9

Initiation PhaseMajor Tasks and Subtasks

Task 1: Preparation Subtask 1.1: Information System Description Subtask 1.2: Security Categorization Subtask 1.3: Threat Identification Subtask 1.4: Vulnerability Identification Subtask 1.5: Security Control Identification Subtask 1.6: Initial Risk Determination

Task 2: Notification and Resource Identification Subtask 2.1: Notification Subtask 2.2: Planning and Resources

IIA Conference February 8, 2005 National Institute of Standards and Technology 13

0

Initiation PhaseMajor Tasks and Subtasks

Task 3: System Security Plan Analysis, Update, and Acceptance Subtask 3.1: Security Categorization Review Subtask 3.2: System Security Plan Analysis Subtask 3.3: System Security Plan Update Subtask 3.4: System Security Plan Acceptance

IIA Conference February 8, 2005 National Institute of Standards and Technology 13

1

Security Certification PhaseMajor Tasks and Subtasks

Task 4: Security Control Assessment Subtask 4.1: Documentation and Supporting Materials Subtask 4.2: Methods and Procedures Subtask 4.3: Security Assessment Subtask 4.4: Security Assessment Report

Task 5: Security Certification Documentation Subtask 5.1: Findings and Recommendations Subtask 5.2: System Security Plan Update Subtask 5.3: Plan of Action and Milestones Preparation Subtask 5.4: Accreditation Package Assembly

IIA Conference February 8, 2005 National Institute of Standards and Technology 13

2

Security Accreditation PhaseMajor Tasks and Subtasks

Task 6: Accreditation Decision Subtask 6.1: Final Risk Determination Subtask 6.2: Risk Acceptability

Task 7: Accreditation Documentation Subtask 7.1: Accreditation Package Transmission Subtask 7.2: System Security Plan Update

IIA Conference February 8, 2005 National Institute of Standards and Technology 13

3

Continuous Monitoring PhaseMajor Tasks and Subtasks

Task 8: Configuration Management and Control Subtask 8.1: Documentation of System Changes Subtask 8.2: Security Impact Analysis

Task 9: Security Control Monitoring Subtask 9.1: Security Control Selection Subtask 9.2: Selected Security Control Assessment

Task 10: Status Reporting and Documentation Subtask 10.1: System Security Plan Update Subtask 10.2: Plan of Action and Milestones Update Subtask 10.3: Status Reporting

IIA Conference February 8, 2005 National Institute of Standards and Technology 13

4

Certification and AccreditationFor Low Impact Information Systems

Incorporates the use of self-assessment activities

Reduces the associated level of supporting documentation and paperwork

Decreases the time spent conducting assessment-related activities

Significantly reduces costs to the agency without increasing agency-level risk or sacrificing the overall security of the information system.

IIA Conference February 8, 2005 National Institute of Standards and Technology 13

5

C&A Part IV

Summary

IIA Conference February 8, 2005 National Institute of Standards and Technology 13

6

Special Publication 800-37Intended to promote and facilitate—

More consistent, comparable, and repeatable assessments of information systems

More complete and reliable security-related information for authorizing officials

A better understanding of complex information systems and associated risks and vulnerabilities

IIA Conference February 8, 2005 National Institute of Standards and Technology 13

7

Security Control Assessments(Currently in-development)

NIST Special Publication 800-53A: Guide for Assessing the Security Controls in Federal

Information Systems

A Framework for Developing Assessment Procedures for controls in SP 800-53

IIA Conference February 8, 2005 National Institute of Standards and Technology 13

8

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: Winter 2004-05

IIA Conference February 8, 2005 National Institute of Standards and Technology 13

9

FISMA Implementation Project:Risk Management Framework (RMF)

In system security plan, provides a an overview of the security requirements for

the information system and documents the security controls planned or in place

SP 800-18

Security Control Documentation

Defines category of information system according to potential

impact of loss

FIPS 199 / SP 800-60

Security Categorization

Selects minimum security controls (i.e., safeguards and countermeasures) planned or

in place to protect the information system

SP 800-53 / FIPS 200

Security Control Selection

Determines extent to which the security controls are implemented correctly, operating as intended, and producing desired outcome with respect to meeting security requirements

SP 800-53A / SP 800-37

Security Control Assessment

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

SP 800-37

System Authorization

Determines risk to agency operations, agency assets, or individuals and, if acceptable,

authorizes information system processing

SP 800-37

Security Control Monitoring

Continuously tracks changes to the information system that may affect security controls and

assesses control effectiveness

Implements security controls in new or legacy information systems; implements security configuration

checklists

Security Control Implementation

SP 800-64/SP 800-70

IIA Conference February 8, 2005 National Institute of Standards and Technology 14

0

Contingency Planning FamilyContingency Planning Policy & Procedures

CP-1 CP-1 CP-1

Contingency Plan CP-2 CP-2 (1) CP-2 (1)

Contingency Training Not Selected

CP-3 CP-3 (1) (2)

Contingency Plan Testing Not Selected

CP-4 (1) CP-4 (1) (2) (3)

Contingency Plan Update CP-5 CP-5 CP-5

Alternate Storage Sites Not Selected

CP-6 (1) CP-6 (1) (2) (3)

Alternate Processing Sites Not Selected

CP-7 (1) (2) (3)

CP-7 (1) (2) (3)

(4)Alternate Telecommunications Services

Not Selected

CP-8 (1) (2)

CP-8 (1) (2) (3)

(4)Information System Backup CP-9 CP-9 (1) CP-9 (1)

(2) (3)

Information System Recovery & Reconstitution

CP-10 CP-10 CP-10 (1)

IIA Conference February 8, 2005 National Institute of Standards and Technology 14

1

The Conceptual Model

AssessmentMethods

InterviewExamine

Test

Security ControlNumber

Baseline

Assessment Procedure

Input

Process

Output

Framework

Example: First security control in Contingency Planning Family

{CP-1, low} {Interview, Examine} Assessment Procedure CP-1

IIA Conference February 8, 2005 National Institute of Standards and Technology 14

2

Assessment Methods Interview

The process of conducting focused discussions with organizational personnel to facilitate understanding, achieve clarification, or obtain evidence

ExamineThe process of checking, inspecting, reviewing, observing, studying, or analyzing an assessment object to generate a verdict or to reach a conclusion

TestThe process of exercising an assessment object under specified conditions, observing and recording the results, and comparing the actual with the expected behavior

IIA Conference February 8, 2005 National Institute of Standards and Technology 14

3

Assessment Objects • Specifications: primarily a document-type control

– Examples: policies, plans, procedures, system requirements, designs

• Activities: primarily a people-oriented control but may be supported by IT mechanisms– Examples: system operations, system administration, management,

exercises, drills

• Mechanisms: primarily implemented in hardware, software, firmware but may require human interaction/support– Examples: I&A, Audit Trails, Access Control, physical devices,

communications protection/cryptography

IIA Conference February 8, 2005 National Institute of Standards and Technology 14

4

Interview Attributes Coverage

Addresses the types of individuals to be interviewed (by organizational roles and associated responsibilities) and the number of individuals to be interviewed (by type).

ApproachAddresses the formality of the interview process. There are two potential values for the approach attribute: (i) informal/unstructured; and (ii) formal/structured.

DepthAddresses the rigor of and level of detail in the interview process. There are three possible values for the depth attribute: (i) cursory; (ii) exploratory; and (iii) comprehensive.

IIA Conference February 8, 2005 National Institute of Standards and Technology 14

5

Examine Attributes Coverageddresses the types of assessment objects to be examined and the number

of objects to be examined (by type).

Approachddresses the formality of the examination process. There are two

potential values for the approach attribute: (i) informal/unstructured; and (ii) formal/structured.

Depthddresses the rigor of and level of detail in the examination process.

There are three possible values for the depth attribute: (i) cursory; (ii) exploratory; and (iii) comprehensive.

IIA Conference February 8, 2005 National Institute of Standards and Technology 14

6

Test Attributes Scope

Addresses the types of testing to be conducted. There are three potential values for the scope attribute: (i) black-box testing; (ii) gray-box testing; and (iii) penetration testing.

Coverageddresses the types of assessment objects to be tested and the number of

objects to be tested (by type).

Approachddresses the formality of the testing process. There are two potential

values for the approach attribute: (i) informal/unstructured; and (ii) formal/structured.

DepthAddresses the rigor of and level of detail in the testing process. There are three possible values for the depth attribute: (i) cursory; (ii) exploratory; and (iii) comprehensive.

IIA Conference February 8, 2005 National Institute of Standards and Technology 14

7

Assurance Attribute Applicable to all assessment methods

Addresses the expectation of the assessor in assessing the implementation of the security control

Values for the assurance attributes are derived directly from the minimum assurance requirements described in NIST Special Publication 800-53

IIA Conference February 8, 2005 National Institute of Standards and Technology 14

8

Assurance Attribute Low Impact Systemshe focus is on the control being in place with the expectation that no obvious

errors exist and that, as flaws are discovered, they are addressed in a timely manner.

Moderate Impact SystemsThe focus is on ensuring that the control is implemented correctly and operating as intended. While flaws are still likely to be uncovered (and addressed expeditiously), the control developer/implementer incorporates, as part of the control, specific capabilities to ensure the control meets its function or purpose.

High Impact SystemsThe focus is expanded to require, within the control, the capabilities that are needed to support continuous and consistent operation of the control and to support continuous improvement in the control’s effectiveness.

IIA Conference February 8, 2005 National Institute of Standards and Technology 14

9

Assessment Expectations Low Impact Systems

Interviews, examinations, and tests are conducted in an informal, unstructured manner at a cursory level of depth and seek to ensure that there are no obvious errors in the security control

Moderate Impact SystemsInterviews, examinations, and tests are conducted in a formal, structured manner at an exploratory level of depth, and seek to ensure that the security control is implemented correctly and operating as intended

High Impact SystemsInterviews, examinations, and tests are conducted in a formal, structured manner at a comprehensive level of depth, and seek to ensure that the security control is implemented correctly and operating as intended on a continuous and consistent basis with continuous improvement in control effectiveness

IIA Conference February 8, 2005 National Institute of Standards and Technology 15

0

Development Methodology Building an assessment procedure for every

security control in SP 800-53 catalog and for every control enhancement

Tailoring the assessment procedures according to impact level (low, moderate, high)

Assessment procedures have a well-defined numbering system to support potential tool development efforts

IIA Conference February 8, 2005 National Institute of Standards and Technology 15

1

Publication Options and Schedule Several options under consideration for SP 800-53A

publicationOption 1: Publish the assessment procedures for security

controls employed in low impact systems first; conduct public review; finish the remaining procedures for moderate and high

Option 2: Publish all assessment procedures for security controls at the same time; conduct public review

Initial Public Draft: March-April 2005

IIA Conference February 8, 2005 National Institute of Standards and Technology 15

2

Methods: Interview, Examine, Test  impact level

attribute values low moderate high

Coverage Specified assessment objects to be assessed (i.e., specifications, activities, mechanisms, or artifacts) and number of objects to be assessed

Defined objects/ numbers

Defined objects/ numbers

Defined objects/ numbers

Scope(Test only)

Black Box √ √ √

Gray Box --- √ √

Penetration --- --- √

Approach Informal, unstructured √ --- ---

Formal, structured --- √ √

Depth Cursory √ --- ---

Exploratory --- √ ---

Comprehensive --- --- √

Assurance No obvious errors √ √ √

Correct implementation, operating as intended --- √ √

Ongoing consistent operation and continuous improvement

--- --- √

IIA Conference February 8, 2005 National Institute of Standards and Technology 15

3

The Conceptual Model

AssessmentMethods

InterviewExamine

Test

Security ControlNumber

Baseline

Assessment Procedure

Input

Process

Output

Framework

Example: First security control in Contingency Planning Family

{CP-1, low} {Interview, Examine} Assessment Procedure CP-1

IIA Conference February 8, 2005 National Institute of Standards and Technology 15

4

CP-1 CONTINGENCY PLANNING POLICY AND PROCEDURESControl: The organization develops, disseminates, and periodically reviews/updates: (i) a formal, documented, contingency planning policy that addresses purpose, scope, roles, responsibilities, and compliance; and (ii) formal, documented procedures to facilitate the implementation of the contingency planning policy and associated contingency planning controls.

ASSESSMENT METHODS: Interview, Examine

ASSESSMENT OBJECTS: Specifications (policy, procedures)

Apply ASSESSMENT PROCEDURES FS PS NS

Low CP-1.1. Interview the Chief Information Officer, Chief Information Security Officer, or their designated representatives to determine which elements of the organization are responsible for developing, disseminating, reviewing, and updating the contingency planning policy and associated procedures for implementing the policy.

     

Low CP-1.2. Interview the Information System Owner (or appropriate/equivalent party) to identify and arrange access to: (i) the contingency plan for the information system and any associated contingency-related procedures; (ii) individuals or groups responsible for the development, implementation, operation, and maintenance of the contingency plan and procedures; (iii) any materials (including records) associated with the implementation of the continginency plan or contingency operations; and (iv) guidance on the number/percentage of objects to be assessed by type.

     

Low CP-1.3. Examine the contingency planning policy to determine if the policy addresses purpose, scope, roles, responsibilities, and compliance for contingency operations.

     

Low CP-1.4. Interview selected organizational personnel with contingency planning responsibilities to determine if the contingency planning policy is: (i) disseminated to appropriate elements within the organization; (ii) reviewed by responsible parties within the organization; and (iii) updated, if review indicates updates are required.

     

IIA Conference February 8, 2005 National Institute of Standards and Technology 15

5

Low CP-1.5. Examine contingency planning policy for evidence (e.g., policy version notation or record of updates) that the policy is being updated periodically (if policy review indicates updates are required).

     

Low CP-1.6. Examine contingency planning procedures to determine if the necessary procedures to implement the contingency planning policy are available.

     

Low CP-1.7. Interview selected organizational personnel with contingency planning responsibilities to determine if the contingency planning procedures are: (i) disseminated to appropriate elements within the organization; (ii) reviewed by responsible parties within the organization; and (iii) updated, if review indicates updates are required.

     

Low CP-1.8. Examine contingency planning procedures for evidence (e.g., procedure version notation or record of updates) that the procedures are being updated (if procedure review indicates updates are required).

     

Low CP-1.9. Interview selected organizational personnel with responsibility for implementing contingency planning procedures to determine if the procedures are in effect.

     

Control Enhancements: None.

  

IIA Conference February 8, 2005 National Institute of Standards and Technology 15

6

Contact Information100 Bureau Drive Mailstop 8930

Gaithersburg, MD USA 20899-8930

Project Manager Administrative SupportDr. Ron Ross Peggy Himes(301) 975-5390 (301) [email protected] [email protected]

Senior Information Security Researchers and Technical SupportMarianne Swanson Dr. Stu Katzke (301) 975-3293 (301) 975-4768 [email protected] [email protected]

Pat Toth Arnold Johnson(301) 975-5140 (301) 975-3247 [email protected] [email protected]

Curt Barker Information and Feedback(301) 975-4768 Web: csrc.nist.gov/[email protected] Comments: [email protected]