It’s big news that RSA’s infrastructure around their SecureID solution has been compromised. While information around this attack and its impact on customers is lacking (RSA is citing an ongoing investigation as a reason to limit public disclosure) a couple of lessons about general security management can be learned.

The first lesson is around vendor management.  As a security assessment company, we get to hear a lot of people at organizations around the world describe their state of security. One thing that we hear a lot is about how secure their vendors are. With little support other than reading a vendor’s marketing materials, the existence of a SAS-70, or listening to the vendor’s sales team story about security, it is assumed that a vendor is secure. If the recent NASDAQ Directors Desk breach is an example of why a vendor’s big claims around security don’t necessarily actually imply security, then this week’s RSA breach exemplifies that a company is secure just because they are big or sophisticated. In our experience, vendors, big or small, often represent the biggest component of an organization’s security risk – no matter what the claim about their security.

Another lesson to be learned from the RSA breach is around complexity. In our experience complexity equates to security risk – the more complexity you have in your IT environment the more inherent security risk. While I wouldn’t say its time to throw away all of your multi-factor authentication solutions – after all, they are generally an effective way to mitigate the risk of a compromised password, I do think its important to realize that every time a new technology is introduced into your IT environment, you are increasing your overall complexity and thus adding some additional risk. So its important to think through any new technology deployment and ask yourself: does the upside of this deployment outweigh the downside of adding complexity to my data center? Security is all about operational discipline, structured process, rigorous testing and smart people – all of which tend to be in short supply; always be aware of how added complexity taxes your finite resources.

So, while it might be too early to get rid of all of your SecureID technology, its not too early to be aware that vendors may represent a big piece of your security risk and the added complexity of more layers of technology in an IT environment represent additional security risk to your organization. Not that vendors and technology are bad, they are necessary, but its important to understand their impact to your risk management strategy.

Here we discuss the need for, and an approach for developing, a structured Business Associate oversight program for data security risk management.

HIPAA and the HITECH Act have highlighted the importance of Business Associate (BA) security. Covered Entities (CEs) need to effectively manage Business Associates security risk, and BAs need to understand their compliance requirements and liability under HIPAA and HITECH regarding protecting protected health information (PHI).

The entire supply chain of PHI from CEs to BAs to BA subcontractors are now subject to compliance with the HIPAA Security Rule. Not only has the definition of BAs been expanded to include data transmission services like HIEs and RHIOs, but BAs now face dual liability – they have both contractual liability to CE for HIPAA compliance via Business Associate Agreements (BAAs) and also direct liability to the government. Furthermore the July 14^th, 2010 notice of proposed rulemaking (NPRM) modifying HIPAA under the HITECH Act clarifies that a lack of understanding is not a valid defense for HIPAA compliance violations.

Given the enhanced breach notification requirements, monetary penalties and increase government scrutiny, both CEs and BAs need to effectively manage security risk. As a security assessment firm, we understand that performing an objective and technically astute security assessment or HIPAA Risk Analysis is an effective way to support a structured information security program that mitigates security and compliance risk under HIPAA. However, we also understand that while performing a dedicated assessment on one’s own organization is a practical solution, devoting significant capital to performing security assessments on BAs and subcontractors might not be feasible. But given the current regulatory climate, having no visibility into a BAs current state of security is not practical either.

What follows is a high-level view of an approach to managing BA risk that is manageable, structured, practical and can be documented to show organizational commitment to a robust risk management program. We see this as an effort that is implemented by a CE in several phases. While the duration for completion of the entire process varies widely depending on the size of the CE in question, we’d expect the duration of the entire process to range from several weeks for a small organization to several months for a larger CE. BA’s need to also be aware of this process – not only to manage any of their own BAs, but also with the expectation that their CE clients will soon be asking the very same questions discussed here.

Business Associate Oversight Program Overview

The primary goal of a BA oversight program is to create a systematic and well-documented process for evaluating and prioritizing risk of a BA PHI data breach or HIPAA Security Rule compliance violation by determining that BAs have the necessary technical, physical and administrative safeguards in place to protect shared PHI.

Step 1: Create BA risk matrix to characterize BAs in terms of data classification, BAA terms and testing history.

Compile a complete list of BAs and create a matrix of readily available information about each BA. While each situation is unique, the following categories should be considered for evaluation.

• Data Classification: This category defines attributes associated with the data the BA has access to, such as the number of records shared with the vendor, criticality and sensitivity of the data, breach history, etc.
• Business Associate Agreement Terms: For each BA on the list, document status of BAA. Does BAA specify appropriate BAA PHI safeguards, notification of disclosures, etc.? Is there a termination-after-breach clause and a right-to-audit clause, …?
• Testing History: Note for each BA the last security assessment performed, the date, and whether it was performed internally or by a third-party. Are results of security assessments available for review by CE?

Step 2: Based on attributes logged in the previous step, prioritize BAs in terms of risk.

Based on the information above, compiled in a matrix, the BAs can be readily prioritized based on risk – high risk at the top, low risk at the bottom. This can be implemented qualitatively or quantitatively. In the example below we show a snippet of a matrix in which a hybrid approach is taken. Notice how the data sensitivity, for example, is given a 1, 2 or 3 rating to represent low, medium or high sensitivity. In this way the data risk can be used as a numerical risk rating to aid in risk prioritization.

Step 3: Determine which vendors require additional evaluation as a function of risk profile on matrix.

Based on the number of vendors on the list and the general risk profile of the BAs, determine the scope and schedule for additional BA security verification. Additional evaluation may include:

• Requiring vendor to complete additional information via questionnaire (download sample Business Associate Questionnaire)
• Telephone interview of BA
• Spot checking of specific security controls defined on questionnaire as a cost-effective sampling strategy to extrapolate opinion of overall state of security
• Full-scope security assessment or HIPAA Risk Analysis

Step 4: Report to BAs and monitor progress

Any findings, deficiencies or requests for further information (such as validation that a security issue has been mitigated, or that the BA has completed security testing) should be reported to the BAs. Any deficiencies should be documented and followed-up on by CE to ensure BA is addressing issues.

Step 5: Keep matrix up-to-date.

Annually, or whenever there is significant change, keep matrix up-to-date to ensure that high risk vendors are given appropriate attention. Based on this, just as in a traditional information security program, cycle back to Step 1 as necessary.

Summary

While even the largest healthcare organizations are not likely to perform an onsite security assessment for each BA, our clients that range from small-to-medium sized organizations to Fortune 100s, have effectively utilized a risk-based approach to prioritize vendors by risk such that high risk vendors are quickly isolated for further scrutiny. The process outlined above can systematically reduce risk in a rapid and cost-effective manner with a repeatable process that ensures accountability and documents an organization’s dedication to a robust information security program.

It’s always educational to review a data security breach to see what can be learned. In the case of the Charleston Area Medical Center (CAMC) last month a number of lessons can be learned. First lets review what we know (and don’t know) about the data breach which happened at CAMC subsidiary CAMC Health Education Research Institute (CHERI).

What Happened

It was a pretty straight forward breach. Last month someone doing an online search for an address found that the name of a relative and their ePHI was readily accessible on a CAMC website via a Google search. He immediately notified the relative who in turn contacted the State of West Virginia Attorney General. The Attorney General’s Consumer Protection Division quickly had the offending site shut down. In all 3655 patients were involved with the breach whose data had been accessible on the site since September of 2010. The site was created by a contractor who inadvertently enabled access to the data.

More Questions than Answers

• If the contractor had access to ePHI, were they treated as a Business Associate (BA)?
• Was there a Business Associate Agreement (BAA) in place?
• Was protecting ePHI specified as an upfront feature/requirement of the site created by the contractor?
• Was any application penetration testing performed on the site before it went live?
• As a result of the breach CAMC has agreed to additional safeguards including a security assessment – does this imply that CAMC had not previously performed a HIPAA Risk Analysis?!?!

Lessons Learned

An ounce of prevention…: While we don’t know details of this particular vulnerability, it appears that an application penetration test would have identified the risk and enabled trivial remediation before an incident. That would be a fraction of the cost of this breach. Its hard to determine the CAMC brand damage and staff costs associated with a breach like this. And its too early to tell if the hospital will see HIPAA / HITECH Act fines associated with the incident. The Equifax credit monitoring cost is also unclear, though calculating the retail cost from their site at $15 per month per user for each of the 3655 individuals affected by the breach for a year tallies to over $54,000 per month and over $650,000 for the year …. a pound of cure.

Security Assessments have more value before a breach: Well I am stating the obvious here, but there’s more to the point than the obvious fact that identifying this particular vulnerability early would be much less painful on the organization. The point is that, in our experience, incident-driven assessments are often knee-jerk reactions to a compliance issue that are completed more to show reaction and publicize respect for client ePHI rather than a core value-driven approach to secure operations. These types of assessments often cost way more and the value can be limited. The value of a security assessment is proportional to an organizations bandwidth to absorb the findings and willingness for organizational improvement. An event-driven assessment for CAMC will not yield a lot of value if the health IT staff is not ready to react to the findings.

Ensure BAs are aware of the need to protect ePHI: When you outsource to a vendor, you are outsourcing the actual labor, but also to a certain extent security management. While you want to expect that a vendor would be aware of information security best practices you can’t always trust the BA to be secure. A robust BAA shows you care? While requiring a BA to complete a Business Association Self Assessment Questionnaire may not be appropriate for a web site developer, quizzing them on a secure software development life cycle might filter out incompetent developers and send a message that you care about their performance.