AKIBIA'S PRACTICAL GUIDE TO ENTERPRISE TECHNOLOGY
Friday, May 28, 2010
Compliance and Security Go Hand in Hand – How to Achieve Both
The buzzword “Compliance” has now overshadowed many of the previous popular terms in security discussions. Many equate “compliance” with “security,” but recent literature abounds with titles such as “Compliant Does Not Mean Secure” and “Information Assurance: The Difference between Secure and Compliant.” These articles make the case that it is possible to be compliant yet not secure. Most discussions focus on payment card industry (PCI) security, because of the high value of the data involved, the stringency of the compliance standards, and recent security breaches of major players. It is also useful for illustration purposes, since the typical PCI technical environment is usually confined, and the standards are very specific. However, it is important to expand the discussion beyond one security standard, especially since others are more comprehensive, although less specific.
State and Federal laws mandating security are mostly in general terms and often open to interpretation. As an example, new state data privacy laws, such as those of Massachusetts and Nevada, specify that personal data must be protected by the implementation of a formal security program with documentation, individually-assigned responsibility, physical and technical controls to prevent unauthorized access to or theft of personal data, and encryption of the data when it is stored on portable media or devices. An organization can meet all of items specified to comply with the letter of the statute and may even be able to “pass’ a third-party audit. However, if certain security practices are omitted, like prohibiting users from removing encryption software, the data will not be secure. On the other hand, a very secure environment may miss the mark on compliance by omitting one or more documentation, testing, or training requirements.
Another example of being compliant but not secure will be familiar to many who perform technical security testing. A certain financial organization must undergo a government audit on an annual basis. When the security testing required by this audit was discussed and the requirements set, the testing of a particular segment was deliberately and conspicuously omitted. The IT director indicated that not only was this testing not desired, that the vendor should not include any recommendations regarding it in the report. The reason for this position became clear in the project delivery meeting where one of the organization’s staff members stated that it was important not to include an item that auditors did not request; otherwise the auditors would require it the following year and on an ongoing basis. The security implications of this position should be clear.
It is easy for a security product and service company to recommend an all-encompassing array of products and services to meet every possible compliance standard and eliminate almost all risk, but it is not so easy to implement, maintain, or pay for everything. So, how does an organization achieve compliance, satisfy auditors, and become and remain secure? The answer is to build a comprehensive security program that includes as a subset the necessary compliance standards and audit requirements. Starting with a compliance standard and building a security program around it is not efficient, since the longevity and the scalability of such a security program is questionable at best. Instead, employ a proactive approach that identifies sensitive assets (data and systems) and risk, and then develop a comprehensive program to secure those assets. Evaluate the comprehensive security program to determine whether any additional measures need to be included to observe applicable compliance standards. Using that approach, new or changing compliance standards should be easy to incorporate. You can be both compliant and secure without excessive effort and expense.
