Anatomy of a Breach: What We All Can Learn from the Utah Medicaid Records Theft
May 18, 2012 Leave a comment
- The March 2012 breach of Utah’s Medicaid health care record system, originally thought to expose the records of 24,000, actually involved the personal information of hundreds of thousands more recipients.
- Human error appears to have played a major role in opening the door to the cyber thieves.
The fallout from the recent theft of 280,000 medical records containing social security numbers and as many as 500,000 additional patient files from the Medicaid server at the Utah Department of Health continued with this week’s resignation of Stephen Fletcher from his position as the state’s Chief Information Officer. Utah Governor Gary R. Herbert held a press conference this week to disclose plans to ensure that the attack is not repeated. The governor announced plans for an independent audit of technology security systems, the appointment of a new health data security ombudsman, ongoing investigation by law enforcement, and personnel changes, which besides Fletcher’s resignation, reportedly also include the firing of a contractor.
Clearly, it is crucial to follow up an incident impacting this many records in such a significant way by examining the security controls applied to other systems to ensure other servers and files are not similarly exposed. It is also equally important for other organizations to look at what went wrong in this incident. Particularly eye-opening is the information which has emerged indicating that multiple mistakes occurred in order to provide the Eastern European cyber thieves with access to the confidential information of hundreds of thousands of individuals.
What we have learned so far is that some of the most basic security precautions fell by the wayside in this case, with Fletcher’s successor in the CIO role, Mark Van Orden, noting that multiple individual errors contributed to leaving what should have been closely held data unencrypted and without the hardened passwords that should have been in place. Though more details are likely to emerge, it appears that while the correct policy was in place, it was not properly executed in the production environment. A contractor installed the server (which was not in accordance with standard policy). Once the server was deployed, a risk assessment – normally standard procedure – was not conducted, thus failing to catch the fact that the default server passwords had never been updated and giving the cyber thieves virtual keys to what should have been protected assets.
While it is understandable those policies can be complex and dense, special attention clearly needs to be paid to high-value assets, hundreds of thousands of which were impacted by this breach. After all, the best policies and the most sophisticated security systems are completely ineffective if the execution is lacking.