Guest Blog // Selected Security Content Provided By Sophos
What's This?
08:36 AM
Dark Reading
Dark Reading
Security Insights

Utah Medicaid Breach Exemplifies Value Of Encryption And Access Control

Proactively applying private- or public-key encryption coupled with access control won't eliminate data breaches. But it will make it harder for the bad guys to take advantage of you

The recent breach on a server of the Utah Department of Technology Services (DTS) that initially was said to have compromised 181,604 Medicaid recipients and the Social Security numbers of 25,096 individual clients -- numbers that on Monday quickly climbed in the latter case to more than 280,000 patients plus exposure of less sensitive information of about another 500,000 -- demonstrates that when it comes to hacking, you can never be overly prepared.

According to IDG News services, the breach -- believed to have originated with hackers based in Eastern Europe -- appears to have been the result of a configuration error at the authentication level when the DTS moved its claims records to a new server.

Initially, DTS said information was accessed from approximately 24,000 claims, but as its investigation progressed, it turned out that the hackers had made off with 24,000 files -- and one single file can potentially contain claims on hundreds of individuals. Notably, two out of three Medicaid recipients in Utah are children.

Claims stored on servers like the one that experienced the breach can include client names, addresses, birth dates, SSNs, physicians' names, national provider identifiers, addresses, tax identification numbers, and procedure codes designed for billing purposes.

In a Salt Lake Tribune article, reporter Patty Henetz quoted Utah Department of Health spokesman Tom Hudachko, who said that in this particular incident, a configuration error occurred at the level where passwords are entered, allowing the hacker to invade the security system. Technology Services has processes in place to ensure the state’s data is secured, but this particular server was not configured according to normal procedure.

Michael Hales, the Health Department’s Medicaid Director, said, "It just looks like processes broke down," according to the Tribune.

Henetz likewise quoted Boyd Webb, the Department of Technology Services' chief information security officer, who admitted he knew who was responsible for putting the server online without its proper security, but wouldn't give a name. "I believe it was just a mistake," he said.

Funny thing about internal breakdowns or mistakes that result in data being compromised: They keep happening. But they don't have to.

Significantly, under the Health Information Technology for Economic and Clinical Health (HITECH) Act, "If the electronic protected health information (PHI) is stored and transmitted in encrypted form, then you do not need to notify patients, even if there is a security breach."

While there's nothing in any of these stories about whether the PHI of any of these records was encrypted, I think you can safely draw your own conclusions. To defend data of this type, you need to apply access control as well as encryption.

In some cases, encrypting sensitive data is routine. For others, it's formalized.

Take MASS 201 CMR 17.00, for example, which requires the use of encryption for PHI data both in-flight (e.g., wirelessly, as transmitted over the cloud) as well as at-rest (on tape, on disk), with heavy penalties applied for organizations that suffer a breach of unencrypted data.

No matter the type or manner of encryption used (public key, private key), it makes all the sense in the world to be proactive about protecting the identity and sensitive information of your customers or clients, regardless of who they are or, as enforced by the MASS 201 CMR 17.00 law, wherever they were located when they transacted business with you.

Encrypting the data also helps protect against unauthorized access by ensuring that users who are not authenticated cannot get access to useful data. However, all data is on the network for a purpose. There will be some users who do need access to it and are allowed to see it. If a flaw in the authentication (whether that be a weakness in the system or the passwords used) allows an attacker to gain access as an authenticated user, then encryption won’t help you. This is where you need to ensure your access control system that enforces user privileges, policies, and permissions are up to the challenge -- for example, proactively removing access privileges for former employees (who formerly had permission to access network services) when they are no longer in your service.

Organizations should also (hopefully) take fail-safe measures, with supervisory IT management following up on server migration projects, just to be sure nothing was missed in the process. As DTS learned the hard way, it takes only one "gap" (or gaffe) for hackers to exploit and a single announced disclosure for your missing data to suddenly make headlines.

Proactively applying private- or public-key encryption coupled with access control won't eliminate all of your breaches. However, it will certainly make it considerably more difficult for the "bad guys" to take advantage of mistakes or breakdowns in processes when they inevitably occur.

Brian Royer, a security subject matter expert, Sophos U.S., is partnering with SophosLabs to research and report on the latest trends in malware, Web Threats, endpoint and data protection, mobile security, cloud computing and data center virtualization. The views and opinions do not necessarily reflect those of Sophos or SophosLabs.

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
4/12/2012 | 3:26:05 AM
re: Utah Medicaid Breach Exemplifies Value Of Encryption And Access Control
Proactively applying private or public key encryption coupled with access control won't eliminate data breaches
Register for Dark Reading Newsletters
White Papers
Current Issue
Flash Poll
Title Partner’s Role in Perimeter Security
Title Partner’s Role in Perimeter Security
Considering how prevalent third-party attacks are, we need to ask hard questions about how partners and suppliers are safeguarding systems and data.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
Published: 2015-07-27
The kvm_apic_has_events function in arch/x86/kvm/lapic.h in the Linux kernel through 4.1.3 allows local users to cause a denial of service (NULL pointer dereference and system crash) or possibly have unspecified other impact by leveraging /dev/kvm access for an ioctl call.

Published: 2015-07-26
jquery_ujs.js in jquery-rails before 3.1.3 and 4.x before 4.0.4 and rails.js in jquery-ujs before 1.0.4, as used with Ruby on Rails 3.x and 4.x, allow remote attackers to bypass the Same Origin Policy, and trigger transmission of a CSRF token to a different-domain web server, via a leading space cha...

Published: 2015-07-26
The ff_mjpeg_decode_sof function in libavcodec/mjpegdec.c in FFmpeg before 2.5.4 does not validate the number of components in a JPEG-LS Start Of Frame segment, which allows remote attackers to cause a denial of service (out-of-bounds array access) or possibly have unspecified other impact via craft...

Published: 2015-07-26
Honeywell Tuxedo Touch before relies on client-side authentication involving JavaScript, which allows remote attackers to bypass intended access restrictions by removing USERACCT requests from the client-server data stream.

Published: 2015-07-26
Cross-site request forgery (CSRF) vulnerability in Honeywell Tuxedo Touch before allows remote attackers to hijack the authentication of arbitrary users for requests associated with home-automation commands, as demonstrated by a door-unlock command.

Dark Reading Radio
Archived Dark Reading Radio
What’s the future of the venerable firewall? We’ve invited two security industry leaders to make their case: Join us and bring your questions and opinions!