Having a safe doesn’t do much good if it is left open. Yet the safe where organizations house their data is sometimes left just as unsecure.
Last year for example, it was revealed that a university system upgrade at the University of North Carolina-Charlotte exposed data on the university’s H: drive on the Internet between Nov. 9, 2011, and Jan. 31, 2012. The news got worse for the university when it was discovered that misconfigured access settings also exposed sensitive data from the school’s College of Engineering from 1997 to February 2012.
“DBAs [database administrators] don’t have time for security – they spend less than five percent of their time on it,” said Forrester Research analyst Noel Yuhanna. “Most enterprises are dealing with data explosion that’s creating performance issues and availability concerns, which is where most of their time an effort goes. In a survey we did last year, performance was the top concern.”
Approaching database security the right way is about more than just persistent data security – it also means properly defining database access policies, ensuring the database’s security controls are correctly configured, audited and enforced.
“Databases are strange beasts,” said Barry Shteiman, senior strategist at Imperva. “They have many different flavors, and so vendors implement similar ideas in different ways and name similar concepts differently. One of the biggest challenges in managing rights and permissions is the need for overarching policies that encompass all of these different types of databases. Consolidation in permission and privilege visibility is the key for success.”
On its list of top 10 database threats for 2013, Imperva ranked excessive and unused privileges and privileges abuse as the top two. Access controls should be checked as often as possible and reviewed against a baseline, Shteiman said.
“One needs to understand that a single database instance could have thousands of users, permission groups, derived rights, and access methods that keep changing, and are very difficult to control,” he explained. “However, organizations that go through a process of creating a baseline of wanted and required access control and implement tools, are able to check the actual access configuration against a baseline, making their lives easier and enabling them to control the privileges from a better visibility standpoint.”
“In regards to enforcement of audit and security rules and permissions, separation of duties and aggregation are recommended when possible,” he said. “Letting the cat guard the milk is known to be a bad security practice.”
Most times, organizations of all sizes install the database servers on the same segment as the application servers, which can cause a major security issue, noted David Maman, CTO of database security firm GreenSQL.
“Separation between the segments should be firewalled,” he said. “With today’s firewall technology, a 2U firewall can support millions of concurrent sessions and close to 100GB per second traffic. There are no limitations to the traffic, and there’s no overhead for internal segmentation.”
Database administrators should also never have the option to get sensitive information from the database, just as application developers, quality assurance or IT teams should never have the ability to run any type of administrative commands on the database, he added.
“In recent reports we have seen how APT [advanced persistent threat] and generic malware is used to infiltrate organizations and steal their data,” said Shteiman. “Such risks need to be taken into account when companies build their database security plan. If a DBA’s computer is being compromised, it is very simple to get to the database itself using the DBA’s credentials, leaving the keys to the kingdom out in the open. Therefore controlling and auditing data access both in the malware infection scenario, and out of plain business logic – a DBA logs in at 2 a.m. and requests 1 million records from the database – is important.”
“The sad truth,” he added, “is that for many of the organizations, the last question asked is ‘so what data should we protect’ or ‘are we auditing a subset of our overall data or everything.’ When regulations and security policies mandate ‘protect your sensitive information’ they don’t define the sensitive data, because it is subject/company/business specific.”
“A key point in securing and auditing databases is understanding what should raise a red flag,” he said. “Classification of your assets is an important and sometimes overlooked step.”
Related Reading: Proving Compliance and the Case for Improving Database Security
Related Reading: SIEM, Database Security Top of Mind for IT Professionals
