Health Care Information Security Challenge

In the last week, I’ve read several articles claiming that health care information is a prime target for cyber-criminals in 2013.  While I agree with this, I don’t agree with one of the reasons given.

Some bloggers and journalists claim that the HIPAA has not kept up with technology, and this is the reason health care is at risk today.  I disagree with this.  the HIPAA is strongly aligned with ISO/IEC 27002:2005.  General compliance with the ISO standard of best practice brings a covered entity into compliance with the HIPAA security rule.  Add to this HITECH, Subtitle B, and a covered entity has everything it needs to keep information safe.  In my view, the problem isn’t with the HIPAA; the problem is with perspective.

Compliance is not security: it is not effective risk management.  When I was director of security for a national health care organization, compliance initially went down this path.  C-level management began to ask why risk still existed after we were judged “HIPAA compliant.”  Putting the need in terms of bottom-line risk helped to turn perspectives; it made management look at HIPAA as a starting point, not an endpoint.

Today, many health care organizations are HIPAA compliant, but that does not mean risk has been sufficiently mitigated.  This is also true of publicly traded companies who pass SOX audits.  One of the biggest mistakes we as security professionals can make is allowing our employers or clients believe they are secure simply because they are compliant with a regulation.

So this begs the question… Is the current health care information security challenge a problem with the regulation or a problem with how we view compliance and risk?

Security None-sense

I’m sitting in my mother’s hospital room. It is in a new, modern, well thought-out addition to the Toledo Hospital. There is even high-speed Internet access via Wi-Fi. However, the hospital’s IT department blocks social networking sites. Why?

If it’s for security, why bother? I can access Facebook and Twitter from my iPhone and iPad using other tools. For example, I sent a Facebook post (just because I could) using my email. I continued to receive friend updates via email and text messaging. I could also post photos or video from my iPhone. So any HIPAA compliance intent is fully circumvented.

If the hospital is blocking social networking to preserve bandwidth, it needs to reconsider. Today’s patients–and their families–have integrated 24/7 social contact into their lifestyles. Blocking access is simply a poor business decision.

Finally, they may block blogging before my next visit, given that I am writing this on my iPad will sitting in my mom’s room…

Permissions Creep: The Bane of Tight Access Management

Organizational role changes are common.  People are promoted, move from one department to another, or responsibilities change for the roles they’re in.  The result over time, commonly known as permissions creep, is a bunch of user accounts for which least privilege and segregation of duties no longer apply.  The solution is a documented and aggressively followed job change process.

First, let’s look at the issue of job changes.  A job change process should use an authoritative source, such as your human resources system, to track role changes.  If you assign a job code to each employee based on his or her position, then this is pretty easy.  One approach is to compare a nightly extract, including employee ID and job code to the previous night’s run.  A difference in job code indicates a change in position.  If your HR system produces a report listing job changes, then you already have what you need.

For organizations with an automated provisioning system, the next step is easy.  Feed the changes to the provisioning server and let it do its thing.  Otherwise, hand it off to a system administrator for manual changes to directory services and all relevant applications.  Whether automated or manual, the process is the same.  For each affected account, remove all current access and replace it with the approved access for the new job role.  This assumes you’ve defined access by application, AD group, etc. for each job code.  If you haven’t, this is a big job so you’d better get started…

Some admins might simply reverse access based on the original role.  This is not effective, especially for an employee who’s been around a few years.  Exceptions to base access settings may have been added over time as the employee’s manager added additional responsibilities not commonly given.  Changing responsibilities causes problems, particularly when an employee’s job never changes and the job change process isn’t invoked.

If you have employees who have worked for your organization for many years, especially those who demonstrate the ability to perform a wide variety of tasks, they have probably been given special permissions in addition to those approved for their organizational role.  These exceptions were likely approved by a data owner and are on file for the auditors.  So far, so good.  However, the dynamic nature of business inevitably shifts these responsibilities around, removing the need for access but not the actual access itself. 

Dealing with permissions creep caused by variable responsibilities over time requires actual reviews of employee access.  Schedule periodic reviews by data owners, managers, etc.  Use the results of these reviews to adjust access to reflect employee job responsibilities today.

Finally, there is the question of location.  For non-healthcare organizations (HIPAA free), this might not be a problem.  However, when you have to manage patient information visibility based on role and location, access reviews take on an additional dimension.  Make sure reviews and job changes take into account where the employee is working and adjust need-to-know controls accordingly.

Managing permissions creep isn’t exciting, but it is a necessary part of securing information assets.

Blame the auditors: What a concept!

I have never thought of this.  After a breach, just blame the auditors.  Wait.  The reason I hadn’t thought of it is because passing a compliance audit IS NOT ASSURANCE OF SECURITY.  But some still don’t get it.

In an interview with CSO’s Bill Brenner, Heartland Payment Systems’ CEO, Robert Carr, blamed his QSA auditors for a recent (huge) breach.  Because they said his organization was PCI compliant, he felt secure.  Wow.  Security by checklist once again.

Rich Mogull, in an open letter to Carr, makes several excellent points about reliance on compliance instead of solid security practices.  He concludes his letter with,

But, based on your prior public statements and this interview, you appear to be shifting the blame to the card companies, your QSA, and the PCI Council. From what’s been released, your organization was breached using known attack techniques that were preventable using well-understood security controls.

As the senior corporate officer for Heartland, that responsibility was yours.

Source: An Open Letter to Robert Carr, CEO or Heartland Payment Systems, Rich Mogull, 12 August 2009

Rich’s letter is a good read, and it should be circulated widely among security professionals and senior executives. 

Among other things, this is another case where an organization is falling back on a completed checklist representing compliance with the PCI standard, a bare minimum set of security requirements.  But whether you are HIPAA, GLBA, or PCI compliant, checking off on recommended practices doesn’t equal security.

Each of us is responsible for placing compliance activities within the proper context: guidelines within a broader security program.  No regulatory or industry standards can protect our critical infrastructure or sensitive data.  Only an aware, thinking human who actually cares about security—and understands how standards apply within his or her unique environment—can do that.

Send secure email free, including attachments

The other day (or once upon a time, whatever), I tried to use Gmail to send an attachment encrypted with SecureZIP.  I was quickly reminded by the Google email service that it didn’t allow encrypted attachments.  So I tried our restaurant’s Yahoo mailbox.  Same result.  I needed to send a secure attachment, and I didn’t want to sign up for a for-fee service to do so.  So I searched the Web for a free secure mail service.  I found two which show promise: Lockbin.com and SendInc.com.

Lockbin.com was simple to use.  After accepting the user agreement and entering a CAPTCHA string, I was presented with the text entry form shown below.  Since the connection established with the site was encrypted (HTTPS), anything I entered and sent was safe from unauthorized sets of eyes.

I entered a short test message and clicked Continue.  The next window (below) prompted for a password to lock the message until picked up by the recipient.  The password, or “Secret Word,” has to be sent to the person receiving the message via standard email, phone call, text message, etc.  I entered a password and clicked Continue.

 

Finally I was prompted for my name, my email address and the recipient’s email address.  I was also shown how the alert message would look when it showed up in the destination mailbox.  The text was not editable at this point.  Clicking enter again, the message was sent. 

Since I had sent the test message to one of my addresses, an alert quickly appeared in my mailbox (shown below) letting me know I had a secure message to retrieve.  To read the message, I clicked the link as instructed.  This opened a secure session with Lockbin.com.  After entering the password I provided when I sent the message, I was shown the message text.  Simple, but not quite what I needed.

There are two potential issues with Lockbin.  First, the sent email is deleted from the Lockbin server as soon as the recipient opens it.  If the person you correspond with doesn’t understand this, you might find yourself resending it.

Second, Lockbin doesn’t support attachments.  This is OK if what you want to share is a small list of private data.  However, I needed to send a complete document.  So on to SendInc.

Like Lockbin, SendInc is a free secure email service which requires no downloads.  But unlike the first solution, SendInc is a better fit for home office or small business use.

With SendInc, I can send up to twenty messages per day.  This would be a serious limitation for larger businesses, but it’s fine for my needs.  And although there is a send limit, I can receive an unlimited number of secure messages.  The best thing about SendInc, however, is that I can include attachments up to 10 MB.

With Lockbin, no account is necessary.  This is not true with SendInc.  This is probably due to the eventual offering of a for-fee service for users with a need for more than 20 outgoing secure messages per day.  SendInc knew immediately after I entered my email address that I didn’t have an account.  I was presented with an account activation form.  Once the form was complete, I entered an activation code sent as the final form completion step.  Now I was ready to enter the test message, as shown below.

After entering my test message and attaching a 5 MB Word attachment, I clicked the send button at the bottom of the form.  The email was  immediately processed, and I received a notification in my Gmail account.  The following image shows the contents of the alert.

Again, I simply clicked the provided link to establish a secure session with SendInc.  However, the Gmail account I sent the message to was not registered with SendInc.  So I was required to activate an associated account with a form similar to the one I completed when activating the sending account, as shown in the following image. 

Once both accounts were activated, I was able to send and receive secure messages with them by supplying the relevant passwords.  Messages once processed are not retained by SendInc.

Both of these solutions work as advertised.  Neither are perfect, and I wouldn’t use them to share national defense secrets.  But I don’t deal with national security issues.  For quick messages without an attachment, Lockbin is certainly easier to use.  For attachments, there is always SendInc.