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.