Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Perimeter

10/4/2012
01:31 PM
Adrian Lane
Adrian Lane
Commentary
50%
50%

What's The Threat?

SQL injection -- not malware -- is the main threat to databases

I got into an interesting series of conversations with different database and application security vendors about their frustration in marketing their solutions to customers. Everywhere they go, customers are talking about anti-malware, and in many cases, their anti-malware vendors say they stop database attacks.

For the record, saying and doing are two different things, and anti-malware solutions don't stop database attacks. They help keep attackers from getting a foothold in your organization, but they do not address attacks on databases.

For those of you in IT, you're probably not aware that analysts -- like myself -- speak with different security vendors every day. Usually three a day. And every single presentation, regardless of product or security market segment, begins with the same set of product justification slides: This is the threat you need to worry about! And right now, every one of those presentations is targeting malware.

So what's the real threat to your organization? Malware or SQL injection? Most vendors will tell you that the real problem facing today's organization is malware. Vendors argue that users get phished through email or social media, which opens their machines for malware infection. At this point, the malware finds what weaknesses it can, downloads more attacks, steals passwords, exfiltrates data, and generally tries to infect everything it can. There is no denying this is a major problem, but malware is not the direct threat to database security.

Most people responsible for database security view all of this malware stuff as simply a way to get a foothold in the organization with the ultimate goal to get sensitive data. That can mean files or databases. Direct and indirect assaults on databases are both at issue, but the last attack is usually SQL injection because it's simple and it works.

Again, it's up to the customer to wade through the half-truths and determine what controls -- and possibly a supporting security technology -- will work for them. The confusion in the market is caused directly by vendors trying to position their products as the solution to your problem. I even had one vendor say it must now educate customers on the difference between anti-malware and Web application firewalls (WAFs).

In fact, unified threat management, secure Web gateway, application whitelisting, browser virtualization, antivirus, email security, VDI, and intrusion-detection system (IDS) vendors all claim to "help address the malware problem." And, in truth, they all either help with a part of the problem or a single avenue of infection.

Similarly, database activity monitoring (DAM), WAFs, white box code scanners, dynamic app scanning, vulnerability assessment, patch management, and IDS all claim to help address the SQL injection problem. Again, they all help in some way, but only WAF and DAM are specifically designed to detect and stop these attacks. And while that remains the principle threat, it's only one facet of database security.

Threats are like fashion in that they change every couple of years. The first big fashion trend was the insider threat, followed closely by SQL injection. More recently it has been the advanced persistent threat (APT), but today the all-important threat is malware. And this is where the frustration sets in for database security vendors: The primary threat is still SQL injection. It's just no longer fashionable, and most of the media is tired of talking about it.

Personally, I think it's helpful to think about this in a different way: Attackers don't care. To them, it's whatever works. If that's password cracking or phishing or SQL injection, then that's fine. Those tricks are easy, and if they work, game over. If not, then try again with a different approach like malware. Or maybe something entirely different. Lazlo Toth and Fernec Spala remind us in their recent DerbyCon 2012 presentation that databases are vulnerable in lots of different ways. They demo'ed siphoning data off from clients, network communication redirection, privilege escalation, and even cracked the horribly out-of-date DES encryption built into Oracle.

The debate about which threat should you be paying attention to is largely one between vendors vying for mindshare. Yes, malware is a prevalent threat -- so serious, in fact, that a huge segment of the security industry has adjusted their marketing to cover this problem.

But you can't myopically focus on a single threat: Database security requires balance -- balance between preventative and detective controls, at restricting access while enabling users, at keeping data, the database and supporting infrastructure safe. If you are a database admin, then you should be more worried about SQL injection than malware. Because SQL injection protection is outside of your control, you also should ensure dev-ops teams are doing what they need to do in order to address the problem. You have enough on your plate with patching, configuration, encryption, identity, and privilege management to keep yourself busy.

Adrian Lane is an analyst/CTO with Securosis LLC, an independent security consulting practice. Special to Dark Reading Adrian Lane is a Security Strategist and brings over 25 years of industry experience to the Securosis team, much of it at the executive level. Adrian specializes in database security, data security, and secure software development. With experience at Ingres, Oracle, and ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Navigating Security in the Cloud
Diya Jolly, Chief Product Officer, Okta,  12/4/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: "The security team seem to be taking SiegeWare seriously" 
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-1114
PUBLISHED: 2019-12-05
A Cross-Site Scripting (XSS) vulnerability exists in LDAP Account Manager (LAM) Pro 3.6 in the filter parameter to cmd.php in an export and exporter_id action. and the filteruid parameter to list.php.
CVE-2012-1115
PUBLISHED: 2019-12-05
A Cross-Site Scripting (XSS) vulnerability exists in LDAP Account Manager (LAM) Pro 3.6 in the export, add_value_form, and dn parameters to cmd.php.
CVE-2012-1592
PUBLISHED: 2019-12-05
A local code execution issue exists in Apache Struts2 when processing malformed XSLT files, which could let a malicious user upload and execute arbitrary files.
CVE-2019-16770
PUBLISHED: 2019-12-05
A poorly-behaved client could use keepalive requests to monopolize Puma's reactor and create a denial of service attack. If more keepalive connections to Puma are opened than there are threads available, additional connections will wait permanently if the attacker sends requests frequently enough.
CVE-2019-19609
PUBLISHED: 2019-12-05
The Strapi framework before 3.0.0-beta.17.8 is vulnerable to Remote Code Execution in the Install and Uninstall Plugin components of the Admin panel, because it does not sanitize the plugin name, and attackers can inject arbitrary shell commands to be executed by the execa function.