•

» data breach

Healthcare Data Breaches-Insider Job, Cybercrime, or Both?

Posted on October 3, 2011 by Dan Berger in Main | Leave a comment

As required by section 13402(e) (4) of the HITECH Act, the HHS Secretary must post a list of breaches of protected health information (PHI)  impacting 500 or more individuals. In the past 2 years, over 11.8 million Americans have been affected in nearly 330 separate incidents. This information is contained in a publicly searchable and downloadable database. Thus many organizations (including Redspin) have published “PHI breach reports” which summarize the data and offer conclusions based on the results of the past 2 years.

Relying solely on historical data has limitations, particularly in such dynamic, fast-moving arenas as healthcare and IT. Any conclusions drawn may turn out to be less predictive or prescriptive than as originally put forth. The old adage “if we don’t learn from history, we are doomed to repeat it,” is diluted by the pace of technological change. Relatively new innovations such as smart phones, iPads, and social media continue to alter the nature of human-machine interaction, workflow and social reach. With new modalities for patient care, such as genetic-driven personalized medicine and mobile consumer health applications, one can easily conclude that how a patient’s health record was breached in 2010 will have little relevance in 2014.

As a case-in-point, Bloomberg Businessweek recently reported on a new healthcare industry privacy and security report released by PwC’s Health Research Institute. The article was entitled: “Theft of Digital Health Data More Often Inside Job, Report Finds” (Sep 22, 2011).  Presumably, the editor relied on the following two statements from the report to support the title; “Theft accounted for 66 percent of publicly reported breaches” and “Thieves are most often ‘knowledgeable insiders.’”

Ah, the dangers of oversimplification. If I were a healthcare CIO or Chief Privacy Officer, I might conclude that my security risk would be markedly reduced with daily shakedowns of all staff and more extensive background checks of prospective new employees. Worse, based on history alone, I might dismiss external hackers as not much of a threat to electronic protected health information (ePHI).

Yet, just this same month, RSA re-released a re-formatted, modestly updated 2009 report entitled “Cybercrime and the Healthcare Industry.” This paper discusses the rise of underground cybercrime networks and explains why a stolen medical identity has 10 times the higher relative value than a “regular” identity theft. Looking into its encrypted crystal ball, RSA concludes: “Cybercrime in healthcare is just starting to evolve but could quickly become a devastating industry, economic and societal problem.”

Inside job or underground cybercriminals, most healthcare organizations are under prepared for data breaches. PwC’s report “Old Data Learns New Tricks: Managing Patient Privacy and Security on a New Data Sharing Playground,” (despite the wildly mixed metaphor) was supported by over 600 interviews with health care executives. The 40+ page document is an excellent treatise on the importance of healthcare IT security, only slightly self-serving, and accurately summarizes the health data breach problem as follows: “Breaches erode productivity and patient trust. They’re costly, unpredictable, and unfortunately quite common.” (p3.)

Those in the healthcare IT industry face an increasingly complex challenge. Patients, providers, payers, business associates, researchers and industry economics will demand a significant increase in data sharing. At the same time, the threat surface for data breach will increase exponentially, exacerbated by personal and mobile communications devices and overall multiplicity of end-points. History can guide us only mildly. To borrow from Aldous Huxley and Shakespeare, it’s a brave new world and a world without data islands. Redspin will meet you there.

Happy Birthday Healthcare Breach Notification Rule

Posted on September 25, 2011 by Dan Berger in Main | Leave a comment

I wasn’t the only one celebrating a birthday last week. It’s been exactly two years since the breach notification rule, mandated by the HITECH Act, took effect. Since then, 330 major health information breaches affecting 11.8 million individuals have been reported to the Department of Health and Human Services’ Office for Civil Rights (OCR). And while major breaches are those that impact the largest number of Americans (500 or more per incident), it is worth noting that another 30,500 smaller incidents have also occurred in 2009 and 2010.  Smaller incidents tend to involve 1 or 2 people and are most often the result of a misdirected communication caused by human error. The large breaches are of the most concern and with two years of data under our belt, here’s the upshot –

  • Historical statistics show that the greatest risk to date (more than 50% of violations) has come from theft or loss of laptops, smart phones, and other electronic media and devices.
  • 20% of all incidents took place at business associates (BA’s), showing the need for a covered entity to have deeper involvement with their vendors’ information security policies, procedures and a say in how frequency they conduct security testing and audits.

Adam Greene, a former OCR official who I met at last May’s Annual HIPAA Security Rule Conference, recently recommended that healthcare organizations focus more on their employees and how they physically safeguard hardware. Encryption is almost always brought up in this context as the potential damage caused by stolen or lost devices that have been encrypted can be minimized. But mandatory encryption still remains a controversial topic within the health care security rule-making bodies in D.C. The official position has been that the need for providers to have flexibility in their workflow to deliver optimal patient care has to be balanced against security risks, at least for now.

Let’s look deeper at the issue of business associates. If you sort the online breach notification database by number of individuals affected, you’ll find that 9 of the top 20 incidents occurred at the hands of business associates. This is a significant problem for covered entities today – as their responsibility and liability extends to companies and organizations that are beyond their direct control. At Redspin, we strongly recommend that hospitals adopt a stronger business associate oversight program. We’ve provided HIPAA Risk Analysis services for dozens of hospitals and we almost always cite risk and vulnerabilities in their business associate management programs. I’m not as confident as my friend Adam that they solution is simply that hospitals must take greater precautions in this area. Hospitals and their vendors have a business relationship – by definition, the business associate needs access to protected health information to perform its duties and fulfill its contractual obligation. To prompt real change in a third-party organization, hospitals need to insist, cajole, negotiate, discuss etc. within the bounds of an arm’s length relationship.

One thing we’d suggest is that hospitals point to their own Security Risk Analysis efforts and share with their vendors some of their findings and recommendation, and recommend companies like Redspin to do BA’s own IT security audits. OCR will soon provide some regulatory help in this regard as directly liability for breach will extend to business associates by the end of 2012. At that time, hospitals may even find their business associates coming to them, proactively asking for direction and guidance in the area of data privacy and security. In our opinion, it won’t be long before covered entities insist that business associates conduct an annual IT security assessment as part of the obligations of their business associate contract.

Preventing a Healthcare Data Breach Epidemic

Posted on July 1, 2011 by Dan Berger in Main | Leave a comment

Certain types of computer dysfunction are analogous to disease, at least in a descriptive sense. For example, we say that a PC can get “infected” by a computer “virus.” The recent rash of hacker attacks makes me wonder if we’re on the verge of a data breach “epidemic?”

True epidemics occur when new human cases of a certain disease substantially exceed what is expected over a period of time. Epidemic diseases need not be communicable; they occur when there are an accelerating number of exploits of similar weaknesses in the human immune system. (Note the clever use of the analogy in reverse). It’s not much of a stretch then to apply the concept of an epidemic affecting  the human body to one that cripples IT infrastructures.

Perhaps recent events even warrant the use of pandemic. There have been over 11 million personal health records compromised in major data breaches in the U.S. since September 2008. Last week, 8.6 million health records were reported at risk due to an unencrypted missing laptop in London.  Add recent hacker intrusions at Epsilon, Sony, the IMF, Citibank, Sega etc. and reported incidents are clearly accelerating at a staggering rate.

This must be disturbing news for a healthcare industry moving forward aggressively on the implementation and adoption of electronic health records. But consider this instead a call-to-action. Providers and business associates should seize this moment to take preventative measures. Hospitals and providers can leverage the mandatory security requirements of the “meaningful use” EHR incentive program to build organization-wide consensus and gain budget approval to invest now in their IT security future.

To qualify for incentive payments under meaningful use, covered entities and eligible providers must “conduct or review a security risk analysis in accordance with the requirements under 45 CFR 164.308(a)(1) and implement security updates as necessary and correct identified security deficiencies as part of its risk management process.” What an opportune time to revisit and revamp the outmoded, insufficient, neglected and/or minimal security risk programs that were likely put in place years ago.

For forward-thinking business associates, this is an opportunity too. Direct liability for ePHI data breach won’t transfer to business associates until sometime in 2012, but there’s no time like the present. In IT security, preventative action trumps reaction and damage control. Just ask Sony. And, as a “culture of security” grows among healthcare providers, business associates will find that data security becomes not only a requirement of doing business with health providers but also competitive differentiators.

So how do we all work together to prevent a data breach epidemic? In the 1995 movie “Outbreak” one proposed solution was to drop a fuel-bomb on a city where the virus had been contained.  But data breaches are rarely containable and even if they were, I doubt there would be many fuel-bombs dropped anywhere but in the computer war game Call of Duty.

Our “call of duty” to prevent data breach outbreaks or epidemics is to first understand that security is an end-to-end process. In this new environment where networks, and networks of networks, will be able to  provide an access path to the most sensitive personal information, there is no such thing as containment. To quote John Halamka, MD, MS, and CIO at Beth Israel Deaconess Medical Center) “the healthcare system is as vulnerable as its weakest link. Thus each application, workstation, network and server within the enterprise must be secured to a reasonable extent.” That is your mission.  And Redspin’s job is to help you achieve it.

RSA: More concerned with their revenue than your security?

Posted on June 9, 2011 by John Abraham in Main | Leave a comment

The RSA Breach, their initial reaction, and their follow-up communication regarding the Lockheed Martin attack (which they are admitting is related to the initial RSA breach) makes us question their priorities.

Revenue and brand come first. Customer security is second.

Of course both of these are inter-related: you surely can’t build a robust security brand given security incidents like this and RSA’s brand is forever tarnished with this breach.

Nonetheless, in the short term RSA’s reaction to this incident clearly shows that, while the initial open letter wasn’t downright un-factual, it did (apparently) downplay the risk. This and other elements associated with this incident question their priorities. Let’s have a look at the the first RSA Open Letter #1 published after the initial breach on RSA and their follow-up RSA Open Letter #2, published after the resulting Lockheed Martin breach. Both letters are from Art Coviello, Executive Chairman of RSA.

Is RSA doing everything it can to protect customers?

RSA Open Letter #1: “We took a variety of aggressive measures against the threat to protect our business and our customers, including further hardening of our IT infrastructure.”

Really? So RSA provided a critical security component for protecting PII for millions of people as well as the protection of government and defense secrets and they weren’t doing everything they could before this incident!?!?! Profit margins for the RSA unit of EMC according to Bloomberg News and May regulatory filings apparently slipped from 67.6% to 54.1% due to costs associated with the breach. Frankly, even 50+% margins aren’t bad. Could it really be that the RSA unit was kicking out annual profits on the order of  hundreds of millions of dollars and they can’t find the budget to do “further hardening” of their IT infrastructures until after this incident? If customers really come first, I think they’d be investing some profits to do everything they can, before an incident like this.

“Advanced Persistent Threat” or oops an employee violated security best practices.

RSA Open Letter #1: “Our investigation has led us to believe that the attack is in the category of an Advanced Persistent Threat (APT).”

Downplaying their culpability sounds like marketing to me. Was the attack sophisticated? Perhaps. However, most attacks involve a chain of events. Every link in the chain must succeed for an attacker to gain access. This is why we preach that organizations take a holistic view of security and address the entire risk profile; break any link (even a minor seemingly benign non-technical vulnerability) in the chain and the data is insecure. In this case, the entire attack started when an RSA employee in a core security division violated elementary security principles (and likely RSA’s own security policy) by downloading and running an attachment. Even many average non-techy citizens would have the wherewithal to avoid this trick. Perhaps RSA should have been investing some profits into security awareness training.

Let’s downplay the impact of the incident.

RSA Open Letter #1: While at this time we are confident that the information extracted does not enable a successful direct attack on any of our RSA SecurID customers, this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack.

In the first open letter, he qualified the above bolded statement by saying the breach in their systems did not enable a direct attack. Whatever that means, I guess it does not preclude attacks in general, which is clarified in his next open letter, after the successful attack against Lockheed Martin:

RSA Open Letter #2: on Thursday, June 2, 2011, we were able to confirm that information taken from RSA in March had been used as an element of an attempted broader attack on Lockheed Martin.

If customers come first, I think a more straightforward profile of the true risk would be appropriate up front. My experience is that RSA SecurID customers had become complacent of the risk to their systems due to the breach because of what they’d been hearing from RSA. I don’t think RSA did their customers any favors by fostering this complacency with a sugar-coated view of the impact of the breach.

We’ll do everything we can for our customers. (except invest in new tokens)

RSA Open Letter #1: Our first priority is to ensure the security of our customers and their trust. We are committed to applying all necessary resources to give our SecurID customers the tools, processes and support they require to strengthen the security of their IT systems in the face of this incident.

Apparently “applying all the necessary resources” did not mean replacing the customer tokens, which would be expensive but effective. Based on that lack of resource commitment RSA seemed to have put its customer data at risk – along with state secrets and the PII of millions of individuals. Of course, as the customers’ knowledge of the risk associated with the RSA breach grew – because of the Lockheed Martin breach as opposed to RSA guidance – RSA has expanded the definition of “all necessary resources.”

RSA Open Letter #2: As a result, we are expanding our security remediation program to reinforce customers’ trust in RSA SecurID tokens and in their overall security posture. This program will continue to include the best practices we first detailed to customers in March, and will further expand two offers we feel will help assure our customers’ confidence:

  • An offer to replace SecurID tokens for customers with concentrated user bases typically focused on protecting intellectual property and corporate networks.
  • An offer to implement risk-based authentication strategies for consumer-focused customers with a large, dispersed user base, typically focused on protecting web-based financial transactions.

Lets give RSA the benefit of the doubt and presume that A) replacing the SecureID tokens will be a no cost solution for the customers and B) that implementing “risk-based authentication strategies” will not be a revenue generator. Assuming this is the case, then its the right approach, but one that should have been undertaken at the outset.

Revenue vs. Customers.

According to Art Coviello’s words “Our customers remain our first priority” however, according to RSA’s actions its not that clear cut.

 

 

Inspector General Takes ONC to Task Over Lack of General Security Controls

Posted on May 18, 2011 by Dan Berger in Main | 1 Comment

We wouldn’t be so bold as to say “I told you so,” but for months Redspin has been publicly calling on the ONC to beef up the security controls and measures in the “meaningful use” EHR incentive plan, the Federal Strategic Health IT Plan, and the HIPAA Security Rule itself. In fact just two weeks ago, we offered the following public comments on the Strategic Plan:

“Next, the “security risk analysis” identified as Core Measure 15 should be defined as more than compliance with the HIPAA security rule. Effective security is a process-driven cycle of regularly-scheduled assessments, validation, remediation, and reporting that deliver continuous and durable improvements in information security and help develop a culture of security awareness within organizations.” (Public Comments on Federal Strategic Health IT Plan, 2011-2015)

Now this week, we learn the HHS Inspector General has audited HIT Standards, privacy protection under HIPAA, and other security measures at CMS and the ONC. Their conclusion? “OIG found weaknesses in the two HHS agencies entrusted with keeping sensitive patient records private and secure.”  Such weaknesses included lax oversight and insufficient standards for healthcare providers.

The CMS audit examined seven hospitals across the country and found 151 “vulnerabilities” in systems and controls that are designed to safeguard electronic protected health information. Those lapses included 124 “high impact vulnerabilities” such as unencrypted laptops and portable drives containing sensitive personal health information, outdated antivirus software and patches, unsecured networks, and the failure to detect rogue devices intruding on wireless networks. As a result, CMS had limited assurance that controls were in place and operating as intended to protect electronic protected health information, thereby leaving ePHI vulnerable to attack and compromise.”

This is exactly why Redspins’ HIPAA Risk Analysis and Security Assessments go well beyond the requirements laid out by the CMS and ONC. And why hospitals, health systems and large provider practices should carefully consider which vendor they select to perform their assessment service. This is not “check the box” type of audit work. This is not something you can entrust to one-man consulting shops.  There are serious implications to leaving ePHI vulnerable to attack and compromise. Sure the ONC should be more specific in regard to specific preventative controls or standards in the regulations. But whether stated in the regulations or not, you as a hospital or business associate bear the ultimate responsibility for data breach. We urge you to hold any outside security assessment vendor (including Redspin) to a higher standard. Don’t settle for competence; seek out excellence.

 

Building Assurance through HIPAA Security, Washington D.C., May 10th-11th

Posted on May 15, 2011 by Dan Berger in Main | Leave a comment

Last Monday night, I boarded a “red-eye” flight from LAX to Dulles to attend the OCR/NIST HIPAA Security Conference. I landed at 6:15AM, did a quick change into my business attire, grabbed some coffee, rented a car, and found my way to the Ronald Reagan Building at 1600 Pennsylvania Avenue, 3 blocks from The White House. I thankfully arrived just before the breakfast buffet ended and took a seat at the back of the conference ballroom.

The room was packed with 400+ attendees – literally standing room only until the conference organizers could arrange for more chairs to be brought in. The congregation included providers, government policy-makers, healthcare lawyers, academics, vendors, and consultants.  From the start of the conference at 9AM Tuesday morning to well after 4PM Wednesday afternoon, there was a sense of purpose in the air. Healthcare IT transformation is well underway and IT security will play a major role in whether or not we, collectively, succeed as an industry, as a major part of the U.S. economy and as a country.

While I gained a wealth of information and education from this conference, I want to summarize a few of the most important “take-away” items here.

-   The development of Stage 2 “meaningful use” requirements is well underway.  Security will remain a key focus. New providers will be expected to conduct a HIPAA security risk analysis (SRA) and Stage 1 qualifiers will be ask to “update and re-assess” the previous SRA they completed in order to meet Stage 1 attestation.

-  While still likely stopping short of mandating encryption, Stage 2 meaningful use will also “shine a spotlight” on the security of data at rest, according to Deven McGraw, co-Chair of the HIT Policy Committee “Tiger Team” and Director of the Health Privacy Project at the Center for Democracy and Technology.

-  A batch of final regulations dealing with healthcare privacy and security issues will be issued in one “Omnibus” package to be released this year and likely within months, if not within weeks. This will include:

  • HITECH Act modifications to the HIPAA privacy, security and enforcement rules.
  • The final version of the breach notification rule, replacing the current interim version.
  • Formalizing privacy provisions under the Genetic Information Nondiscrimination Act that forbids use of genetic information for insurance underwriting and categorizes such use as a violation of both privacy and non-discrimination regulations.

-  Sue McAndrew, Deputy Director for Health Information Privacy at the Office of Civil Rights (OCR) called the HIPAA security risk analysis provision a foundational element of HITECH, along with updating the SRA regularly and implementing reasonable and appropriate safeguards.

-  Ms. McAndrew further confirmed and clarified that business associates and their subcontractors will have the same obligations as covered entities under the HIPAA Security Rule and therefore must conduct their own HIPAA security risk assessments. Within 12 months from the issuance of the Omnibus NPRM, business associates will be directly liable for the breach of protected health information (PHI) under HITECH Act sections 13401 and 13404.  She went on to describe this extension of directly liability to business associates “a sea change” in the regulations.

-  Stepped-up enforcement of the HIPAA security and privacy provisions is on the way. Federal enforcement training of State Attorneys Generals offices was done in Texas this past April, and will be conducted in Atlanta and Washington D.C. by end or May and in San Francisco in early June.

 

To Audit Or Not To Audit: If A Business Associate Is In Violation Of The HIPAA Security Rule And No One Knows, Does It Matter?

Posted on April 1, 2011 by John Abraham in Main | Leave a comment

There has been some debate as to the extent that a covered entity (CE) should audit a business associate (BA) to ensure that they are compliant with the HIPAA Security Rule and adequately safeguarding customer PHI. While I don’t offer up the answer to that question, I thought it made sense to explore some of the surrounding issues.

Some of the key factors that come to mind are:

Monetary Penalties

The HITECH Act creates “several categories of violations that reflect increasing levels of culpability” for HIPAA violations. There are four tiers of fines: $100 (“did not know”), $1,000 (“reasonable cause”), $10,000 (“willful neglect – corrected”), $50,000 (“willful neglect – not corrected”) per violation. In each tier there is a minimum fine of $50,000 per incident and a maximum fine of $1,500,000 per calendar year. As these fines are calculated per violation, with each record exposed, in the case of a data breach for example, counting as a violation, the fines can be significant. Of course, the actual fine amount is a function of the culpability. According to the HITECH Act: “in the case of a violation where it is established that a covered entity did not know of the violation and would not have known through the exercise of reasonable diligence” the lowest tier of $100 would apply.

If minimizing monetary penalty risk is a primary objective, then performing “reasonable diligence” might be the recommended approach. Though defining “reasonable” is another question.

Security

If security is your objective and protecting your client data is an important ideal, then you might define reasonable in another way. For example, if most of your patient records are accessible by one particular BA then it could be that the bulk of the CEs data security risk is really encapsulated in a single BA – and perhaps extra care might be taken to ensure the BA has an effective information security program in place. In this case you might call for the BA to perform some type of security assessment or HIPAA Risk Analysis.

Practical Business Management

Another issue is the case of a BA with the following attributes: they provides a critical business function for the CE, they have extensive access to PHI and they are difficult to swap out with another vendor. In this case it’s a question of – do I really want to know if they are in non-compliance? This is a tough question. In the best case you’d identify a critical area of security risk or non-compliance, notify the BA and then they’d fix it. But what if they don’t fix it?

Pure Capitalism

Besides the monetary fines, how else might a security incident impact revenue? Well that depends on the extent that the CE is commoditized. In the banking sector, for example, it is very easy for a customer to move from one institution to another, so a security breach can cause a wave of customer defections. If you are the only hospital in town, for example, then perhaps this is less of a risk. Other brand damage due to a security breach is more difficult to quantify.

Summary (AKA what is “reasonable”)

So perhaps its all about “reasonable due diligence”. This will depend on how each individual CE prioritizes how a security breach impacts their business and compliance responsibilities. And it will surely be the subject of extensive interpretation by both the courts and BAs (when contract liability is being litigated).

A “Reasonable” Approach to HIPAA Risk Analysis

Posted on March 17, 2011 by Dan Berger in Main | Leave a comment

The Office of Civil Rights (OCR) is responsible for issuing annual guidance on the provisions in the HIPAA Security Rule (45 C.F.R. §§ 164.302 – 318.). But with so much recent interest in IT security driven by the “meaningful use” incentive program, we want to share some our observations and perspectives from recent Redspin client engagements in the healthcare industry.

All electronic protected health information (ePHI) created, received, maintained or transmitted by an organization is subject to the Security Rule. The importance of safeguarding ePHI cannot be understated. Sure, publicized breach notifications and million dollar penalties damage a healthcare organization’s reputation and bottom line. But more than that, such incidents undermine professional and public trust of electronic health records (EHR). And make no mistake about it – the widespread adoption of EHR is fundamental to future improvements in efficiency, communications and patient care.

So if security is the cornerstone to health IT transformation, what can your organization do to not only comply with the regulations but also contribute to this important mission? First, all heathcare organizations are required to evaluate risks and vulnerabilities in their environments. Then they must “implement reasonable and appropriate security measures to protect against reasonably anticipated threats or hazards to the security or integrity of e-PHI.” While “reasonability” is a quintessential element of modern judicial systems, it doesn’t provide a lot of guidance. At Redspin, we suspect there will be little sympathy for major ePHI security breaches no matter what any standard of reasonability might dictate. More simply put, it’s better to be safe than sorry.

Conducting a risk analysis that maps to the HIPAA Security Rule is the first step in protecting ePHI. Note, the Department of Health and Human Services (HHS) does not endorse or recommend any particular risk analysis or risk management model. At Redspin, we think this is wise. From our direct experience, no template or “one-size-fits-all” approach can meet the diverse needs of the healthcare industry. We treat each client individually and conduct a thorough review of their environment even before drafting a scope of work, including:

- size and complexity of the IT environment

- number of physical and logical locations where ePHI is stored

- number of IT staff; their knowledge and experience level

- types of EHR, CPOE and other new applications

- functional responsibilities of team members

- progress-to-date toward EHR completion

- company culture and information security awareness

While a HIPAA Risk Analysis is often project-based, we also consider it the start of a process that will lead to ongoing and durable improvements in information security. The Security Rule itself requires an entity to update and document its security measures “as needed” and specifically recommends conducting continuous risk analysis to identify when such updates are warranted. While the rule does not specify how frequently to do this, it’s a moot point for Redspin’s enterprise security assurance clients. By providing our services on a monthly or quarterly subscription basis, regularly-scheduled assessments, validation and re-testing simply become part of an overall operating environment. Our enterprise solution also tracks and documents all historical findings and remediation via our secure, online web portal. The portal’s dashboard view displays summary information via a compelling graphical user interface, making complex data easier to understand and better enabling you to communicate improvements in your overall security posture to all stakeholders.

In summary, Redspin empowers healthcare organizations to truly integrate their risk analysis and management process. This helps them to accommodate: (1) new technologies (2) evolving business operations, (3) new regulations and (4) personnel changes. And by addressing security risks in a proactive, timely manner rather than fixing problems after implementation, healthcare organizations gain greater value from their investment in IT. Sound reasonable?

Increased Penalties for Healthcare Privacy and Security Violations? Batten Down the Hatches!

Posted on February 23, 2011 by Dan Berger in Main | 1 Comment

The 2009 HITECH Act authorized the Health and Human Resources Office for Civil Rights (HHS OCR) to add teeth to existing security and privacy regulations, and they’ve obviously taken the responsibility seriously.

On the same day that HHS OCR imposed a whopping $4.3 million dollar fine on Maryland-based Cignet Health for violating a provision of the HIPAA Privacy Rule, we also learned that HHS OCR intends to tighten healthcare data breach regulations further and to increase financial penalties across the board for privacy and security violations.

The Cignet Health fine was the first civil fine issued specifically under the existing provision of the Privacy Rule which requires covered entities to provide copies of patients’ health records within 30 days of request. As you may know, as covered entities (CE) and eligible professionals (EP) move to electronic health records (EHR), the time limit for responding to a patient’s request for access will become even shorter. To qualify for meaningful use incentives, an EP must provide EHR access within 4 business days. More recently, OCR suggested that, if patients request copies of the protected health information (PHI) and it is not readily available in the format requested, they must be directed to their EHR.

A senior OCR health IT and privacy advisor spoke at HIMMS11 this week. In addition to confirming that the final privacy, security and breach notification rules will be issued simultaneously in 2011, he got everyone’s rapt attention by announcing increases in financial penalties for privacy and security violations. This raises the security stakes considerably. The penalty for a single violation will be increased to $50,000 with a maximum penalty per year of $1.5 million per each provision of the rules. Since many breach incidents can include multiple violations, the corresponding fines could be huge.

Further, OCR is expanding the requirements for business associates. They will now assume direct liability for adhering to privacy and security rules 240 days after the final rules are issued. Subcontractors will also be held to the same standard as business associates. Currently business associates can only be found directly liable under the breach notification rule.

While it’s been publicly reported that over 220 organizations have suffered large data breaches (each impacting >500 individuals), we also got the stunning details that the OCR has been notified of more than 14,000 smaller breaches of PHI (each affecting <500 individuals).

As we noted in Redspin’s 2010 Protected Health Information Breach Report, theft or loss of portable devices such as laptops caused >65% of large breaches. But portable media is here to stay. Instead of trying to restrict where sensitive data is taken, adopt a more data driven view and protect it where it is stored. Solutions like Imation’s Defender product line (encrypted storage: flash, external hard drive and optical) may be right for your organization.

Clearly OCR also understands that business associates are data rich targets and will likely encounter an increase in malicious activity. At present, covered entities must extend their oversight of their business associates IT environment and security posture. This should be included in the CE’s HIPAA Risk Analysis. And with the impending extensions of direct liability to business associates, those organizations should also start preparing to conduct security assessments of their own. And sooner not later.

Of course, at Redspin we think every organization that handles ePHI should have a process in place for external security testing, remediation, validation and retesting. As security consultants, you may think our view is self serving but we consider it an issue in the common interest. After all, even security consultants are healthcare patients at one time or another! We’re all in the same boat – when malevolent storms or hackers strike, we want to avoid data leakage and protect our privacy. So “batten down the hatches – quick men!” (Chambers Journal, 1883)

Healthcare Web Applications – The Security Achilles Heel (Part 2)

Posted on January 27, 2011 by Dan Berger in Main | Leave a comment

Last June, one of my colleagues at Redspin blogged about his concern that security flaws in software applications that house ePHI (electronic protected health information) represent a big threat. We had just completed a security assessment for a client and had found it relatively easy to access their customer portal using a common SQL injection technique. ePHI  records represent tempting targets for cyber crime as they typically include a wealth of personal info (name and address, SSN’s, credit card numbers, DOB and more).

The healthcare industry is currently very motivated to deploy EHR systems, increase interconnectivity via HIE’s, and launch new web applications. As data is made more accessible to more audiences, the risk of a breach increases too. The scope of a HIPAA Risk Analysis should include software applications but be sure to hire a company with specific application penetration testing expertise. Make sure your provider is competent, has relevant experience and applies best practices, starting with the Top 10 Web Application Vulnerabilities list as outlined by the Open Web Application Security Project (OWASP).

Another area of focus should be your internal patch management process. Effective maintenance of your current day-to-day IT operating systems and applications is essential but be sure to conduct an inventory of older applications as well. They may have been developed by people who are no longer with your organization.  Some may perform tasks that are very mundane, highly specialized and/or are rarely used. At Redspin we often uncover these “out-of-sight, out-of-mind” applications in our HIPAA Risk Analysis process. Fortunately we have an application penetration testing methodology that is applicable to both web applications and non-web applications

1 2   Next »