Performance-based GRC (Governance, Risk and Compliance)




If you can't see what lies ahead ...

Walking blindfolded off cliff into sharks

In the past, governments and regulatory organizations delivered risk assessment rules that focused on compliance with long lists of cyber controls. Such approaches hoped that, if organizations would simply deploy the latest cybersecurity tools that intrusions would be reduced. No doubt these tools provided some beneficial results, but it is undeniable that the number of comprises (and the severity of the incidents) continues to increase.

Regulatory organizations are beginning to understand this and there appears to be a trend towards performance-based (or results-based) risk assessments. In other words, newer regulations are less focused on prescribing the exact types of controls that need to be present and are instead asking for demonstrable results. A 2013 paper by Eric Vugrin and Jennifer Turgeon of Sandia National Laboratories noted that the "current cybersecurity philosophy ... centers on the detection and prevention of an attack." The paper continues to say that the trend was toward performance-based assessment with the goal of enhancing the resilience of systems when faced with an attack.

But, how do you assess the performance of your cybersecurity controls (aside from waiting for an adversary to present themselves and then observing whether their attack is successful)?

Most of the popular risk assessment methodologies attempt to do this by asking the analyst to estimate the likelihood of various attacks. For instance, chapter three, page 240 of the NIST SP800-53 Security and Privacy Controls for Information Systems and Organizations advises practitioners to "Conduct a risk assessment, including:

  1. Identifying threats to and vulnerabilities in the system;
  2. Determining the likelihood and magnitude of harm from unauthorized access, use, disclosure, disruption, modification, or destruction of the system, the information it processes, stores, or transmits, and any related information; and
  3. Determining the likelihood and impact of adverse effects on individuals arising from the processing of personally identifiable information;

Performance-based GRC (Governance, Risk and Compliance) using SecurITree

Methodologies such as STRIDE assist in identifying threats to systems. MITRE's ATT@CK and CAPEC frameworks (in conjunction with the CVE data base) help identify potential vulnerabilities. But steps 2 and 3 leave it up to the practitioner to determine the likelihood of the various incidents. This observation is not meant to criticize NIST SP800-53 - almost all of the other risk assessment methodologies are similarly vague in their descriptions of how an analyst should estimate probability and frequency.

Consider, for example, the PASTA threat modeling process. A leading PASTA supporter (with whom Amenaza is not affiliated) - - describes a six step methodology. Quoting that website, " To blueprint a good model for attacks, you want to use attack trees. Using attack trees allows you to map known vulnerabilities to a node on the attack tree to determine its likelihood."

What is needed is a mechanism to expose the target system to a variety of threats and adversaries, and to predict how the system will perform under such stress. Attack tree analysis using Amenaza's SecurITree does exactly that. It allows the analyst to create a safe, graphical, mathematical model of the system they wish to protect. They then expose the model to adversaries of varying capabilities and observe how the system will perform. SecurITree enables performance-based risk analysis.

If GRC (Governance Risk and Compliance) is important to your organization, SecurITree gives you greater assurance that your system will perform well when (not if) it is attacked!

† Advancing Cyber Resilience Analysis with Performance-Based Metrics from Infrastructure Assessments
Eric D. Vugrin, Jennifer Turgeon
International Journal of Secure Software Engineering (IJSSE) 4(1)

SecurITree. Modeling, the future of security.


Request Attack Tree Methodology >