Last week I provided Howard Anderson at HealthInfosecurity.com with some of my thoughts about the recent Utah Department of Health breach of the files of 900,000 individuals, and counting. He included some of my thoughts in his blog post, along with thoughts from others. I wanted to provide my full reply here, along with some expanded thoughts.
As background, for those of you who may not have heard of this hack yet, in a nutshell:
- The data breach occurred on March 30
- A configuration error occurred at the password authentication level
- This allowed hacker(s), located in Eastern Europe, to obtain files containing sensitive information by circumventing the Utah Department of Technology Services’ (DTS’s) security system.
- The files were stored on a server that contained Medicaid information at DTS.
Why Does A Breach Like This Happen?
What is important to note about this breach is that it reportedly resulted from not following procedures, which allowed the subsequent incorrect configuration to leave the door open for hackers to exploit, coupled with not adequately monitoring network activity. I believe such mistakes, oversights, and outright “…well, no one’s going to catch this…” types of situations are likely widespread.
I know from my years as a systems analyst, and maintaining a large change control system, that it is not only very easy for mistakes to occur within the network security architecture of a complex set of systems, but that there will always be some humans involved who are tempted to bypass important security controls because they slow them down, are cumbersome to follow, take too long to perform, or they simply believe that no one will ever be able to find such a vulnerability. It frustrated me all those years ago to spend a lot of time maintaining an effective, well documented, secure system only to walk through the various programming areas and see certain individuals working together to bypass the controls within the system. For example, upon at least a half dozen occasions I found the Directors of various programming areas, who were supposed to serve as the final approval of moving code into production after performing certain reviews to ensure the code had been appropriately tested and vetted (that took only a few minutes), leaving their computers logged on at the approval screen to allow the programmers to simply go into their offices and submit the approval themselves. Did any bad code ever get into production through these managers’ areas? Oh, indeed. I know from speaking with many programmers and other IT staff since those early experiences that such activities still occur throughout all organizations.
During the hundreds of information security and privacy audits I’ve performed over the years I’ve heard a large percentage of the IT folks I’ve interviewed give me statements to the general effect of, “Really, what is the likelihood of anyone being able to find one hole in the system? It’s very unlikely. These are large complex systems! Skipping some settings are usually not that big of a deal with all the other controls that are in place.” The long-held belief of security by (perceived) obscurity still prevails, but is still as flawed in thinking as it ever was. Tools exist to find such vulnerabilities in the blink of an eye, and then exploit them just as quickly.
Only an investigation and associated audit will determine exactly why controls were inadequate and procedures not followed in the Utah DTS breach; purposeful disregard of the procedures may not be a factor. Perhaps there simply weren’t adequate security controls in place to begin with. Time will tell.
Hackers Hack Where The Digital Jewels Are Stored
This incident should also make clear to business leaders, in all types of organizations, that there are hackers out there that are keeping an eye on organizations that have systems they view as prime targets yielding huge goldmines of valuable data if they can find one hole to slip through. Hospitals, insurance companies, their business associates (of all sizes), government agencies, banks, and so many other types of organizations of all sizes, possess huge amounts of data that can be used by unlimited numbers of cybercriminals, in unlimited ways, and sold to other crooks for large amounts of money. In addition many cybercriminals love to get access to systems capabilities (e.g., bandwidth for playing a game; they sell the access to this bandwidth to whomever wants a superfast connection). Such data in malicious hands not only can lead to systems down time, identity theft, medical identity theft, and financial fraud, just to name a few, misuse can truly impact the lives and health of the patients involved.
Back to the Future Security Basics
This incident points out the need for organizations, of all sizes and in all industries, to do the following to help prevent the same type of breach as that within the Utah DTS:
- Have well documented systems and applications procedures and supporting standards in place that are consistently followed
- Provide training and ongoing awareness for the procedures and standards
- Log changes consistently, and have teams responsible for reviewing the logs, and maintaining the logs for an appropriate period of time
- Perform ongoing audits to catch such configuration errors
- Have a change control process in place to help keep the mistakes of individuals from being put into production
- Use intrusion detection systems (IDSs) and intrusion prevention systems (IPSs) to identify inappropriate access as soon as possible
- Create and maintain well documented breach detection and response plans
- Establish breach response teams and provide them with periodic training and ongoing awareness communications
- Engage independent third parties to perform periodic vulnerability scans and penetration tests
- Encrypt sensitive data, in transit and as rest in all storage locations. As this incident demonstrates, even if a sensitive file is located on a network behind a firewall, the bad guys may possibly still be able to get to it.
All these activities are part of an effective risk management program, which is required by and supports HIPAA, GLBA, and other regulatory compliance. And, considering all the sophisticated automated tools cybercriminals have at their disposal, is a necessary part of business today to protect against such real and numerous threats.
BTW, as I was getting ready to post this I learned that IBM for Midsize Businesses will hold a related webinar on May 15 entitled “Mid-Market in the Crosshairs: Why Cybercriminals Are Targeting Midsize Organizations and How to Foil Them.” Looks like it will cover many of these concepts.
Other discussions of the Utah breach
To learn more about the Utah DTS breach, here are some other good resources that covered this incident.
• Utah Medicaid Data Breach Information
• Gary R. Herbert, UT Governor: Independent Audits Needed in Wake of DTS Medicaid Data Breach
• Utah Department of Health: a bold repeat marcher in the parade of major PHI security breaches
• Utah’s Medicaid Data Breach Worse Than Expected
This post was written as part of the IBM for Midsize Business program, which provides midsize businesses with the tools, expertise and solutions they need to become engines of a smarter planet.
Tags: audit, breach, breach response, change controls, compliance, DTS, encryption, IBM, Information Security, information technology, infosec, IT security, Medicaid, midmarket, non-compliance, personal information, personally identifiable information, PHI, PII, policies, privacy, privacy breach, privacy professor, privacyprof, protected health information, Rebecca Herold, security, security engineering, sensitive personal information, SPI, systems security, Utah