Don't Panic
Addressing the caveats of regulatory compliance is like approaching any other risk. We will look at the risk and then we will develop a plan to mitigate the risk. Sounds simple, right? Good, because it really is as long as we know what we need to do. Yes, there are serious consequences for non-compliance but in the words of Douglas Adams, “Don’t Panic!” So, grab your towel and we will find our way.
What these regulatory statutes require is having business processes in place that address operations policy, security policy, and regular audit data that supports that your actions. The key is that we have controls in place that eliminate the chance for mistakes or allowing malicious actions. We need to align the specific actions that are associated with the different regulatory statutes and then we can map these into our IT security and privacy framework. There is that framework thing again.
There are several auditing frameworks out there but the most well known is COBIT or Control Objectives for Information and related Technology. COBIT provides a clear and easy to follow framework that fits nicely into the ITIL framework. And Microsoft’s Operational Framework is based on ITIL. It is pretty easy then to create a set of processes to address the compliance caveats. Another neat thing that COBIT does is it gives us a rating system that we can use to measure our effectiveness. These metrics can then be used to create our IT security and privacy scorecard.
There are benefits to identifying Control Objectives for your IT organization. The first benefit is that auditors like automated processes, so you can identify all the inefficient manual processes that are in place in your enterprise and get your management’s buy in to replace these with automated processes. Whether it is provisioning users, creating standard system builds, or just establishing a central repository for log files this is your opportunity to automate. Sure this is going to cost money but the value proposition is that you will be more compliant. You should now feel empowered to go after these as long as they fit the IT control and privacy policy.
This should also help you standardize your systems hardware because to lower the number of standard builds you are responsible for to control costs the fewer number of builds you will need. While this creates its own set of concerns your life just got better and you lowered your stress level. Something else a standard build allows you to do is to lower your help desk costs by allowing you to establish a policy of imaging a system after an unsuccessful attempt to correct a problem. Have the user save their data off of the target machine, re-image the box, restore the users data and you are done. The users can get back to work quickly. But you are already doing that, right?
Back to Control Objectives, this term describes the effort to fulfill a regulatory requirement. Several regulations may require you to control and report for the same thing, such as defining how to control your desktops. Inside this objective might be strategies to satisfy several independent requirements. If you actually enjoy the pain you are welcome to read each regulation but you can take it from, me there is a lot of overlap. Inside these objectives we will satisfy questions like who will have access, what information is needed to perform the task, and is the user’s machine compliant. Now we can start to think about the control solutions we can establish to address these questions.
A couple of weeks ago, Joe Scalone did a really good job of pointing out which Microsoft technologies can be used to address the requirements that would come from creating a Control Objective. The technology solution defines how we will use the technology to satisfy the requirement. This becomes the process that we need to fulfill the caveats of our IT control and privacy policies. These automated processes are what we use to demonstrate to the auditors that we are meeting the caveats of the requirements that are in each regulation.
So Regulatory Compliance is security management, operational precision, and a good measure of common sense in developing these processes. If you were worried about trying to make sense of all of this, I don’t think that you should spend your time reading the text and interpretations of Sarbanes Oxley. Instead you should spend your time reading about COBIT and some of the other auditory and operational frameworks. Building a framework for your IT operations is more valuable than trying to determine what requirements you will have to meet for a single regulation. I have included a few links below to help. You can also use the MSN Search to find more. .
COBIT
Mark Eden