eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Databases are among the most often attacked pieces of enterprise computing technology as they are the places where the information that attackers want tends to be kept. It’s a situation that Josh Shaul, director of product management at Trustwave, is well aware of, which is why he spoke at length in a session at last week’s RSA security conference on how to defend databases.
In an interview with eWEEK, Shaul noted that the classes of attacks used against databases are not new, though there are some new attack vectors that have emerged.
“We’re still seeing SQL injection and cross-site scripting, as well as all sorts of URL manipulation types of attacks,” Shaul said.
SQL injection has long been identified as a leading form of attack against databases. In a SQL injection attack, an invalid SQL statement is made, which enables an attacker to obtain data.
“The attack methods aren’t changing, and that’s not much of a surprise,” Shaul said. “Why invent a new way of breaking into databases when the old ways still work really well?”
Shaul noted that while the old vulnerability classes still work, they don’t work everywhere, and some of the major e-commerce platforms have taken steps to effectively mitigate the risk.
In terms of the specific attack vectors that modern database hackers employ, there has been a small shift in recent years. A SQL injection attack involves attackers abusing certain database function calls and procedures, according to Shaul. When software developers fix flaws in database procedures that are known to be at risk, attackers find new flaws in other procedures.
“It’s still SQL injection, but the actual parameters that the attackers are injecting SQL into has changed over the years,” he said. “The attack surface area is so large that we are still able to find new legacy classes of vulnerabilities in code.”
Input validation is often cited by security professionals as being the key to limiting the risk of SQL injection attacks. That said, software code isn’t always under an organization’s control, according to Shaul.
“It [SQL injection] is embedded in some of the vendor products,” he said. “Vendors are releasing software that is not properly secured.”
Recommendations
To limit the risk of database insecurity, Shaul recommends that organizations conduct a risk assessment. That assessment should include an enumeration of what databases are running inside the organization and which databases include sensitive data.
“Organizations that I have worked with have always been surprised to find databases on their networks that they weren’t tracking for whatever reason,” he said. “You can’t protect what you don’t know about.”
In terms of the actual databases, Shaul recommends making sure all the databases in use have been updated with the latest vendor patches and that there are strong passwords in place for users and administrators. He also recommends that organizations make sure that database security features are actually turned on.
“Security features have this funny way of working—if you turn them off, they don’t do anything,” Shaul said. “Most database security features are turned off by default, so folks have to turn them on to actually get value out of them.”
Organizations should also look at access controls for the database and make sure that a policy of least privilege is in place. With a least privilege policy, only the minimum amount of access control is granted to users to perform required tasks.
There is also a need to secure the Web application layer, which is typically the infrastructure tier behind which a database is located. Shaul recommends the use of secure coding practices for Web applications as well as the use of a Web Application Firewall (WAF).
“Organizations should protect the front-end access to the database,” Shaul said.
There is also a need for continuous database monitoring to constantly check access and to make sure no known exploits are occurring and that there is no obvious abuse of the database.
The last step that Shaul recommends is that all organizations have an incident response plan. “So if the monitoring of the database shows an attack in progress, the organization will know what to do to stop the attack,” he said.
Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com. Follow him on Twitter @TechJournalist.