Taking a Risk-Based Approach to Pen Testing

Risk management is one of the most important parts of an organization’s path to information security. Cyberrisk professionals are likely familiar with the more classic methods of risk assessment, which are typically documented on Microsoft Excel sheets and performed once a year. This approach may be considered acceptable from a compliance and audit perspective, but it is not enough to manage risk comprehensively (or necessarily correctly).

Optimal risk management processes should address all potential sources of risk (figure 1), unlike the traditional approach, which relies primarily on data obtained from interviews. The contents of threat and vulnerability reports should be assessed and treated as possible sources of organizational risk. Security incidents may be used as indicators to identify root causes of risk. Deficiencies and incidents of noncompliance documented in various audit reports (e.g., legal compliance, standard certification) can also inform risk-mitigating actions. The results of penetration (pen) tests are also worth examining using a risk-based approach.

FAQs on Pen Test Results

A pen test report contains the identified vulnerabilities for which a technical severity can be calculated. Additionally, testers can provide guidance for risk assessment (based on the type of data affected) and an associated classification, ideally based on a well-defined methodology. But this is not a traditional risk assessment based on business impact, rather, it is an estimation based on the limited information available to the pen testers. The scoring methodology of such an external assessment does not calculate the harm caused by exploitation, which results in increased risk of processes being affected. This means that a vulnerability classified as critical could present a lower level of risk based on the business impact of possible damages or compensating controls built into the affected business processes, which could also decrease the probability of the risk occurring. For example, pen testers could gain unauthorized read-only access to all data in the system being tested using general and easy-to-perform attack methods, but the affected information could not be interpreted by itself, decreasing the impact. Alternatively, a potential attacker could easily cause a system shutdown, but the outage of the affected processes would result in a lower level of damage, leading to a lower—or possibly an acceptable—level of risk to the enterprise.

Cyberrisk professionals often receive questions about such topics. It is important to answer them, dispel doubts and support information security managers to find the most suitable methods to address pen test findings.

It is important to answer [questions], dispel doubts and support information security managers to find the most suitable methods to address pen test findings.

There are a number of frequently asked questions (FAQ) that cyberrisk professionals may encounter. Those questions and their corresponding answers include:

• “Do we have to fix all of the problems identified by the pen test findings?”—Not necessarily. To define risk response methods and mitigating actions and prioritize countermeasures, the organization should assess the business impact of the identified vulnerabilities and evaluate the risk. If findings are deemed acceptable based on risk assessment results, management may decide to accept the risk and determine that no corrective action is needed.
• “If we fix everything, then there can be no more problems, right?”—No. Each type of audit gives only a snapshot of the investigated organization or system. There are no guarantees that other types of attacks and vulnerabilities will not appear later, especially in case of environmental changes, developments or upgrades. As such, pen testing should be performed routinely, and it is recommended to perform an additional audit after corrections have been made in case of major changes in the system. When tests are performed with limited information, it is also important to identify and treat the root causes of the findings to eliminate whole classes of vulnerabilities in the long term.
• “Could we reclassify the level of risk for this finding to critical/low?”—Pen test reports contain the classification of the findings according to the methodology used by the experts who performed the audit. As mentioned, these statements do not fully evaluate risk and business impacts, and usually a complete risk assessment is not part of pen testing. It is advisable to either extend the project with externally supported risk assessment or internally evaluate the findings and complement the original results with the modified classification (as presumably is the case for other vulnerability reports). So, it is not a problem to assess that a medium-risk finding is critical, or vice versa, but it should be documented separately, not in the original pen test report, and based on appropriate assessment.
• “Could this result not appear in the report at all?”—No. Audit reports should contain all factual statements and findings. If there is any reason to mitigate or modify the results, experts can insert them into the documentation, but deleting statements is unprofessional and later it can even be disadvantageous (e.g., if environmental changes take place).
• “Is this result an acceptable level of risk? Could we accept all the findings?”—If the risk is deemed acceptable by the organization, yes, but pen tests do not include a complete risk evaluation or investigation of business impact. To decide whether to accept a level of risk, the previously mentioned analysis should be performed and the reason for the decision should be confirmed. Accepting risk without knowing the business impact can lead to serious damages (e.g., if an unpatched vulnerability is exploited, attackers can harm the confidentiality, integrity and availability [CIA] of affected data).
• “How do we compare to other organizations? How do other organizations handle report findings?”—Every organization is different, so similar pen test results may present different levels of risk—and, consequently, different risk treatment methods. Risk tolerance (i.e., the organization’s readiness to bear the risk after risk treatment to achieve its objectives)¹ and risk appetite (i.e., the types and amount of risk, on a broad level, an organization is willing to accept in its pursuit of value)² can also influence risk management decisions, so there is no universal correct answer to these questions. It is advisable to evaluate the business risk of the findings and take responsibility for the decision based on the results of the assessments, rather than imitating other enterprises with different risk profiles.

Converting Pen Test Results to Information Security Risk

The steps of risk assessment are risk identification, analysis, evaluation and treatment.³ As revealed by the FAQs listed, business impact analysis, risk identification and evaluation are also critical to pen tests. Organizations should have a business impact analysis or (preliminary) risk assessment process in place to identify their critical resources, namely, the information systems to be investigated by pen tests (figure 2). Risk identification includes classification of data and assets that need protection, followed by identifying and describing the vulnerabilities and threats that pose a risk to each.⁴ If an organization does not have any supportive tools, initial points of access (e.g., perimeter systems, internal workstations) are generally good first targets of initial pen tests. It should be noted that without identifying the crown jewels (i.e., the organization’s most important assets), substantial vulnerabilities and risk will not be identified and assessed, so proper risk assessment remains crucial.

Another oft-missed step is the risk evaluation phase, during which assessment results are compared to the organization’s risk profile.⁵ In the case of pen tests, this may also mean reassessing the risk of the findings according to their business impacts. If findings of pen tests are not evaluated, an organization is left not knowing when the identified vulnerability was exploited or what damage may have been caused. In the absence of risk evaluation, the reduction of risk posed by the pen test findings could not be performed effectively and in a (cost-)efficient way. Typically, easy-to-fix and low-cost vulnerabilities are prioritized, which would not be a problem, if it did not hinder addressing more complex (and usually higher risk) findings. Unfortunately, dealing with many low-risk issues can quickly deplete precious resources.

Because of these problems, applying risk assessment methods to pen tests is recommended to determine targeted systems and evaluate risk areas of the findings. These steps support the making of informed decisions about risk treatment opportunities and the defining of effective risk response actions.

Conclusion

Pen testing is a critical part of risk assessment. Testing results explore and technologically evaluate vulnerabilities, but only an organization can assess the business impacts of its organizational risk. To determine an effective and efficient response to report findings, cyberrisk professionals must assess the entire business risk of the identified vulnerabilities when planning risk mitigation.

Endnotes

¹ Stine, K.; S. Quinn; G. Witte; R. K. Gardner; NISTIR 8286: Integrating Cybersecurity and Enterprise Risk Management (ERM), National Institute of Standards and Technology, USA, 2020
² Ibid.
³ Deane, A.; A. Kraus; The Official (ISC)² CISSP CBK Reference, 6^th Edition, USA, 2021
⁴ Ibid.
⁵ Ibid.

Eszter Diána Oroszi, CISA, CRISC, CISM, ISO 27001 LA

Is head of the Information Security Compliance Consulting department at an information security consulting company based in Hungary. She has 14 years of experience in the field of information security, with a special interest in human-based attacks, social engineering audits and security awareness improvement using gamification. She is also a lead consultant of risk management and business continuity projects, and she often works with members of the ethical hacking department to identify risk areas to help clients scope pen tests and support the selection of the most suitable risk response method for the identified vulnerabilities.