Avoiding The Next Big Data Breach

Tuesday, June 21, 2011

Alexander Rothacker


Article by Richard Tsai

2011 has been turning out to be looking very different than 2010 with respect to data loss.

A year ago, in 2010, the large data breaches were minimal in occurrence. In fact, the total records compromised were just 4 million according to Verizon’s 2011 Data Breach Investigations Report, in their sample set.

While the data loss decreased dramatically, compared to the previous year’s amount of 144 million, the sheer number of incidents dramatically rose.

I’ve attended talks earlier this year where white-hat presenters have stated that the organized cyber-criminals have modified their tactics and were avoiding the database, but were rather focusing on the easier payloads.

The thought is that more companies are aware of the need to protect the database and have begun implementing security controls, and the risks were no longer outweighing the reward—the large set of records that can be stolen from a centralized source—the database.

Well, half-way through 2011, the situation couldn’t look more different. Several notable large-scale attacks targeting databases have made headline news this year. Headliners have included the LizaMoon attack, the Epsilon database breach, ADP, and Bethesda Softworks – and not to mention the many incidents on the Sony networks that have resulted in well over 100 million records being compromised.

Recent coverage has certainly increased the profile of certain hacktivism groups, or whatever you want to categorize them as. Hacktivism groups certainly now realize what draws attention—the exposure of a lot of records. We should expect the rise of copy-cat groups, especially since the abundance of information on hacking techniques is readily available.

Known vulnerabilities are typically well documented on the internet, complete with exploit code, and information about how to perform SQL Injections. One group describes their hacking justification as simply to “spread fun”.

Recently, Citigroup joined the group of victims, announcing that 200,000 banking customer records were affected. If your company is a custodian of personal information, you have been officially put on notice. The threats are real!

If you are a business with an online presence, what can you do to strengthen the protection around your databases? If you haven’t read my colleague, Josh Shaul’s article, “Why SQL Injection Attacks Continue to Succeed,” then that is one place to start. Let’s delve further into areas that can short-circuit the attack on the database.

SQL Injection. Since SQL Injection is not an actual vulnerability, per se, it is an attack technique that takes advantage of poorly coded or configured applications. It’s not easy enough to just patch it, because you can’t. Validate all the input entering the application. Check for type, length, format, and try to restrict input to expected values. Almost all web applications use a shared account to access the database. Ensure that account has restricted privileges on the database, and can only read and write to the necessary objects. When possible, segment the services that make up the applications to use separate restricted accounts, so that each only has access to perform their specific functions. An example would be the segmentation of payment, catalog access, and customer data. Application developers must avoid the usage of dynamic SQL statements, and instead use parameterized SQL statements to prevent injections. Database activity monitoring solutions with intrusion detection will detect and react to SQL injections, allowing an organization to decide how they want to react—block it immediately or collect evidence and contact authorities, as an example.

Passwords. Should an attacker get access to the database, there should be no reason that a properly restricted account they’ve connected with should have access to the list of other users and their passwords. Accessing other database accounts can allow an attacker access to other parts of the database, and most times to other systems on the network, where other sensitive data will reside. All major databases have decent password policy features—use them. They will force users to change their passwords on a regular basis and create strong ones. Of course some users will naturally try to weaken them for the purpose of convenience. Use available tools to continuously monitor for weak passwords and to locate the presence of accounts that should be removed, such as orphaned accounts and default accounts.

Malware. Many times, the web application is just the front door that will lead to the creation of a beachhead somewhere else within the network. Malware can be installed to provide a backdoor, or used for reconnaissance, or be used for siphoning data out. In order to get malware installed, the hacker requires an account that has the administrative privileges to successfully get it installed on the underlying operating system. We discussed restricted access previously, and the account connected to the database should be restricted from any operating system privileges. Note that many databases allow access to the operating system. Un-patched vulnerabilities in the database are a hacker’s best friend, because most allow an attacker to elevate their privileges to garner the administrative privileges that they need. This is why it is important to apply security patches as quickly as possible—it literally covers up the holes. In some cases, vulnerable components can either be removed or reconfigured so they no longer pose a threat. In other cases, databases can be easily misconfigured, introducing other security risks that allow an attacker to gain the privileges they need. Organizations should compare their configurations to third-party verified security checklists to develop a baseline. Two very good resources include the U.S. Department of Defense’s Defense Information Systems Agency (DISA) and the Center for Internet Security (CIS). Both DISA and CIS provide security checklists for databases, called Security Technical Implementation Guides (STIG) and Security Configuration Benchmarks, respectively.

Certainly the list of recommendations above is neither comprehensive, nor required for everyone. Instead it is used to illustrate that a good defense-in-depth approach is the best bet to short-circuit the threat of data leakage. With the wealth of easy targets out there, there is no reason your organization needs to be the eye of an opportunistic attack.

The large data breaches have certainly been disconcerting; however, they present an opportunity to educate and move security projects forward. It’s incumbent on the individuals that are responsible for the security of the data to ride this wave of activity, raise awareness, and move their security projects forward.

There is no reason these large breaches should be occurring, not when the solutions already exist.

Cross-posted from TeamSHATTER.com

Possibly Related Articles:
Information Security
SQl Injection Passwords breaches Databases malware Hacktivist TeamSHATTER
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.