Are Your Databases Secure? Think Again
Targeting enterprise databases is a common attack tactic, as the Anthem breach showed, yet many companies neglect database security.
The rapid growth of unstructured data gets a lot of attention. Yet structured data is experiencing its own huge expansion. This increase is opening security doors that aren’t receiving enough attention in many organizations and making weak database security an increasingly favored attack vector.
"Database security often gets overlooked," said Tanya Baccam, senior instructor at the Sans Institute. "Yet [databases] are increasingly being targeted by attackers."
Database Security Shortchanged
Organizations pump millions into security systems yet leave their databases largely uninspected. A recent Ponemon Institute survey found that organizations allocate the bulk of their budget (40 percent) to network security and only 19 percent to database security.
"The dominant philosophy has been to create an impenetrable perimeter security defense using such things as firewalls and intrusion detection systems (IDS)," said Michael Sabo, vice president of Marketing at DB Networks. "If you believe that nothing can get through your perimeter it probably seems like a waste of money, time, and effort to invest in database security."
That mindset is changing, though, as more people realize that a perimeter-only security strategy has failed. Attackers can circumvent perimeter security devices relatively easily and prey on gullible personnel to let them inside.
Database Security a Tough Sell
Convincing people to take greater care with database security can be a tough sell – particularly if they have never been exposed to an attack. One way to call more attention to database security may be to highlight the number of high-profile breaches where database security played a role. Probably the best example is the Anthem attack, which exposed 80 million customer records.
A database admin discovered the attack, noticing unauthorized access to the database before anyone else. The attackers managed to compromise the credentials of at least five employees and used them to exfiltrate records. Such problems are only going to get worse – unless companies pay more attention to database security.
The issue will remain a critical one, with the continued importance of the database. A recent Dell Software survey found that structured data represented at least three-quarters of the data under management for most organizations. In addition, the survey found, relational databases from vendors like Oracle, Microsoft and IBM remain the dominant repositories for this data.
"The amount of data collected and stored in databases continues to grow at exponential rates, and with it the need for better database security to protect from the inadvertent or unauthorized exposure of confidential or sensitive information," said Perry Dickau, director of product management at DataGravity.
"While there are some groups that are protecting databases with a high degree of vigilance, many are not doing everything they can, or sometimes anything at all," said ESET security researcher Cameron Camp. "Scammers know this and can run rudimentary tools to try to exploit public websites, internal data from organizations they infiltrate and a host of other sources to try to slurp up the records, often containing exploitable personal information that you may not even know is being stored about you."
Camp recommended that companies sign up for security services such as penetration testing or build their own with free tools like OpenVAS that scan systems for vulnerabilities from an attacker’s perspective and let you know what problems they find.
Top Database Security Vulnerability
The top database vulnerability by far is SQL injection, Sabo pointed out. For eight years SQL injection appeared at the top of a list of top security threats compiled by the Open Web Application Security Project (OWASP).
Such attacks occur when untrusted data is transmitted as part of a command or query, which tricks the system into executing unintended commands or accessing data without proper authorization. For instance, forms used on websites can be fed specially crafted code instead of normal plaintext answers (like name and address), which will cause the website to run a database query directly rather than just input the information.
10 Tips to Defend Against SQL Injection
"Mounting a viable defense against SQL injection requires a comprehensive defense-in-depth strategy," Sabo said.
This encompasses many facets:
Deploy continuous monitoring. Continuously monitor and analyze all SQL statements generated by database-connected applications to identify vulnerabilities and rogue SQL statements. Machine learning and behavioral analysis capabilities, such as DB Networks DBN-6300, can be helpful with this. "Identifying rogue SQL in the core network is the last line of defense before the database is breached," Sabo said.
Baseline database infrastructure. Create a map of all application-to-database connectivity. Unpatched and insecure applications may have been inadvertently connected to production databases offering attackers an easy opportunity.
Enforce coding best practices. Don’t concatenate dynamic SQL from external input, and use parameterized SQL in those cases when you must handle external input.
Disable unnecessary database capabilities. This prevents an attacker from using these capabilities, with particular attention paid to capabilities that escalate privileges and those that spawn command shells.
Enforce least privileges. Restrict application privileges to the minimum.
Apply patches. SQL injection vulnerabilities are regularly being identified in commercial software, so patch as soon as possible.
Conduct penetration testing. Consider regular penetration testing of database-connected applications to identify vulnerabilities that may have crept in.
Deploy perimeter security. Firewalls and IDS are a first line of SQL injection defense. Keep signature files up to date.
Suppress error messages. Attackers can discover a great deal about your architecture and operational environment through error messages. Verbose error messages should be kept local. If external messages are necessary, keep them generic.
Enforce password policies. Enforce the use of strong passwords and change the passwords of application accounts into the database on a regular basis.
Drew Robb is a freelance writer specializing in technology and engineering. Currently living in Florida, he is originally from Scotland, where he received a degree in geology and geography from the University of Strathclyde. He is the author of Server Disk Management in a Windows Environment (CRC Press).