SlideShare a Scribd company logo

Are NIST standards clouding the implementation of HIPAA security risk assessments?

•
•
David Sweigert
David Sweigert

The HIPAA Security Rule (at 45 C.F.R. §164.308(a)(1)(ii)(A)) requires an initial security risk analysis according to risk analysis guidance issued by HHS/OCR based on NIST standards. OCR Audit Protocols for Risk Analysis are clear! CMS, as planned, has launched audits of organizations who have attested to Meaningful Use Objectives and Risk Analyses will be audited. Have you completed a bona fide HIPAA Security Risk Analysis?

1 of 3
Download to read offline
1 Are NIST standards clouding the implementation of HIPAA protections? Part nine of a series September 2013 Author: Dave Sweigert, M.Sci., CISSP, CISA, PMP (non-attorney providing scholarly (non-legal) advice) ABSTRACT Subcontractors processing protected health information should be aware of legal liabilities regarding the adequacy of bona fide security risk assessments. Background September 23, 2013 is the deadline for those entities processing “protected health information” (PHI) to ensure their subcontractors align their security practices with the national PHI protection floor known as the Security Rule of the Health Insurance Portability and Accountability Act (HIPAA). The mechanism to accomplish this objective is known as the Business Associate Agreement (BAA). Subcontractors are considered “business associates” in this model and their BAA may require their compliance with the HIPAA Security Rule; which among other things, requires a “security risk assessment”; Title 45 Code of Federal Regulations (C.F.R.) Section 164.308(a)(1). It would be an over-simplification to assume that a 45 C.F.R. 164.308(a)(1) security risk assessment is open to broad interpretation, as to adequacy, by the entity conducting such a security risk assessment. NIST Standards Mandated There is a bright-line test as to the required level of sufficiency for a 45 C.F.R. 164.308(a)(1) security risk assessment. “Federal contractors” have been bound by pre-existing requirements regarding the level of quality required of their information security practices for a decade. The Medicare Prescription Drug, Improvement, and Modernization Act of 2003 (MPDIMA) added information security requirements for Medicare administrative contractors (MAC), fiscal intermediaries, and carriers. MPDIMA imposed the requirements of the Federal Information Security Management Act (FISMA, 44 U.S.C. 3541 et seq.) as the prevailing bright- line test for information security practices of CMS “federal contractors”. See 42 U.S.C. § 1395kk-1.
2 Requirements for NIST compliance The 1988 Omnibus Trade and Competitiveness Act (OTCA) gave the exclusive domain for the promulgation of federal computer security standards to the U.S. National Institute of Standards and Technology (NIST). The NIST Information Security Laboratory and the Computer Security Division are the only pertinent, relevant and chartered (by Congress), organizations to render opinions on behalf of the U.S. Government in matters of computer security technology and standardization. Office of Management and Budget (OMB in the Executive Office of the President (EOP)) instruction M-10-15, (OMB M-10-15), entitled, Reporting Instructions for the Federal Information Security Management Act (FISMA, 44 U.S.C. 3541 et seq.) and Agency Privacy Management 13-14 (2010), requires federal contractors to ensure the operation of information technology infrastructure is in compliance with the security provisions of the FISMA law. Quoting OMB instructions M-10-15 in relevant part (at page 15): “..Agencies are fully responsible and accountable for ensuring all FISMA and related policy requirements are implemented and reviewed and such must be included in the terms of the contract. Agencies must ensure identical, not "equivalent," security procedures. For example, annual reviews, risk assessments, security plans, control testing, contingency planning, and security authorization (C&A) must, at a minimum, explicitly meet guidance from NIST. Additionally, IGs shall include some contractor systems in their “representative subset of agency systems,” and not doing so presents an incomplete independent evaluation. [emphasis added] The U.S. Department of Health and Human Services (DHHS), Office of Chief Information Officer (OCIO) policy regarding Cybersecurity; known as HHS-OCIO-2011-0003, states: (quoting in relevant part) “…This Policy applies to all HHS organizational components (i.e., Operating Divisions [OPDIVs] and Staff Divisions [STAFFDIVs]) and organizations conducting business for and on behalf of the Department through contractual relationships. This Policy does not supersede any other applicable law, higher-level agency directive, or existing labor management agreement in place as of the effective date of this Policy….” [emphasis added]; and, “…4.1.1 OPDIVs/STAFFDIVs shall use the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-37 Revision (Rev.) 1, Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach (dated February 2010), as the methodology for the security authorization of information systems (formerly known as “certification and accreditation” or “C&A”), in accordance
3 with FISMA and direction from the Office of Management and Budget (OMB)…”; [emphasis added] and, “…4.1.4 Information assurance and privacy activities conducted within the Department shall be consistent with the guidance, methodologies, and intent prescribed by the NIST SP series, in particular NIST SP 800-53 Rev. 3 and NIST SP 800-53A Rev. 1, Guide for Assessing the Security Controls in Federal Information Systems and Organizations, Building Effective Security Assessment Plans, and other relevant Federal laws and guidance documents. It is incumbent upon each OPDIV to appropriately follow the steps in the NIST SP 800-37 Rev. 1 Risk Management Framework (RMF) to select, implement, assess, authorize, and monitor such controls commensurate with a system’s FIPS 199 categorization….”[emphasis added] Bona fide risk assessment The foregoing authorities can be summarized within the industry term “bona fide security risk assessment”. That is, to meet the bright-line test and legal sufficiency for assessing security management practices an adequate risk assessment must be completed (for those subcontractors supporting HIPAA “covered entities” that are federal contractors) to the NIST standard. Such bona fide assessments will demonstrate a baseline of adequate security policies, standards and guidelines (PSGs) that have been put in place to protect PHI. A risk assessment will measure the implementation maturity of those guidelines (practical implementation in the I.T infrastructure with appropriate evidence to demonstrate compliance) and identify gaps. Gaps (material weaknesses) will then be compared with the downstream consequences of failure or exploit. These gaps, and consequences, will be presented to senior management so that remediation can be planned and prioritized. The foregoing represents a significant departure from the usual check-box compliance approach of conducting a network penetration study or red team dumpster diving and then hoping for the best. Business associates of federal contractors processing PHI, especially on behalf of DHHS, would be prudent to accurately assess their need to comply with the authorities cited. About the author: Dave Sweigert is a Certified Information Systems Security Professional, Certified Information Systems Auditor, Project Management Professional and holds Master’s degrees in Information Security and Project Management. A former consultant to the U.S. Department of Homeland Security, he is a practitioner of developing HIPAA Security Rule compliant policies, standards and guidelines that demonstrate compliance for many organizations (including Delta Dental, Kaiser Permanente and others). He can be reached at LINKEDIN.COM.

More Related Content

Are NIST standards clouding the implementation of HIPAA security risk assessments?

  • 1. 1 Are NIST standards clouding the implementation of HIPAA protections? Part nine of a series September 2013 Author: Dave Sweigert, M.Sci., CISSP, CISA, PMP (non-attorney providing scholarly (non-legal) advice) ABSTRACT Subcontractors processing protected health information should be aware of legal liabilities regarding the adequacy of bona fide security risk assessments. Background September 23, 2013 is the deadline for those entities processing “protected health information” (PHI) to ensure their subcontractors align their security practices with the national PHI protection floor known as the Security Rule of the Health Insurance Portability and Accountability Act (HIPAA). The mechanism to accomplish this objective is known as the Business Associate Agreement (BAA). Subcontractors are considered “business associates” in this model and their BAA may require their compliance with the HIPAA Security Rule; which among other things, requires a “security risk assessment”; Title 45 Code of Federal Regulations (C.F.R.) Section 164.308(a)(1). It would be an over-simplification to assume that a 45 C.F.R. 164.308(a)(1) security risk assessment is open to broad interpretation, as to adequacy, by the entity conducting such a security risk assessment. NIST Standards Mandated There is a bright-line test as to the required level of sufficiency for a 45 C.F.R. 164.308(a)(1) security risk assessment. “Federal contractors” have been bound by pre-existing requirements regarding the level of quality required of their information security practices for a decade. The Medicare Prescription Drug, Improvement, and Modernization Act of 2003 (MPDIMA) added information security requirements for Medicare administrative contractors (MAC), fiscal intermediaries, and carriers. MPDIMA imposed the requirements of the Federal Information Security Management Act (FISMA, 44 U.S.C. 3541 et seq.) as the prevailing bright- line test for information security practices of CMS “federal contractors”. See 42 U.S.C. § 1395kk-1.
  • 2. 2 Requirements for NIST compliance The 1988 Omnibus Trade and Competitiveness Act (OTCA) gave the exclusive domain for the promulgation of federal computer security standards to the U.S. National Institute of Standards and Technology (NIST). The NIST Information Security Laboratory and the Computer Security Division are the only pertinent, relevant and chartered (by Congress), organizations to render opinions on behalf of the U.S. Government in matters of computer security technology and standardization. Office of Management and Budget (OMB in the Executive Office of the President (EOP)) instruction M-10-15, (OMB M-10-15), entitled, Reporting Instructions for the Federal Information Security Management Act (FISMA, 44 U.S.C. 3541 et seq.) and Agency Privacy Management 13-14 (2010), requires federal contractors to ensure the operation of information technology infrastructure is in compliance with the security provisions of the FISMA law. Quoting OMB instructions M-10-15 in relevant part (at page 15): “..Agencies are fully responsible and accountable for ensuring all FISMA and related policy requirements are implemented and reviewed and such must be included in the terms of the contract. Agencies must ensure identical, not "equivalent," security procedures. For example, annual reviews, risk assessments, security plans, control testing, contingency planning, and security authorization (C&A) must, at a minimum, explicitly meet guidance from NIST. Additionally, IGs shall include some contractor systems in their “representative subset of agency systems,” and not doing so presents an incomplete independent evaluation. [emphasis added] The U.S. Department of Health and Human Services (DHHS), Office of Chief Information Officer (OCIO) policy regarding Cybersecurity; known as HHS-OCIO-2011-0003, states: (quoting in relevant part) “…This Policy applies to all HHS organizational components (i.e., Operating Divisions [OPDIVs] and Staff Divisions [STAFFDIVs]) and organizations conducting business for and on behalf of the Department through contractual relationships. This Policy does not supersede any other applicable law, higher-level agency directive, or existing labor management agreement in place as of the effective date of this Policy….” [emphasis added]; and, “…4.1.1 OPDIVs/STAFFDIVs shall use the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-37 Revision (Rev.) 1, Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach (dated February 2010), as the methodology for the security authorization of information systems (formerly known as “certification and accreditation” or “C&A”), in accordance
  • 3. 3 with FISMA and direction from the Office of Management and Budget (OMB)…”; [emphasis added] and, “…4.1.4 Information assurance and privacy activities conducted within the Department shall be consistent with the guidance, methodologies, and intent prescribed by the NIST SP series, in particular NIST SP 800-53 Rev. 3 and NIST SP 800-53A Rev. 1, Guide for Assessing the Security Controls in Federal Information Systems and Organizations, Building Effective Security Assessment Plans, and other relevant Federal laws and guidance documents. It is incumbent upon each OPDIV to appropriately follow the steps in the NIST SP 800-37 Rev. 1 Risk Management Framework (RMF) to select, implement, assess, authorize, and monitor such controls commensurate with a system’s FIPS 199 categorization….”[emphasis added] Bona fide risk assessment The foregoing authorities can be summarized within the industry term “bona fide security risk assessment”. That is, to meet the bright-line test and legal sufficiency for assessing security management practices an adequate risk assessment must be completed (for those subcontractors supporting HIPAA “covered entities” that are federal contractors) to the NIST standard. Such bona fide assessments will demonstrate a baseline of adequate security policies, standards and guidelines (PSGs) that have been put in place to protect PHI. A risk assessment will measure the implementation maturity of those guidelines (practical implementation in the I.T infrastructure with appropriate evidence to demonstrate compliance) and identify gaps. Gaps (material weaknesses) will then be compared with the downstream consequences of failure or exploit. These gaps, and consequences, will be presented to senior management so that remediation can be planned and prioritized. The foregoing represents a significant departure from the usual check-box compliance approach of conducting a network penetration study or red team dumpster diving and then hoping for the best. Business associates of federal contractors processing PHI, especially on behalf of DHHS, would be prudent to accurately assess their need to comply with the authorities cited. About the author: Dave Sweigert is a Certified Information Systems Security Professional, Certified Information Systems Auditor, Project Management Professional and holds Master’s degrees in Information Security and Project Management. A former consultant to the U.S. Department of Homeland Security, he is a practitioner of developing HIPAA Security Rule compliant policies, standards and guidelines that demonstrate compliance for many organizations (including Delta Dental, Kaiser Permanente and others). He can be reached at LINKEDIN.COM.