Problem solve Get help with specific problems with your technologies, process and projects.

The security consultant's role in regulatory compliance

This tip explains how to identify the root cause of security issues by comparing your customer's security practices with established standards, and offers tips for channel professionals on keeping regulatory compliance auditors happy.

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.


    [1]Health Insurance Portability and Accountability Act

    [2]Sarbanes-Oxley Act of 2002 (Pub. L. No. 107-204, 116 Stat. 745, also known as the Public Company Accounting Reform and Investor Protection Act of 2002)

    [3]Gramm-Leach-Bliley Act, also known as the Gramm-Leach-Bliley Financial Services Modernization Act, Pub. L. No. 106-102, 113 Stat. 1338

    [4]Payment Card Industry Data Security Standards

    [5]North American Electric Reliability Council

    [6]Federal Information Security Management Act of 2002 ("FISMA", 44 U.S.C. § 3541, et seq.) is a United States federal law enacted in 2002 as Title III of the E-Government Act of 2002 (Pub.L. 107-347, 116 Stat. 2899).


    About the author
    Adam Rice is a Manager at VeriSign's Global Security Consulting. VeriSign's Global Security Consulting Services help Fortune 500 companies understand corporate security requirements, navigate the maze of diverse regulations, identify security vulnerabilities, defend against and respond to attacks, reduce risk, and meet the security compliance requirements of your business and industry. Adam has authored several white papers and technical articles on security professional services and emerging threats to the Internet community. He has an extensive background working in security professional services product development and business delivery.

    Dig Deeper on Regulatory compliance with cybersecurity laws and regulations

    Start the conversation

    Send me notifications when other members comment.

    Please create a username to comment.