With multiple industry regulations continuing to be the dreaded thorn in the side of most database administrators and security practitioners, the notion of database compliance is a significant challenge. When coupled with the growing difficulty in making a concrete distinction between data and databases, database compliance issues have created a horde of unanswered questions.
In today's networked environment, it is unheard of to create a static application, especially if that application is to have any type of business functionality. Databases not only store data, but they also have become the driving force for nearly every type of distributed application in today's enterprise and government environments. One couldn't even fathom storing large amounts of information outside of a database; even flat files formatted in a certain way are now being called databases, i.e. XML. Regardless, industry regulations now interchange data and databases. For instance, in the newest formal release of the Payment Card Industry Data Security Standard (PCI) specifies that "controls that meet all of the following conditions… provide ability to restrict access to cardholder data or databases."
It is clear that the trend is to become more detailed in the types of protections that should be required as well as to the types of "personal data." For example, the Health Insurance Portability and Accountability Act of 1996 (HIPAA) broke ground by stating that organizations must "ensure the integrity and confidentiality of the information." Little other directional guidance was provided, and in turn companies spent hundreds of millions of dollars quickly becoming compliant. In 2004, Visa and Mastercard joined forces and formed a new program, the PCI Data Security Standard. It makes a distinction on security keys whereas organizations must "store [encryption] keys securely in the fewest possible locations and forms."
Statistical fact: Regulations and policies will continue to evolve.
Question: Are you creating policies to meet the policies of today or tomorrow?
Ambiguity creates as many opportunities for "lazy" organizations as it does for ambitious companies. Innovative organizations will create and enforce policies that include combinations of technology, operational processes and staff expertise to implement effective measures, whereas "lazy" organizations will probably just acquire and quickly implement individual pieces of technology.
Every recent regulation addresses the umbrella concern of protecting personal data. California leads the personal data protection initiative in regard to state-mandated legislation. California SB1386 details that an organization must disclose when any data security breach may have compromised unencrypted personal information. Although it does not define personal information or state a specific type of cryptography, this regulation alone has built a business case for implementing column-level database encryption.
PCI v1 includes a narrative on the apparent value of database encryption without actually using the "DB" word. "Encryption is the ultimate protection mechanism because even if someone breaks through all other protection mechanisms and gains access to encrypted data, they will not be able to read the data without further breaking the encryption."
Other regulations that have touched upon protecting sensitive data include HIPAA, which aims to ensure that customer healthcare data is safeguarded. The Sarbanes-Oxley Act (SOX) aspires to ensure that all financial information is properly protected while the European Union Data Privacy Directive focuses on securing sensitive data that is transmitted over a shared network.
Due to the nature of the regulations, each will certainly be tailored to different audiences and business drivers. While Federal Information Secuity Management Act (FISMA) focuses on risk management, PCI on credit card number protection and SOX on enforcing and reporting upon controls, universal compliance can be achieved through six straight forward steps.
- Ensure user and developer database compliance policies are in place.
- Design and implement a hardened configuration baseline a.k.a. "gold standard" for the selected database platform (Oracle, MS SQL, MySQL, etc).
- Encrypt all sensitive, customer and internal data with AES. Encrypt all communication links with SSLv3 or TLS.
- Implement an annual security review and testing program.
- Monitor for database intrusions and authenticated misuse.
- Automate system maintenance, user auditing, and log storage.
Audit points will change along with new technologies and firm interpretations; however, the goal for any successful database security program and subsequent compliance initiatives will remain the same. Automate policy enforcement and reporting where possible and keep a steady focus on what's at risk now while creating a framework that is as comprehensive as it is adaptable.
About the author
James C. Foster runs a software security practice for a large private firm near Washington D.C. He has authored more than 20 books, including Buffer Overflow Attacks and Writing Security Tools and Exploits.
