Archive for August, 2010

You don’t know what you don’t know – Do we have a "detection" problem with the healthcare data breach numbers?

Like some of you perhaps, I have been reading a few recent articles on Healthcare data breaches, especially the one from Dark Reading and a detailed analysis of the 2010-to-date breaches from HITRUST Alliance.

What stood out for me from these articles is something that is not necessarily highlighted in the articles and that is the very low number of breaches involving technology/people/process controls as opposed to physical losses.

These articles focused on the 119 or so breaches that have been reported to Department of Health and Human Services (HHS) or made public to date in 2010. From the HITRUST Alliance analysis, it is clear that an overwhelming majority of the breaches resulted from physical loss/theft of paper or electronic media, laptops etc.  Only two breaches resulted from hacking incidents.

I then went back to do a little bit of my own analysis of the 2010 data breach incidents covered in the Identity Theft Resource Center report available here. I came up with the following numbers for breaches other than those that involved physical loss, theft, burglary, improper disposal etc. :

• Malware  infection -1
• Unauthorized access to file share – 1
• Database misconfiguration or vulnerability – 2
• Website vulnerability – 1
• Improper access or misuse by internal personnel – 6

As you can see, these account for less than 10% of the healthcare breaches known or reported so far this year.  Contrast this with the findings in 2010 Verizon Data Breach Investigation Report which attributes 38% of breaches to malware, 40% to hacking and 48% to misuse. It is pertinent to note that the Verizon report focused on 141 confirmed breaches from 2009 covering  a variety of industries,  but I think it is still good for a high level comparison to determine if we may be missing something in the healthcare breach data.

The comparison seems to suggest that the healthcare industry probably has much stronger safeguards  against malware, hacking, improper logical access etc.  I know from my own experience working with healthcare entities that this is not necessarily the case. For further corroboration, I reviewed two Ponemon Institute survey reports – Electronic Health Information at Risk: A Study of IT Practitioners and Are You Ready for HITECH? – A benchmark study of healthcare covered entities & business associates, both from Q4 2009. Following sample numbers from these reports further validate that the state of Information Security and Privacy among HIPAA Covered Entities (CEs) and Business Associates (BAs) is far from perfect:

Electronic Health Information at Risk: A Study of IT Practitioners

Are You Ready for HITECH? – A benchmark study of healthcare covered entities & business associates

All this leads me to think of the possibility that some HIPAA CEs and BAs may not be detecting potential breaches. If you study the healthcare breaches that have been reported so far, almost all of them have been through physical losses of computers or media (which is easy to know and detect) or through reporting by third parties (victims, law enforcement, someone finding improperly disposed PHI paper records in trash bins  etc.).  I don’t know of any healthcare data breach this year that was detected through proactive monitoring of information systems.

As I covered in a related post on breach reports and what they tell us, I would recommend that CEs and BAs focus on certain key controls and related activities (see table below) in order to improve their breach prevention and detection capabilities:

If you are familiar with the HIPAA Security Rule, you will notice that not all of the above controls are “Required” (as opposed to “Addressable”) under HIPAA Security Rule or in the proposed amendments to the rule under the HITECH Act. One may argue however, that the above controls must be identified as required based on “risk analysis” , which of course is a required implementation specification in the HIPAA Security Rule. In any event, CEs and BAs need to look beyond the HIPAA compliance risk and focus on the risk to their business or brand reputation if a breach were to occur.

Hope this is useful! As always, we welcome your thoughts and comments.

RisknCompliance Services Note

We at RisknCompliance maintain a up-to-date database of the current security threats and vulnerabilities at a detailed level. We are able to leverage this knowledge in  providing our clients with  high quality risk analysis.

Please contact us here if you would like to discuss your HIPAA security or privacy needs. We will be glad to talk to you about how we could be of assistance.

May we suggest some priority adjustments to your PCI DSS Compliance program?

It isn’t any news that achieving PCI DSS Compliance continues to be onerous for many merchants out there. PCI DSS is after all an all-or-nothing regulation meaning that not passing even one of over 200 requirements could prevent you from getting there. And then, if you do become compliant, there is really no assurance that you will have 100% security. This is something we have known all along to be true for any regulation and now we have one more statistic from the 2010 Verizon Data Breach Investigation Report to prove it …  21% of organizations facing payment card data breaches were compliant with PCI DSS at the time of the breach.

So, may be it is time to rethink our approach to PCI DSS compliance, in terms of how do we get there by way of addressing controls that carry higher breach risks before the others. That will at least help improve your  organization’s security posture against potential breaches even if you are nowhere close to meeting all PCI DSS requirements.   I think recent breach surveys or reports are a great source to identify such controls  with an objective of prioritizing the remediation initiatives in the right order. Such prioritization should help in achieving a better security posture sooner, as we’ll see below.

I am not the first one to suggest a prioritized approach to achieving PCI DSS compliance. In fact, PCI SSC already has guidance on this, though the guidance itself is somewhat dated having been issued back in February 2009. Since then,  the threat environment has probably evolved somewhat and exploitation of certain  vulnerabilities isn’t quite of the same order relative to others. Therefore, I suggest leveraging the data breach findings to make necessary prioritization adjustments.

Here are some findings from three recent reports on which I am basing my recommendations:

Here then is a summary of the key controls in the above table, relevant PCI DSS requirements and priorities from the PCI SSC Guidance.

Note: Numbers in brackets are the priority numbers from the PCI SSC guidance. Numbers in the guidance range from 1 through 6. A lower number indicates a higher priority.

As we can see from the table, there are several requirements which if addressed sooner, will actually improve an organization’s security posture against potential breaches, based on what we know from the recent breach studies.  I would recommend increasing the priority of the requirements in red to at least 3 if not 2. I do realize that organizations may not be able to afford to address too many requirements at a higher priority. If that is the case, you may want to review the current priority 2 and 3 requirements against the key controls in the table above and then decide to push some of them lower down the priority order as applicable.

Hope this is useful! As always, we welcome your thoughts and comments.

RisknCompliance Services Note

We at RisknCompliance track about a dozen of such reports every year and maintain a up-to-date database of the current security threats and vulnerabilities at a detailed level. We are able to leverage this knowledge in  providing our clients with  a much-wanted third-party assessment of their risk management or audit methodologies and  programs. After all, security risk assessments and audits form the very foundation of risk management or audit programs, so we believe it is critical that every organization fine-tunes its methodologies and  knowledgebase.

Please contact us here if you would like to discuss your needs. We will be glad to talk to you with the details and how we could be of assistance to you.

Verizon 2010 Data Breach Investigations Report – Key takeaways for Security Assessors and Auditors

The Verizon 2010 Data Breach Investigations Report (DBIR) released last week has some interesting findings, just as it did last year. What makes it special this year is that Verizon partnered with the United States Secret Service in developing this report. I don’t intend to discuss all the statistics in this blog (will do so in another upcoming blog) but as you will see explained in the report, the Secret Service’s involvement has thrown new light into some of the findings.

My intention here is to highlight the significance of such a report to security and audit practitioners with the objective of improving the quality of their risk assessments or audits and more importantly, help make the right recommendations to management.  From my experience as a security practitioner and an occasional auditor, I can tell that we may not always be using all the available information to help improve the quality of our risk assessments or audits. And, I think reports such as the Verizon DBIR can provide some valuable help from that standpoint.

Let me explain what I mean… Deliverables for any risk assessment or audit typically include a list of findings and for each finding, we provide an explanation of the risk, the risk severity  (High, Medium, Low) and suitable recommendations for risk mitigation or remediation.  The management would then proceed to remediate various gaps in priority based on our risk rankings. Considering that risk is a product of likelihood and impact (I like the OWASP risk rating methodology, so will use it here), it is important that we get the impact and likelihood right.  Impact is largely a function of the organization’s characteristics including various technical and business factors seen in the methodology. On the other hand, likelihood is a function of threats and vulnerabilities.  I think the DBIR can be a useful reference in estimating the likelihood.

For example, the DBIR says that external agents were responsible for about 78% of the breaches whereas about 48% were caused by insiders. These numbers can be used to arrive at a better objective estimate  of the likelihood that these threat agents may cause any harm. Similarly, the DBIR also says that  48% of the breaches involved privilege misuse, 40% resulted from hacking  and 38% utilized malware. These numbers can be used for objective estimation of the likelihood that associated vulnerabilities could be exploited. The OWASP methodology has an illustration for such objective risk estimation.

These are but a couple of examples. The DBIR has a wealth of information that can be useful to auditors and security practitioners alike, both in improving the quality of their work as well as in being able to defend their risk rankings. We all realize that risk rankings almost always have a level of subjectivity in them but I think reports like the DBIR can be leveraged to make them as objective as possible. A very good example is the risk level one might normally assign to a case of unpatched vulnerability versus a configuration issue.  It may not be readily obvious that one might need to be assigned a higher risk level over another until you read the DBIR. The DBIR tells us that the likelihood of exploitation of an unpatched  vulnerability is far less as compared to a vulnerability caused by a configuration issue. If we didn’t leverage the DBIR (and assuming both issues had equal impacts), we might assign equal risk levels to both the findings or worse, we might assign the unpatched vulnerability a higher risk level.

Over the next couple of weeks, I plan to be blogging with a detailed commentary on some of the findings in the report including a special post on how the report can be leveraged to enhance the effectiveness of PCI DSS programs.

Hope this is useful! As always, we welcome your thoughts and comments.

RisknCompliance Services Note

We at RisknCompliance track about a dozen of such reports every year and maintain a up-to-date database of the current security threats and vulnerabilities at a detailed level. We are able to leverage this knowledge in  providing our clients with  a much-wanted third-party assessment of their risk management or audit methodologies and  programs. After all, security risk assessments and audits form the very foundation of risk management or audit programs, so we believe it is critical that every organization fine-tunes its methodologies and  knowledgebase.

Please contact us here if you would like to discuss your needs. We will be glad to talk to you with the details and how we might be of assistance to you.