corporate security
Trustwave Director of Product Management, Josh Shaul
Despite maybe a decade of dealing with these problems, SQL injection and brute force or credential theft attacks remain among the most potent methods used by attackers seeking to compromise corporate databases and steal valuable information from them.
We spoke with Trustwave director of product management, Josh Shaul, who plans to walk his audience through a typical attack on a corporate database – from the initial intrusion to the eventual exfiltration of data – at the RSA Conference later this month.
According to Shaul, what needs to be done in order to secure enterprise databases is straightforward and well known, but companies are, for a variety of reasons, failing to implement the proper security controls and install necessary patches. In brief, enterprises need know how many databases they have, they need to make sure built-in security features are enabled, they need to stay on top of patch installation, monitor employee permissions, and make sure access credentials are strong. In addition to these measures, it is integral that organizations have an incident response plan before the breach occurs. Having an incident response plan in place ahead of time I many cases is what saves companies from going out of business following a breach.
SQL injections remain massively problematic. They are without doubt the largest threat vector for database security. Not only are they the avenue through which attackers often access databases, they are just as often the mechanism by which attackers escalate their privileges once inside a database. That said, malware designed to sniff out credentials is a commonly deployed means of accessing databases as well. Shaul also noted that newer database specific vulnerabilities that disable access limits grant attackers the opportunity to make an unlimited number of password guesses, thus enabling brute-force entry attacks.
“I think the fact that the sql injection problem hasn’t gone away is not a good indication that the problem is unsolvable,” Shaul said. “It’s really more of an indication of the size of the community of folks that are putting software onto the market and the motivations of those folks.”
He went on to explain that there is an abundance of developers who are building software for corporate environments who have not been properly trained or even trained at all about how to create secure applications. Unfortunately, he continued, the voices of the people that preaching about how to properly secure these applications just aren’t reaching everyone.
“We have new applications being written by folks who just don’t know what they are doing from a security perspective, introducing new SQL injections,” Shaul said. “Then you’ve got software vendors who are writing software and releasing it out there and it’s very commonly run software that also end up with sql injection vulnerabilities in their software.”
Over and over again, Shaul believes many developers are introducing vulnerabilities to their database environments because they aren’t performing security tests or full code reviews or otherwise practicing diligence during their application development process.
“I think it’s a very likely a motivation issue for those folks,” he says. “It’s less profitable to release more secure software. So they are making business decisions, and that’s understandable, but that’s often putting consumer data and often intellectual property and other data at risk.”
Even after an attacker compromises and enters the corporate database, that person’s ability to get back out of that database with valuable information is largely dependent upon system configurations.
Of course, it’s also always possible that the attacker lucks out, stealing credentials for a database administrator and going straight to the top.
“Let’s say you do get in as a low privilege user. It’s all about how that database was configured and if it was patched. That’s going to mean the difference between someone getting in and easily going from no privilege at all – just the ability to login – to full ownership of the database.”
Problematically, exploited database vulnerabilities don’t yield small parts of they database. On the contrary, they tend give an attacker everything all at once. That problem is compounded by the fact that these vulnerabilities are very easy to exploit once an attacker is inside the database.
If you can patch the database, he said, you can fix those problems. And resolving these issues up front is the best way to protect a database.
Once an attacker is in, has found the data, and is ready download it and leave, eyes on the logs, Shaul says, whether they’re human eyes or an automated monitoring system are likely the best defenses for limiting the scope of the breach. The best option at this point is to have controls enabled in the database that will let its administrator cut off access to certain data if suspicious activities are detected. Unfortunately, it doesn’t take long to download significant amounts of information off a database, so near-constant vigilance is required to protect valuable data.
In general, Shaul says database security begins with a risk assessment. That risk assessment must involve taking inventory of all the databases a company controls.
“It may be surprising, but almost every organization we have ever gone into – and we’ve been doing this for maybe ten years or so – and done a database inventory scan, we’ve found more databases in their environment than they expected,” Shaul said. “Usually, at least 30 percent more. Sometimes 300 or 400 percent more.”
The rest of the risk assessment has to do with an organization understanding its own security posture. How up-to-date are their security patches? Who can access which information and do they have good passwords? Are the security features in the database turned on? These databases, he claims, are sent from manufacturers to the organizations that will deploy them with most of the security controls turned off, because an organization is going to customize the database for their needs.
“Funny thing about security features,” Shaul said, “if you don’t turn them on, they don’t work.”
Shaul is slotted to speak at the RSA Conference in San Francisco later this month. His presentation, Peeping Naked Data: How Attackers Expose Databases and How to Cover Your Back End, is scheduled for February 25 from 2:40 PM to 3:10 PM.
