How to test an organization’s cybersecurity risk management program

By:
Joel Lanz, CPA/CITP, CFF, CISA, CISM, CISSP, CFE
Published Date:
Mar 23, 2015

The audit committee season is now under way, and though first-quarter meetings usually focus on financial statement matters, there’s a good chance that the client’s ability to effectively mitigate cybersecurity risk will come up for discussion.

Given the surge in threats and the media attention surrounding them, cybersecurity risk is increasingly being viewed as a key business issue. More and more, boards and audit committees, whether to demonstrate regulatory compliance or to protect the company’s brand and image in the marketplace, are raising questions about an entity’s risk management programs and how extensively they’ve been tested. In addition, if your client is part of a regulated industry such as financial services or health care, for example, they will likely need to address cybersecurity testing in order to demonstrate compliance with regulatory requirements.

Unfortunately, there’s confusion about the scope of different security tests and the extent to which they can be relied upon for governance and other oversight activities, including determining compliance with contractual requirements.

This is quite understandable, since there are no generally accepted standards for performing security testing. Many times, entities can only differentiate between testing services offered by competing providers by considering the total cost or the amount of effort involved. Obviously, this is not an optimal solution for those with governance responsibilities.

Although not a generally accepted standard as in the audit sense, the National Institute of Standards and Technology (NIST) Special Publication 800-115, Technical Guide to Information Security Testing and Assessment, serves as a reputable reference within the information security community and provides guidance that government agencies should adhere to, as well as best practices for the industry in general.

Many security professionals rely on NIST publications, as they are free of commercial prejudices that may be included in other nonindependently developed methodologies. Although not subject to the same scrutiny as our profession’s auditing standards, the special publications produced by the NIST are also exposed for public comment, thereby providing some public recognition and acceptance.

The most common types of testing
There are three terms frequently associated with cybersecurity testing, and while they are often used interchangeably, they mean very different things: vulnerability assessment, penetration—or “pen”—testing and security audit. Some consultants add to the confusion by combining the terms—for example, by using the phrase “penetration assessment”—which enables them to circumvent some hard discussions about the proposed scope and the actual testing performed. Here’s a closer look at the differences between the approaches.

Vulnerability assessment

Vulnerability assessment is typically performed by employing some type of software that runs against the network. It identifies missing security patches and in some—but not all—cases, software misconfigurations. When first developed, it was commonly employed by security consultants while performing an annual review of vulnerabilities.

In the past, this technique was prohibitively expensive. As a result, it was largely just the companies with complex environments that would invest in the software and perform the testing, typically, on a quarterly basis. However, the cost of the software has declined so much that even midsized companies now invest in it in order to identify vulnerabilities on a more frequent basis, usually monthly.

Though this testing continues to be a popular component of services provided by security consultants, as it mitigates the risk of some of the most critical threats that companies face, it does have some downsides. For one, vulnerability assessment does not take into account human or social engineering lapses that are frequently cited as critical means of exploiting a system. Another criticism is that the technology staff is usually aware that this testing is occurring and can, therefore, prepare for it, which they would not be able to do if an actual hacker was trying to access technology resources.

Penetration testing

For many executives and others involved in governance, the concept of penetration testing is very appealing. Under this type of testing, the company is subjected to similar types of probes and exploitation that simulate what a hacker would actually use in order to gain access to company resources. Methods used in penetration testing are not limited to automated solutions, as is the case with vulnerability assessment. For example, testers may choose to use social engineering techniques, or procedures that are specifically geared to facilitate the disclosure of sensitive information (e.g., passwords) by users. The ability to demonstrate actual weaknesses that a hacker would exploit to the board, management or those with operational responsibilities provides a realistic incentive to quickly remediate issues. However, since the scope of a penetration test is not subject to generally accepted standards, test results, especially when a penetration did not occur, cannot always be relied upon. What’s more, because of the lack of standards, buyers of such services need to pay particular attention to the proposed scope and ensure that it addresses the needs of the organization.

Security audit

When performing a security audit, entities review all of the processes that support information security risk management. Depending on the need, the audit can be supplemented with either a vulnerability assessment or penetration testing, though the former is more likely to occur. In addition to technical considerations, the security audit also considers managerial and other governance-related activities. Frameworks such as Control Objectives for Information and Related Technology (COBIT), created by the international professional association ISACA, or standards from the International Organization for Standardization (ISO) can be used to define the engagement’s scope. Alternatively, the AICPA’s Trust Services framework can also be used as a guide to help define appropriate scoping issues.

Given resource constraints, organizations typically need to choose one type of testing rather than perform all three. Moreover, each organization faces its own particular kind of risk and, as a result, needs to decide what best suits its needs. Generally, I recommend that clients do a vulnerability assessment, if they have not done so, in order to quickly assess the state of their technical security. I then recommend a security audit in order to ensure that all processes and policies are in place, so as to reduce the risk to an acceptable level. Only after they have done everything they can to manage their security risk, do I feel that penetration testing is cost-effective and will help provide the client with a new perspective to test the effectiveness of its security strategies.

Joel Lanz, CPA/CITP, CFF, CISA, CISM, CISSP, CFE, is the sole proprietor of Joel Lanz, CPA P.C., and an adjunct professor at SUNY–College at Old Westbury. He is a member of the NYSSCPA’s Technology Assurance Committee and The CPA Journal Editorial Board.

Click here to see more of the latest news from the NYSSCPA.