hitrust risk management frameworks
TRANSCRIPT
Risk Management Frameworks How HITRUST provides an efficient and effective approach to the selection, implementation, assessment and reporting of information security and privacy controls to manage risk in a healthcare environment
March 2013
This document is the intellectual property of HITRUST Alliance, LLC. Permission to reproduce or reference is not permitted without the express consent of HITRUST Alliance, LLC. Requests can be sent to [email protected]. For general questions regarding this piece or HITRUST, please contact [email protected]. Media should contact [email protected].
HITRUST
Contents
Introduction 3 Background 4
Overview 4 HIPAA 5 HITECH 5 Omnibus Rule 5 Other Drivers 5
Summary 6 Risk Management Frameworks 7
Overview 7 General RMF 7 Step 1 -‐ Identify Risks and Define Protection Requirements 7 Step 2 -‐ Specify Controls 8 Step 3 -‐ Implement and Manage Controls 8 Step 4 -‐ Assess and Report 8
Summary 8 NIST RMF 9
Step 1 -‐ Identify Risks and Define Protection Requirements 9 Step 2 -‐ Specify Controls 9 Step 3 -‐ Implement and Manage Controls 10 Step 4 -‐ Assess and Report 10
Summary 11 HITRUST RMF 12
Step 1-‐ Identify Risks and Define Protection Requirements 12 Step 2 -‐ Specify Controls 13 Step 3 -‐ Implement and Manage Controls 13 Step 4 -‐ Assess and Report 13 Summary 17 Conclusion 18 About HITRUST 19
MyCSF 19 Appendix A -‐ Frequently Asked Questions 20 Appendix B -‐ Glossary 25
HITRUST
HITRUST 3
Introduction Healthcare organizations continue to face a multitude of challenges with regards to information security and privacy. At the fore-‐ front of these challenges is the need to apply “reasonable and appropriate” safeguards to provide “adequate” protection of sensitive information in order to demonstrate compliance with a growing number of continuously evolving federal, state and industry requirements. However, given the general lack of definition and prescriptiveness of these requirements, organizations are left with the task of deciding what actions would be considered “reasonable and appropriate” and what level of protection would be “adequate” in the eyes of federal, state and industry regulators, business partners, patients and their families, and other interested third-‐parties.
This complex challenge is the basis for why the healthcare industry came together and formed HITRUST. HITRUST, on behalf of the healthcare industry, does the heavy lifting by integrating multiple international, federal, state and industry regulations, standards, and best practice frameworks; adapting them to the healthcare environment; and determining an industry standard of due diligence and due care that can be tailored to an individual organization based upon its specific business requirements. The result of these efforts is the HITRUST CSF, an industry-‐wide framework of security controls that is based on and cross-‐references existing requirements already applicable to healthcare. In addition, the HITRUST CSF Assurance Program provides organizations with a single approach for conducting an assessment and reporting against these multiple requirements. Both the CSF and CSF Assurance Program are updated at least annually to account for changes in legislation, regulations, standards, guidance and best practices, such as with the 2012 release of the Office of Civil Rights (OCR) Audit Protocol and 2014 release of the NIST Framework for Improving Critical Infrastructure Cybersecurity. Further, all changes to the CSF are provided to the industry for review and comment, ensuring transparency and openness. HITRUST provides the CSF free to qualified healthcare organizations that wish to implement the framework.
So, why does the CSF increase in value as new/updated requirements or guidance are released? Because the more complex the security and regulatory landscape becomes, the more difficult it is for healthcare organizations to maintain compliance, protect information, and protect themselves against breaches. HITRUST established a flexible control structure early on and is able to continuously add and update the framework in response to changing regulations, standards and guidance.
HITRUST 4
Part of the process is to analyze each new source and map its requirements to the control structure, often performed with the assistance of a cross-‐industry working group. In addition, the CSF was structured in such a way that allows additional tailoring based on risk factors that align to the healthcare industry, such as organizational type or a specific system characteristic. HITRUST also continues to develop and publish guidance and tools like the CSF assessment methodology and MyCSF™ as part of an overall risk management framework (RMF), which is essentially a common taxonomy and standard set of processes, procedures, activities and tools that support the identification, assessment, response, control and reporting of risk. This provides organizations with one set of requirements irrespective of new or updated regulations, guidance or best practices, and one compliance approach to implement and manage “reasonable and appropriate” safeguards that demonstrate the level of due care and due diligence required to ensure “adequate” protection of the health information with which they are entrusted.
What would organizations need to do without HITRUST and the CSF? The alternative is to continually review changes to regulations, guidance and standards to determine the requirements that are appropriate based on each organization’s risk profile, identify industry best practices to address the requirements, and develop an approach to assess its compliance against these requirements. Because each organization would be working independently, each interpretation and implementation of the requirements would be proprietary, impeding the ability to form trusted, third-‐party business relationships and the healthcare industry’s progress in the digital age.
This paper describes: • How organizations struggle with the constantly changing security and regulatory landscape, • How the most efficient and effective way to deal with these changes is by adoption of an appropriate RMF, • The NIST and HITRUST RMFs using a 4-‐step risk management process, and • How the HITRUST RMF is more practical and provides more value for non-‐federal health care entities.
The more the security and regulatory landscape changes, the more an RMF is needed, and the better value HITRUST offers the industry—the heavy lifting is already done.
Background
Overview Healthcare organizations are facing multiple challenges with regards to information security and privacy. Redundant and inconsistent requirements and standards increase complexity and drive up costs. Confusion around acceptable safeguards and the lack of defined security requirements result in critical systems without appropriate administrative, physical and technical safeguards. Further, the increased scrutiny from regulators, auditors, underwriters, customers and other third parties leaves the industry coping with additional exposure, increased liability, and growing risks to patients, their families and healthcare organizations. In addition, organizations are challenged with appropriately managing the sharing of information due to the wide range of business partners and other third parties with different capabilities, requirements and risk profiles.
These issues led to a growing need and broad desire within the industry for a common security framework—a set of common standards and supporting methodologies—that would provide a minimum baseline set of security requirements. Due to the varied nature of organizations in the healthcare industry, this framework also needed to be tailorable to a specific size and type of organization, which would improve trust as well as mitigate potential liability from breaches of sensitive information.
Thus, HITRUST was born out of the belief that information security and privacy are critical to the broad adoption, utilization and confidence in health information systems, medical technologies and electronic exchanges of health information. The HITRUST CSF provides the needed fundamental and holistic change in the way the industry manages information security and privacy-‐related risk. It rationalizes regulations and standards into a single overarching framework tailored for the industry and provides a consistent approach to certification and risk acceptance.
HITRUST 5
HIPAA The principle driver behind security and privacy in healthcare for many years was without a doubt the Health Information Portability and Accountability Act (HIPAA), which incorporates specific privacy and security requirements for providers, payers and other covered entities in the healthcare industry. HIPAA’s Security Rule provided numerous implementation specifications that essentially required covered entities to implement reasonable and appropriate administrative, technical and physical safeguards for protected health information (PHI).
Unfortunately, the implementation specifications lack the level of prescriptiveness necessary to determine a standard of due care or diligence, i.e., what safeguards would be considered “reasonable and appropriate,” or ensure the consistent application of these safeguards. Organizations were left to determine these safeguards for themselves but often found it difficult to justify the costs associated with their implementation. It is notoriously difficult to quantify a return on investment for new security investments unless existing technologies or processes are being replaced, allowing such costs to be calculated. Unless specifically required, security investments are most often justified based on “cost avoidance” calculations or what has been referred to as “fear, uncertainty and doubt.”
To compound matters, healthcare is a service industry focused on quality of care as well as efficiency and cost. Given that patients and others have found it difficult to evaluate this quality of service, it is subsequently difficult for organizations to calculate their return on investment for any initiative, let alone those with significant security and privacy requirements. Fortunately, it only took three years after compliance with the Security Rule was mandatory, for the federal government to realize the difficulties covered entities had with the Rule’s practical application and issue additional legislation.
HITECH As part of the national initiative to improve quality and lower the cost of healthcare through the meaningful use of electronic health record (EHR) systems and health information exchanges (HIEs), Congress passed the Health Information Technology for Economic and Clinical Health (HITECH) Act as part of the American Recovery and Reinvestment Act of 2009. In addition to the privacy and security requirements for meaningful use in which covered entities are expected to conduct or review a security risk analysis and correct identified deficiencies, the most significant changes stemming from HITECH were the establishment of a federal breach notification requirement and increased enforcement of the HIPAA Security Rule through the Office of Civil Rights (OCR).
Unfortunately, the HITECH Act did not provide significant additional guidance to organizations on what levels of due diligence and due care are reasonable and appropriate. It was not until sometime later when OCR and the National Institute of Technology and Standards (NIST) began cooperating and provided covered entities with an indication of the increased level of rigor the federal government expected through a series of annual joint conferences on security and privacy as well as the publication in 2011 of the NIST HIPAA Security Rule (HSR) Toolkit. OCR published additional guidance in 2012 on the audit protocol being used as part of the overall HIPAA enforcement effort.
Omnibus Rule The HIPAA Final Omnibus Rule published in January of 2013—10 years after the Security Rule was released—provides final modifications to the HIPAA Privacy, Security and Enforcement Rules embedded in the HITECH Act, a final rule on tiered monetary penalties, and a Breach Notification Rule. One of the most significant aspects of the Omnibus Rule is its application to business associates, which are now directly liable for failure to comply with the all the Rule’s requirements, including the HIPAA Security Rule as mandated by HITECH.
Other Drivers While legislation and regulation is arguably the principle driver for security and privacy in healthcare, there are numerous other legislative, regulatory, industry and best practice requirements that healthcare entities must address. Examples include the Privacy Act of 1974, the Genetic Information Non-‐discrimination Act (GINA) of 2008, the Federal Trade Commission (FTC) Red Flags Rule and Fair Information Practice Principles, Federal Drug Administration (FDA) requirements for EHRs and electronic signatures, multiple state-‐level security and privacy legislation and regulations, and the Payment Card Industry Digital Security Standard (PCI-‐ DSS).
HITRUST 6
Summary Healthcare organizations have faced and will continue to face multiple challenges with regards to information security and privacy, including the growing need to demonstrate compliance with multiple federal, state and industry requirements such as HIPAA, HITECH, PCI-‐DSS and others for the application of “reasonable and appropriate” safeguards to provide “adequate” protection of sensitive information. However, given the general lack of definition and prescriptiveness of these requirements, organizations are left with the task of deciding what actions would be considered “reasonable and appropriate” and what level of protection would be “adequate” in the eyes of federal, state and industry regulators, business partners, patients and their families, and other interested third parties. Implementing the right framework, processes and tools is the only efficient and effective way to manage information risk and compliance.
The HITRUST CSF provides the needed fundamental and holistic change in the way the industry manages information security and privacy-‐related risk. It rationalizes regulations and standards into a single overarching framework tailored for the industry and provides a consistent approach to certification and risk acceptance.
7
HITRUST
Risk Management Frameworks
Overview So, how can an organization determine “reasonable and appropriate” safeguards to provide “adequate protection” for sensitive information? Or stated another way, how can an organization select and implement a specific set of controls to manage information security and privacy-‐related risk at an acceptable level?
The textbook answer is through a comprehensive risk analysis that (1) includes threat and vulnerability assessments, information asset valuation, and the selection of a comprehensive set of information security and privacy controls that address the enumerated threat-‐vulnerability pairs (a process sometimes referred to as threat modeling), (2) is cost-‐effective, and (3) manages risk at a level deemed acceptable by the organization.
From a quantitative viewpoint, this process is virtually impossible for most—if not all—organizations. For example, unless actuarial-‐type information is available, the likelihood a threat-‐source will successfully exploit one or more vulnerabilities cannot be calculated with any level of precision. In the case of a human actor, likelihood is also dependent on the motivation of the threat source and the difficulty or cost associated with exploiting one or more vulnerabilities to achieve the threat actor’s objectives. As a result, it is similarly difficult to develop a valid business case for a specific risk response or treatment based on a return on investment. Organizations could take a semi-‐ or quasi-‐quantitative approach or even a purely qualitative approach; however, it would still be difficult for an organization—especially one in healthcare—to develop a valid business case, particularly for a comprehensive set of risk responses.
An alternative approach is to rely on a set of controls developed by another organization that does have the resources to develop such a set of controls that address similar threats to similar technologies employed by their own organization. This is the approach employed by the intelligence community (IC), defense department and civilian agencies of the federal government with their respective information security control frameworks, which is currently in the process of being consolidated into a single framework for all federal agencies. It is also the approach used by HITRUST with the healthcare industry’s CSF.
These control frameworks are also part of a broader risk management framework. For the IC, it is Director of Central Intelligence Directive (DCID 6/3). For the Department of Defense (DoD), it is the control catalog contained in DoD Instruction (DoDI) 8500.2 combined with other documentation such as the Defense Information Assurance Certification and Accreditation Process (DIACAP) outlined in DoDI 8510.01. For federal civilian agencies, it is the control catalog contained in NIST SP 800-‐53 r4, the many publications that make up the NIST Risk Management Framework, other NIST publications including NIST SP 800-‐66 r1, which provides information on how NIST controls support the HIPAA Security Rule, and the NIST HSR Toolkit. For the healthcare industry, it is the HITRUST CSF combined with CSF Assurance Program-‐related documents and tools, such as the HITRUST CSF Assurance Program requirements, HITRUST CSF Assessor requirements, HITRUST CSF assessment methodology, and HITRUST’s comprehensive online tool, MyCSF.
General RMF In all cases, the risk management framework supports a basic 4-‐step risk management process model:
• Step 1—Identify risks and define protection requirements • Step 2—Specify controls • Step 3—Implement and manage controls • Step 4—Assess and report
Step 1 -‐ Identify Risks and Define Protection Requirements The objective of this step is to determine the risks to information and information assets that are specific to the organization. Risks can be identified through the analysis of regulations and legislative requirements, breach data for similar organizations in the industry, as well as an analysis of current architectures, technologies and market trends. The end result of this analysis should be a prioritized list of high-‐risk areas and an overall control strategy to minimize the risk to the organization from the use of PHI and other sensitive or business critical information in terms of overall impact to the organization.
HITRUST 8
This step is supported by seven sub-‐processes, which range from the classification of information assets to the development of specific risk treatments. As indicated previously, this is one of the more problematic aspects of risk analysis that a risk management framework will help an organization address.
Step 2 -‐ Specify Controls The next step is to determine a set of reasonable and appropriate safeguards an organization should implement in order to adequately manage information security risk. The end result should be a clear, consistent and detailed or prescriptive set of control recommendations that are customized for the healthcare organization.
A control-‐based risk management framework will provide a comprehensive control catalog derived from the seven sub-‐processes outlined earlier as well as specific criteria for the selection of a baseline set of controls, which is performed in this step.
Step 3 -‐ Implement and Manage Controls Controls are implemented through an organization’s normal operational and capital budget and work processes with board-‐level and senior executive oversight using existing governance structures and processes. A risk management framework will provide guidance and tools for the implementation of the framework, including the controls specified earlier in step 2.
Step 4 -‐ Assess and Report The objective of this last step is to assess the efficiency of implemented controls and the general management of information security against the organization’s baseline. The end result of these assessment and reporting activities is a risk model that assesses internal controls and those of business associates based on well-‐defined risk factors. It should also provide common, easy-‐to-‐use tools that address requirements and risk without being burdensome, support third-‐party review and validation, and provide common reports on risk and compliance.
Summary Unless skilled personnel and other resources are available to determine a comprehensive set of “reasonable and appropriate” safeguards to provide “adequate protection” for sensitive information, healthcare organizations should leverage existing control and risk management frameworks. This is the same approach used by the federal government, and it is also the approach used by HITRUST.
Regardless of the source, a risk management framework is supported by a risk management process, which at a basic level incorporates four distinct steps.
• Step 1—Identify risks and define protection requirements • Step 2—Specify controls • Step 3—Implement and manage controls • Step 4—Assess and report
Although based on the International Standards Organization and International Electrotechnical Committee (ISO/IEC) Standard 27001 and 27002, the HITRUST CSF integrates NIST SP 800-‐53 control requirements and relies heavily on NIST and other federal security guidance such as the Centers for Medicaid and Medicare (CMS) Information Systems (IS) Acceptable Risk Safeguards (ARS). As such, the rest of this white paper will focus on the NIST and HITRUST risk management frameworks in the context of this four-‐step process and identify some of the differences between them.
HITRUST 9
NIST RMF NIST provides a structured process and a significant amount of guidance to help federal organizations identify and assess risk to their information and information systems and take steps to reduce risk to an acceptable level. This is accomplished through the publication of various NIST SP 800-‐series documents, Federal Information Processing Standards (FIPS) documents, and Inter-‐agency Reports (NIST IRs), which help guide federal agencies through a six-‐step risk management process designed to minimize the risk of harm from the unauthorized access, use, disclosure, disruption, modification or destruction of sensitive information. NIST SP 800-‐37 outlines the process and provides additional guidance by mapping other NIST documents in the framework to each step of the process.
The six-‐step NIST risk management process can be mapped to the basic four-‐step process as follows: “Categorize Information Sys-‐ tem” to step 1; “Select Security Controls” to step 2; “Implement Security Controls”, “Assess Security Controls” and “Authorize Information System” to step 3; and “Monitor Security Controls” to step 4.
Step 1-‐ Identify Risks and Define Protection Requirements The first step of NIST’s risk management process, “Categorize Information Systems,” categorizes an information system and the information being processed, stored and transmitted by the system based on the potential impact to the organization should a threat-‐source successfully exploit a vulnerability. FIPS 199 requires organizations to categorize their information systems as low-‐impact, moderate-‐impact, or high-‐impact for the security objectives of confidentiality, integrity and availability. The potential impact values assigned to the respective security objectives are the highest values (high-‐water mark) from among the security categories determined for each type of information processed, stored, or transmitted by the information system(s) considered in scope. Related publications include NIST SP 800-‐60.
Although not technically part of the NIST RMF publications, NIST SP 800-‐66 provides links from the NIST RMF to the HIPAA Security Rule’s implementation specifications. However, the publication doesn’t specify a security categorization for ePHI; this exercise is left to the federal healthcare organization.
Step 2 -‐ Specify Controls The first step in selecting security controls for the information system is to choose an initial set of baseline security controls based on the impact level of the information system as determined by the security categorization performed in step 1. The organization selects one of three sets of baseline security controls from the security control catalog in NIST SP 800-‐53 corresponding to the low-‐ impact, moderate-‐impact, or high-‐impact rating of the information system.
After selecting the initial set of baseline security controls, the organization starts the tailoring process to appropriately modify and more closely align the controls with the specific conditions within the organization (i.e., conditions specific to the information system or its environment of operation). The tailoring process includes:
• Applying scoping guidance to the initial baseline security controls to obtain a preliminary set of applicable controls for the
tailored baseline; • Selecting (or specifying) compensating security controls, if needed, to adjust the preliminary set of controls to obtain an
equivalent set deemed to be more feasible to implement; and • Specifying organization-‐defined parameters in the security controls via explicit assignment and selection statements to
complete the definition of the tailored baseline.
Although the security control selection process is generally focused on the information system, NIST states the selection process is also applicable at the organizational and mission/business process levels. General guidance in applying the NIST RMF at these levels may be found in NIST SP 800-‐39. However, the tailoring process described in NIST SP 800-‐53 is neither prescriptive nor managed, which does little to guarantee tailoring is performed consistently from one organization to the next or, more often than not, that tailoring is performed at all. Related publications include FIPS 200.
NIST SP 800-‐66 provides some additional tailoring recommendations for healthcare organizations by mapping controls from NIST SP 800-‐53 to the HIPAA Security Rule’s implementation specifications and describing key activities for each specification; however, this would only address an organization’s obligations under the Rule. Other controls may be needed to support other legislative, regulatory, industry or best practice requirements. NIST SP 800-‐66 provides limited guidance on the risk assessment process that could help address these other requirements should an organization have the skilled personnel and resources to conduct the analysis.
HITRUST 10
In addition, there is little if any prescriptive guidance on control selection based on risk factors such as organizational size/capability or assignment of acceptable organization-‐defined parameters. However, healthcare organizations may refer to the CMS IS ARS for additional guidance on the selection of organization-‐defined parameters for low, moderate and high-‐level NIST control baselines.
Step 3-‐ Implement and Manage Controls NIST provides guidance on various information security controls in an extensive library of NIST SP 800-‐series, FIPS and NIST IR documents and provides a guide for selecting documents organized by specific topics such as biometrics (e.g., FIPS 201-‐1 and NIST SP 800-‐116) and cryptography (e.g., FIPS 198-‐1 and NIST SP 800-‐78-‐1) or specific NIST control families such as access control (e.g., FIPS 200 and NIST SP 800-‐114) and Contingency Planning (e.g., NIST SP 800-‐34 and NIST SP 800-‐84). NIST also provides guidance on incorporating security into the federal capital planning and investment control process in NIST SP 800-‐65 and the information system development lifecycle (SDLC) in NIST SP 800-‐64 Rev 2; however, there is little in the way of specific guidance or tool support on how organizations can implement the NIST control framework in their organization. Related RMF publications include NIST SP 800-‐37, 800-‐53A and 800-‐70.
NIST SP 800-‐66 does not provide information on how to implement or manage security controls in a healthcare environment.
Step 4 -‐ Assess and Report NIST provides assessment guidance for the NIST SP 800-‐53 control catalog in NIST SP 800-‐53A, a technical guide for information security testing and assessment in NIST SP 800-‐115, and specific guidance for the assessment of access control systems in NIST IR 7316. NIST also provides a process maturity-‐based security assessment methodology called PRISMA (Program Review for Information Security Management Assistance) in NIST IR 7358. Although not formally incorporated in the NIST RMF, PRISMA provides an intuitive approach to the evaluation of information security controls by considering whether the requirement is specified in policy, supported by formal processes, implemented across the organization, tested to ensure continued effectiveness, and that activities supporting the first four levels are fully integrated with each other and the organization’s control environment. The NIST IR also provides guidance on how to prepare for and execute a PRISMA-‐based assessment as well as information around the practical application of the formal report. Related RMF publications include NIST SP 800-‐37.
NIST SP 800-‐66 provides specific questions for healthcare organizations to consider organized by HIPAA Security Rule implementation specification as well as a stand-‐alone automated tool called the NIST HSR Toolkit, which provides 472 questions for “standard” organizations and 809 questions for “enterprise”-‐level organizations. NIST also references other sources for each question: 491 questions map to NIST SP 800-‐66 sections addressing the HIPAA implementation specifications, 290 map to a specific NIST SP 800-‐53 control, and 28 are not mapped.
Each section in NIST SP 800-‐66 addresses key activities for an implementation specification, e.g., section 4.1.1 is “Identify Relevant Information Systems,” which supports HIPAA § 164.308(a)(1), Security Management Process. There is a description of the activity as well as sample questions an organization may use to help them assess the activity. An organization may also look up the associated NIST controls and NIST RMF documents referenced in each section for more information. For example, NIST SP 800-‐66 §4.1.1 maps 164.308(a)(1) NIST SP 800-‐53 control RA-‐1 and crosswalks to the following publications: FIPS 199, NIST SP 800-‐14, NIST SP 800-‐18, NIST SP 800-‐30, NIST SP 800-‐37, NIST Draft SP 800-‐39, NIST SP 800-‐42, NIST SP 800-‐53, NIST SP 800-‐55, NIST SP 800-‐60, NIST SP 800-‐84, NIST SP 800-‐92, and NIST SP 800-‐100. However, it’s up to the organization to parse the references among the nine key activities, as well as read through and apply information from each of the referenced publications.
An organization can use NIST SP 800-‐66 to determine all the possible NIST controls that support the implementation specification and come up with additional controls that map to the implementation specifications but not explicitly provided in the NIST tool-‐ kit. Similarly, it is left to the organization to parse through the NIST SP 800-‐53 controls and determine the subset of requirements that directly support the HIPAA Security Rule’s implementation specifications.
Organizations may also leverage the OCR Audit Protocol to determine high interest areas they should ensure are addressed in their security program and assessed accordingly. However, organizations must understand that, like all audits, the Protocol is narrowly focused and does not address all the security control requirements that support the HIPAA Security Rule, nor does it address all the implementation specifications in the Rule. The audit procedures also focus heavily on policy and process requirements but do not provide specific procedures to evaluate the implementation of many of the Rule’s requirements. Neither tool provides a mechanism to evaluate and score the relevant maturity of the control, compute risk estimates or support risk reporting. This is left for the organization to determine.
HITRUST 11
More recently, DHS and OCR collaborated on a security risk assessment (SRA) tool to help providers in small to medium-‐sized offices to conduct risk assessments. The tool does a much better job than the audit protocol in helping organizations address salient elements of the HIPAA standards and implementation specifications; however, the questions are specific to the HIPAA requirements and subsequently has some of the same limitations as the OCR audit protocol. Organizations should also note that while the NIST HSR Toolkit, OCR Audit Protocol and DHS/OCR SRA tool will support HIPAA-‐specific assessments, they do not necessarily support a more general assessment that includes other legislative, regulatory, industry or best practice requirements.
Summary NIST publishes a comprehensive set of controls designed for use by federal agencies, an extensive library of guidance documents for the NIST RMF, and special interest documents on specific information security topics and control areas. NIST also publishes an excellent resource on the implementation of NIST SP 800-‐53 security controls to satisfy HIPAA requirements. However, private-‐ sector healthcare organizations are not subject to all the same legislative and regulatory requirements as a federal healthcare organization (e.g., the Federal Information Security Management Act), nor do they have the same skilled personnel and resources available to support their information security program. It can be difficult for many organizations to adapt the NIST RMF to their specific needs, i.e., to determine what controls are “reasonable and appropriate” for a non-‐federal healthcare organization. In addition, NIST healthcare guidance is focused on compliance with the HIPAA Security Rule and does not specifically address the selection and implementation of controls necessary to satisfy other legislative, regulatory, industry and best practice requirements.
HITRUST 12
HITRUST RMF HITRUST was formed from an alliance of healthcare organizations to address the growing need and broad desire within the industry for a common framework—a set of common standards and supporting methodologies—that would provide a minimum baseline set of security requirements, tailorable to a specific size and type of organization, which would improve trust as well as mitigate potential liability from breaches of sensitive information. HITRUST believes that improvements in the state of information security and privacy in the industry are critical to the broad adoption, utilization and confidence in health information systems, medical technologies and electronic exchanges of health information, which is necessary to improve the quality of patient care while lowering the cost of delivery. The HITRUST RMF provides a consistent approach to certification, risk acceptance and shared trust through the HITRUST CSF, CSF Assurance Program, and supporting methodologies and tools such as the HITRUST CSF Assessment Methodology and MyCSF.
Step 1 -‐ Identify Risks and Define Protection Requirements The HITRUST CSF provides a fundamental and holistic change in the way the industry manages information security and privacy-‐ related risk by rationalizing relevant regulations and standards into a single overarching framework designed for the industry and tailorable to the organization.
This diagram is intended to show how various frameworks and standards are mutually reinforcing, can be tailored to an organization’s needs, and intelligently applied in the intended environment to help ensure organizations meet business goals while achieving regulatory compliance. It shows that the overarching governance frameworks such as the Control Objectives for Information and Related Technology (COBIT) can be integrated with risk management frameworks like the NIST RMF and ISO/IEC 27001, as well as other frameworks like ITIL for service delivery and ISO 9000 for capability or process maturity. This concept applies to many other standards that an enterprise may wish to adopt. The key is to adopt specific frameworks and standards that meet one’s needs, tailor them appropriately and implement them smartly.
HITRUST built the CSF on ISO/IEC 27001 and 27002 and integrated NIST SP 800-‐53 control requirements as well as security-‐ and privacy-‐relevant requirements from legislative, regulatory, industry and best practice frameworks such as HIPAA, HITECH, CMS, FTC Red Flags, PCI-‐DSS, ISO 27799 and COBIT. State information security requirements from Massachusetts, Nevada and Texas are also integrated into the framework. This allows organizations to implement a single control framework to meet healthcare clinical and business objectives and satisfy multiple regulatory and other compliance requirements.
The CSF is freely available to qualified organizations by paid subscription to MyCSF for an interactive version tailorable to the subscribing organization.
HITRUST 13
Step 2 -‐ Specify Controls Like NIST, HITRUST built the CSF to accommodate multiple control baselines. However, unlike NIST, HITRUST assigns baseline controls using three risk factors: organizational type and size (e.g., a physician practice with fewer than 60,000 visits per year), system requirements (e.g., the system stores ePHI, is accessible from the Internet, and processes fewer than 6,750 transactions per day), and regulatory requirements (e.g., subject to FTC Red Flags Rule and PCI-‐DSS compliance). The result is a healthcare industry-‐specific baseline tailored to an organization’s clinical, business and compliance requirements, as shown below.
The capability to tailor controls to a specific organization’s needs is available in MyCSF. Training on the CSF is provided to anyone seeking the HITRUST Certified CSF Practitioner (CCSFP) credential.
Step 3 -‐ Implement and Manage Controls HITRUST trains third-‐party consulting and assessment firms in the CSF and CSF Assurance Program methodologies and tools so that they may offer CSF implementation support to healthcare provider organizations as recommended by OCR that lack the capability to implement and assess information security and privacy controls.
HITRUST recommends the development of an information security and privacy risk management architecture in which strategic planning and information security architecture, policies and standards form the foundation for specific customer-‐facing information security and privacy services, which should be documented in security and privacy service catalogs as recommended by the Information Technology Infrastructure Library (ITIL). Examples of these customer-‐facing services include security operations, incident management and investigations, business continuity and disaster recovery, identity and access management, and education, training and awareness. CSF controls and available resources can then be mapped to each service. The result is the ability to develop operational and capital project plans for defined security services based on deficiencies for specific control requirements identified via risk assessment and monitoring activities such as vulnerability assessment, penetration testing, control maturity assessments and incident root cause analysis.
HITRUST provides training on the implementation and management of information security controls to anyone seeking the CCSFP credential.
Step 4 -‐ Assess and Report The CSF Assurance Program provides simplified and consistent compliance assessment and reporting against the CSF and the authoritative sources it incorporates. This risk-‐based approach, which is governed and managed by HITRUST, is designed for the unique regulatory and business needs of the healthcare industry and provides organizations with an effective, standardized and streamlined assessment process to manage compliance. This solution offers a more effective process than that used by other assessment approaches and toolkits which support only limited requirements and checkbox approaches.
HITRUST 14
An integral component of the CSF Assurance Program is the HITRUST risk assessment methodology, which is built around the concept of residual risk, i.e., the risk that is left after controls have been fully implemented, in order to manage risk to a level deemed acceptable by the organization. Thus, excessive residual risk occurs when one or more controls are not fully implemented. It is this excessive residual risk the organization must strive to minimize through its risk management program.
Since excessive residual risk may be estimated by the risk of a control failure, we must estimate the likelihood the control will fail as well as the impact to the organization when a failure occurs. Some purists might argue that only quantitative assessments provide value; however, in reality, decisions are often made with incomplete information. The reasons for this are many and varied. For example, there may be a limited amount of time in which to make a decision, or the information simply is not available. In many cases, expert judgment is applied such as when auditors scope work or make judgments about the effectiveness of financial controls.
The level of precision one needs to make a decision may also depend on the type of problem or question being addressed. For example, triage in an emergency room following a natural disaster requires a general level of information. Is the patient breathing or bleeding? Is the injury life threatening? Medical diagnoses, on the other hand, generally require a much more granular level of information to determine if the patient is suffering from one particular disease or another with similar symptoms. However, none of the decisions described are made without some sort of framework or methodology to support the decision-‐making process.
HITRUST leverages the NIST PRISMA methodology, which incorporates the concept of capability maturity to determine likelihood of a control failure but expresses the levels in a way that, while roughly equivalent with their Capability Maturity Model-‐Integrated (CMMI) counterparts, is much more intuitive for the evaluation of information security as opposed to the traditional language used around process maturity. HITRUST also leverages the PRISMA quasi-‐quantitative scoring model to facilitate the assessment process when incorporated into security test and evaluation plans as well as express control maturity (effectiveness).
The other part of the risk equation—the impact of a specific control failure—is often harder to assess than the efficacy of the control implementation, especially in the context of the entire control environment. One way to make this more tractable is to map control-‐level impacts from and thru established information security control frameworks in order to provide a non-‐contextual estimate of the relative impact of one control failure with respect to another. HITRUST leveraged work done by the DoD to assign non-‐contextual impact values to individual controls contained in DoD Instruction 8500.2. By mapping through the NIST 800-‐53 controls to the ISO 27001 information security control clauses, estimates of the relative impact for the failure of each control were obtained. This provides a common point of reference for organizations to use in a contextual analysis performed on a smaller sub-‐ set of controls that are found deficient, which is generally more tractable than trying to determine the impact of all the controls in the environment at the same time (i.e., contextually). HITRUST believes this approach is justified as it is used extensively by the DoD in its information system security certification and accreditation methodology when developing a residual risk analysis after a security test and evaluation.
Once estimates are obtained for impact and likelihood, the computation of estimated residual risk is relatively straightforward. However, rather than represent risk in terms of “heat maps,” it is possible to present risk to executive management in a more intuitive way. By making adjustments to the PRISMA scoring model and normalizing the risk computations on a scale of zero to 100, excessive residual risk may be represented as academic-‐style grades. In this model, anything below 60 would be a failing grade. This is intuitively obvious if one considers a score of 50 percent basically means—when viewed in terms of control maturity and discounting impact—that the control will likely fail half the time. Thus anything below 60 would be a severe risk. Similarly, scores from 60 to 70 would represent a high risk, from 70 to 80 a medium risk, from 80 to 90 a low risk, and from 90 to 100 as a minimal risk.
Although not a true quantitative estimate of the risk, the scores provide sufficient information in a very intuitive way for organizations to make decisions under normal conditions of uncertainty about the relative control-‐related risks these scores represent.
A graphical representation of the control objectives and the control categories they support (such as the one that follows) can be provided for specific systems such as electronic health records or medical devices, organizations such as single hospitals within a health system, or common departments within health systems such as emergency rooms or pharmacies. These scores can also be used for internal and industry-‐level benchmarking.
HITRUST 15
CSF assessments are now supported by a fully integrated, optimized, and user-‐friendly tool—MyCSF—that marries the content and methodologies of the CSF and CSF Assurance Program with the technology and capabilities of a governance, risk and compliance (GRC) tool. MyCSF provides healthcare organizations of all types and sizes with a secure, Web-‐based solution for accessing the CSF, performing assessments, managing remediation activities, and reporting and tracking compliance. MyCSF is also managed and supported by HITRUST, providing organizations with up-‐to-‐date content, accurate and consistent scoring, reports validated by HITRUST and benchmarking data available nowhere else in the industry, thus going far beyond what a traditional GRC tool provides.
By utilizing the capabilities of a GRC platform, MyCSF provides organizations with a sophisticated and user-‐friendly tool in which to scope, assess and manage their environment. This new tool increases the efficiency with which organizations can implement and assess against the CSF by utilizing advanced workflows, custom criteria, automated data collection and notifications, and enhanced navigation and search tools. The tool also provides a user-‐friendly interface with the availability of dashboards and reports and acts as a central repository for managing documents, corrective action plans, test plans and system scoping.
MyCSF Components: • MyCSF View – This vehicle provides online access to the CSF and its authoritative sources for reference purposes and can also
provide customized views based on organization and system profile data. Users can now maintain single or multiple views and concentrate on only the controls and implementation levels applicable to their organizations and systems. Other additions include new and enhanced search tools.
• MyCSF Assessment – This risk-‐based approach uses organizational, regulatory and system profile information to create a comprehensive and customized assessment questionnaire from a standard set of controls. Assessments can be submitted directly to HITRUST so an organization can receive a CSF Validated report with standardized scoring that provides organizations with a way to communicate their compliance both internally and to third parties.
-‐ Baseline Assessment – The baseline assessment efficiently measures an organization against a streamlined set of requirements from the 63 controls required for CSF Certification, which are identified and selected based upon risk. A HIPAA scorecard, which reports an organization’s compliance with HIPAA requirements only, is also available once a baseline assessment is complete.
-‐ Comprehensive Assessment – The comprehensive assessment efficiently measures an organization against a streamlined set of requirements from all 135 controls of the CSF. Scorecards for any of the other CSF authoritative sources will be available once a comprehensive assessment is complete. The comprehensive assessment also supports evaluation of the CSF controls mapped to the American Institute of Certified Public Accountants (AICPA) Trust Services Principles, which organizations can then leverage for Statement on Standards for Attestation Engagements (SAE16) Service Organization Controls (SOC) 2 reporting.
HITRUST 16
Also included in MyCSF is the availability of benchmarking data, allowing organizations to see how they compare to their peers in the healthcare industry. This data is gathered using the standardized approach and scoring methodology of the CSF Assurance Program to ensure the highest quality of data. HITRUST aggregates, analyzes and breaks down this valuable information so organizations can measure themselves against other healthcare entities of a similar type and size or the industry as a whole.
The CSF Assurance Program enables trust in health information protection through an efficient and manageable approach by identifying incremental steps for an organization to take on the path to becoming CSF Validated or CSF Certified.
The comprehensiveness of the security requirements for the assessed entity is based on the multiple levels within the CSF as determined by defined risk factors. The level of assurance for the overall assessment of the entity is based on multiple tiers, from self-‐assessment questionnaires to on-‐site analysis/testing performed by a CSF Assessor. The results of the assessment are documented in a standard report with a compliance scorecard and remediation activities tracked in a corrective action plan (CAP). Once vetted by HITRUST and performed for all levels of assurance, the assessed entity can use the assessment results to report to external parties in lieu of existing security requirements and processes, saving time and containing costs.
The below diagram following outlines the relationship between comprehensiveness of the assessment and the level of assurance provided by the assessment for organizations of varying complexity based on the risk of the relationship as determined by the relying organization:
A CSF assessment allows an organization to communicate to relying entities its compliance with the CSF, and optionally with other requirements such as HIPAA and HITECH. HITRUST reviews the assessment results and CAP to provide added assurance to the external entities relying on the assessed entity’s results.
HITRUST 17
The CSF Assurance Program effectively establishes trust in health information protection through an achievable assessment and reporting path for organizations of all sizes, complexities and risks. The CSF Assurance Program operates at three levels: Self Assessment, Third-‐party Validated, or Third-‐party Certified.
Summary HITRUST—on behalf of the healthcare industry—has integrated multiple international, federal, industry frameworks and best practice standards and frameworks, adapted them to the healthcare environment, and provided an industry standard of due diligence and due care that can be tailored to an individual organization based upon its specific business requirements. The CSF and CSF Assurance Program provide organizations with a single approach to assessment and reporting against these multiple requirements, and both are updated at least annually to account for changes in legislation, regulation, standards, guidance and best practices, such as with the release of the NIST SP 800-‐53 revision 4, the NIST HSR Toolkit, and the OCR Audit Protocol. Further, all changes to the CSF are provided to the industry for review and comment to ensure an open and transparent framework that is freely available to qualified healthcare organizations that wish to use it.
HITRUST 18
Conclusion The only thing constant about information security and privacy in the healthcare environment is change. New regulations, standards, guidance and tools continue to complicate the landscape, and organizations are left to determine how best to achieve compliance and provide an “adequate” level of protection.
Healthcare organizations often do not have the skilled personnel or resources to develop a custom set of “reasonable and appropriate” safeguards and choose to adopt and adapt external information security control and risk management frameworks. But even this can be difficult for healthcare organizations to do. So, rather than independently performing the work of integrating multiple international, federal and industry frameworks and best practice standards and then adapting them to the healthcare environment and their particular organization, HITRUST was formed to perform this work on behalf of the industry and establish a standard of due diligence and due care that can be tailored to an individual organization based upon their specific business requirements—the CSF.
The CSF Assurance Program also provides organizations a single approach to assessment and reporting against these multiple requirements, and both the CSF and CSF Assurance Program are updated at least annually to account for changes in legislation, regulation, standards, guidance and best practices, such as with the 2012 release of the Office of Civil Rights (OCR) Audit Protocol. Further, all changes to the CSF are provided to the industry for review and comment, ensuring transparency and openness. And HITRUST provides the CSF free to qualified healthcare organizations that wish to implement the framework.
So, given that the CSF is an integrated, harmonized, healthcare centric, transparent, prescriptive, tailorable, scalable and certifiable framework that provides a common mechanism for the sharing of risk information, why hasn’t it been adopted by 100 percent of healthcare organizations? Unfortunately, many organizations have not yet come-‐to-‐terms with the level of due diligence and due care required to safeguard ePHI and meet regulatory compliance requirements.
For example, the NIST HSR toolkit appeals to some organizations because it provides a “check-‐the-‐box” approach to addressing specific safeguards; however, they often fail to dig deeper into the references to determine what is actually “in-‐the-‐box” they are checking. They may stop with the results of this control gap analysis and fail to fully evaluate the likelihood and impact components necessary to complete the risk analysis. Other organizations may go even further and rely on the OCR Audit Protocol to satisfy their HIPAA risk analysis requirements without realizing the protocol is incomplete, doesn’t address every implementation specification in the Security Rule, and does not integrate well with the NIST HSR Toolkit or the NIST RMF. The focus is on “passing” an audit rather than on the spirit and intent of their compliance requirements. The CSF on the other hand, is tightly integrated with the CSF Assurance Program and MyCSF.
Fortunately, most of the industry understands the need to provide “reasonable and appropriate” safeguards and satisfy their regulatory obligation to provide “adequate” protection. And this is why the CSF enjoys various levels of adoption by 83 percent of hospitals and 82 percent of health plans and is unarguably the de facto standard for health information security safeguards in the healthcare industry.
For those that have not yet fully adopted the CSF, many are left with the task of choosing, adapting, and implementing an existing information security control framework. Even those that have decided to fully adopt the CSF can sometimes struggle with its implementation. This is why HITRUST continues to develop and publish guidance and tools like the CSF assessment methodology and MyCSF as part of an overall risk management framework to help organizations implement and manage “reasonable and appropriate” safeguards that demonstrate the level of due care and due diligence required to ensure “adequate” protection of the health information with which they are entrusted.
So, when HITRUST is asked how new regulations, standards, guidance and tools effect the value of the CSF and CSF-‐related tools, the answer is simple. The CSF, CSF Assurance Program and related methodologies and tools that make up the HITRUST RMF are needed more now than ever before.
HITRUST 19
About HITRUST The Health Information Trust Alliance (HITRUST) was born out of the belief that information security should be a core pillar of, rather than an obstacle to, the broad adoption of health information systems and exchanges. HITRUST, in collaboration with healthcare, business, technology and information security leaders, has established the CSF, a certifiable framework that can be used by any and all organizations that create, access, store or exchange personal health and financial information. Beyond the establishment of the CSF, HITRUST is also driving the adoption of and widespread confidence in the framework and sound risk management practices through awareness, education, advocacy and other outreach activities. For more information, visit www.HITRUSTalliance.net.
MyCSF MyCSF is a fully integrated, optimized, and powerful tool that marries the content and methodologies of the HITRUST CSF and CSF Assurance Program with the technology and capabilities of a governance, risk and compliance (GRC) tool. The user-‐friendly MyCSF tool provides healthcare organizations of all types and sizes with a secure, Web-‐based solution for accessing the CSF, performing assessments, managing remediation activities, and reporting and tracking compliance. Managed and supported by HITRUST, MyCSF provides organizations with up-‐to-‐date content, accurate and consistent scoring, reports validated by HITRUST and bench-‐ marking data unavailable anywhere else in the industry, thus going far beyond what a traditional GRC tool can provide. For more information, visit www.hitrustalliance.net/mycsf.
HITRUST 20
Appendix A – Frequently Asked Questions HITRUST is often asked various questions about the CSF and CSF Assurance Program and how they relate to other frameworks, guidance, tools and best practices. This appendix provides answers to those more pertinent to the topic at hand.
FAQ# FAQ Answer More Info
1 Where can I find NIST publications like NIST SP 800-‐66 r1?
NIST has a Web site with links to all the 800-‐series publications: http://csrc.nist. gov/publications/PubsSPs.html.
http://csrc.nist.gov/publications/ CSD_DocsGuide.pdf
2 Where can I find HITRUST publications like the HITRUST CSF and HITRUST Assessment methodology documents?
Qualified subscribers can find these documents on the HITRUST Publicly Available Downloads section
https://hitrustalliance.net/downloads/
3 Are NIST SP 800-‐series documents intended for all healthcare organizations?
No, you’ll find in the introduction of most NIST SP 800-‐series publications (e.g., NIST SP 800-‐66 r1, p.1) that they’re primarily written as guidance for federal agencies; however, they may also be used by non-‐federal organizations on a strictly voluntary basis. Note that not all guidance may be applicable to a particular non-‐federal healthcare entity or the healthcare industry as whole.
4 What is the NIST HSR Toolkit The NIST HIPAA Security Toolkit Application is intended to help organizations better understand the requirements of the HIPAA Security Rule, implement those requirements, and assess those implementations in their operational environment. Target users include, but are not limited to, HIPAA covered entities, business associates, and other organizations such as those providing HIPAA Security Rule implementation, assessment, and compliance services. Target user organizations can range in size from large nationwide health plans with vast information technology (IT) resources to small health care providers with limited access to IT expertise.
http://scap.nist.gov/hipaa/
HITRUST 21
FAQ# FAQ Answer More Info 5 What is the OCR Audit Protocol? The OCR HIPAA Audit program analyzes processes,
controls, and policies of selected covered entities pursuant to the HITECH Act audit mandate. OCR established a comprehensive audit protocol that contains the requirements to be assessed through these performance audits. The entire audit protocol is organized around modules, representing separate elements of privacy, security, and breach notification. The combination of these multiple requirements may vary based on the type of covered entity selected for review. The protocol covers Security Rule requirements for administrative, physical, and technical safeguards as well as Privacy Rule requirements for (1) notice of privacy practices for PHI, (2) rights to request privacy protection for PHI, (3) access of individuals to PHI, (4) administrative requirements, (5) uses and disclosures of PHI, (6) amendment of PHI, and (7) accounting of disclosures. The protocol also covers require-‐ ments for the Breach Notification Rule.
http://www.hhs.gov/ocr/privacy/ hipaa/enforcement/audit/protocol. html
6 What’s the difference between the NIST HSR Toolkit and the OCR Audit Protocol?
The NIST HSR Toolkit provides a way to assess an organization’s compliance with the HIPAA Security Rule implementation specifications. The OCR Audit Protocol provides a set of audit procedures for a large subset of the Rule’s specifications, which are of particular interest to OCR, but does not go into the same level of detail that the Toolkit is capable of providing.
7 What is MyCSF? My CSF is a fully integrated, optimized, and powerful tool that marries the content and methodologies of the HITRUST CSF and CSF Assurance program with the technology and capabilities of a governance risk and compliance (GRC) tool. The new user-‐friendly MyCSF tool provides healthcare organizations of all types and sizes with a secure, web-‐based solution for accessing the CSF, performing assessments, managing remediation activities, and reporting and tracking compliance.
http://www.hitrustalliance.net/ mycsf/
HITRUST 22
FAQ# FAQ Answer More Info 8 What assessments are available in
MyCSF? There are three types of assessments available in MyCSF: • Baseline Assessment – The baseline assessment efficiently measures an organization against a streamlined set of requirements from the 63 controls required for CSF Certification, which are identified and selected based upon risk. A HIPAA scorecard, which reports an organization’s compliance with HIPAA requirements only, is also available once a baseline assessment is complete. • Comprehensive Assessment – The comprehensive assessment efficiently measures an organization against a streamlined set of requirements from all 135 controls of the CSF. Scorecards for any of the other CSF authoritative sources will be available once a comprehensive assessment is complete. • Detailed Control Assessment – The detailed con-‐ trols assessment is the most comprehensive measurement of compliance and allows an organization to assess at the most granular level against the prescriptive implementation requirements outlined in each CSF control.
http://www.hitrustalliance.net/ mycsf/
9 What’s the difference between the NIST HSR Toolkit and the assessments available in MyCSF?
The NIST HSR Toolkit assessment is most similar to the MyCSF Comprehensive Assessment. However, the Toolkit is only scalable to ‘standard’ and ‘enterprise’ level organizations and does not support tailoring based on other risk factors. Only simple “Yes/No” responses with the ability to provide comments are available. The Toolkit does not provide a control maturity or effectiveness rating that would provide a repeatable, consistent likelihood estimator.
10 What’s the difference between the OCR Audit Protocol and the assess-‐ ments available in MyCSF?
The OCR Audit Protocol is most similar to the illustrative procedures contained in the MyCSF Baseline Assessment. However, the protocol is primarily a compliance tool as it does not provide a control maturity or effectiveness rating that would provide a repeatable, consistent likelihood estimator. Note also that the Protocol is not designed to be scalable or tailorable to the organization.
HITRUST 23
FAQ# FAQ Answer More Info 11 Is there a difference between a risk as-‐
sessment and a risk analysis? the terms can be significantly different in common us-‐ age, e.g., technical vulnerability assessments and control effectiveness assessments are sometimes confused with a risk assessment. Also, risk assessments in practice may not always contain all the elements necessary to support a valid risk analysis, e.g., vulnerability assessment, threat assessment, asset valuation and impact assessment, risk evaluation and prioritization, or remediation planning.
12 Will an assessment using the NIST HSR Toolkit help my organization satisfy the requirements for a risk analysis?
Yes, but not completely. The NIST HSR Toolkit provides a set of questions that map to the HIPAA Security Rule. Although some questions reference a specific NIST SP 800-‐53 security control, most reference the section in NIST SP 800-‐66 that addresses that particular implementation specification. The Tool allows organizations to perform a compliance assessment (“Yes/No” responses) but does not provide the estimates of likelihood and impact needed to support a risk analysis. This is left to the organization conducting the assessment.
http://scap.nist.gov/hipaa/ http://csrc.nist.gov/news_events/ hiipaa_june2012/day2/day2-‐3_smill-‐ er-‐jsheldondean-‐swilson_hsr-‐tool-‐ kit-‐use-‐case.pdf
13 Will an assessment using the OCR Audit Protocol help my organization satisfy the requirements for a risk analysis?
No. The OCR Audit Protocol does not address every implementation specification in the HIPAA Security Rule. It will only provide organizations a better chance of “passing” an OCR audit.
http://www.hhs.gov/ocr/privacy/ hipaa/enforcement/audit/protocol. html
14 Will an assessment using MyCSF help my organization satisfy the require-‐ ments for a risk analysis?
Yes. A MyCSF Baseline Assessment will cover every implementation specification in the HIPAA Security Rule. However, a MyCSF Comprehensive Assessment will al-‐ low an organization to assess controls that support the primary controls mapped from the Rule to the HITRUST CSF. Both assessments provide likelihood estimators for probability and impact, which supports the risk calculations needed to determine a risk strategy and prioritization of risk responses.
http://www.hitrustalliance.net/ mycsf/
HITRUST 24
FAQ# FAQ Answer More Info 15 What are the key differences between
the HITRUST and NIST control frame-‐ works?
Although HITRUST CSF incorporates a majority of the NIST control requirements, there are marked differences between the two frameworks. NIST is primarily designed for federal agencies and some of the requirements may not be suitable for some health care organizations. The CSF is also specifically designed to meet the multitude of legislative, regulatory and other requirements relevant to the healthcare industry, whereas NIST—while an excellent framework—is simply one of them. The NIST framework is tailorable in that one of three baselines may be selected based on the highest level of impact from a loss of confidentiality, integrity and availability, whereas the CSF is tailorable based on multiple organizational, system and regulatory risk factors. The CSF scales to the size of organization; NIST does not (however, the NIST HSR Toolkit arguably scales the NIST controls for standard-‐ and enterprise-‐level organizations). And HITRUST manages additional tailoring through the alternate control approval process whereas NIST allows additional unmanaged tailoring.
https://hitrustalliance.net/content/uploads/2015/03/CSFComparisonWhitpaper.pdf
HITRUST 25
Appendix B -‐ Glossary
Term Definition
Adequate Security [OMB Circular A-‐130, Appendix III]
Security commensurate with the risk and magnitude of harm resulting from the loss, misuse, or unauthorized access to or modification of information.
Adversary [DHS Risk Lexicon] Individual, group, organization, or government that conducts or has the intent to conduct detrimental activities.
Alternate Control [HITRUST] See Compensating Control.
Analysis Approach The approach used to define the orientation or starting point of the risk assessment, the level of detail in the assessment, and how risks due to similar threat scenarios are treated.
Assessment See Security Control Assessment or Risk Assessment.
Attack [CNSSI No. 4009] Any kind of malicious activity that attempts to collect, disrupt, deny, degrade, or destroy information system resources or the information itself.
Availability [44.U.S.C., Sec. 3542] Ensuring timely and reliable access to and use of information.
Compensating Security Control [CNSSI No. 4009]
A management, operational, and/or technical control (i.e., safeguard or countermeasure) employed by an organization in lieu of a recommended security control in the low, moderate, or high baselines that provides equivalent or comparable protection for an information system. Synonymous with Alternate Control [HITRUST].
Confidentiality [44 U.S.C., Sec. 3542] Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information.
Criticality [NIST SP 800-‐60] A measure of the degree to which an organization depends on the information or information system for the success of a mission or of a business function. Note criticality is often determined by the impact to the organization due to a loss of integrity or availability.
Defense-‐in-‐Breadth [CNSSI No. 4009] A planned, systematic set of multidisciplinary activities that seek to identify, manage, and reduce risk of exploit-‐ able vulnerabilities at every stage of the system, network, or subcomponent life cycle (system, network, or product design and development; manufacturing; packaging; assembly; system integration; distribution; operations; maintenance; and retirement).
HITRUST 26
Term Definition Defense-‐in-‐Depth [CNSSI No. 4009] Information security strategy integrating people, technology, and operations capabilities to establish variable
barriers across multiple layers and missions of the organization. Impact Level [CNSSI No. 4009] The magnitude of harm that can be expected to result from the consequences of unauthorized disclosure of in-‐
formation, unauthorized modification of information, unauthorized destruction of information, or loss of information or information system availability.
Impact Value [CNSSI No. 1253] The assessed potential impact resulting from a compromise of the confidentiality, integrity, or availability of an information type, expressed as a value of low, moderate, or high.
Information Security Risk The risk to organizational operations (including mission, functions, image, reputation), organizational assets, individuals, other organizations, and the Nation due to the potential for unauthorized access, use, disclosure, disruption, modification, or destruction of information and/or information systems. See Risk.
Information System-‐Related Security Risk [Adapted]
Risk that arises through the loss of confidentiality, integrity, or availability of information or information systems considering impacts to organizational operations and assets, individuals, and other organizations. A subset of Information Security Risk. See Risk.
Integrity (44 U.S.C., Sec. 3542) Guarding against improper information modification or destruction, and includes ensuring information non-‐ repudiation and authenticity.
Likelihood of Occurrence [CNSSI No. 4009, adapted]
A weighted factor based on a subjective analysis of the probability that a given threat is capable of exploiting a given vulnerability or a set of vulnerabilities.
Plan of Action and Milestones [OMB Memorandum 02-‐01]
A document that identifies tasks needing to be accomplished. It details resources required to accomplish the elements of the plan, any milestones in meeting the tasks, and scheduled completion dates for the milestones. Synonymous with Corrective Action Plan.
Quantitative Assessment [DHS Risk Lexicon] A set of methods, principles, or rules for assessing risks based on the use of numbers where the meanings and proportionality of values are maintained inside and outside the context of the assessment.
Qualitative Assessment [DHS Risk Lexicon] A set of methods, principles, or rules for assessing risk based on non-‐numerical categories or levels.
Repeatability The ability to repeat an assessment in the future, in a manner that is consistent with, and hence comparable to, prior assessments.
Reproducibility The ability of different experts to produce the same results from the same data. Residual Risk [CNSSI No. 4009] Portion of risk remaining after security measures have been applied.
HITRUST 27
Term Definition Risk Analysis [CNSSI No. 4009, Adapted] Examination of information to identify the risk to an information asset. Synonymous with risk assessment.
Risk Assessment [Adapted] The process of identifying, estimating, and prioritizing risks to organizational operations (including mission, functions, image, and reputation), organizational assets, individuals, and other organizations, resulting from the operation of an information system. Part of risk management, incorporates threat and vulnerability analyses, and considers mitigations provided by security controls planned or in place. Synonymous with risk analysis.
Risk Factor A characteristic in a risk model as an input to determining the level of risk in a risk assessment.
Risk Management [Adapted] The program and supporting processes to manage information security risk to organizational operations (including mission, functions, image, and reputation), organizational assets, individuals, and other organizations, and includes: (i) establishing the context for risk-‐related activities; (ii) assessing risk; (iii) responding to risk once determined; and (iv) monitoring risk over time.
Risk Management Framework [HITRUST] A common taxonomy and standard set of processes, procedures, activities, and tools that support the identification, assessment, response, control and reporting of risk.
Risk Mitigation [CNSSI No. 4009] Prioritizing, evaluating, and implementing the appropriate risk-‐reducing controls/countermeasures recommended from the risk management process. A subset of Risk Response.
Risk Model A key component of a risk assessment methodology—in addition to the assessment approach and analysis approach—that defines key terms and assessable risk factors.
Risk Monitoring [NIST SP 800-‐39] Maintaining ongoing awareness of an organization’s risk environment, risk management program, and associated activities to support risk decisions.
Risk Response [NIST SP 800-‐39, adapted] Accepting, avoiding, mitigating, sharing, or transferring risk to organizational operations (i.e., mission, functions, image, or reputation), organizational assets, individuals, or other organizations. See Course of Action. Synonymous with Risk Treatment.
Root Cause Analysis A principle-‐based, systems approach for the identification of underlying causes associated with a particular set of risks.
Scaling [HITRUST] The act of applying specific considerations related to the size and financial/resource capabilities/constraints of an organization on the applicability and implementation of individual security and privacy controls in the control baseline. A subset of Scoping.
HITRUST 28
Term Definition Scoping [NIST SP 800-‐53, adapted] The act of applying specific technology-‐related, infrastructure-‐related, public access-‐related, scalability-‐related,
common security control-‐related, and risk-‐related considerations on the applicability and implementation of individual security and privacy controls in the control baseline.
Security Control [CNSSI No. 4009, adapted] The management, operational, and technical controls (i.e., safeguards or countermeasures) prescribed for an organization and/or information system(s) to protect information confidentiality, integrity, and availability.
Security Control Assessment [NIST SP 800-‐39; CNSSI No. 4009, adapted]
The testing and/or evaluation of the management, operational, and technical security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired out-‐ come with respect to meeting the security requirements for an information system or organization.
Security Control Baseline [CNSSI No. 1253, adapted]
A set of information security controls that has been established through information security strategic planning activities intended to be the initial security control set selected for a specific organization and/or system(s).
Semi-‐Quantitative Assessment [DHS Risk Lexicon]
Use of a set of methods, principles, or rules for assessing risk based on bins, scales, or representative numbers whose values and meanings are not maintained in other contexts. Synonymous with Quasi-‐Quantitative Assessment.
Tailored Security Control Baseline [NIST SP 800-‐39]
A set of security controls resulting from the application of tailoring guidance to the security control baseline. See Tailoring.
Tailoring [NIST SP 800-‐53; CNSSI No. 4009] The process by which a security control baseline is modified based on: (i) the application of scoping guidance; (ii) the specification of compensating security controls, if needed; and (iii) the specification of organization-‐defined parameters in the security controls via explicit assignment and selection statements.
Threat [CNSSI No. 4009, adapted] Any circumstance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, or other organizations through an information system via unauthorized access, destruction, disclosure, or modification of information, and/or denial of service.
Threat Assessment [CNSSI No. 4009] Process of formally evaluating the degree of threat to an information system or enterprise and describing the nature of the threat.
Threat Event An event or situation that has the potential for causing undesirable consequences or impact.
Threat Scenario A set of discrete threat events, associated with a specific threat source or multiple threat sources, partially ordered in time.
Threat Source [CNSSI No. 4009] The intent and method targeted at the intentional exploitation of a vulnerability or a situation and method that may accidentally exploit a vulnerability.
Vulnerability Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited by a threat source.
Vulnerability Assessment Systematic examination of an information system or product to determine the adequacy of security measures, identify security deficiencies, provide data from which to predict the effectiveness of proposed security measures, and confirm the adequacy of such measures after implementation.