Posts Tagged ‘Privacy’

Let’s talk some “real” insider threat numbers – How can Access Governance and SIEM be useful as effective safeguards?

If you have been following some of our posts, you probably realize that we don’t advocate security for the sake of security. Nor do we like to do compliance for the sake of compliance though you may not have much choice there if the compliance requirements are mandated by external regulations such as industry regulations (e.g. PCI DSS, NERC CIP etc.) or government regulations (e.g. HIPAA, GLBA, SOX etc.). On the other hand, we think that every investment in security projects or operations (beyond what is required for routine business support) must be justifiable in terms of the risk(s) that we are trying to mitigate or eliminate. And the allocation of IT resources and budgets must be prioritized by risk level which in turn requires every IT organization to conduct periodic risk assessments  and rank the risks by severity.  This probably sounds all too obvious but we still see a lot of security purchasing decisions being made that are not based on formal risk assessments or discernable risk-aligned  priorities. BTW, I talk about the quality of risk assessments in another post.

In this post, I would like to go over some “real” numbers on insider threats, as we know from a few recent survey reports. More importantly, I’ll cover how Access Governance and Security Information and Event Management (SIEM) can be effective safeguards in mitigating risks from insider threats.  If you are not up to speed on what Access Governance (sometimes also referred to as Access Assurance) includes, I would point you here (may need registration).  For SIEM, I would point you here.

It probably needs an explanation as to why I chose Access Governance and SIEM for this discussion. Insider threats, by definition, are caused by people  (employers, contractors, partners etc.) whose identity is known to the organization and have been provided some level of access to one or more of the organization’s information systems.  Access Governance can be both an effective detective control (through access reviews) and preventative control (through role based access provisioning and access remediation) for user access. SIEM can be an effective control for detecting anomalous, suspicious  or  unauthorized user activities. When properly integrated, Access Governance and SIEM  solutions can help achieve substantial reduction of risks from insider threats.

Below is a discussion of findings related to insider threats from recent reports. Also provided are notes on how effective implementations of Access Governance and SIEM processes or technologies can be useful safeguards against these threats. I use findings from three recent reports for the analysis – 2010 Verizon Data Breach Investigations Report (DBIR), 2010 CyberSecurity Watch Survey (CSWS)and Securosis 2010 Data Security Survey (SDSS).

Size and significance of Insider Threats

As one can infer from these findings, insider threats are the cause of at least as many security breaches as external threats. It also appears that the cost of breaches caused by internal threats could be higher than those caused by external threats.

Intentional Vs Accidental

It appears from the findings that insiders could be causing breaches intentionally more often than accidentally. Access Governance can help reduce malicious insider risk  by enforcing “least privilege” user access and "segregation of duties" through role based access provisioning, access reviews and remediation of improper access. On the other hand, a properly implemented SIEM solution can be an effective deterrent (as a detective control) to malicious insider threats by logging user activities, correlation of user activities and alerting on suspicious activities by the user. By suitable integration of SIEM and Access Governance solutions, it is possible to analyze user activities (obtained from SIEM) against a user’s role in the organization and hence what the user is authorized to do (obtained from Access Governance).

Cause and prevention

The DBIR findings clearly illustrate the need for organizations to enforce least privilege access through business need-to-know (managing user access based on a user’s role), periodic review of user access (access reviews and certification) and prompt remediation of improper user access.  Access Governance solutions can help achieve these objectives effectively as well as efficiently.

The CSWS finding seems to suggest a problem with the enforcement of organization’s policies related to user access.  As mentioned above, a properly implemented Access Governance program and solution can help with effective enforcement of user access policies.

To conclude, it is obvious that risk management of insider threats needs to be a key focus area of any Information Security  or Risk Management program. An effective Access Governance and SIEM program can help with significant mitigation of the insider risk.

————————————————————————

RisknCompliance Consulting Services Note

We at RisknCompliance have extensive advisory and implementation experience in the Access Governance and SIEM areas.

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

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.

Proposed updates to HIPAA Security and Privacy Rules – What is new?

It was good to see the Office of Civil Rights (OCR) publish the long awaited proposed updates to HIPAA Security and Privacy Rules Thursday last week. Note that OCR is the division of the Department of Health and Human Services (HHS) responsible for enforcing both the HIPAA Security and Privacy Rules.

I want to emphasize that these are proposed updates, also called Notice of Proposed Rulemaking (NPRM) in Federal Government parlance. There is a 60 days period for the public to submit comments on the NPRM after it was published yesterday in the Federal Register. The comments are due by 09/13/2010.

The NPRM includes updates to the following HIPAA rules or areas:

1. Privacy Rule

2. Security Rule

3. Rules pertaining to Compliance and Investigations

4. Imposition of Civil Money Penalties, and

5. Procedures for Hearings (Enforcement Rule)

As noted in the NPRM, these updates are being made to “implement recent statutory amendments under the Health Information Technology for Economic and Clinical Health Act (HITECH) and to strengthen the privacy and security protection of health information, and to improve the workability and effectiveness of these HIPAA Rules”.

For those who don’t have much history on HIPAA, the current Privacy Rule was issued on December 28, 2000, and amended on August 14, 2002 while the Security Rule was issued on February 20, 2003. So, the proposed updates are long overdue in any case given that Information Security and Privacy risk landscapes have changed substantially since these rules were issued.

I’ll focus on updates to just the Security and Privacy Rules in this post. I’ll have two more posts over the next week or so, one with an in-depth coverage on what to expect from proposed updates to the Security Rule and the other one with a similar coverage of the Privacy Rule.

So, here are notable proposed updates:

1. Replace “individually identifiable health information” with “protected health information” to better reflect the scope of the Privacy and Security Rules.

2. Definition of “Business Associate”(BA) being expanded to include the following new constituents:

a. Patient Safety Organizations (PSO)

b. Health Information Organizations (HIO)

c. E-Prescribing Gateways

d. Other Persons that facilitate PHI data transmissions for Covered Entities or other BAs and require routine access to such PHI

e. Vendors of Personal Health Records (like Google Health and Microsoft Healthvault)

f. Subcontractors of a Covered Entity (CE) – i.e., those persons that perform functions for or provide services to a BA, other than in the capacity as a member of the business associate’s workforce.

3. As provided in section 13401 of the HITECH Act, the Security Rule’s administrative, physical, and technical safeguards requirements in §§ 164.308, 164.310, and 164.312, as well as its policies and procedures and documentation requirements in § 164.316, shall apply to BAs in the same manner as these requirements apply to CEs.

4. BAs shall be civilly and criminally liable for penalties for violations of the provisions in #3 above.

5. Requirements of BA contracts (or other arrangements) between CEs and BAs will now apply to contracts (or other arrangements) between BAs and their subcontractors. It is important to note here that the burden of obtaining assurances (through contracts) from subcontractors regarding safety of PHI falls on the BA rather than the CE.

6. A subcontractor will be required to notify any breaches of unsecured PHI to the BA who in turn would be required to notify the CE. The CE then notifies the affected individuals, HHS, and, if applicable, the media, of the breach, unless it has delegated such responsibilities to a BA.

7. BAs, like CEs, may not use or disclose PHI except as permitted or required by the Privacy Rule or their contracts with CEs or as required by law. If a CE and its BA have failed to enter into a BA contract or other arrangement, then the BA may use or disclose PHI only as necessary to perform its obligations for the CE.

8. Other proposed changes to the Privacy Rule include:

a. Certain material changes to the Notice of Privacy Practices (NPP) issued by a CE or by a BA, if delegated so by a CE through contract

b. A number of changes to the definition of “marketing” in the Privacy Rule at § 164.501

c. Provisions for individuals to request restriction of disclosure of certain PHI to a health plan under certain circumstances

d. New restrictions on sale of PHI by CEs and BAs

e. Strengthen the right of “access” more uniformly to cover all protected health information maintained in one or more designated record sets electronically, regardless of whether the designated record set is an electronic health record

OCR has also proposed that the compliance deadline for all new and updated requirements in the Security and Privacy rules will be 180 days after the final update which I believe can be expected in Q4 this year. OCR is also proposing an additional one-year transition period to modify certain BA agreements. The NPRM further qualifies the one-year transition period as “The additional transition period would be available to a covered entity or business associate if, prior to the publication date of the modified Rules, the covered entity or business associate had an existing contract or other written arrangement with a business associate or subcontractor, respectively, that complied with the prior provisions of the HIPAA Rules and such contract or arrangement was not renewed or modified between the effective date and the compliance date of the modifications to the Rules.”

Assuming that these timelines don’t change in the final rule, all CEs and BAs need to plan for full compliance with the final rules by Q2 of 2011 and for revision of existing BA agreements no later than Q2 of 2012. I want to emphasize here that the current BAs (as defined in section § 160.103  of 45 CFR 160) must already be in compliance with the current  Privacy Rule and certain provisions of the current Security Rule beginning February 18, 2010 as required by the HITECH Act. The new deadlines will apply only to the new BAs (see 2. a-f above)  and for all CEs and current BAs to comply with any new or updated requirements in the final rules.

So, what are the highlights in this NPRM? We have known all along (from the HITECH Act) that the BAs need to comply with the Privacy Rule and certain provisions of the Security Rule. The real highlight to me in this NPRM is the expansion of the definition of a BA. Pretty much everyone (including all subcontractors and others) that has the custody of PHI will now have to comply with both the Security and Privacy Rules. Another highlight to me is the expected compliance deadlines as discussed in the previous paragraph.

As I mentioned earlier in this post, I’ll provide an in-depth coverage of the updates to Security and Privacy Rules in two of my upcoming posts.

As always, we welcome your thoughts and comments. We would also obviously like to hear if you need any consulting support in order to prepare for the anticipated HIPAA changes.