Database security: Who should have access?
The only users who should be allowed full access to any data store should be your system administrators. What about everybody else?
As options have increased for midmarket companies to house their data, so, too, have options for securing their...
Continue Reading This Article
Enjoy this article as well as all of our content, including E-Guides, news, tips and more.
databases and data stores. Once the preserve of only large companies, a range of data storage options are now available and within reach of companies of all sizes.
Databases are rarely seen by users and are usually hidden behind the scenes as part of inaccessible back-end systems. Yet they're the unsung heroes of applications, particularly Web applications, where they're at the heart of what makes most websites dynamic. Without them, modern e-commerce wouldn't be possible.
Protection of data in databases and other stores is also part of compliance with regulations such as the Sarbanes-Oxley, Gramm-Leach Bliley and Health Insurance Portability and Accountability acts, and industry guidelines like the Payment Card Industry (PCI) Data Security Standard.
Access control is key
The pillars of database and data storage security are access control, encryption, monitoring and configuration or architecture. For midmarket companies, this boils down to two things: a combination of best practices and security tools. Most database and data storage products have some sort of built-in security tools, but other tools can be added, as needed, to enhance security.
Access control is fundamental. In general, the only system administrators should be allowed full access to any data store. They need full access to add user accounts and maintain systems.
Other users should be granted access based on the principle of least privilege, meaning allowed access to only the data they need for their job functions and nothing more. They shouldn't have full run of the database, and write access -- the ability to add, change or delete data -- should be restricted on the same principle. For most users, read access may be sufficient.
Although user accounts can be added to databases for access, ideally access should be controlled through your existing identity and access management platform. That means tying user access to profiles in Active Directory , Lightweight Directory Access Protocol (LDAP) or whatever directory service you use.
Highly selective access
Access to mass data storage used for backups and disaster recovery should be even more restricted, since these stores aren't used for routine day-to-day work. Access should be through only a single interface that transmits data automatically from your systems and not from individual users.
More on database security
PCI compliance without costly consultants
Risk assessment frameworks easy to employ
Customer-facing websites should never have direct access to any company database. Access should be through only the middle tier of the Web application, and then only through a guest account with limited access. Don't use the default "sa" account built into most databases, which has powerful administrative privileges. Create a special limited account and put its user ID and password in server-side property files that are inaccessible from the website. Such user IDs and passwords should never be hard coded into the application where they can be found by hackers' prying eyes.
An inside job
Another concern with database access is malicious use by your own employees, the so-called insider threat. This is where monitoring comes in. All access to databases and other data storage should be logged to determine who accessed the stores and what they accessed. One such tool is StrongBox DBProtector from Crossroads Systems Inc. DBProtector is a network appliance that checks every SQL request to the database and provides alerts of malicious activity.
Another product that provides both access control and logging facilities is DataFort from Decru. DataFort meshes with Active Directory and LDAP to restrict access and can use smart cards to provide even further protection for back-end data storage.
SecureSphere Database Security Gateway from Imperva Inc. is another leading product for monitoring access to databases. SecureSphere is part of a suite from Imperva that also includes its well-known Web application firewall, a natural fit since websites and applications are frequently sources of malicious access to databases. SecureSphere works through user profiling and vulnerability assessments of databases.
Guardium Inc. offers a software suite for protecting databases and back-end data stores. It also integrates access controls, auditing, logging and monitoring. The product works with other appliances, like DataFort, to provide encryption.
Of course, besides these specialized tools, traditional firewall logging and intrusion detection systems can also be used for monitoring database access. Though crude and not as thorough as other tools, they may do the trick for cash-strapped midmarket companies.
Compliance escalates risk
The next big issue is encryption, which, like access controls, is a compliance issue. Under PCI, for example, credit card information must be stored encrypted. The standard is clear on this point.
Here, again, there are a number of tools available for the midmarket. But before embarking on a costly encryption program, make sure to do a thorough risk analysis of the data being stored. Is it sensitive customer data that, if exposed, could open the company to regulatory violations, legal liability or the theft of customer identities? Or is it marketing data used for sales modeling that can't be traced back to individual customers? The first will require encryption. The second just standard security procedures like database hardening and access controls.
Ideally, as part of your security program, higher-risk data should be segregated so it can be given a correspondingly higher level of protection. A tiered storage approach can avoid putting costly controls on systems with mixed high- and low-risk data, just to protect the high-risk data.
For back-end data storage in particular, the key is to encrypt data in transit to the data store. This could be done through an encrypted channel, such as a virtual private network. In this area, DataFort again offers a product geared toward the midmarket.
Another product from CipherMax Inc. uses a high-speed encryption engine at 256 bits for both storage area network management and encryption in one appliance. The Sentio HD 8000 series from Revinetix Inc. also has encryption capabilities with built-in network-attached storage capabilities.
Besides tools, midmarket companies can also follow basic rules for architecting their systems to protect data storage assets.
First, make sure all databases and stores are behind a firewall. That sounds obvious, but that means behind the inner firewall of your demilitarized zone (DMZ). Databases should never be inside a DMZ, where they're more exposed to malicious attacks from the Internet.
Second, where possible, don't double up your databases on servers. If it's in the budget, each database should be on its own server, where it can be protected based on the risk level of its data.
Third, in Web applications make sure developers add code to filter and sanitize all user input. This is meant to prevent SQL injection attacks, which can allow malicious access to a database. In addition to secure Web coding practices, like those in the Open Web Application Security Project, a Web application firewall that blocks SQL and other injection attacks might be in order.
With these range of options, a midmarket company should have no problem securing its databases and back-end data stores. It just has to determine what data it has, where it resides and its risk level.
About the author:
Joel Dubin, CISSP, is an independent computer security consultant. He is a Microsoft MVP specializing in Web and application security, and is the author of The Little Black Book of Computer Security, Second Edition, available from Amazon.com. He hosts a radio show on computer security on WIIT in Chicago and runs The IT Security Guy blog at www.theitsecurityguy.com.