Purpose and Applicability

NIST SP 800-60 addresses the FISMA direction to develop guidelines recommending the types of information and information systems to be included in each category of potential security impact.

This guideline is intended to help agencies consistently map security impact levels to types of: (i) information (e.g., privacy, medical, proprietary, financial, contractor sensitive, trade secret,

investigation); and (ii) information systems (e.g., mission critical, mission support, administrative).

This guideline applies to all Federal information systems other than national security systems.

National security systems store, process, or communicate national security information.²

FISMA Framework documents:

FIPS 199 FIPS 200

NIST SP 800-30 NIST SP 800-37,

NIST Draft SP 800-39, Managing Risk from Information Systems: An Organization Perspective NIST SP 800-53,

NIST SP 800-53A NIST SP 800-59 NIST SP 800-60

NIST Risk Management Framework:

9.

Executive Summary

Some federal agencies, in addition to being subject to the Federal Information Security Management Act of 2002 (FISMA), are also subject to similar requirements of the Health Insurance Portability and Accountability Act of 1996 (HIPAA) Security Rule (the Security Rule), if the agency is a covered entity as defined by the rules implementing HIPAA.

The HIPAA Security Rule specifically focuses on the safeguarding of electronic protected health information (EPHI). Although FISMA applies to all federal agencies and all information types, only a subset of agencies are subject to the HIPAA Security Rule based on their functions and use of EPHI. All HIPAA covered entities, which include some federal agencies, must comply with the Security Rule, which specifically focuses on protecting the confidentiality, integrity, and availability of EPHI, as defined in the Security Rule. The EPHI that a covered entity creates, receives, maintains, or transmits must be protected against reasonably anticipated threats, hazards, and impermissible

uses and/or disclosures. In general, the requirements, standards, and implementation specifications of the Security Rule apply to the following covered entities:

Covered Healthcare Providers—Any provider of medical or other health services, or

supplies, who transmits any health information in electronic form in connection with a transaction for which the Department of Health and Human Services (DHHS) has adopted a standard.

Health Plans—Any individual or group plan that provides, or pays the cost of, medical care, including certain specifically listed governmental programs (e.g., a health insurance issuer and the Medicare and Medicaid programs).

Healthcare Clearinghouses—A public or private entity that processes another entity’s healthcare transactions from a standard format to a nonstandard format, or vice versa.

Medicare Prescription Drug Card Sponsors –A nongovernmental entity that offered an endorsed discount drug program under the Medicare Modernization Act. This fourth category of

―covered entity‖ remained in effect until the drug card program ended in 2006.

NIST publications, many of which are required for federal agencies, can serve as voluntary

guidelines and best practices for state, local, and tribal governments and the private sector, and may provide enough depth and breadth to help organizations of many sizes select the type of

implementation that best fits their unique circumstances. NIST security standards and guidelines (Federal Information Processing Standards [FIPS], Special Publications in the 800 series), which can be used to support the requirements of both HIPAA and FISMA, may be used by organizations to help provide a structured, yet flexible framework for selecting, specifying, employing, and evaluating the security controls in information systems.

This Special Publication (SP), which discusses security considerations and resources that may provide value when implementing the requirements of the HIPAA Security Rule, was written to:

• Help to educate readers about information security terms used in the HIPAA Security Rule and to improve understanding of the meaning of the security standards set out in the Security Rule;

• Direct readers to helpful information in other NIST publications on individual topics addressed by the HIPAA Security Rule; and

• Aid readers in understanding the security concepts discussed in the HIPAA Security Rule.

This publication does not supplement, replace, or supersede the HIPAA Security Rule itself.

Figure 1 shows all the components of HIPAA and illustrates that the focus of this document is on the security provisions of the statute and the regulatory rule. Figure 1. HIPAA Components

10.

An information security assessment is the process of determining how effectively an entity being assessed (e.g., host, system, network, procedure, person—known as the assessment object) meets specific security objectives. Three types of assessment methods can be used to accomplish this—testing, examination, and interviewing. Testing is the process of exercising one or more assessment objects under specified

conditions to compare actual and expected behaviors. Examination is the process of checking, inspecting, reviewing, observing, studying, or analyzing one or more assessment objects to facilitate understanding, achieve clarification, or obtain evidence. Interviewing is the process of conducting discussions with individuals or groups within an organization to facilitate understanding, achieve clarification, or identify the location of evidence. Assessment results are used to support the determination of security control effectiveness over time.

This document is a guide to the basic technical aspects of conducting information security assessments. It presents technical testing and examination methods and techniques that an organization might use as part of an assessment, and offers insights to assessors on their execution and the potential impact they may have on systems and networks. For an assessment to be successful and have a positive impact on the security posture of a system (and ultimately the entire organization), elements beyond the execution of testing and examination must support the technical process. Suggestions for these activities—including a robust planning process, root cause analysis, and tailored reporting—are also presented in this guide.

The processes and technical guidance presented in this document enable organizations to:

 Develop information security assessment policy, methodology, and individual roles and responsibilities related to the technical aspects of assessment

 Accurately plan for a technical information security assessment by providing guidance on determining which systems to assess and the approach for assessment, addressing logistical considerations, developing an assessment plan, and ensuring legal and policy considerations are addressed

 Safely and effectively execute a technical information security assessment using the presented methods and techniques, and respond to any incidents that may occur during the assessment

 Appropriately handle technical data (collection, storage, transmission, and destruction) throughout the assessment process

 Conduct analysis and reporting to translate technical findings into risk mitigation actions that will improve the organization’s security posture.

The information presented in this publication is intended to be used for a variety of assessment purposes.

For example, some assessments focus on verifying that a particular security control (or controls) meets requirements, while others are intended to identify, validate, and assess a system’s exploitable security weaknesses. Assessments are also performed to increase an organization’s ability to maintain a proactive computer network defense. Assessments are not meant to take the place of implementing security controls and maintaining system security.

To accomplish technical security assessments and ensure that technical security testing and examinations provide maximum value, NIST recommends that organizations:

 Establish an information security assessment policy. This identifies the organization’s requirements for executing assessments, and provides accountability for the appropriate individuals to ensure assessments are conducted in accordance with these requirements. Topics that an assessment policy should address include the organizational requirements with which assessments must comply, roles and responsibilities, adherence to an established assessment methodology, assessment frequency, and documentation requirements.

 Implement a repeatable and documented assessment methodology. This provides consistency and structure to assessments, expedites the transition of new assessment staff, and addresses resource constraints associated with assessments. Using such a methodology enables

organizations to maximize the value of assessments while minimizing possible risks introduced by certain technical assessment techniques. These risks can range from not gathering sufficient information on the organization’s security posture for fear of impacting system functionality to affecting the system or network availability by executing techniques without the proper

safeguards in place. Processes that minimize risk caused by certain assessment techniques include using skilled assessors, developing comprehensive assessment plans, logging assessor activities, performing testing off-hours, and conducting tests on duplicates of production systems (e.g., development systems). Organizations need to determine the level of risk they are willing to accept for each assessment, and tailor their approaches accordingly.

 Determine the objectives of each security assessment, and tailor the approach accordingly.

Security assessments have specific objectives, acceptable levels of risk, and available resources.

Because no individual technique provides a comprehensive picture of an organization’s security