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
|
#
|
Question
|
% of respondents saying “Yes”
|
|
1 |
My organization’s senior management does not view privacy and data security as a top priority |
70% |
|
2 |
My organization does not have ample resources to ensure privacy and data security requirements are met – 61% of respondents. |
61% |
|
3 |
My organization does not have adequate policies and procedures to protect health information |
54% |
|
4 |
My organization does not take appropriate steps to comply with the requirements of HIPAA and other related healthcare regulations |
53% |
Are You Ready for HITECH? – A benchmark study of healthcare covered entities & business associates
|
#
|
HIPAA compliance requirements that are not formally implemented
|
% of respondents saying “Yes”
|
|
1 |
Risk-based assessment of PHI handling practices |
49% |
|
2 |
Access governance a and an access management policy |
47% |
|
3 |
Staff training |
47% |
|
4 |
Detailed risk analysis |
45% |
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:
|
# |
Key Controls |
Recommended Activities |
|
1 |
Secure Configuration and Lockdown |
Review configuration of information systems (network devices, servers, applications, databases etc.) periodically and ensure that they are locked down from a security configuration standpoint |
|
2 |
Web Application Security |
· Scan web applications periodically for OWASP Top 10 vulnerabilities and fix any discovered vulnerabilities · For new applications under development, perform code reviews and/or vulnerability scans to fix any security vulnerabilities before the applications are put to production use (Studies show that it is far more cost effective to fix the vulnerabilities before applications are put to production use than after) · Use Web Application Firewalls as appropriate |
|
3 |
Strong Access Credentials |
· Configure PHI systems and applications to have a strong password policy (complexity of the password, periodic change of password etc.) · Implement multi-factor authentication on PHI systems and applications wherever possible
|
|
4 |
Access Assurance or Governance |
· Conduct Access Certifications periodically, preferably at least every quarter for PHI systems and applications. · Review access privileges within PHI systems and applications to ensure all access conforms to the “Least Privilege” principle. In other words, no user, application or service must have any more privileges than what is required for the job function or role · If any excess privileges are found, they must be remediated promptly · Revoke access to PHI systems and applications promptly in the event that a person leaves the organization or no longer requires access due to a change in the person’s job role within the organization |
|
5 |
Logging, Monitoring and Reporting |
· Identify “risky” events within PHI systems · Configure the systems to generate logs for the identified events · Tamper-proof the logs · Implement appropriate technologies and/or processes for monitoring of the events (Refer to our related posts here and here for examples) · High risk events must be identified and monitored through near-real-time alerts · Responsibilities for daily review of log reports and alerts must be assigned to specific personnel |
|
6 |
Encryption (Data at rest, media), Physical security of media |
· Maintain an inventory of locations and systems wherever PHI exists · Implement suitable encryption of PHI on laptops and removable media · Implement appropriate physical security safeguards to prevent theft of devices or systems containing PHI |
|
7 |
Security Incident Response |
· Implement and operationalize an effective Security Incident Response program including clear assignment of responsibilities, response steps/workflows etc. · Test Incident Response process periodically as required |
|
8 |
Security Awareness and Training |
· Implement a formal security awareness and training program so the workforce is aware of their responsibilities, security/privacy best practices and actions to take in the event of suspected incidents · Require personnel to go through the security awareness and/or training periodically as appropriate |
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.
Categories: Data Breaches, HIPAA/HITECH Compliance, Information Risk, Privacy, Regulatory Compliance, Security Tags: Breach, HIPAA, HITECH, Logging, Privacy, Risk, Security
Logging for Effective SIEM and PCI DSS Compliance …. UNIX, Network Devices and Databases
In one of my previous blogs, I covered the importance of logging the “right” events for an effective Log Management or Security Information and Event Management (SIEM) deployment … see here or here for a discussion on the two technologies. The blog also provided a suggested listing of the Windows or Active Directory events that you might want to log from a PCI DSS Compliance standpoint.
Clearly, no amount of investment in your Log Management or SIEM solution is going to do much good, unless you have been able to generate all the right logs to begin with … see a related discussion with the recognized PCI Expert and Author, Dr. Anton Chuvakin here.
I would like to extend my suggested list in the previous post to cover a few other systems here, specifically UNIX/LINUX, Network Devices and Databases. Note that this list is only a starting point so you can work with the respective System Specialists or Administrators in your organization to generate these events.
UNIX/LINUX Logging for Effective SIEM and PCI DSS Compliance
Logging of Network Devices for Effective SIEM and PCI DSS Compliance
-
Database Logging for Effective SIEM and PCI DSS Compliance
Categories: HIPAA/HITECH Compliance, PCI DSS Compliance, Regulatory Compliance, Security, SIEM Tags: Compliance, HIPAA, HITECH, Logging, PCI DSS, SIEM
Logging for PCI DSS Compliance
PCI DSS has had specific requirements for logging and review of those logs for sometime now. The logging requirements (under Requirement 10 ) have a primary objective of supporting forensics in the event of a breach of cardholder data. I believe it is fair to say that PCI DSS has played a large role in bringing into limelight the topic of Log Management, in effect creating an assured market for several vendors who are vying for a piece of the PCI business out there.
While most Log Management vendor solutions are featured enough and support quick deployments (normally a selling point one hears from most vendors), I believe it is important for PCI merchants and service providers to take that with a grain of salt. Granted that most vendor solutions have features for effective log parsing, normalization, reporting, alerting etc… As I am sure anyone that has worked on PCI DSS (or for that matter any Log Management or SIEM deployments) would attest, an effective deployment requires deliberate planning and ground work. And in my view, the most critical step for an effective Log Management solution (and most certainly those focused on PCI DSS Compliance) is the very first step, which is Log Generation (see NIST 800-92 Guide to Computer Security Log Management to learn more about Log Management processes). After all, you can get to managing and analyzing logs only if you generate them and more importantly from a PCI DSS standpoint, generate all the right logs!
To illustrate the point, below is a partial suggested list of events you might want to log on Windows and Active Directory. One really can’t overemphasize the need for various system administrators to work closely with the PCI readiness teams to make this happen. I have also included sample mappings to PCI DSS requirements, the likes of which you can use to demonstrate due diligence to your QSA.
Hope you find this information useful and I welcome your comments!
|
# |
Event Description |
Windows Event Id#
- Vista or Windows Server 2008 |
PCI DSS Requirements |
||
|
Logon events |
|||||
|
1 |
Successful Logon – Privileged users only |
4624 |
6.3.3, 8.1, 8.5.1, 8.5.4, 8.5.6, 10.2.2 |
||
|
2 |
Logoffs – Privileged users only |
4634 |
6.3.3, 8.1, 8.5.1, 8.5.4, 8.5.6, 10.2.2 |
||
|
3 |
Failed Logon attempts – All users |
4625 |
6.3.3, 8.1, 8.5.1, 8.5.4, 8.5.6, 10.2.2 |
||
|
4 |
Account Lockouts – All users |
4740 |
8.5.13, 10.2.4 |
||
|
5 |
Account Lockout Release – All users |
4767 |
8.5.13, 10.2.2, 10.2.4 |
||
|
6 |
Privilege escalation through “Run as” |
? |
10.1, 10.2.1, 10.2.2 |
||
|
|
Object access events |
||||
|
7 |
All access to folders containing Cardholder Data |
5143 |
10.2.1 |
||
|
8 |
Changes to access privileges on folders containing Cardholder Data |
4670 |
10.2.1,10.2.2 |
||
|
9 |
Changes to ownership on folders containing Cardholder Data (“Take Ownership”) |
4670 |
10.2.1,10.2.2 |
||
|
10 |
All access to files containing Cardholder Data |
4663,? |
10.2.1 |
||
|
11 |
Changes to access privileges on files containing Cardholder Data |
4670 |
10.2.1 |
||
|
12 |
Changes to ownership on files containing Cardholder Data (“Take Ownership”) |
4670 |
10.2.1,10.2.2 |
||
|
13 |
Creation or deletion of files in folders containing Cardholder Data |
4660, 4663 (Delete)
|
10.2.1 |
||
|
14 |
Access to (Read, Modify or Delete) Security Event Logs by anyone other than the Windows system or the account used for log collection by the Log Management Solution |
? |
10.2.2, 10.2.3, 10.2.6, 10.2.7, 10.5 |
||
|
15 |
Changes to %SYSTEMROOT%\SYSTEM32 folder contents (System Level Object) |
5143 |
10.2.7 |
||
|
16 |
A registry value was modified (System Level Object) |
4657 |
10.2.7 |
||
|
|
Account Management |
||||
|
17 |
User Account Created |
4720 |
7.1.4, 8.1, 8.5.1,10.2.2 |
||
|
18 |
User Account Enabled |
4722 |
7.1.4, 8.1, 8.5.1, 8.5.6,10.2.2 |
||
|
19 |
Password Change/Reset Attempted |
47239(Change), 4724(Reset) |
8.5.3, 8.5.9 |
||
|
20 |
Account Password Set |
4738(?) |
8.5.3, 8.5.9 |
||
|
21 |
User Account Disabled |
4725 |
6.3.3, 7.1.4, 8.1, 8.5.1,8.5.4, 8.5.5,10.2.2 |
||
|
22 |
User Account Deleted |
4726 |
6.3.3, 7.1.4, 8.1, 8.5.1,8.5.4, 8.5.5,10.2.2 |
||
|
23 |
User Account Changed |
4738 |
6.3.3, 7.1.4, 8.1, 8.5.1,10.2.2 |
||
|
24 |
Security Group Created |
4727 (Global Group) 4731 (Local Group) |
6.3.3, 7.1.1, 7.1.4,10.2.2 |
||
|
25 |
Security Group Member Added |
4728(Global Group) 4732(Local Group) |
6.3.3, 7.1.2,10.2.2 |
||
|
26 |
Security Group Member Removed |
4729(Global Group) 4733(Local Group) |
6.3.3, 7.1.4, 8.1, 8.5.1,8.5.4, 8.5.5,10.2.2 |
||
|
27 |
Security Group Deleted |
4730(Global Group) 4734(Local Group) |
6.3.3, 7.1.4, 8.1, 8.5.1,8.5.4, 8.5.5,10.2.2 |
||
|
|
Directory Service access events |
||||
|
28 |
Creation of new group policies |
? |
10.2.2, 10.2.7 |
||
|
29 |
Changes to group (Active directory) or server policies |
? |
10.2.2, 10.2.7 |
||
|
30 |
Application of group policies to a container |
6144(?) |
10.2.2, 10.2.7 |
||
|
|
Privilege use events |
||||
|
|
Privilege use (Failure only) for the following user groups:
|
||||
|
31 |
Server or Domain Administrators |
4674(?) |
10.2.2 |
||
|
32 |
Account Operators |
4674(?) |
10.2.2 |
||
|
33 |
Accounts (User, service or process) with access to Cardholder Data |
4674(?) |
10.2.2 |
||
|
|
System events |
||||
|
34 |
Windows – Starting up |
4608 |
10.2.2 |
||
|
35 |
Windows – Shutting down |
4609 |
10.2.2 |
||
|
36 |
An authentication package was loaded by the Local Security Authority. |
4610 |
10.2.5 |
||
|
37 |
A trusted logon process has registered with the Local Security Authority. |
4611 |
10.2.5 |
||
|
38 |
Internal resources allocated for the queuing of security event messages have been exhausted, leading to the loss of some security event messages. |
4612 |
10.2.3, 10.2.6, 10.2.7, 10.5 |
||
|
39 |
A notification package was loaded by the Security Accounts Manager |
4614 |
10.2.5 |
||
|
40 |
Server time out of synchronization with Domain Controller |
4616(?) |
10.4 |
||
|
|
Windows updates |
||||
|
41 |
Windows Software Update Services – Successes and Failures |
? |
6.1 |
||
Categories: PCI DSS Compliance, Regulatory Compliance Tags: Compliance, Logging, PCI DSS