Achieving a stable and secure IT environment can be accomplished in a number of ways but at the core, you need a framework that helps to guide you in decision making and helping to set priorities. There are two words that go hand in hand as part of defining this kind of framework: compliance and standards.
Standards provide a well documented way to review your business environment within a particular context and compliance is the act of having proven that you have met the requirements as set out by a particular standard. Let’s grapple with the issues of compliance and standards and use two very well-known standards in PCI and ISO: specifically PCI DSS and ISO 27002.
The PCI Data Security Standard (PCI DSS) consists of 12 mandatory high-level requirements for all organizations that store, transmit, or process payment cards. ISO 27002, also known as ISO 17799, is a security standard of practice. It has 12 different sections that provide best practice recommendations on information security management.
At a high level one might come to the conclusion that you would either use one or the other. In practice, and running your business for the long-term, it would be better to think about using both as the use of one will help with the other. They, as it turns out, have a natural tendency to reinforce good security decisions across each other while at the same time leading to the desired state of being compliant in a specific one. ISO provides a good over-arching security framework while PCI details the expectations to ensure that critical customer information is handled correctly (for the specific purpose of dealing with credit card information).
We believe that the best way to deal with these standards is to adopt a lifecycle approach and remember that the process is something that will be iterated many times: education, assessment, and remediation. A good way to do that is to think of this as a 3-part cycle.
In the first part of the cycle you are trying to educate. Go through the high level sections of each section and try to come to consensus on what each of the them mean to your business and talk about how you deal with them now. This can be achieved in a small amount of time and helps to crystallize your thoughts and to get you all on the “same page” for the more detailed analysis to follow.
In the second part of the cycle you actually perform an assessment: you walk through all of the control requirements and specifically note if you are compliant partially compliant, non-compliant, or not applicable to your business. In those areas where you are deficient, you note what needs to change to get you to a compliant state.
In the last part of the cycle, after you have had time to make changes to those controls that were not in full compliance, you review the remediation steps that have been taken and decide if you are now in the desired state.
The process of going through this cycle will not only educate your organization on where you stand, but give you opportunity to think about each requirement or control objective not only on a one-by-one basis, but also as a whole. You’ll understand what you are doing well, what you are doing poorly, and most importantly, what you are not yet doing at all.
Brad Johnson is Vice President of SystemExperts Corporation and has been a leader of the company since 1995. He has participated in seminal industry initiatives including the Open Software Foundation (OSF), X/Open, the IETF, and has published many articles on open systems, Internet security, security architecture, ethical hacking and web application security.