First, the SP 800-128 includes a sample of the data elements that should be tracked for a change request:

• Date Prepared;
• Title of Change Request;
• Change Initiator/Project Manager;
• Change Description;
• Change Justification;
• Urgency of Change: {Scheduled/Urgent/Unscheduled};
• Personnel involved with the Change;
• Expected Security Impact of Change;
• Expected Functional Impact of Change;
• Expected Impact of Not Doing Change;
• Potential Interface/Integration Issues;
• Required Changes to Existing Applications;
• Project work plan including change implementation date, deliverables, and back-out plan; and
• Funding Required Implementing Change.

Appendix F to SP 800-128, entitled BEST PRACTICES FOR ESTABLISHING SECURE CONFIGURATIONS provides very specific industry guidance on good security configuration management practices. (the following is largely a reproduction of Appendix F, however, I have summarized what I consider to be the most significant issues and removed duplicative references to some NIST Publications.  Some personal commentary appears in red below.

Use Standards for Secure Configuration Settings. Organizations should consider available standards as the basis for establishing secure configuration settings. A source for information on configuration settings is the National Checklist Program.

• NIST SP 800-68: Guide to Securing Microsoft Windows XP Systems for IT Professionals;
• NIST SP 800-69: Guidance for Securing Microsoft Windows XP Home Edition: A NIST Security Configuration Checklist; and
• NIST SP 800-70: National Checklist Program for IT Products-Guidelines for Checklist Users and Developers.

Centralize Policy and Standards for Configuration Settings. Where possible and appropriate, secure configurations should be developed and implemented in a top-down approach to ensure consistency across the organization. An example is the implementation of the group policy functionality, which can be used to distribute secure configuration policy in a centralized manner throughout established domains.

Tailor Secure Configurations According to System/Component Function and Role. Secure configuration settings should be tailored to the system component’s function. For example, a server acting as a Windows domain controller may require stricter auditing requirements (e.g., auditing successful and unsuccessful account logons) than a file server. A public access Web server in a DMZ may require that fewer services are running than in a Web server behind an organization’s firewall supporting an intranet.

• NIST SP 800-41: Guidelines on Firewalls and Firewall Policy (Consumer grade network routerts and wireless routers can be significant improved by using DD-WRT.  “DD-WRT is a Linux based alternative OpenSource firmware suitable for a great variety of WLAN routers and embedded systems.” (See http://www.dd-wrt.com/site/index.) ;
• NIST SP 800-44: Guidelines on Securing Public Web Servers;
• NIST SP 800-45: Guidelines on Electronic Mail Security;
• NIST SP 800-48: Guide to Securing Legacy IEEE 802.11 Wireless Networks (I would avoid having a wireless network connected to a e-PHI system if possible);
• NIST SP 800-52: Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations; (Mandatory TLS encryption is still difficult to implement, most organizations are not in a position to support this functionality on their email solution);
• NIST SP 800-95: Guide to Secure Web Services;
• NIST SP 800-123: Guide to General Server Security; and
• NIST SP 800-124: Guidelines on Cell Phone and PDA Security. (Consumer grade cell phones, PDAs, and blackberries have a number of security configurations available (e.g. timeout, password protection, etc.) that can help to secure these devices).

Eliminate Unnecessary Ports, Services, and Protocols (Least Functionality). Devices should be configured to allow only the necessary ports, protocols, and services in accordance with functional needs and the risk tolerance in the organization. Open ports and available protocols and services are an inviting target for attackers, especially if there are known vulnerabilities associated with a given port, protocol, or service. Sources such as the NIST National Vulnerability Database (NVD) are available for highlighting vulnerabilities in various system components.

Limit the Use of Remote Connections. While connecting remotely to information systems allows more flexibility in how users and system administrators accomplish their work, it also opens an avenue of attack popular with hackers. Use of remote connections should be limited to only those absolutely necessary for mission accomplishment.

• NIST SP 800-46: Guide to Enterprise Telework and Remote Access Security;
• NIST SP 800-47: Security Guide for Interconnecting Information Technology Systems; and
• NIST SP 800-77: Guide to IPsec VPNs.

Develop Strong Password Policies. Passwords are a common mechanism for authenticating the identity of users and if they are poorly implemented or used, an attacker can undermine the best security configuration. Organizations should stipulate password policies and related requirements with the strength appropriate for protecting access to the organization’s assets.

Implement Endpoint Protection Platforms (EPPs). Personal computers are a fundamental part of any organization’s information system. They are an important source of connecting end users to networks and information systems, and are also a major source of vulnerabilities and a frequent target of attackers looking to penetrate a network. User behavior is difficult to control and hard to predict, and user actions, whether it is clicking on a link that executes malware or changing a security setting to improve the usability of their PC, frequently allow exploitation of vulnerabilities. Commercial vendors offer a variety of products to improve security at the “endpoints” of a network. These EPPs include:

• Anti-malware. Anti-malware applications should be a part of the standard secure configuration for system components. Anti-malware software employs a wide range of signatures and detection schemes, automatically updates signatures, disallows modification by users, run scans on a frequently scheduled basis, have an auto-protect feature set to scan automatically when a user action is performed (e.g., opening or copying a file), and may provide protection from zero-day attacks. For platforms for which anti-malware software is not available, other forms of anti-malware such as rootkit detectors may be employed.
• Personal Firewalls. Personal firewalls provide a wide range of protection for host machines including restriction on ports and services, control against malicious programs executing on the host, control of removable devices such as USB devices, and auditing and logging capability.
• Host-based Intrusion Detection and Prevention System.  Host-based IDPS is an application that monitors the characteristics of a single host and the events occurring within that host to identify and stop suspicious activity.
• Restrict the use of mobile code. Organizations should be cautious in allowing the use of “mobile code” such as ActiveX, Java, and JavaScript. An attacker can easily attach a script to a URL in a Web page or email that, when clicked, will execute malicious code within the computer’s browser.

NIST SP 800-28: Guidelines on Active Content and Mobile Code.

Use Cryptography.  In many systems, especially those processing, storing, or transmitting information that is moderate impact or higher for confidentiality, cryptography should be considered as a part of an information system’s secure configuration. There are a variety of places to implement cryptography to protect data including individual file encryption, full disk encryption, Virtual Private Network connections, etc.

NIST SP 800-111: Guide to Storage Encryption Technologies for End User Devices.

Develop a Patch Management Process. A robust patch management process is important in reducing vulnerabilities in an information system. As patches greatly impact the secure configuration of an information system, the patch management process should be integrated into SCM at a number of points within the four SCM phases including:

• Performing security impact analysis of patches;
• Testing and approving patches as part of the configuration change control process;
• Updating baseline configurations to include current patch level;
• Assessing patches to ensure they were implemented properly; and
• Monitoring systems/components for current patch status.

NIST SP 800-40: Creating a Patch and Vulnerability Program.

Control Software Installation. The installation of software is a point where many vulnerabilities are introduced into an organization’s information system. Malware or insecure software can give attackers easy accessto an organization’s otherwise tightly protected network. Although the simplest approach is to lock down computers and manage software installation centrally, this is not always a viable option in many organizations. Other methods for controlling the installation of software include:

• Whitelisting – All software is checked against a list approved by the organization;
• Checksums – All software is checked to make sure the code has not changed;
• Certificate – Only software with signed certificates from a trusted vendor is used;
• Path or domain – Only software within a directory or domain can be installed; and
• File extension – Software with certain file extensions such as .bat cannot be installed.

Related Blogs

• The Internet Public Libraray With a Useful Guide to Photo Sharing …
• PREPRINT: Free Access: “Use of Web Resources in the Journal …
• Israel's Policy and the idea of A One State solution
• Researchers Map Multi-Network Cybercrime Infrastructure — Krebs on …
• Alan Taub Elected Vice Chair of NIST Advisory Group | Japanese …

          

NIST announced the publication of Initial Public Draft Special Publication 800-128, Guide for Security Configuration Management of Information Systems. originally appeared on Law Blog 2.0 on March 19, 2010.

Despite the Federal Governments incentives, State HIE grants, new privacy/security regulations, and regulations on how to make meaningful use of an EHR there remain a number of serious issues that will need to be addressed before we can expect a National Health Information Network as envisioned by the Bush administration.  The personal health record and electronic health record distinction created by the Federal government has created a dichotomy between the official and personal health record.  The FTC is responsible for defining appropriate security measures for personal health records and HHS responsible for defining appropriate security measures for EHRs.  Most EHRs contain information that would be defined as protected health information and be subject to the HIPAA Privacy and Security regulations.

The following is a summary of the implementation issues that will need to be addressed by the Federal Government, health-care providers and technology vendors:

• Ownership. Ownership of the electronic health record and/or the personal health record remains unclear.  There is significant disagreement among providers and privacy advocates as to who owns a person’s medical data;
• Patient Rights. Similarly, if an individual owns his/her medical record should he/she be permitted to change the record, add material, and/or block portions of the record from being shared with a health care provider.  On the other hand are there components of an individual’s medical record that should not be available to the patient;
• Proprietary Formats. Electronic medical records largely remain in proprietary formats relegated to various data silos with a small group of providers.  Some larger providers have entered relationships with Google Health and/or Microsoft Health Vault.  However, absent the existence of an information sharing agreement between the provider, the PHR vendor (in this case) and the patient there remains no unified medical record that can be created and then shared with all;
• Interoperability. Ensuring the interoperability of a diverse array of electronic medical record systems remains a serious limitation with many EHR solutions.  Organizations tend to stick to the old data structures implemented on historical mainframes and disregard interoperability as a key issue when implementing an EHR.  While theoretically versions of the same EHR should be interoperable in house customizations in many instances break any inherent interoperability that may exist within EHR systems of the same type.  There are some promising projects on the horizon like the open source connect initiative, a java framework for defining gateways and interfaces for an organization to communicate with the NHIN;
• User Acceptance. Building consumer and physician confidence in the use of an electronic medical record system remains difficult;
• Meaningful Use. Developing criteria for the government to assess whether any given provider is a meaningful user of his/her medical record system.  The real value of an EHR is typically analyzed retrospectively such data is suspect in the absence of an experimental control group and the inability to evaluate the technology without accounting for other variables that may affect the result;
• Long Term Data. Compiling long term data to evaluate the effectiveness (meaningful use) of various EHR components will be necessary to drive investment by the private sector; there are some proof of concept implementations for certain categories of providers.  Such examples are rare given the diverse array of health care providers and the technology used to store data related to any given patient;
• Access Controls. There are no industry standards for delineating (describing) and administering rights with respect to an individual’s personal health record.  Various technologies like private key / public key encryption, certificate authorities, and algorithms to ensure the confidentiality and integrity of protected health information exist, but these systems are poorly understood by most health information technology departments even at the largest providers;
• Appropriate Security Safeguards. The complex array of state and federal laws make defining the appropriate mix of administrative, physical and technical safeguards an intractable problem.  First movers that take the initiative to define how to protect patient data from disclosure, modification while ensuring the availability of this information in the event of an emergency, are subject to government second guessing; and
• Legal Liability and Storage Limitations. While storage is cheaper than ever, there is not enough space to store all data related to the care of a patient. It is not clear what information must be retained so that a court can subsequently evaluate the quality of care in any given scenario where a physician may be sued for malpractice.  One example are DICOM (see http://en.wikipedia.org/wiki/Digital_Imaging_and_Communications_in_Medicine)  medical images that require 100’s of megabytes of data, if multiple versions of a medical record must be maintained the storage requirements for an individual’s medical record will expand at an exponential rate.  Some algorithmic methods to conserve space for storing data cannot be used.  The application of irreversible compression technology potentially makes an EHR subject to regulatory review by the FDA.

Related Links:

Discussion of MSFT Health Vault Support of  the Continuity of Care Record (CCR) and the Continuity of Care Document (CCD).

Discussion of Google Health’s Implementation of a Subset of the CCR.

Sample DICOM Images

Definitions

Continuity of Care Record -

The CCR  is a patient health summary standard that includes core health information about a patient.  The CCR is not intended to represent a patients entire medical history.  The CCR standard is based on XML.  An XML scheme to be used to verify the proper formatting of a CCR document can be purchased along with a description of the standard from ASTM International.

DICOM-

The Digital Imaging and Communications in Medicine standard created by the National Electrical Manufacturers Association (NEMA) to aid the distribution and viewing of medical images, such as CT scans, MRIs, and ultrasound.

Related Blogs

          

The Elephant in the Room – Implementation Issues for a National Health Information Network from HIMSS 2010 originally appeared on Law Blog 2.0 on March 12, 2010.

Directs federal agencies participating to:

• Transmit to Congress a cybersecurity strategic research and development plan and triennial updates; and
• Develop and annually update an implementation roadmap for such plan. Provides for the award of computer and network security research grants by the National Science Foundation (NSF) in the research areas of social and behavioral factors, including human-computer interactions, and identity management.

Instructs that applications for the establishment of Computer and Network Security Research Centers include how such Centers will partner with government laboratories, for-profit entities, other institutions of higher education, or nonprofit research institutions.

Requires the NSF Director to carry out a program of awarding fellowships to encourage young scientists and engineers to conduct postdoctoral research in the fields of cybersecurity and information assurance, including the research areas under which computer and network security research grants are awarded.

Requires the Office of Science and Technology Policy (OSTP) Director to convene a cybersecurity university-industry task force to explore mechanisms for carrying out collaborative R&D activities. Requires (currently, permits) the National Institute of Standards and Technology (NIST) Director to establish priorities for the development of checklists of settings and options that minimize security risks associated with computer systems that are, or are likely to become, widely used within the federal government.

Requires:

• Development or identification and revision or adaptation as necessary, of checklists, configuration profiles, and deployment recommendations for products and protocols that minimize such risks; and
• Development of automated security specifications respecting checklist content and associated security related data.  Ensures that any products developed under the National Checklist Program for any information systems, including the Security Content Automation Protocol, be disseminated to federal agencies Requires conducting of intramural security research activities under NIST’s computing standards program.

Instructs the NIST Director to:

• Ensure coordination of U.S. government representation in the international development of technical standards related to cybersecurity;
• Implement a cybersecurity awareness and education program through the Manufacturing Extension Partnership program; and
• Establish a program to support development of technical standards, metrology, testbeds, and conformance criteria with regard to identity management research and development.

(Summary excerpted from http://www.govtrack.us/congress/bill.xpd?bill=h111-4061).

Related Blogs

• Legal Information Institute: Sunlight Foundation Proposes Public …
• Information About Usual Swine Flu Symptoms | Pig Flu Pandemic …
• PHP Development India – maglev08.com
• elearnspace › Social Networks and Learning: Research/Doctoral Seminar
• Club Troppo » What a free computer might do for a kid's education …
• Book preview: PHP 5 E-commerce Development « Eirik Hoem's Blog
• Commtouch's New Open-Source Email Security Technology Featured at …
• Cybersecurity Technologies a Government Priority | The New New …
• Featured Job- Cyber Security Engineer with Booz Allen | The New …
• Stock Gumshoe Investigates: “$25 Cyber Security Doubler to Hit $50 …
• SEO Consult – Different content requires different styles of writing
• Programmers that… can't program. | Musings of an Anonymous Geek
• Nokia Research Centre Africa (NRC-Africa) research insights and …
• IP Osgoode » Building new models for innovation and R&D requires …
• The Alex Jones Show with Jason Bermas 1/3: Cybersecurity Act …
• UK Government Criticized For Frightening Climate Change Television …
• 50 Excellent Tutorials for Web Development Using CSS3 | Dzinepress
• Europe's economic recovery requires e-Skills
• Temporary Worker Program Could Threaten Immigration Reform …
• [Fix] Installation of Microsoft Office 2010 Requires MSXML Version …

          

Would you like to play a nice game of chess? originally appeared on Law Blog 2.0 on February 5, 2010.

Recent HHS Guidance has emphasized key areas of importance related to a covered entity’s security assessment-

This guidance document has been prepared with the main objective of reinforcing some of the ways a covered entity may protect EPHI when it is accessed or used outside of the organization’s physical purview. In so doing, this document sets forth strategies that may be reasonable and appropriate for organizations that conduct some of their business activities through (1) the use of portable media/devices (such as USB flash drives) that store EPHI and (2) offsite access or transport of EPHI via laptops, personal digital assistants (PDAs), home computers or other non corporate equipment.

The Centers for Medicare & Medicaid Services (CMS) has delegated authority to enforce the HIPAA Security Standards, and may rely upon this guidance document in determining whether or not the actions of a covered entity are reasonable and appropriate for safeguarding the confidentiality, integrity and availability of EPHI, and it may be given deference in any administrative hearing pursuant to 45 C.F.R. § 160.508(c)(1), the HIPAA Enforcement Rule.

The kinds of devices and tools about which there is growing concern because of their vulnerability, include the following examples: laptops; home-based personal computers; PDAs and Smart Phones; hotel, library or other public workstations and Wireless Access Points (WAPs); USB Flash Drives and Memory Cards; floppy disks; CDs; DVDs; backup media; Email; Smart cards; and Remote Access Devices (including security hardware).

In general, covered entities should be extremely cautious about allowing the offsite use of, or access to, EPHI. There may be situations that warrant such offsite use or access, e.g., when it is clearly determined necessary through the entity’s business case(s), and then only where great rigor has been taken to ensure that policies, procedures and workforce training have been effectively deployed, and access is provided consistent with the applicable requirements of the HIPAA Privacy Rule.

(see http://www.cms.hhs.gov/SecurityStandard/Downloads/SecurityGuidanceforRemoteUseFinal122806rev.pdf).

Special publication 800-53, Revision 3 includes: (1) a simplified, six-step Risk Management Framework; (2) additional security controls and enhancements for advanced cyber threats; (3) recommendations for prioritizing security controls during implementation or deployment; (4) revised security control structure with a new references section; (5) guidance on using the Risk Management Framework for legacy information systems and for external information system services providers; (6) Updates to security control baselines based on current threat information and cyber attacks; (7) Organization-level security controls for managing information security programs; and (8) Guidance on the management of common controls within organizations.  Table 1 below maps HIPAA Security implementation specifications to NIST Security controls.  The NIST taxonomy of controls, as mapped by NIST SP 800-66, is invaluable in understanding the technical details of how to implement HIPAA compliant safeguards and what additional safeguards should be evaluated.

NIST Assessment Methodology

Encryption of portable media is a key enforcement priority of the OIG.  USB flash drives and other portable media are usually put in bags, backpacks, laptop cases, jackets, trouser pockets or are left at unattended workstations.  Tracking corporate data stored on personal flash drives is a significant challenge; the drives are small, common, and constantly moving.  Consequently USB drives are frequently misplaced.  Most HIPAA covered entities and business associates have strict management policies toward USB drives, and some companies ban them to minimize risk (by prohibiting the drives in a company acceptable use policy and/or in the operating system configuration).

Table 1 – Data by Type Copied by Employees

Other findings include:

1. 53 percent of respondents downloaded information onto a CD or DVD, 42 percent onto a USB drive and 38 percent sent attachments to a personal e-mail account;
2. 79 percent of respondents took data without an employer’s permission;
3. 82 percent of respondents said their employers did not perform an audit or review of paper or electronic documents before the respondent left his/her job; and
4. 24 percent of respondents had access to their employer’s computer system or network after their departure from the company.

(see also State of the Endpoint IT Security & IT Operations Practitioners in the United States, United Kingdom, Australia, New Zealand & Germany sponsored by Lumension; Independently conducted by Ponemon Institute LLC; Publication Date: November 30, 2009)(avaliable at http://www.ponemon.org/local/upload/fckjail/generalcontent/18/file/Lumension%20State%20of%20the%20Endpoint%20FINAL%203.pdf).

Organizational Structure

• Which individual(s) oversee HIPAA privacy and security issues — state their names and titles of the: (1) the private officer; (2) the security officer; and (3) principle contact in the event of a security incident.
• Do you have written policy and/or a job description for the privacy, security and security incident response contact person?
• Does the organization conduct internal monitoring regarding HIPAA compliance through: (1)  an internal privacy security team; (2) an external third-party; (3) or there is no HIPAA compliance monitoring?
• Briefly describe what protected health information your organization maintains and where said information is retained (i.e. application, systems, database)?
• Does business associate have a reporting mechanism for potential privacy or security breaches?
• If a reporting mechanism exists, who is responsible for addressing potential breaches and what is the chain of command within your organization?
• Please specify any reported security breaches to a covered entity, government entity, and/or consumers in the last 3 years?
• Does the business associate have an Information Technology (IT) group oversee risk management related to PHI stored in business associate systems?
• Please provide a list of individuals responsible for such oversight activity along with their credentials/certifications.
• What responsibilities do individuals in your legal department have related to HIPAA compliance?
• Does your organization have a business continuity plan to address preserving access to and integrity of PHI in the event of a disaster or other catastrophic event?

Administrative Structure

• What policies (and procedures) are available specifically addressing HIPAA privacy and security rules and compliance including the following:
  1. Risk Management;
  2. Risk Assessment and Application Criticality Analysis (FIPS 200);
  3. Physical Security;
  4. Encryption;
  5. Remote Access;
  6. Media and Document Destruction;
  7. Change Control/ Patch Management;
  8. Acceptable Use (Email, Portable Media, Software, Company Resources);
  9. Training and Security Reminders;
  10. Antivirus and Workstation Security;
  11. Unique User Identification;
  12. Audit and Log Monitoring;
  13. Security  Incident;
  14. Contingency and Emergency Access; and
  15. Workforce Clearance, Sanction, and Access Management.
• Who or what group within the organization is responsible for creating and updating these policies?
• When were the organization’s policies last updated?
• How often have any of these policies been updated?
• Are new employees trained to follow these policies and procedures?
• How frequently are existing employees re-trained on existing policies and procedures?
• How frequently are existing employees trained regarding updates in HIPAA rules?
• How are personnel screened in order to grant certain levels of access to PHI?
• Does the organization have a formal security incident response plan to address potential breaches of security that include at a minimum: (1) roles and responsibilities; (2) isolate affected system; (3) preserve evidence; (4) restore compromised system from known safe backups; and (5) post incident response report including identification of lessons learned and other mitigating controls may be indicated based on the incident?
• Does the organization require business partners to comply with its privacy and security policies?
• Does organization ever send PHI via email or ftp (file transfer protocol)?
• Does the organization have policy or procedures related to de-identifying PHI for use in advertising, marketing, educational programs?
• What policies and procedures exist regarding notification in the event of a breach?

Physical Structure

• How is PHI stored within the organization (i.e. fixed server databases/hard drives versus removable media such as backup tapes)?
• Does your company of a physical security plan?
• What types of controls exists to limit access into buildings containing servers that host PHI?
• What types of controls exists to limit access within buildings to rooms housing servers containing PHI?
• Who has access to facilities containing PHI, and what process exists to grant these individuals access?
• What environmental controls exist to protect PHI from destruction?
• To the extent PHI is physically maintained, does the organization employ shredders or other destroying devices for confidential PHI containing documents?  Do you train and document the training of employees on the use of shredders?

Technical Structure

• What types of security and encryption protect portable media containing PHI? (Portable media should always be encrypted.)
• What types of security exists to protect PHI as it flows to and is accessed at remote workstations?
• Describe the data flow “life-cycle” of PHI through the organization’s information systems.  (This should cover hosting services, software development, quality assurance, other issues.)
• Does the organization have routine maintenance protocols that backup, delete, relocate, or otherwise impact data containing PHI?
• What types of audit mechanisms exist to track access and transmission of PHI by internal or external users?  Typically audit logs include a timestamp, a unique user account, data accessed/modified/created, and the location of the user.
• How often are these audit mechanisms used to detect abnormal use?
• Do automatic triggers exist to notify the organization of abnormal PHI use?
• Does the organization prevent browsers with un-patched security vulnerabilities from accessing the company’s information system?

Compliance History and Future Developments

• Has the organization had any security incidents in the past 5 years?  How many and when?
• Has business associate received any negative press related to privacy or security issues in the past 5 years?  How many and when?
• What if any HIPAA security and privacy litigation has business associate been party to in the past 5 years?  Describe the timeline, the circumstances, and the outcome.
• Has business associate conducted risk assessments and vulnerability assessments through independent third parties?  When was the last assessment done?
• Has business associate developed its business off-shore?  If so, are the off-shore business associate facilities ISO 17799 certified?
• Does business associate have new technologies on the horizon that involve PHI, and what if any safeguards are contemplated to protect this data?

Key Terms

Advanced Encryption Standard (AES) – specifies the FIPS 140-2 approved cryptographic algorithm that can be used to protect electronic data.

Business Associate – a third party that acts on behalf of a covered entity by performing a function or activity that HIPAA’s Administrative Simplification rules regulate or that provides certain services (e.g., legal or consulting services) that involve the use or disclosure of individually identifiable health information.

Covered Entity – a health plans, health care clearinghouses, health care providers, and endorsed sponsors of the Medicare prescription drug discount care that conduct covered transactions electronically.  Covered entities are subject to HIPAA’s Administrative Simplification mandates.

Encryption - Cryptographic transformation of data (called “plaintext”) into a form (called “ciphertext”) that conceals the data’s original meaning to prevent it from being known or used. If the transformation is reversible, the corresponding reversal process is called “decryption”, which is a transformation that restores encrypted data to its original state.

HIPAA (The Health Insurance Portability and Accountability Act) – mandates the use of standards for the electronic exchange of health care data; to specify what medical and administrative code sets should be used within those standards; to require the use of national identification systems for health care patients, providers, payers (or plans), and employers (or sponsors); and to specify the types of measures required to protect the security and privacy of personally identifiable health care information.

NIST (National Institute of Standards) - an agency in the Technology Administration that makes measurements and sets standards as needed by industry or government programs.

Protected health information (PHI), under the US Health Insurance Portability and Accountability Act (HIPAA), is any information about health status, provision of health care, or payment for health care that can be linked to an individual. This includes any part of a patient’s medical record, diagnosis,  and/or payment history.

PHI identifiers include:

1. Names;
2. All geographical subdivisions smaller than a State, including street address, city, county, precinct, zip code, and their equivalent geocodes, except for the initial three digits of a zip code, if according to the current publicly available data from the Bureau of the Census: (1) The geographic unit formed by combining all zip codes with the same three initial digits contains more than 20,000 people; and (2) The initial three digits of a zip code for all such geographic units containing 20,000 or fewer people is changed to 000;
3. Dates (except year) for dates directly related to an individual, including birth date, admission date, discharge date, date of death; and all ages over 89 and all elements of dates (including year) indicative of such age, except that such ages and elements may be aggregated into a single category of age 90 or older;
4. Phone numbers;
5. Fax numbers;
6. Electronic mail addresses;
7. Social Security numbers(SSN);
8. Medical record numbers;
9. Health plan beneficiary numbers;

10.  Account numbers;

11.  Certificate/license numbers;

12.  Vehicle identifiers and serial numbers, including license plate numbers;

13.  Device identifiers and serial numbers;

14.  Web Universal Resource Locators (URLs);

15.  Internet Protocol (IP) address numbers;

16.  Biometric identifiers, including finger, retinal and voice prints;

17.  Full face photographic images and any comparable images; and

18.  Any other unique identifying number, characteristic, or code (note this does not mean the unique code assigned by the investigator to code the data)

Table 2 – NIST SP 800-66 HIPAA Security Compliance Guidance

Related Blogs

• The collapse of China's English-teaching schools » The Peking Duck
• Irish Mr. English : Unleashed Online
• Idea Lab: Full English Breakfast from Scratch
• Language Log » Chinese Endangered by English?
• Toy Tokyo x Secret Base x Ron English X-Ray McSupersized Figure …

          

Business Associate and Covered Entity HIPAA Compliance — Auditing Questions and NIST 800-53 Security Controls. originally appeared on Law Blog 2.0 on November 29, 2009.

Next year should be interesting.  From Red Flag compliance, federal breach reporting requirements, significantly augmented HIPAA penalties, and HIPAA security standards that are based on NIST guidelines will change the traditional compliance model for Covered Entities and Business Associates.  Hot topics for enforcement next year (based on recent CMS audits of their business partners) will likely be in the areas encryption of portable media devices, remote access by employees to protected health information, and failure to document a rational risk management process.

1. Electronic Health Records and Interoperability.  The American Recovery and Reinvestment Act of 2009 (ARRA) allocated $19 billion over a five-year period to help providers purchase and implement electronic health record systems.  Of more concern to providers, however, are the penalties for failing to adopt (and make meaningful use) of an EHR system before 2015  when providers will face a reduction in their Medicare fee schedule of -1% in 2015, -2% in 2016, and    -3% in 2017 and beyond.  There are many willing health care providers that want to implement EHR systems.  However, whether the EHR systems work as intended and actually meet the government’s meaningful use requirements remains an open question.
2. Federal Breach Reporting Requirements.  Covered entities will be on the spot for ensuring that their business associates report security breaches to them in a timely manner.  Covered entities must then document their risk analysis and their conclusion as to why or why not a security incident should be reported to members.  This analytic process should be incorporated into your security incident policy and procedures as soon as practicable.  Due diligence of some sort may be indicated for those business associates who have heretofore not been meeting their obligations to comply with the requirements of the HIPAA Privacy and Security regulations.  Moreover, some members of Congress are not entirely happy with the harm standard; they favor a strict acquisition based reporting obligation.  If this happens, we can expect to see a lot of security breach reports, many plaintiff class actions, and further federal legislation in reaction to the perceived threat of riskless security breaches.
3. HIPAA Security and Privacy Regulations will begin to look a lot like FISMA.  The Federal Information Security Management Act of 2002 (“FISMA”, 44 U.S.C. § 3541, et seq.) requires each federal agency to develop, document, and implement an agency-wide program to provide information security for the information and information systems that support the operations and assets of the agency, including those provided or managed by another agency, contractor, or other source.  NIST prepared a series of guidelines to help federal agencies comply with FISMA.  These guidelines address administrative, physical and technical safeguards. We expect HHS to largely remove itself as the source of all knowledge as to what is specifically required to with respect to administrative, physical and technical safeguards and utilize NIST standards as the new guideposts for evaluating the effectiveness of a covered entity’s risk management program and mitigating safeguards.  For example, CMS’s auditing materials used to audit CMS’s business partners are very similar to NIST privacy and security guidance.  Unlike HIPAA, NIST standards are very specific and include well over 20 core publications.  You can get a head start on your spring reading by reviewing SP 800-66 Rev 1, An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule (Oct. 2008).
4. Encryption and Remote Access.  2010 will be the year where many organizations will begin layering encryption controls onto portable media, laptops, and publically accessible workstations.  Whether an encryption product has been certified as FIPS 140-2 should be a key consideration when purchasing a new encryption solution.  You can find out whether a product you are considering has been certified at http://csrc.nist.gov/groups/STM/cmvp/validation.html.  In addition, you can get a sample implementation policy produced by the manufacturer at the time of certification stating how the product should be deployed.  The FIPS 140-2 standard is an information technology security accreditation program for cryptographic modules produced by private sector vendors who seek to have their products certified for use in government departments and regulated industries (such as financial and health care institutions) that collect, store, transfer, share and disseminate “sensitive, but un-classified (SBU)” information.  Proper encryption policies and procedures rely on ensuring that users are properly trained to follow the precise process dictated by the encryption product’s documentation.  The failure to do so will compromise a company’s encryption solution.   The elephant in the room remains remote access to systems containing sensitive information by users from their home computers.  Unfortunately, although remote access is convenient for employer and employee alike, its safeguards are expensive and difficult to implement.  It is not clear what level of control must be exercised over an employee working from home on his/her remote computer.
5. Watch for Further Enforcement Actions.  Enforcement activities by the OIG provides some insight into what is important for avoiding HIPAA Privacy and Security liability.  For example, after the Providence Health System case we know encrypting portable media is a hot topic.  And following the CVS enforcement action, most organizations are making sure that their employees have easy access to shredders and training on how to properly destroy documents.
6. Red Flag Compliance.  The Federal Trade Commission (FTC) has delayed the compliance deadline of the Red Flags Rule yet again — this time until June 1, 2010.  The AMA is pushing the FTC and Congress to republish the rule so that there is sufficient opportunity to formally comment and state AMA’s objections to physician inclusion in the program.  However, I would not count on the Red Flag Rules being delayed again.

          

Key Issues in Privacy and Security for 2010 originally appeared on Law Blog 2.0 on November 17, 2009.

HHS Security Breach Notice Regulations - Update

A series of privacy advocates have expressed displeasure with the HHS “harm standard” as articulated in the recent Covered Entity .  However, I believe the “harm standard” is reasonable and appropriate.  One recent article is available here (published by computer world): HHS guts health-care breach notification law, groups warn Posted using ShareThis

I am a little unclear as to why privacy advocates and security vendors believe that the harm standard, found within the new HHS regulations for security breaches, in any way hampers the HITECH Act’s security breach notice rule for covered entities and business associates.  Many states use a similar risk based type analysis, in fact only seven states have a strict acquisition based standard, of those only a couple of these states link their definition of encryption to FIPS 140-2.*  In comparison to risk based states where one assesses the potential risk to a consumer resulting from theft of sensitive information, the federal standard is more helpful in the sense that it highlights key criteria to be evaluated in assessing risk to consumers.

*I am not certain on this, but I believe the most problematic state is California.  California includes health information within the definition of personal information, California references FIPS 140-2, California is an acquisition based state, and guidance documents issued by the state are extremely draconian.

Second, implementing a FIPS 140-2 approved encryption system is an expensive and complicated process — it seems reasonable that HHS should temper FIPS 140-2 with a harm standard analysis.  As many covered entities have started to dissect the requirements of what would constitute acceptably encrypted data under the HITECH act they have quickly realized that process of implementing what is largely a FISMA (Federal Government/ Military) based encryption standard presents many problems.  FIPS approved algorithms and processes require precise configuration; such systems are designed to fail closed.  Failing closed means denying access — this could be a good thing with money but a bad thing when dealing with clinical data in an emergency situation.  Security controls in the health care industry are a delicate balance of confidentiality, integrity and availability. (http://law2point0.com/wordpress/2009/09/15/50-state-security-breach-notice-law/).  Pushing out government grade security safeguards too fast could create serious issues in the event a provider needs immediate access to patient records but hospital A cannot communicate with hospital B due to a conflicting encryption schema.

Without the harm standard, covered entities would be forced into over-reporting incidents — over-reporting can be just as damaging as not reporting any security incidents.  There are two studies that help to put the “harm” or risk-based standard for security breach reporting in an appropriate (real-world) context.
The first study is a report prepared by the General Accounting Office (GAO) from 2007 entitled PERSONAL INFORMATION — Data Breaches Are Frequent, but Evidence of Resulting Identity Theft Is Limited; However, the Full Extent Is Unknown (the report is available for free at http://www.gao.gov/new.items/d07737.pdf).  This report evaluated the 24 largest breaches reported in the media from January 2000 through June 2005.  The study found that:

1. In only three instances was there evidence of fraud on existing accounts and in only one instance of the three identified cases did the GAO find evidence of unauthorized creation of a new account;
2. For 18 of the breaches, no clear evidence was uncovered linking the breach to identity theft; and
3. In the remaining two cases there was insufficient information to make a determination.

A second article, by S. Romanosky, R. Telang, and A. Acquisti, entitled Do Data Breach Disclosure Laws Reduce Identity Theft? (available for free at  http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1268926) summarizes the debate surrounding security breach notification laws and their impact.  The authors’ analyses reveal a modest effect of security breach disclosure laws in reducing identity theft rates by approximately 2%.  However, this article also notes that over-reporting has many negative consequences — including unnecessary costs and desensitizing consumers such that when a real incident that they should take notice of is ignored.

The FIPS-140-2 standard is a Federal Standard and the guidance cited by HHS (OMB Memorandum M-07-16 is also a federal standard (available at http://www.whitehouse.gov/OMB/memoranda/fy2007/m07-16.pdf)).  The OMB the guidance and the FIPS 140-2 are both compoennts of the federal government program to protect against harm resulting from a security breach.  It seems logical if that we are following a FISMA structure that OMB Memorandum M-07-16 should be considered when assessing the scope and consequences of a security breach.

The harm standard may result in fewer notices, in some states where there are exceptions for HIPAA covered entities for some provisions of state reporting requirements, but absent an applicable exception an entity could still be bound by the state standard and the federal standard.  Many states are including health information within the definition of personal information; even so it is frequently the case that when health information is compromised the triggering elements for a given state’s reporting statute are present within the compromised health data.  Unfortunately, the end result will likely be a negligible  reduction in notice unless the seven states and the DC that have an acquisition based standard move to a risk based / harm based analysis.  In my opinion an acquisition based standard reaches the wrong result for both consumers and companies.  The one benefit will be that the Federal standard does provide a rational framework for entities absent other guidance that can be used to frame analysis of a security incident and what mitigation efforts are appropriate.

          

Fear Mongering or Legitimate Criticism — “HHS guts health-care breach notification law, groups warn” originally appeared on Law Blog 2.0 on September 22, 2009.

a.    Take immediate action to stop the incident from continuing or recurring.

b.    If the incident does not involve the loss of confidential information or have other serious impacts to individuals IT should repair the system, restore service, and preserve evidence of the incident.

c.    If the incident involves the loss of confidential information or critical data or has other potentially serious impacts, you should consult with your general counsel or your legal counsel for guidance under applicable federal and state laws.

e.    File a Security Incident Report including a description of the incident and documenting any actions taken thus far.

f.     Refrain from discussing the incident with others until a response plan has been formulated.

g.    Repair the system and restore service.

h.    Preserve evidence of the incident.

Did a reportable security breach occur?

Some factors to consider when evaluating a potential security breach.

When determining whether or not acquisition has actually or is reasonably believed to have occurred, on should consider, at a minimum, the following indicators:

1. The information is in the physical possession and control of an unauthorized person, such as a lost or stolen computer or other devices that have the capability of containing information, or such as a misdirected electronic mail transmission received and opened by an unauthorized person containing notice-triggering information.
2. The information has been downloaded or copied (e.g., any evidence that download or copy activity has occurred which may require forensic analysis);
3. The attacker deleted security logs or otherwise “covered their tracks”;
4. The duration of exposure in relation to maintenance of system logs or in cases of an inadvertent or unauthorized Web site posting;
5. The attack vector is known for seeking and collecting personal information;
6. The information was used by an unauthorized person, such as instances of identity theft reported or fraudulent accounts opened.

Appropriate Incident Handling Procedures Are Key.

DOs

1. Immediately isolate the affected system to prevent further intrusion, release of data, damage, etc.
2. Use the telephone to communicate. Attackers may be capable of monitoring email traffic.
3. Immediately notify your security incident response team.
4. Activate all auditing software, if not already activated.
5. Preserve all pertinent system logs, e.g., firewall, router, and intrusion detection system.
6. Make backup copies of damaged or altered files, and keep these backups in a secure location.
7. Identify where the affected system resides within the network topology.
8. Identify all systems and agencies that connect to the affected system.
9. Identify the programs and processes that operate on the affected system(s), the impact of the disruption, and the maximum allowable outage time.
10. In the event the affected system is collected as evidence, make arrangements to provide for the continuity of services, i.e., prepare redundant system and obtain data back-ups. To assist with your operational recovery of the affected system(s), pre-identify the associated IP address, MAC address, Switch Port location, ports and services required, physical location of system(s), the OS, OS version, patch history, safe shut down process, and system administrator or backup.

DON’Ts

1. Delete, move, or alter files on the affected systems.
2. Contact the suspected perpetrator.
3. Conduct a forensic analysis.

Other Considerations

1. Collect information for each server, router, switch, and Data Service Unit (DSU) including:
   • IP address
   • Media Access Control (MAC) address
   • Switch Port location (switch name and port number)
   • Port assignment
   • Ports and services are required
   • Statement that all other unneeded ports and services are closed and/or removed
   • Responsible system administrator and backup
   • Physical location of server
   • Physical security implemented
   • Emergency contact information (both technical and user management)
   • OS/Version/Patch history
   • Systems supported, impact of outage, and maximum allowable outage (MAO)
   • Shutdown script (if applicable)
   • Recovery process
2. Identify all external connections, assess the need for the connections, the security risk to each connection, and any recommended safeguards or strategies.
3. Provided an adequate security message and warning banner on your system.
4. Implement a keystroke monitoring program.
5. Does personal information reside on, or is it transmitted through the affected system (as defined by federal and/or state security breach notification statutes)?

Steps to Minimize Potential Liability

1. Review physical and electronic access by employees and investigate abnormal activity in ALL computing environments.
2. Review system administrators, field accounts, and special access rights for appropriate access levels.
3. Ensure that systems are always backed up and the data is securely placed in an offsite location. Periodically conduct data restore tests.
4. Ensure that current anti-virus protection software and upgrades are installed, operational, and monitored. In addition, schedule routine virus scans on servers and desktops.
5. Remove sensitive information from websites.
6. Limit the size and manage the type of email attachments that can be received (certain systems allow you to disable executable files).
7. Keep the IT Operational Recovery Plan (ORP) and Business Continuity Plan (BCP) up-to-date, tested, and ready for implementation.
8. Establish security accountability for any and all users at appropriate levels.
9. Improve security on access to critical assets and facilities with technology environments.
10. Remove unnecessary services on routers, ports, servers, and network devices.
11. Trace or monitor the necessary services.
12. Designate an Information Security Officer (ISO) who shall report to the Director of the department or designee. The ISO shall not report to the Chief Information Officer (CIO).
13. Continuously educate management on the priority of security and the security risks associated with Information Technology.
14. Install warning banners at the login process for access to all state systems and applications.
15. Increase user awareness in security by continuously enhancing technology use policy such as “non-personal use of email.”
16. Verify that software updates and patches are continuously installed on a timely basis to operating systems and applications. Be wary of standard software installations. These installations often include services or features which you do not use and do not update.
17. Ensure that current anti-virus protection software and upgrades are installed, operational, and monitored.
18. Improve or remove user accounts with weak passwords, default or built-in passwords, old passwords, or no passwords. All accounts must have passwords and passwords should be complex and difficult to guess.
19. Require use of passwords containing alpha-numeric-special character combinations. Passwords should expire after a set period of time and employ a password history to prevent repeated passwords.
20. Ask if you have a policy which cancels log-ins/passwords when employees leave your organization. If so, verify that the policy is enforced.
21. Implement intrusion detection, provide monitoring on critical information systems, such as maintaining system logs on write only CDs.
22. Restrict non-business use of e-mail.
23. Review your remote access procedures and policies. Who is granted access? How is it monitored? If virtual private network (VPN) access is provided, have minimum security standards been established for the remote computer? How is this verified?
24. Enforce a policy regarding Internet use (viruses such as Trojan Horses can be introduced by visiting websites).
25. Restrict use of chat room software, AOL Instant Messenger, IRC Chat, ICQ Chat, (viruses can be introduced by visiting chat rooms).
26. Maintain a firewall between your system and any untrusted system (Internet connection).

Recommended Resources

NIST Special Publication 800-61 (Rev. 1)(Mar 2008    ) Computer Security Incident Handling Guide (available at http://csrc.nist.gov/publications/nistpubs/800-61-rev1/SP800-61rev1.pdf).
NIST Special Publication 800-86(Aug 2006) Guide to Integrating Forensic Techniques into Incident Response (available at http://csrc.nist.gov/publications/nistpubs/800-86/SP800-86.pdf).
NIST Special Publication 800-83(Nov 2005) Guide to Malware Incident Prevention and Handling (available at http://csrc.nist.gov/publications/nistpubs/800-83/SP800-83.pdf).

          

Evaluating Secutiy Incidents — Security Incident DOs and DON’Ts originally appeared on Law Blog 2.0 on September 8, 2009.

Breach Reporting Requirements

The Department of Health and Human Services (HHS) released on Wednesday, August 19, 2009, its interim final rule for “breach notification,” as required under the Health Information Technology for Economic and Clinical Health (HITECH) Act, passed as part of the American Recovery and Reinvestment Act of 2009 (ARRA) (“HHS Breach Rule”).  HHS was two-days late with the issuance of the final rule for breach notification.  The interim final rule requires HIPAA covered entities to notify individuals—and, in some cases, the HHS Secretary and the news media—when “unsecured protected health information” is breached or compromised.  The interim final rule is scheduled for publication in the Federal Register on Monday, August 24, 2009.  The rule will be effective thirty days after publication in the Federal Register (approximately September 23, 2009); comments on the rule are due to the HHS Office of Civil Rights within sixty days of the rule’s publication (approximately October 23, 2009).  However, HHS In the comments to the new Breach Reporting Rules, states that HHS “will use [its] enforcement discretion to not impose sanctions for failure to provide the required notifications for breaches that are discovered before 180 calendar days from the publication [of the HHS regulations],”  which will be the middle of February 2010.

Personal Health Records and the FTC Security Breach Rule

Also on August 17th, 2009, the FTC, as required by ARRA, issued the final guidance regarding security breach notification requirements for entities that collect personal health information and/or vendors of personal health records for purposes of a consumer directed health record.  The FTC released the proposed regulations entitled the “Health Breach Notification Rule” on April 16, 2009.  Unlike, Electronic Health Records (EHRs), Personal Health Records (PHRs) are not covered by HIPAA, however, PHRs are covered by some states’ security breach notification rules (e.g. California).  The FTC’s rules expands the scope of entities that must take certain actions in the event of a PHR security breach, but the rule does not apply to HIPAA Covered Entities or Business Associates (with one exception discusse below).  The FTC regulations will apply to “breaches of security” that occur on or after September 18, 2009, if the breach involves information contained in or related to PHRs.  While the interim final rule for “breach notification” issued by HHS will apply to HIPAA Covered Entities and Business Associates.  Unlike an EHR, PHR’s are “electronic record of identifiable health information on an individual that can be drawn from multiple sources and that is managed, shared, and controlled by or primarily for the individual.” (FTC Final Rule (Guidance) p. 27).

The FTC further clarified the definition of a PHR:

The Commission emphasizes that PHRs are managed, shared, and controlled “by or primarily for the individual.” See, e.g., AIA at 2; ACLI; Molina Healthcare at 2-3; National Association of Mutual Insurance Companies (“NAMIC”) at 3-4. Thus, they do not include the kinds of records managed by or primarily for commercial enterprises, such as life insurance companies that maintain such records for their own business purposes.

PHI and HHS’ Security Breach Rule

Interestingly the preamble to the HHS breach rule clarifies that in some instances a HIPAA business associate could theoretically covered by the FTC and HHS security breach notification requirements-  in those limited cases where an entity may be subject to both HHS’ and the FTC’s breach notification rules, such as a vendor that offers PHRs to customers of a HIPAA covered entity as a business associate and also offers PHRs directly to the public, HHS and FTC have apparently been harmonized by including the same (or similar requirements). (HHS Breach Notification Rule p. 14).

Similar to the FTC  breach notification regulations for PHR vendors, the regulations developed by the HHS Office for Civil Rights (OCR) requires health care providers and other HIPAA covered entities to promptly notify affected individuals of a breach, as well as the HHS Secretary and the media in cases where a breach affects more than 500 individuals.  Breaches affecting fewer than 500 individuals will be reported to the HHS Secretary on an annual basis. The regulations also require business associates of covered entities to notify the covered entity of breaches at or by the business associate.

“This new federal law ensures that covered entities and business associates are accountable to the Department and to individuals for proper safeguarding of the private information entrusted to their care.  These protections will be a cornerstone of maintaining consumer trust as we move forward with meaningful use of electronic health records and electronic exchange of health information,” said Robinsue Frohboese, Acting Director and Principal Deputy Director of OCR.

(FTC Final Rule (Guidance) p. 27).

Acceptable Encryption Methods and the Effect Thereon of the Data’s Current State

The commentary to Breach Notification rules include further details regarding the distinctions between data at rest and data in motion:

• “Data in Motion” includes data that is moving through a network, including wireless transmission, whether by e-mail or structured electronic interchange, while “data at rest” includes data that resides in databases, file systems, flash drives, memory, and any other structured storage method;
• “Data in Use” includes data in the process of being created, retrieved, updated, or deleted, and “data disposed” includes discarded paper records or recycled electronic media;
• “Data at Rest” includes data that resides in databases, file systems, flash drives, memory, and any other structured storage method; and
• “Data Disposed” includes discarded paper records or recycled electronic media.

While these categories are not new to computer security practitioners they represent a much more advanced approach as compared against earlier HIPAA privacy and security guidance. (Guidance at 12).  The Guidance notes that HHS consulted the NIST when identifying appropriate safeguards.  The reader is also directed to review the NIST Special Publication 800-66-Revision1 “An Introductory Resource Guide for Implementing the HIPAA Security Rule“.

Encryption is one of the core methods to render PHI unreadable; however encryption encompasses domains such as cryptology, number theory, and crypto analysis for even the most well versed security expert understanding how to encrypt information properly is complex.  HHS solves this problem by relying on NIST.  PHI must be encrypted using a NIST approved algorithm and procedure– to be considered unreadable.  Electronic PHI is encrypted when “the use of an algorithmic process to transform data into a form in which there is a low probability of assigning meaning without use of a confidential process or key” (45 CFR 164.304) and key to decrypt the PHI has not been breached.  Encryption identified by NIST and judged to meet this standard NIST’s encryption standards is acceptable to render PHI unreadable. (Guidance at 16).  Current acceptable encryption methods include:

• For data at rest the reader those methods contained within NIST Special Publication 800-111, Guide to Storage Encryption Technologies for End User Device; and
• For data in motion those methods contained within the Federal Information Processing Standards (FIPS) 140-2 are acceptable. These methods are explained in detail in NIST Special Publications 800-52, Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations; 800-77, Guide to IPsec VPNs; or 800-113,Guide to SSL VPNs, and others which are FIPS 140-2 validated. (Guidance at 17).

The commentary notes that:

[C]overed entities and business associates may continue to create limited data sets or de-identify protected health information through redaction if the removal of identifiers results in the information satisfying the criteria of 45 CFR 164.514(e)(2) or 164.514(b), respectively. Further, a loss or theft of information that has been redacted appropriately may not require notification under these rules either because the information is not protected health information (as in the case of de-identified information) or because the unredacted information does not compromise the security or privacy of the information.

Finally HHS notes that the encryption/ destruction guidance will be updated annually.  The press release notes-

To determine when information is “unsecured” and notification is required by the HHS and FTC rules, HHS is also issuing in the same document as the regulations an update to its guidance specifying encryption and destruction as the technologies and methodologies that render protected health information unusable, unreadable, or indecipherable to unauthorized individuals.  Entities subject to the HHS and FTC regulations that secure health information as specified by the guidance through encryption or destruction are relieved from having to notify in the event of a breach of such information.  This guidance will be updated annually.

An excellent demonstration of the Advanced Encryption Standard (AES) — one of the few FIPS approved algorithms to render PHI unreadable and/or encrypted for purposes of the security breach safe harbor under both the FTC and HHS rules is avaliable at http://www.cs.bc.edu/~straubin/cs381-05/blockciphers/rijndael_ingles2004.swf.

Destruction is also an acceptable method of rendering PHI unreadable, acceptable methods for destroying PHI at this time:

• Paper, film, or other hard copy media be shredded or destroyed such that the PHI cannot be read or otherwise reconstructed; and
• Electronic media must be cleared, purged, or destroyed consistent with NIST Special Publication 800-88,Guidelines for Media Sanitization, such that the PHI cannot be retrieved. (Guidance at 17).

HHS draws an interesting distinction between encryption and other access controls:

While we believe access controls may render information inaccessible to unauthorized individuals, we do not believe that access controls meet the statutory standard of rendering protected health information unusable, unreadable, or indecipherable to unauthorized individuals. If access controls are compromised, the underlying information may still be usable, readable, or decipherable to an unauthorized individual, and thus, constitute unsecured protected health information for which breach notification is required.

Accordingly, HHS believes strong access controls are required however HHS believes that a review of potential safeguards is beyond the scope of the this guidance which primarily details methods of rendering PHI unreadable.

Following the same line of reasoning HHS rejected redaction of PHI as a method of rendering PHI unreadable.  The preambles states that “redaction is not a standardized methodology with proven capabilities to destroy or render the underlying information unusable, unreadable or indecipherable, we do not believe that redaction is an accepted alternative method to secure paper-based protected health information.”  However the physical destruction of paper is a method rendering PHI unreadable.  This again is a rather interesting distinction considering that electronic documents, for example PDFs, can be redacted such that the information cannot be recovered.

The reader should note that covered entities and business associates must keep encryption keys on a separate device from the data that they encrypt or decrypt to ensure the keys are not compromised.

Harm or Risk Based Threshold

HHS confirmed that the statutory language and the new breach regulations includes a harm threshold and the definition that “compromises the security or privacy of the protected health information” means “poses a significant risk of financial, reputational, or other harm to the individual.”  This position is consistent with some State breach notification laws, as well as other existing obligations on Federal agencies (some of which also must comply with these rules as HIPAA covered entities) pursuant to OMB Memorandum M-07-16 (available at http://www.whitehouse.gov/OMB/memoranda/fy2007/m07-16.pdf) to have in place breach notification policies for PII that take into account the risk of harm caused by the breach.  Thus, to determine if an impermissible use or disclosure of PHI constitutes a breach, covered entities and business associates will need to perform a risk assessment to determine if a significant risk of harm to the individual as a result of the impermissible use or disclosure. In performing the risk assessment, covered entities and business associates should consider a number of factors.  Five factors that should be considered to assess the likely risk of harm:

• Nature of the Data Elements Breached. The nature of the data elements compromised is a key factor to consider in determining when and how notification should be provided to affected individuals.41 It is difficult to characterize data elements as creating a low, moderate, or high risk simply based on the type of data because the sensitivity of the data element is contextual. A name in one context may be less sensitive than in another context.42 In assessing the levels of risk and harm, consider the data element(s) in light of their context and the broad range of potential harms flowing from their disclosure to unauthorized individuals.
• Number of Individuals Affected. The magnitude of the number of affected individuals may dictate the method(s) you choose for providing notification, but should not be the determining factor for whether an agency should provide notification.
• Likelihood the Information is Accessible and Usable. Upon learning of a breach, agencies should assess the likelihood personally identifiable information will be or has been used by unauthorized individuals. An increased risk that the information will be used by unauthorized individuals should influence the agency’s decision to provide notification.

(See OMB Memorandum M-07-16, page 14)(avaliable at http://www.whitehouse.gov/OMB/memoranda/fy2007/m07-16.pdf).

HHS notes that the fact the information has been lost or stolen does not necessarily mean it has been or can be accessed by unauthorized individuals.  A June 2007 GAO Report entitled “PERSONAL INFORMATION- Data Breaches Are Frequent, but Evidence of Resulting Identity Theft Is Limited; However, the Full Extent Is Unknown” (Dated June 2007) expands upon this rather important point.  The GAO report reviewed the 24 largest breaches reported in the media from January 2000 through June 2005 finding that:

1. Only in three instances were there any evidence of resulting fraud on existing accounts and only one instance of the three identified cases did the GAO find evidence of unauthorized creation of new accounts;
2. For 18 of the breaches, no clear evidence had been uncovered linking them to identity theft; and
3. In the remaining two cases there was not sufficient information to make a determination.

Practical Steps in the Event of a Breach

In the comments to the new Breach Reporting Rules, HHS provides a basic overview of the steps to follow in order to determine whether the entity has breach reporting obligations.  The recommended steps are as follows:

Step 1 – Determine whether the disclosure or use of PHI was impermissible under the HIPAA Privacy Rule.

Step 2 – Determine whether the PHI was “secured” or “unsecured,” and whether the impermissible use or disclosure of PHI compromises the security or privacy of such PHI, and document its process and determination.  The use or disclosure would be impermissible if it poses a “significant risk of financial, reputational, or other harm to the individual.”

Step 3 -   Determine whether the use or disclosure falls under one of the exceptions to the definition of a “breach.”  The exceptions to the definition of a “breach” are: (i) any unintentional access or use of PHI by a Covered Entity’s or Business Associate’s workforce or person acting under the authority thereof, if such access was in good faith, within that person’s scope of authority, and did not result in further impermissible use or disclosure of the PHI; (ii) any inadvertent disclosure by a person who is authorized to have access to such PHI to another authorized person at the same Covered Entity or Business Associate, or organized health care arrangement in which the Covered Entity participates, and the PHI disclosed is not further used or disclosed in an impermissible manner; and (iii) disclosure of PHI where the Covered Entity or Business Associate has a good faith believe that the unauthorized person who received the PHI would not reasonably have been able to retain such PHI.

If the breach poses a significant risk to the individual whose PHI was disclosed, and the disclosure does not fall under one of the enumerated exceptions to the definition of a “breach,” the entity must take the following step:

Step 4 – Provide appropriate notice of the breach in accordance with the Breach Reporting Rules.

Regardless of whether a breach is in violation of the Privacy Rule or Security Rule and raises reporting obligations under the Breach Reporting Rules, the entity may have reporting obligations under state security breach reporting laws that are not preempted by the Privacy Rule or Security Rule.  Therefore, it would be prudent for the entity to take the following additional step:

Step 5 – Determine whether the breach raises any additional reporting obligations under applicable state security breach reporting laws.

          

Interim Final Rule on Breach Notification for HIPAA Covered Entities and Business Associates Released by HHS (Effective September 23, 2009) & FTC Releases Final Guidance on PHR Security Breach Notification Requirements originally appeared on Law Blog 2.0 on August 21, 2009.

NIST Approves XTS-AES

NIST approved XTS-AES for the secure encryption of block devices in NIST Special Publication 800-38E, Recommendation for Block Cipher Modes of Operation: The XTS-AES Mode for Confidentiality on Block-Oriented Storage Devices (Draft August 2009)(available at http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/XTS/follow-up_XTS_comments-Ball.pdf) subject to a caveat on the file size.  The IEEE P1619 task group completed work on an AES standard for the XTS encryption algorithm in December 2007.  The algorithom was designed to be suitable “for encryption of stored data in a fixed-block device, and a standard for an XML-based key-export format.  XTS stands for ‘XEX TCB with ciphertext stealing’ and is a narrow-block cryptographic mode. (XEX stands for ‘XOR-Encrypt-XOR’, and TCB is Tweakable CodeBook mode encryption).”

On Sept 4, 2008, NIST completed a public review for XTS-AES. Based on these comments, NIST made the decision to adopt XTS-AES as an approved mode of operation under FIPS 140-2.The number of blocks that can be securely encrypted using this method is 2^20 blocks.  The Advanced Encryption Standard (AES) is a FIPS-approved cryptographic algorithm (Rijndael, designed by Joan Daemen and Vincent Rijmen, published in 1998) that may be used by US federal departments and agencies to cryptographically protect sensitive information.  There are various modes of operation some of them are approved by NIST FIPS 140-2.  NIST’s decision approves the use of XTS-AES for encrypting block devices (hard drives, optical media, etc.) is particularly significant because TrueCrypt is an open source implementation of AES.

TrueCrypt provides a cost effective alternative to other encryption solutions available in the market.  It is distributed without cost and the source code is available for download at http://www.truecrypt.org.  TrueCrypt can operate in various modes for example by creating a virtual encrypted disk within a file or an encrypted volume on an individual partition.  Unlike most encryption utilities available on the market TrueCrypt supports Microsoft Windows, Mac OS X and Linux.  TrueCrypt limits the size of an encrypted file or volume to one petabyte (or 1000 terabytes) for security reasons.

TrueCrypt

The XTS-AES mode is an implementation of XEX that can only encrypt sequences of complete blocks (string that is a multiple of 128 bits) however, XTS-AES is not subject to the same limitation utilizing Ciphertext Stealing.  Ciphertext stealing reorders the transmission of the last two blocks of ciphertext by padding the last block (which is possibly incomplete) with the high order bits from the second to last ciphertext block (stealing the ciphertext from the second to last block).  The last block can be encrypted, and then exchanged with the second to last ciphertext block, which is then truncated to the length of the final plaintext block, removing the bits that were stolen.

Seagate submitted comments last year when NIST was evaluating the security of XTS-AES.  Seagate argued that other methods were more secure, faster and simpler.  XTS-AES is based on an IEEE Standard 1619-2007.  All comments and other supporting documentation is available at http://csrc.nist.gov/groups/ST/toolkit/BCM/comments.html.  Interesting, an alternative mode of operation “ECB” is FIPS 140-2 approved but not secure, the acceptance of XTS-AES may mean that the certification of products using ECB will be retired with the implementation FIPS 140-3. (http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/XTS/follow-up_XTS_comments-Ball.pdf

The license for TrueCrypt is not an industry accepted “open source” license; the ambiguity (un-litigated) license may discourage broad adoption of TrueCrypt within commercial enterprises; however it is relatively certain other solutions will soon be on the market utilizing this same algorithm.  Nevertheless TrueCrypt and more generally XTS-AES deserves your attention as one option for unauthenticated encryption of data at rest.  See http://en.wikipedia.org/wiki/Disk_encryption_theory#XTS for a more involved discussion of the algorithm.

The following is a simple python implementation XTS-AES (see http://www.bjrn.se/code/pytruecrypt/truecrypt5py.txt).

Other NIST publications recently updated include: “

1. Draft Special Publication 800-73 -3 Interfaces for Personal Identity Verification (4 Parts)

Pt. 1- End Point PIV Card Application Namespace, Data Model and Representation

Pt. 2- PIV Card Application Interface

Pt. 3- PIV Client Application Programming Interface

Pt. 4- The PIV Transitional Data Model and Interfaces

http://csrc.nist.gov/publications/PubsDrafts.html#800-73-3

2. NIST Interagency Report (IR) 7611, Use of ISO/IEC 24727 — Service Access Layer Interface for Identity (SALII): support for development and use of interoperable identity credentials is now available.  See http://csrc.nist.gov/news_events/index.html#aug14; http://csrc.nist.gov/publications/PubsNISTIRs.html#nistir7611.

3. Special Publication 800-53 Revision 3 was updated last Friday to include an errata page, and all the supporting files were also updated and uploaded Friday, August 14.

          

NIST Approves XTS-AES for Secure Encryption of Block Devices: TrueCrypt Meets FIPS 140-2 Standard Thus Becoming a HHS Approved Algorithom for Securing PHI originally appeared on Law Blog 2.0 on August 18, 2009.