Why criminals care about health records

Some have emailed me asking why criminals would even care about Personal Health Information (PHI).  Sure, it’s private information but what use is it to a criminal?

The Digital Health Conference last year discussed this question and a panel of cyber security specialists determined that a single PHI record is worth $50 on the black market.  This is the same value given by Pan Dixon, executive director of the World Privacy Forum in a 2007 interview.  So what makes these records worth $50, a value higher than that of social security numbers or credit card information?  Criminals can use a health record to make fake medical claims, purchase prescriptions or receive treatment under a false name.  Since medical information cannot be “canceled” as easily as a credit card number, criminals have a much larger window in which to exploit the information.

For these reasons, PHI records are a tempting target for criminals, especially with the rising costs of health care.  So, yes, you should be concerned about the disclosure of your medical records because it does present a real threat to patients. This is why it is so important for organizations that handle PHI to have adequate security controls in place whether they’re clinics, medical billing, insurance providers, or business associates.  Adhering to HIPAA helps but being compliant doesn’t necessarily mean you are secure.

U.S. Department of Energy suffers data breach

Two weeks ago hackers took control of 14 servers and 20 workstations at the U.S. Department of Energy (DOE), obtaining personal information including names, social security numbers, driver’s license numbers, pictures, fingerprint and handwriting samples, dates of birth and family information for hundreds of DOE employees.  The hackers did not gain access to classified information which investigators believe was the target of the attack.

Until yesterday, the hacker group Anonymous was viewed as a potential perpetrator since one of their factions, Parastoo, claimed responsibility on Pastebin.  However, the posted information was dated, and investigators believe Parastoo is not responsible for the attack.  According to an article published on February 4 in the Washington Free Beacon, unnamed government officials confirmed that the assault involved a foreign nation state.  This nation-state is most likely China based on repeated attempts by Chinese hackers to gain access to DOE information and the value such information has to Chinese efforts.  If so, this employee information will probably be used to launch further attacks and gain the confidence of DOE employees with access to sensitive information.

The DOE and FBI are still investigating the incident, but speculation abounds as to how the attack on their systems took place including weak server security configurations, inadequate user training, and an over-reliance on outdated methods.  The security of DOE systems has certainly been called into question, and some suggest that government agencies such as the DOE should rely more on the help of industry experts and security firms.

HIPAA Omnibus increases data breach response requirements

The Department of Health and Human Services (HHS) released the HIPAA Omnibus rule on January 17, 2013, designed to give patients additional rights to their health information and increase penalties to organizations that fail to protect Personal Health Information (PHI).  The rule went into effect on March 26, 2013, and it includes some changes to data breach response requirements.

HIPAA required covered entities to conduct a risk assessment when a data breach occurs.  The risk assessment would determine whether the breach impacted an individual enough to require notification.  If the risk assessment determined that the risk was low, then the covered entity did not need to notify the individuals nor the Office of Civil Rights (OCR).  According to HITECH Answers, the HIPAA Omnibus rule now requires that covered entities retain documentation on the risk assessment performed that could be provided to the OCR if their decision not to notify is called into question, in other words, a burden of proof.  If the OCR finds that the covered entity did not meet the burden of proof, it may find the covered entity to be negligent and fine them accordingly or require them to perform corrective action.  The rule also adds new requirements for determining the harm to the individual.

Also of interest to HIPAA data breaches is the revised language that broadens the definition of business associates to include more downstream providers who touch PHI.  This increases the number of companies that will need to adhere to the HIPAA requirements.  These companies will need to become compliant before the rule takes effect but many may not even be aware that they will soon be subject to HIPAA.

Canadian Hack Back

Back in November, I blogged about the hack back initiative here in the United States.  Well, similar debates are taking place in Canada.  In January of 2012, Public Safety Canada commissioned a report on hacking, specifically hacking related to online protesting and activism known as hacktivism.  The report recommended several exemptions to existing legislation to allow researchers, investigators, and even journalists to hack into other computers.  Some of the hack back recommendations included allowing security researchers to attack and reverse engineer software in order to determine security concerns (Montreal Gazette), investigators to take additional actions in investigating attacks such as data breaches and malware and reporters to break into private computers to obtain information in the interest of public welfare (Postmedia).

Over the past year, a discussion has taken place between Public Safety Canada and the minister’s office on this subject resulting in a decision by Public Safety Canada on January 16, 2013, to reject the recommendations.  This is by no means a complete loss for those supporting hack back since such large scale initiatives often take years to implement.  Alana Maurushat, the author of the report, wrote, “no surprise that there is no inclination to take up recommendations…these things often take decades of slow changes.”  The past year of discussion will increase awareness of the hack back initiative and we will most likely see other proposals in the future that will address the shortfalls of this proposal which Public Safety Canada has not provided.

Small healthcare data breaches can result in significant fines

On January 2, 2013, the Department of Health and Human Services (HHS) fined the Hospice of North Idaho $50,000 for violations of the Health Insurance Portability and Accountability Act (HIPAA).  The primary violation was the loss of an unencrypted laptop containing Personal Health Information (PHI) for 441 patients, but the penalty included non-compliance areas such as the hospice’s failure to perform a risk analysis and the lack of mobile device security policies and procedures.  This is the first HIPAA fine issued for a breach of PHI from less than 500 patients.

HHS Office of Civil Rights Director, Leon Rodriguez, made it clear in his statement on the breach that HHS will hold businesses responsible for protecting PHI irrespective of their size.  “This action sends a strong message to the healthcare industry that, regardless of size, covered entities must take action and will be held accountable for safeguarding their patients’ health information.”

This comes as shocking news to some who assumed that HHS would not take action on smaller breaches which comprise the majority of healthcare breaches.  According to the December 2012 U.S. Healthcare Data Breach Trends report, there have been only 500 breaches reported to HHS over the last three years involving more than 500 patients but the same period has seen 57,000 breaches involving less than 500 patients.  These businesses should be prepared not only for the cost of notification, lost customers, breach response, and remediation but also HHS fines in the years ahead.

Dexter malware threatens data breaches on point of sale equipment

Security researchers have identified a new malware called Dexter that specifically targets Point of Sale (POS) systems such as cash registers and scanning stations to obtain credit card numbers.  As of December 12, 2012, Dexter had infected systems in 40 different countries with the majority of infected systems residing in North America and the United Kingdom.  The malware infected machines a few months ago, just in time to steal data from many of the holiday shoppers.

Dexter steals credit card data by recording downloaded files from the POS device and retrieving information from memory.  More specifically, it looks for Track 1 or Track 2 data which is read by most POS devices and contains the account holder name, account number and security code for a credit card.  The malware stores the data and sends it in batches every five minutes to the malware operator who can then use it to make false purchases or clone credit cards.

Malware researchers are still trying to determine how Dexter is infecting POS systems but POS owners are not defenseless.  They can protect themselves from the malware by using devices that encrypt the credit card data from the point at which the card is scanned through the processing stage in what is known as Point-to-Point Encryption (P2PE).  P2PE encrypts the data before it is placed in memory and Dexter is currently unable to decrypt the data so P2PE effectively stops Dexter from harvesting credit card numbers on the POS device.

Effectively gathering facts following a data breach

It is easy for miscommunication to happen after a data breach.  There could be many people working on the incident and those people may document differently and without guidance, critical facts could be lost due to inconsistent or ineffectual documentation procedures.  This can make it difficult for incident response teams to understand the relevant facts of the matter.  Here are some guidelines in documenting a breach.

It can be very helpful to start with a timeline.  Discuss the incident with those who first noticed it and those who validated that there was an incident.  Put the time of the reported incident and the validation on the sheet and then add the events that led up to the incident.  Keep adding events to the timeline as you progress and this will help show the incident flow and help you determine the cause and effect of the incident.  Review the timeline with the incident response team and receive feedback.  The timeline can be used similar to a murder board in a police investigation.  Post the known facts and their times on the wall in the incident briefing room and then tack on new facts to it as you progress.  You can do this digitally as well if the team is not all in one place.

Next, record the facts only.  Don’t let personal opinions creep into the log.  Documented assumptions can lead the incident response team in the wrong direction.  They can also be detrimental if legal action is taken as part of the investigation as these documents could be part of the discovery process.

The National Institute of Standards and Technology’s (NIST) Computer Security Incident Handling Guide suggests that teams should have a person designated as the documenter while another person performs tasks so that the critical facts are not left out.

Lastly, don’t jump to conclusions.  There could be many explanations given the available data so care must be taken to eliminate available options.  Determine what data you will need to eliminate an option and then seek that out.  Keep track of the possible scenarios and their underlying criteria and whether those criteria have been proved or disproved.