Enforcement of HIPAA / HITECH violations and how to improve

A great challenge with gaining massive industry adoption of a set of standards – regardless of security, privacy, or operational effectiveness measures is making it worthwhile.  Some aspects of regulation and industry led practices are obvious and clear.  Others are strikingly similar (duplication in many instances) and can be adopted simply by communication and adjustments.  Unfortunately there are specific requirements that are not sufficient alone as self-evident, and these are then made necessary through fines and punitive actions.

HIPAA / HITECH components are absolutely valuable to the consumer, the individual enterprise, and the industry as a whole.  This is true when the directives are merged into the existing culture, and the business is able to remain competitive.  There are challenges of course when a business tries to bolt-on a set of requirements, as these are seldom done efficiently, effectively, and are generally unsustainable.

The financial damage to industry is clear – the most recent studies show over the past 5 years data breaches have cost victims $139 billion (Digital Forensics Association).  In addition there is a growing trend of enforcement by state and the federal agencies, such as the California DPH actions (audio teleconference file).

When these enforcements are released though there is always valuable intelligence released highlighting what is expected – today.  This perspective reinforces that security mandates’ intent are to secure the data, and businesses must shift and respond as the attack vector shifts and evolves.  The recent Rite Aid $1,000,000 penalty enforced by the OCR and FTC provided the following direction:

1. Implementation of complete and sufficient Policies and Procedures is critical – specifically must include safeguarding PHI during the disposal process (dumpsters, shredding, disk wipe management, third party terminations)
2. Develop complete training related to all aspects for protection of sensitive information – job specific training
3. Develop, implement, and maintain sanctions policies

A nice article regarding Rite Aid is available here from Information Week.

As has been consistent with prior Federal enforcement, a 20 year expectation of independent security assessments is required with sufficient monitoring and triggering.  Here is the link to the Federal press release.  Other case examples and resolutions are available here.

As the data suggests that 395,000 individuals’ data files are being stolen daily, this is not a focus on the Healthcare sector but to provide lessons learned from others.

Highlights and interesting mentions within the HHS Health Information Technology Implementation Guidance Documents

The Human Health Services (HHS) released two lengthy documents outlining the final rules for applicability to security and privacy.  The two documents reviewed are:

1. Medicare and Medicaid Programs: Electronic Health Record Incentive Program
2. Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology

The length is deceiving (1,000+ pages) – the final rules are not very long comparatively, but these documents contain the comment response sections.  These are massively important for understanding the intent and thoughts behind each requirement.  This public feedback and public response is a welcomed process – especially within the complex world of information technology.

While diving through these documents several sections struck me as helpful and insightful.  I have included those below for reference and comment:

“This means that to qualify for incentives, an eligible professional or eligible hospital must both adopt Certified EHR Technology and demonstrate meaningful use of this technology.”

Interesting clarification on the scope of this publication:

“The purpose of this final rule, therefore, is to adopt standards, implementation specifications, and certification criteria to test and certify that a Complete EHR or EHR Module provides certain capabilities, and where applicable, to require that those capabilities be implemented in accordance with adopted standards and implementation specifications. The adopted standards, implementation specifications, and certification criteria were not intended to impose independent requirements on the entities using Certified EHR Technology.”

A request was made to provide clarity in moving forward guidance and mandates. This was a timely question given how often the final rule and responses provided reference future publications and related legislation.  The question submitted to HHS:

“…timelines for making changes to HIT, that it would benefit the HIT industry if we could provide a roadmap, framework, or more descriptive “glide path” for future standards adoption activities…”

Response:

“We plan to work closely with the HIT Standards Committee to develop a forward looking agenda and to make known in advance the types of standards, implementation specifications, and certification criteria on which we will seek
recommendations from the HIT Standards Committee.”

The concept of Complete EHR was clarified and provides useful guidance on what is included and what is excluded from the implied completeness of the term:

“…however, does not in any way preclude any additional capabilities from being included in a Complete EHR or implemented in a complementary fashion.  The definition sets forth a floor, not a ceiling, and serves to signify that once tested and certified to all applicable certification criteria, a Complete EHR meets the definition of Certified EHR Technology.”

A comment was proposed to HHS regarding the scope and legality of these new standards as they are promoting better security and equally more detailed requirements than are mandated within HIPPA.

“What a HIPAA covered entity must do to remain in compliance with the HIPAA Security Rule is separate and distinct from the capabilities that a Complete EHR or EHR Module must include in order to be certified. We do not believe that we are precluded by the HITECH Act from adopting certification criteria that go beyond the requirements specified by the HIPAA Security Rule. We believe that the HITECH Act, while directing that standards, implementation specifications, and certification criteria be consistent with the HIPAA standards, authorizes the Secretary to adopt certification criteria more broadly for the electronic use and exchange of health information. Section 3004(b)(1) of the
PHSA, as added by the HITECH Act, requires the Secretary, for instance, to adopt an initial set of standards, implementation specifications, and certification criteria to enhance the interoperability, functionality, utility, and security of health information technology.”

A distinction was made regarding encryption, but can provide insight onto the broader intent of these certification technologies that is a key understanding to practitioners. The question is of capability versus necessary. This concept highlights the importance of a thorough and accurate risk management process holistically across the enterprise. The referenced quote is below:

“Certified EHR Technology must include the capability to encrypt and decrypt information regardless of the transmission method used. This certification criterion and related standard do not specify the circumstances under which encryption and decryption must be performed; they simply require the capability.”

As interesting documents surface during my research into these mandates and technology controls I will post them.

James DeLuccia

New and Improved OWASP Top 10 and its effects on PCI & IT Controls

On April 19, 2010 OWASP released the final version of the world renowned Top 10 list.  While the updates are not a surprise given the lengthy discussions and feedback that this updated list received it will have an impact on organizations worldwide.  In the world of payment card transaction security the standard directly states under section 6.5 to rely upon the current version of OWASP Top 10 for meeting the web application safeguards requirement.

Beyond PCI DSS there are other industry standards and organization practices that rely upon baselines, such as OWASP, to focus security efforts.
Organizations should take this opportunity to…

1. Evaluate their Information Technology governance programs,
2. SDLC,
3. Change Control,
4. Secure Coding training,
5. Secure Code testing,
6. Attack detection/prevention technologies

…to ensure these risks are incorporated and operate effectively.

The 2010 OWASP Top 10 include:

• A1: Injection
• A2: Cross-Site Scripting (XSS)
• A3: Broken Authentication and Session Management
• A4: Insecure Direct Object References
• A5: Cross-Site Request Forgery (CSRF)
• A6: Security Misconfiguration
• A7: Insecure Cryptographic Storage
• A8: Failure to Restrict URL Access
• A9: Insufficient Transport Layer Protection
• A10: Unvalidated Redirects and Forwards

Please visit OWASP to take find more tools and great discussions on web application security.  Contributors are always welcome and there are chapters around the world.

Here is a link to PCI DSS
Here is a link to the OWASP Top 10 PDF

Best,

James DeLuccia

Excerpts from s.773 as introduced in the U.S. Senate: Cybersecurity Act of 2009

The following are interesting excerpts from S.773 that were of particular interest.  I strongly suggest reading the full bill and the included comments, as this will be impactful to global information technology security controls in the near future.

SEC. 6. NIST STANDARDS DEVELOPMENT AND COMPLIANCE.

(b) CRITERIA FOR STANDARDS- Notwithstanding any other provision of law (including any Executive Order), rule, regulation, or guideline, in establishing standards under this section, the Institute shall disregard the designation of an information system or network as a national security system or on the basis of presence of classified or confidential information, and shall establish standards based on risk profiles.

Developing standards based on a “Risk Profile” is massively more universal and feasible to execute than the minutiae that exists broadly.  It is important to note that the Risk Profile for one institution shall be different than another institution based on the infrastructure, management setup, personnel, and third party service providers enjoined in the business/government processes.  This is equally true for businesses, and a point often raised with regards to PCI DSS – that it addresses specific risks for specific data, but is not an appropriate information security framework for all / any / whole businesses.

SEC. 7. LICENSING AND CERTIFICATION OF CYBERSECURITY PROFESSIONALS

(a) IN GENERAL- Within 1 year after the date of enactment of this Act, the Secretary of Commerce shall develop or coordinate and integrate a national licensing, certification, and periodic recertification program for cybersecurity professionals.
(b) MANDATORY LICENSING- Beginning 3 years after the date of enactment of this Act, it shall be unlawful for any individual to engage in business in the United States, or to be employed in the United States, as a provider of cybersecurity services to any Federal agency or an information system or network designated…as a critical infrastructure information system or network, who is not licensed and certified under the program.

The establishment of a mandatory certification program is important, and valuable.  I would stipulate that a series of certifications shall be presented (likely from an existing training provider, such as SANS) to provide certifications that reflect specific subject areas (network security; application security; governance and compliance; etc…).

SEC. 14. PUBLIC-PRIVATE CLEARINGHOUSE

(b)(1) shall have access to all relevant data concerning such networks without regard to any provision of law, regulation, rule, or policy restricting such access

The consolidation of “relevant data” will create a large of amount of information that can be transformed into very actionable intelligence for both public and private institutions.  It is great that (C ) INFORMATION SHARING allows for the private sector to access this data repository.  The amount of trending and innovations that could be developed would be significant.  Conversely it is also highly risky to setup widespread data sharing permissions, large scale transmission of likely sensitive data, and the propensity for organizations to institute data masking and privacy measures to limit their risk but also the value of such data.

(2) may declare a cybersecurity emergency and order the limitation or shutdown of Internet traffic to and from any compromised Federal Government or United States critical infrastructure information system or network

This is a section that has received widespread attention, so I shall not comment but it is a concern that should be evaluated by all parties.

As this bill is continually debated and amended it will surely change, but it is critical that security professionals understand the intent of this legislation.  It is this core intent that will prevail in the long term.  The focus of information security and national threats is escalating, as highlighted specifically in the - 2009 Report to Congress on the US-China Economic and Security Review Commission and the ‘Capability of the People’s Republic of China to Conduct Cyber Warfare and Computer Network Exploitation‘ (There are many threats across the globe, but these two reports are simply highlighted given their recent release).

Comments / Concerns?

James DeLuccia

Lessons from Microsoft’s ‘Global Criminal Compliance Handbook’

Just finished reading the Microsoft Global Criminal Compliance Handbook, and a few things jump to mind that are beneficial for every business owner, security professional, and innovator…

• First off – the detail and type of information available is very interesting and demonstrates a very and prudent effort to lock down what can be reliably provided to law enforcement.  I am certain with a bit of effort less reliable data may be uncovered if required, but consider the intense level of technology practices and controls required to unequivocally state these data points are available.
  • Ask yourself this question – what data points/metrics does my business rely upon, and can we currently make such absolute statements with regards to the availability and integrity of such information.  A step further – what information requests does your business receive (within the context of Information Technology / Audit / Security / Risk Management) throughout the year, and how rapidly can this information be presented?  It appears from this document that Microsoft has worked the process into a near real-time response, and that is the new reality and requirement for organizations to be competitive and cooperative with internal and external parties.
• Secondly – The access to the business financial accounts and the online storage accounts highlights (or simply reinforces) a concern of Cloud computing systems.  Deploying / Using systems that are not “yours” creates a reasonable chance for the true operator to grant access to your data for “appropriate” reasons.  While I encourage businesses to respond to legal requests as required, it is Risk Managers task to consider these situations and ensure operators have SLA in place along with technical assurances that provide proper safeguards.
  • SLA discrepancies between companies and third party providers is a gap that is growing with the usage of SaaS (other iterations) providers, and it is a new risk vector that must be considered, carefully.
• Thirdly – Information versus Knowledge:  The document goes beyond simply dumping data on the recipient and is designed to help the layman understand the data provided.  The effort to convey knowledge truly is exceptional and not often found within the highly technical and complex system environment that is technology.  Reflection on internal documentation and the conveyance of knowledge should be equal in effort if not more than the actual production of data points.  As technologists are able to interpret complex interactions between multiple routing devices and ACL logs, the team lead / business manager / auditor / CEO need the knowledge of this meaning in order to merge these facts into the greater business risk landscape.

While several articles highlight the privacy and direct implications, I hope this post has provided productive and next step information with this Microsoft document.  The Microsoft document may be downloaded directly here from WikiLeaks.  A ComputerWorld article is available and nicely breaks down the document.

Other perspectives?

James DeLuccia