•

» healthcare information security

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.

HIPAA Audits – Paying a Little Attention Now Will Pay Big Benefits Later

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

In July, the HHS’ Office of Civil Rights (OCR) announced that they had appointed consulting firm KPMG to conduct up to 150 HIPAA audits of covered entities and business associates by the end of 2012. The implementation of the audit program fulfills a compliance enforcement mandate of the 2009 HITECH Act.

The KPMG contract enables OCR to put “feet on the street,” while retaining an oversight role in the process. Sue McAndrew, OCR’s deputy director for health information privacy, confirms that some audits could even result in OCR enforcement action. “Certainly, if we uncover in the course of the audit major violations or potential violations … we will be dealing with those … in the same manner we would through our formal enforcement process,” she said recently, according to www.healthcareinfosecurity.com

Details of the focus and scope of HIPAA audits have yet to be fully defined. However a few things are clear. Each audit will follow a “typical onsite audit process” with an in-person visit and interviews with key management personnel such as the CIO, privacy officer, legal counsel, and health information management/medical records director. Draft reports will be shared with the organization before they are completed, and management responses will be incorporated in the final audit report.

Fair enough, but further details are a little murkier.  Ms. McAndrew goes on to say that the audits will “initially offer comprehensive assessments of compliance with the HIPAA privacy and security rules rather than specific narrower issues.” For covered entities, it must be a little confusing to see the words “comprehensive assessment” juxtaposed with “rather than specific, narrower issues.”

At Redspin, we use the term “comprehensive security assessments” to mean that we include specific, narrow issues. After all, we’re guided by the HIPAA Security Rule— 84 pages long, even in its simplified version! See following link: (Administrative Simplification Regulation Text, March 2006). It’s also unclear how the OCR and KMPG will select organizations to audit. While the projected number of 150 audits in 2012 makes the likelihood of an audit visit to your organization fairly low – keep in mind, OCR has a separate initiative underway to train State Attorneys General on the HIPAA audit process as well.

We think it would be prudent for a healthcare organization to consider what it can do now, knowing there’s a possibility of a HIPAA audit sometime in the future.  An old Scouting motto comes to mind: “Be Prepared.” This is a good time for covered entities and business associates to review their HIPAA privacy and security programs and ensure that their documentation is up to date.

Most importantly, given the increased civil penalties and liabilities for PHI breach, it can now be considered a fiduciary responsibility for healthcare companies to assess whether their security programs are effectively safeguarding electronic protected health information (ePHI). Organizations participating in the EHR “meaningful use” plan already have a compelling incentive to “conduct or update a security risk analysis” but note, with or without meaningful use, this is a mandatory requirement for all covered entities and business associates, taken verbatim from the HIPAA Security Rule itself.

To help you prepare, let’s fast forward to what an actual HIPAA security audit may look like. The first thing any security auditor looks for is the policies and controls that you have in place, how they are documented, implemented, communicated, enforced, and lastly, how effective they’ve been. They’ll want to review whether or not you have identified vulnerabilities within your organization in the past and what steps you’ve taken to mitigate them.  At Redspin, we’ve worked with IT auditors for nearly a decade in our banking and financial practice. We’ve found that companies that have previously engaged independent firms like Redspin to conduct comprehensive Security Risk Assessments (rather than checkbox compliance solutions) benefit greatly when audit time rolls around.

First impressions are always important, and when an auditor sees that you’ve already conducted a Security Risk Assessment in accordance to the HIPAA Security Rule, they know their work is more than halfway-done. And so is yours. The follow-up demands on your organization’s time and resources will be much lighter and the outcome is virtually guaranteed to be more positive. You’ll be able to show well-documented policies and procedures, an objective rating of the effectiveness of your controls, the actions management has taken to address known vulnerabilities and how your security risk posture has improved over time.

When Redspin conducts a Security Risk Analysis, we make all of the information above accessible to you from our secure, web-base client portal. This further enhances your ability to navigate through large amounts of information quickly and present summary results in a compelling, graphical, easy-to-understand format. Lastly, if requested, we’ll stand side-by-side with you during an audit. Redspin security engineers are always available to you to discuss the results from your assessments. We’re also happy to discuss those findings, validations and final reports with outside auditors at no additional charge.

 

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.

 

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)

8 “Simple” Rules for Protecting PHI

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

In the popular TV series: “8 Simple Rules for Dating My Teenage Daughter,” the rules may have been a bit exaggerated but they sure made their point. (Rule #1: Use your hands on my daughter and you’ll lose them after). Likewise, my “8 Simple Rules for Protecting PHI” strike a similar chord – no threats to bodily harm, but certain transgressions may be bad enough to result in personnel sanctions or even loss of employment. This is serious stuff.

And as with the dating commandments, my 8 rules for safeguarding PHI are not simple but they are doable – provided you can engender operational discipline throughout your enterprise and extend that influence over important business partners. This always requires a 100% commitment to security at the highest level of your organization. But that really shouldn’t be an issue. After all, breach notification rules are strict and the monetary penalties high enough that survival of your business may literally depend on it.

Rule #1: Maintain a comprehensive PHI inventory within your organization and your business associates. You need to know everywhere under your direct and indirect control where protected health information “lives.” This includes both structured and unstructured data in ePHI, records replicated in multiple places, paper files etc.

Rule #2: Establish a data classification model and assign levels of sensitivity. While many government agencies use a 5-level model (or even more), a 2 or 3-tiered system should be sufficient to start with.

Rule #3: Map how ePHI travels during normal workflow. Ensure that compatible security controls exist at both ends of each data transfer. Then do an additional exercise looking at how ePHI might need to be transferred during exceptional events or in crisis management situations. Apply the same safeguards.

Rule #4: Develop access control policies balancing “need to know” without compromising patient care. Then implement and enforce those policies and controls systematically so that software applications, database rules, and personnel restrict access to sensitive information to only people and/or other software programs that have been specifically granted access rights.

Rule #5: Monitor and audit all access to ePHI (include read-only, data changes, privileged activity such as changes to data structures and changes to user access rights).

Rule #6: Conduct internal vulnerability testing and an assessment of current security measures (controls testing). These are components of the risk analysis process that everyone should be working on. If you don’t have the skill set in house, bring in a qualified outside vendor. Expert security firms can add more technical depth to your analysis. Establish a regular, repeatable, ongoing security assessment process that enables you to adapt to new changes in technology, people, systems, business relationships and workflows. Make certain the process maintains historical data so that management can see progress over time.

Rule #7: Implement an ongoing security awareness campaign and regular training program that fits your culture, yet ensures employees understand their role in safeguarding PHI. Conduct social engineering testing on your employees to measure the effectiveness of the training.

Rule #8: Encrypt all ePHI stored on any device that can be carried out of your office (desktops, laptops, hard drives, backup tapes, iPads/tablets, smart phones, and other portable media).

We understand that this is one of the most significant undertakings facing healthcare organizations today. But there really isn’t a choice. A single individual’s healthcare involves multiple practitioners, facilities, diagnostic labs, administrators, payers, ancillary service providers, etc. The very benefits that electronic health records promise can only be realized if the security challenges are met. We’re here to help. It’s 11PM. Do you know where your PHI is?

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

Business Associates: The HITECH Act requires BAs to be compliant with the HIPAA Security Rule – that’s a good thing.

Posted on January 17, 2011 by John Abraham in Main | Leave a comment

Managing vendors and business partners is hard in any industry, but when the data is sensitive ePHI, you are trying to achieve EHR meaningful use and there are penalties like the HITECH Act’s breach notification requirements, it can be even more daunting.

Fortunately, one aspect of the HITECH Act can minimize security risk and facilitate managing Business Associates (BAs). Under the HITECH Act Business Associates need to be compliant with the HIPAA Security Rule. According to the HITECH Act Section 13401(a):

“Sections 164.308, 164.310, 164.312, and 164.316 of title 45, Code of Federal Regulations, shall apply to a business associate of a covered entity in the same manner that such sections apply to the covered entity.“

This means that a Business Associate is required to comply with the administrative, physical and technical requirements of the HIPAA Security Rule as well as with the HIPAA policy, procedure and documentation requirements. This is a good thing because it provides a defined set of standards for BAs to follow. This also provides better criteria for a covered entity to evaluate if the BA is effectively protecting ePHI. Prior to the HITECH Act managing security of ePHI fell upon the covered entity in the form of a Business Associate agreement. The HHS sample template for Business Associate agreements shows how ill-defined this could be

“Business Associate agrees to use appropriate safeguards to prevent use or disclosure of the Protected Health Information.“

The problem with this approach is that, while it sets some contractual expectations of protecting PHI, it does not:

  • set standards as to how that data is protected, and it does not
  • provide a baseline for validating if Business Associate are actually following the standards.

In our experience as security auditors doing health IT security assessments and risk analysis, we understand that both setting standards and validating to ensure these standards are met, are necessary. The reason is that, while it is easy to specify minimum control standards, actually living up to these standards is much harder. Here are some practical examples of how the documented security standard within an organization can be quite different than the actual security provided, even for the most basic controls:

Example 1: encryption of ePHI

If you poll your Business Associates and ask: are you using full-disk encryption for all laptops? Most likely, they’ll answer yes. However, during an assessment, if you dig a little deeper, you will find, for example, that many laptops are in sleep mode, rather than turned off, so the disks are not necessarily encrypted during travel. Furthermore many laptops will use directory level encryption instead of full-disk, which is just fine in theory, however, when you analyze them, you will find that ePHI is stored outside of the encrypted directory.

Example 2: virus protection

Ask a Business Associate – are you using virus protection? – and they’ll all say yes – because of course they are… everybody is these days. However, if you dig a little deeper, you will find many workstations that are not using up to date virus signatures because the user inadvertently turned off the auto-updating or the anti-virus client is not synced to the correct update server.

Example 3: patch management

Ask any health IT professional that works at a Business Associate about system patching? – and they’ll say yes of course we patch everything so all of our software is up to date. However, some in depth analysis will often show that, while operating system patching is fairly consistent, there is a significant lack of patching for 3rd-party applications on servers, workstations and laptops alike.

Other common examples of controls that exist but are not as effective as intended include: wireless networks, mobile devices, and network segmentation (such as attempts to partition ePHI via DMZs and internal firewalls). Now the discrepancy between the existence of these controls and the effectiveness of the controls does not imply some malicious intent by the Business Associates. To the contrary, they most likely have implemented these controls with the best of intentions. However, as anyone who works in a health IT environment knows, there are limited IT resources and too many things to do, and sometimes there is not enough resource cycles left to verify that controls are working as intended. So the upside of the HITECH Act requiring Business Associates to comply with the HIPAA Security Rule is that it will provide a more defined set of standards by which covered entities can evaluate Business Associates, and also for Business Associates to evaluate their own internal security.

In the end this could mean:

  • better protection of ePHI,
  • improved compliance with the “protecting electronic health information” core objective of meaningful use, and
  • reduced chance of a breach notification event under the HITECH Act.

These are good objectives for everyone!

Download a Business Associate Questionnaire to insure your BAs are effectively protection ePHI

The Top 10 Coast-to-Coast

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

On January 4th, Kroll, a worldwide risk consultancy firm headquartered in New York, released their “top 10 data security issues for 2011.”  Two days later, we published Redspin’s “top 10 security issues for 2011.” (I promise, we didn’t read their version first!) So aside from the coincidence, it’s the differences between the two lists that really caught my eye. Maybe it’s an East Coast-West Coast thing. Or maybe they wear their Bruno Maglis a little tight, while we’re sporting Vibram FiveFingers. Perhaps it’s just a difference in perspective. Kroll, being risk consultants, created a list of potential data security risks.  Redspin is in the business of providing security assessments which include findings and analysis. For us, a list of risk areas alone is incomplete without actionable recommendations.

In Kroll’s Top 10, they simply identify potential breach types.  Number 2, for example, is theft, of laptops, cell phones and even “low-tech” item such as paper files. Kroll’s # 3 is lost devices. Their other breach concerns include sending private data (such as EHR) over networks and unintentional social media exposure. Kroll also discusses the risk of the regulatory environment tightening, particularly HIPAA/HITECH, in response to publicized breaches.  To me, this is a little like saying “fire” is dangerous but the new fire safety laws might also hurt your business. At Redspin, our version might be “don’t play with matches, at least not around any sensitive data.”

Thus our Top 10 list looks quite different. We start by assuming sensitive information will be accessed, wired and wirelessly from all possible devices – desktops, laptops, iPads, Droids. As penetration testers, we know that our “assumption” is basically just the cold hard truth. Almost any networked computing device can be hacked, given enough time and resources. If you accept this premise, does it make any sense to still try to exert control over the device itself? Further, an increasing number of companies are deploying applications and storing data in the cloud. Wireless is nearly ubiquitous. Secure the perimeter? What perimeter?

So we say focus on the data. Quoting from the #1 issue on our list:  “Ensure only people who need access are granted access. Understand where the data must be stored to support business processes and update your information security policies to include mobile devices.”  If you get stuck on that last part, we offer a free mobile device security policy template on our new website at www.redspin.com Our full Top 10 List is there too.

As technology use becomes more mobile and social, the line between personal and business use will continue to blur. My hunch is that Pandora’s inbox is already wide open.  Social media is already a fertile ground for farming private data (and I don’t mean “Farmville.” Oh wait, maybe I do!), we strongly suggest that you “ensure that your policies clearly state what can and cannot be communicated through social media and train your employees appropriately.”

Which brings us to a 2011 New Year’s resolution that both Redspin and Kroll agree on. Train your people on privacy issues and information security awareness. In this regard, we offer social engineering testing. Our assessment determines how vulnerable you are to employee disclosure through insecure or shared password information, unapproved use of portable media, and even unauthorized physical access to premises (you should see us in our blue contractor uniforms and tool belts).

Lastly, it’s certainly wise to know where your potential breach areas are. It’s even better to have policies and controls in place that address them. But ultimately you need to test those policies and controls to see if they are working.  That’s Redspin’s forte. In addition to social engineering, we offer a full suite of penetration testing services for your IT infrastructure (external and internal, including wireless), and web applications

In conclusion, if politics makes strange bedfellows, I’d suggest network security guys and risk consultants just stop for an occasional drink at the bar. Most people think of penetration testers as “ethical” hackers. But you can also think of us as the policy-testing dudes.

1 2   Next »