Six Messy Database Breaches So Far In 2010
From a National Guardsman's external hard drive faux pas to a financial services firm's slack practice of password-sharing, this year has already had its share of shocking database exposures
Ericka Chickowski- Contributing Writer,
July 02, 2010
Whether it be insecure Web applications, poor password management, or a lack of database policies and monitoring, the average database today is at risk of exposure through a host of different threat vectors that many organizations are not even aware of -- let alone are addressing. Already in 2010, the number of database breaches as a result of such mistakes is mounting.
The list of disturbing database breaches so far this year mostly could have been avoided. The affected organizations had to learn the hard way, through public embarrassment and expensive incident response procedures. But the missteps that led to them provide a cautionary tale for other organizations.
"Security needs to be addressed by appropriate policies and systems, but perhaps more importantly a cultural commitment and buy-in by employees to achieving security," Daniel Mayo and Graham Titterington, principal analysts for Ovum, wrote recently about database security.
Garnering that cultural commitment starts with awareness. Here are six of the more eye-popping database-related breaches so far this year -- and some lessons learned from each:
1. Arkansas Army National Guard
Breach Details: An Arkansas soldier caused the Arkansas Army National Guard a lot of embarrassment earlier this year when he brought home an external hard drive containing a copy of the Guard's entire personnel database with the personal information of more than 32,000 current and former Guardsmen. For about two months the Guard couldn't track the hard drive down and had to notify personnel of the loss as a result of the potential breach. The drive was eventually recovered and the information destroyed, but the entire event left the organization with egg on its face.
Lessons Learned: Strike one in this case was that the data was completely unencrypted. But strike two and three was the fact that the soldier in question was able to copy the database in the first place and take it off-site.
Database security experts repeatedly warn organizations to take measures to prevent wholesale copying of database files, whether by innocent but negligent insiders or by malicious insiders looking to steal data. Database activity monitoring tools can help monitor for and prevent such activities.
2. University of Louisville
Breach Details: A staff doctor who set up a Web application that tapped into a University of Louisville database of dialysis patients put hundreds of patient records at risk by failing to use password protection to prevent unauthorized access to the application. The records were openly available online for close to a year-and-a-half until someone outside of the organization sent an e-mail cluing the university in on the privacy breach.
Lessons Learned: Web applications are the Achilles' heel of database security, and organizations have to work hard to bring DBAs, developers, and business stakeholders together to develop Web app security policies, particularly around access management issues that can cause breaches such as this.
Breach Details: A business logic flaw in a Web application that was tied to a database of individual insurance customers of health giant WellPoint allowed unauthorized users to potentially access any of 470,000 customer records. The vulnerability was discovered by a WellPoint customer who found that a simple URL manipulation could give her access to other customers' personal data. Turns out an outsourced vendor tasked with updating the application introduced the flaw last fall.
Lessons Learned: Insecure Web app code is frequently the submerged iceberg just waiting to sink an organization's database security. Before rolling out new or updated applications to live environments, organizations should run application testing that not only scans for common code vulnerabilities, but also business logic flaws such as this one.
4. Virginia Beach Department of Social Services
Breach Details: In April The Department of Social Services in Virginia Beach, Va., announced it had fired or disciplined at least eight employees and supervisors in the past year for abusing their database privileges to access restricted information about former employees, family members, and clients. In one egregious example, a supervisor made her employees access a Virginia database to find information about her husband's child.
Lessons Learned: Insider threats to database information are very real, as this example clearly illustrates. While all of the employees involved in these incidents had legitimate access to departmental databases, their use of credentials was for purposes way outside the bounds of their job duties. Robust database activity monitoring tools are the only reliable way for organizations to ferret out account abuse cases on this plane.
5. Florida International University
Breach Details: Though details are sketchy about the exact nature of this breach, what is clear is that Florida International University found the "existence of a database containing sensitive information that did not reside in a secure computing environment" during a risk assessment following an unrelated security incident, according to notification letters sent to nearly 20,000 students and faculty. The unsecure database contained personal data, such as student data related to state mastery standards, grade tracking, assignments, and Social Security numbers of both students and faculty.
Lessons Learned: Not only do databases themselves need to be secured, but so, too, do the systems on which they run and the networks that they're attached to. This means practicing diligent patch and configuration management on database servers, segregating critical databases onto the most secure network segments, and employing the rule of least privilege for these critical database environments.
6. Lincoln National Corp.
Breach Details: In January this financial services firm revealed that lax password management practices and frequent credential-sharing for access to the company's client portfolio database potentially exposed the records of 1.2 million customers. Some shared passwords were used for as long as seven years. The security lapse was not uncovered until an anonymous whistleblower sent Financial Industry Regulatory Authority (FINRA) a user name and password combo that gave access to the portfolio.
Lessons Learned: Password-sharing is one of the most common and potentially damaging behaviors to affect enterprise database security postures. Not only do organizations need to develop and enforce password management policies, they also need a way to look for account use patterns that indicate illegitimate sharing.
Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.