Most organizations that fall under the shadow of government and industry regulations have established an internal mechanism to deal with the requirements. Banks, healthcare and companies conducting online credit card transactions are the most diligent. So how can security consultants assist these organizations with their regulatory compliance efforts? Is there a checklist you can follow to assess an organization's state of compliance? It's not that easy.
Regulations can be divided into two broad categories: Those that have explicated information security requirements and those that do not. Some regulations state in general terms that information of certain types must be protected, but the regulations do not stipulate how. Government regulations tend to be general. For example, HIPAA[1] for health care, SOX[2] for publicly traded companies and GLB[3] for financial organizations fall under this category. Other regulations provide checklists of explicit technologies and security controls that are required for an organization to be compliant. PCI/CIP[4] for Visa and MasterCard, NERC[5] for the electrical utilities and FISMA [6] for the government, address specific security and auditing controls that are detailed in checklists.
Government regulations are based around broader reaching goals, with information security a part of a means to the end but not the entire focus. These regulations want to see that an organization is making a reasonable effort to protect its information, but to do so the regulations rely on a secondary standard. ISO/IEC 17799:2005 Information technology - Security techniques - Code of practice for information security management [7] is a perfect standard to satisfy the secondary requirements of the general regulations like HIPAA, SOX and GLB. These engagements tend to have:
Interviews of key personnel
Review of IT operational procedures
Review of information security policy and procedures
Review of technical security controls
Review of HR procedures
Review of network topology
Review of business continuity and disaster recovery policies and procedures
Review of physical security controls
The deliverable is a detailed report of findings that provide a matrix-based gap analysis of the results compared against the ISO standard selected, which in turn, if the auditors agree, satisfy the information security requirements of the regulations. Before you jump into the project, always discuss the deliverable with the customer's auditors. They are the end consumers of your report. If you cannot speak to the auditors, ask to review the last audit report and get an understanding of the auditors' interpretation of the problem areas and how they would fix them.
Other regulations, like PCI/CIP, NERC and FISMA, are much more technology focused. They call for explicit configurations, technologies and controls. They come with checklists that spell out the standards of compliance for each sub-section of the larger rules. In many ways these engagements are cleaner. You don't have to do much interpreting of the requirements. However, I have run into situations that need some clarification. It is good to find an insider within the regulator organization that can give you advice. The deliverable, again, is a detailed report of findings that provide a matrix-based gap analysis of the results compared against the regulation. Use the checklists provided.
At the end of the day, regulations that define information security standards have an underlying goal: make an organization place appropriate resources and effort toward maintaining a reasonably secure network to protect sensitive information. The rules exist because organizations were not taking care of this on their own. Without the rules, sadly, many organizations that should insist on due diligence, would not to save money and headaches. Approach a compliance engagement with the underlying goal in mind. Compare them against a secondary standard like ISO 17799 or the checklist. Write a report. Try to find the root cause of problems, and all will be well.
Footnotes
