Editor's Note: At the intersection of cutting-edge security needs and the new territory of migration environments lay security regulations. HP 3000 managers might not be familiar with any process that goes beyond HIPAA, Sarbanes-Oxley or PCI credit card demands. (Although that sounds like a pretty big list anyway.) As a result of his job advising the clients of Oxygen Finance, security expert Steven Hardwick has taken us through the steps of responding to security regulation requests -- and proving your system's compliance.
By Steven Hardwick
Third in a series
In many cases, a compliance audit is viewed like a bad case of the flu. While it is ongoing it is miserable and many wish it would end. Once over, everyone is happy it is behind them. Fortunately, like the flu, precautions can be taken to help make the event a lot less traumatic and uncomfortable.
A request to comply to a specific regulations can be daunting. The major challenge is that the regulations are written by security specialists and for security specialists. To make matters worse, the regulations themselves may not be overly specific in the exact response required.
One of the first steps is to understand which data set is covered by the regulation. As outlined in our second article, a regulation is directed to a specific set of information: PCI = credit card data, for example. It is very important to identify the people, systems and environments that deal with the data in question. This will give an indication of the minimum scope of the regulations.
Minimum? Well, one advantage of a regulation is that it is compiled from security specialists. Although the full measure of the regulation applies to specific data sets, there is no reason that elements of the requirements can't be used for other data sets. In fact, it may be easier to apply the certain requirement to all data in a certain system; encryption is a good example.
The next step is to try and categorize the requirements against the security controls they relate to. The goal of a regulation is to look at a wide variety of ways information can be compromised. This will break down into the physical, technical and administrative groups (which we covered in our first article). Doing this, you can make an alignment with the owner of the area that's affected.
Finally, determine who should be the final decision maker when it comes to defining how well the regulation has been met. Compliance is an exercise in measuring the security environment against an approved set of requirements. One constant challenge is what to do if the environment does not meet the standard. This exposes a risk to the organization. You must decide to either address the risk (mitigate it), transfer the risk (buy insurance) or accept it (do not mitigate). Since senior management is responsible for assessing the risk to the corporation, they must be part of the decision-making when it comes to compliance. Especially mitigating any gaps found during the compliance assessment.
By the way, “doing nothing” equals accepting the risk.
Another approach is to conduct an internal assessment that is not based on a set of regulations to establish a baseline. This assessment can be simple, but very effective in finding the more obvious gaps in a security infrastructure. It also has an advantage that any mitigation can be carried out at a pace set by the organization instead of reacting to a compliance deadline. Furthermore, the scope can be set to encompass all data within the corporation.
For example, I have seen data covered by a regulation that was well protected, while other data, such as intellectual property, had little to no protection. Very often there is a misconception that being compliant equals being secure. A comprehensive and free resource on how to conduct an assessment is the NIST SP800-30 Guide to Conducting Risk Assessments.
Using a security framework is another useful approach. One major challenge is the need to comply with multiple regulations. A security framework will help establish a general set of security requirements. Each pertinent regulation can then be stacked up against the framework and the commonalities identified. This will minimize the amount of effort and cost associated with the compliance effort.
A good example of this type of tool is the security matrix from the Cloud Security Alliance. Although targeted to cloud services providers, it can provide a good starting point to making a tool to handle multiple compliance requirements. One added benefit of choosing a framework: it will break down the controls into the various control categories, making it easier to identify the owner.
Next time: 10 Simple Steps to make the process of compliance easier