With increasingly sophisticated attacks and rising internal data theft, database security merits a strong focus...
among enterprise information security teams that goes beyond traditional authentication, authorization and access control.
A single intrusion that compromises private data, such as credit card numbers or financial data, can cause immense damage to an organization, not to mention lawsuits and regulatory fines that can have long lasting ramifications. Forrester Research Inc. advises organizations to revisit their database security strategies and look for gaps where the application of new security features and functionality may be necessary to help protect databases against new threats.
The key to any successful database security policy is knowing why you're protecting each database, which databases to protect, and how to best secure data against all types of threats keeping various compliance regulations -- such as SOX, HIPAA, PCI DSS, GLBA and European Union directives -- in mind. In recent research, Forrester recommends that enterprises build a comprehensive database security strategy on the following three pillars:
- Build a strong foundation with authentication, authorization, access control, discovery and classification, and patch management.
Understanding which databases contain sensitive data is a fundamental requirement for any database security strategy. Enterprises should take a complete and ongoing inventory of all databases, including production and nonproduction, and classify them into categories that should observe the same security policies. All databases, especially ones that hold private data, should have strong authentication, authorization and access control, even if the application tier does authentication and authorization. The lack of a strong foundation with these concepts weakens other security measures such as auditing, monitoring and encryption.
In addition, patch all critical databases at least semi-annually, if not quarterly, to eliminate known vulnerabilities. Investigate rolling patch or clustering products from database management systems (DBMS) vendors and other vendors to minimize database downtime when applying patches. Always test the security patches in test environments, running regular test scripts to ensure the patches don't affect application functionality or performance.
- Take preventative measures with data masking, encryption and change management.
After establishing a solid, foundational database security policy, it's time to take preventative measures to secure critical databases. This means providing an added layer of protection for both production and nonproduction databases. Data privacy does not stop with production systems; it needs to extend to nonproduction environments too, including test, development, quality assurance (QA), staging and training instances, essentially wherever private data could reside. Database security professionals should evaluate the use of data masking and test-data generation to protect private data in test environments or when outsourcing application development.
Consider using network encryption to prevent data exposure to prying eyes that might be snooping on network traffic, or data-at-rest encryption, which focuses on data stored in the database. As they address different threats, these encryption approaches can be implemented independent of each other. Usually, neither has an effect on application functionality.
Also seek to protect critical database structures by following formalized change management procedures. In the past, scheme or other database changes in the production environment required a database shutdown, but new DBMS releases allow many such changes while the database is online, creating a new security risk. A formalized change management procedure ensures that administrators change production databases only after approval from management and that they track all changes. Organizations should also update their recovery and availability plans to deal with the new contingency of data or metadata corruption that such changes bring.
- Establish database intrusion detection with auditing, monitoring and vulnerability assessment.
Whenever critical data changes unexpectedly or suspicious data access activity is discovered, it is imperative that the organization launches a quick investigation to determine what happened. Data and metadata in databases can be accessed, changed or even deleted in a matter of seconds. Database auditing provides the ability to answer tough questions such as, "Who changed what data?" and "When was it changed?" To support regulatory compliance standards such as those mentioned earlier, security and risk management professionals should track all access and changes to private data such as credit card numbers, Social Security numbers, and names and addresses for critical databases. If private data was changed or accessed without appropriate authorization, organizations should seek accountability from the person responsible. Lastly, a vulnerability assessment report can be used to identify security gaps in a database environment, such as weak passwords or excessive access privileges, supplementing DBA and security group monitoring.
Don't forget security policies, standards, role separation and availability.
Database security strategy is not only about auditing and monitoring, it's also an end-to-end set of processes that focuses on minimizing risk, meeting regulatory compliance requirements and defending against internal and external attacks. Database security needs a broader focus that fills security gaps, works with common policies, and formalizes security approaches. When crafting your strategy, look to align database security policies with information security policies, focus on industry security standards, enforce role separation, and clearly articulate recovery and data availability procedures.
About the author:
Noel Yuhanna is a principal analyst at Forrester Research, where he serves application development and delivery professionals. He will speak at Forrester's Business Process and Application Delivery Forum 2010, October 7-8, in Washington, D.C.