Risk – The possibility of something bad happening. In our space, there’s an incredible level of discussion on risk. When abstracted, most of these reflections are on defining what it actually is/means, who is ultimately responsible, and how we can better manage or treat it. Despite some noteable academic and practitioner scholarship on the subject, we’re often left with broad generalizations where the term risk is equally leveraged to explain what are otherwise very unique and distinct elements that are part of a greater calculation to bring much needed clarity on – threats, vulnerabilities and assets – but we’ll get to that later.  

How We Manage Risk

We have all managed risk throughout our careers either intentionally or indirectly, and in variety of contexts and circumstances. More precisely we have to varying degrees applied the rigor of discovery, analysis, and evaluation to reduce the possibility of something bad happening. My experiences with risk were shaped through a combination of following framework and trial/error in planning and executing military operations, complex intelligence activities, building new programs, and of course now growing a technology startup:

  • In the Army, it meant I would have to: Identify hazards | Assess the hazards | Develop controls and Make decisions | Implement controls | Supervise and Evaluate
    • Never without a template, the Army also provided a convenient risk assessment form that included a welcomed rubric for categorizing probability (the frequency of potential occurrence) and severity (the expected consequence).
  • In the Department of Defense, we upped the game a bit from the Army’s tactical focus to include some additional elements. While the DoD is too big to have just one framework (of course) that I could conveniently cite, it also considers: Identify assets | Determine vulnerabilities | Assess cost vs. benefit of proposed actions to reduce the possibility of something bad happening.
  • In industry, I’ve served in both physical and cyber/information security roles and know that are also not immune to the doctrine and policy leaning tendencies of our public sector colleagues. While there are numerous examples, I’ll focus on the two that arguably get the most attention:
    • ISO 31000 - Risk Management,  defines risk as the “effect of uncertainty on objectives, which focuses on the effect of incomplete knowledge of events or circumstances on an organization’s decision making.” Like others in the risk tribe, there is analogous language on the need to identify, analyze, and treat.
    • NIST SP 800-37, Risk Management Framework for Information Systems and Organizations, puts Oxford to shame with a robust risk definition: a measure of the extent to which an entity is threatened by a potential circumstance or event, and typically is a function of: (i) the adverse impact, or magnitude of harm, that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. There’s a lot to unpack there but putting aside the highly complex sentence structure, we find a lot of shared language and emphasis.
  • In Finance, risk, as defined by FINRA, is "any uncertainty with respect to your investments that has the potential to negatively impact your financial welfare." This version of risk is measured in financial terms. When I’ve had P&L ownership, this version of risk informs how confident I am in my forecasts based on the resources available, and is measured by the potential deviations that might occur given uncertainty. For strategic planning, budgeting, and the other management tasks, this is the definition of risk that is used to make decisions.

Security and Risk

This definitional exploration is important because it (selfishly) validates our design rationale and reduces the opportunity for what can often be a limiting perspective on how to manage cyber risk. In our own engagements with enterprise customers, we have had great discussions with security teams, risk teams, compliance and/or GRC teams. At times, we’ve also heard that security and risk are clearly distinct functions and in the most extreme cases, quite siloed. Perhaps it’s the way it’s always been, perhaps in heavily regulated industries, compliance has become the defining – if not exclusive – risk management component. And yet, if security is about the measures and practices taken to protect assets, and risk management is about measures and practices taken to reduce the possibility of something bad happening to those same assets, we have an opportunity to take a more unified approach.

In order to protect, we must start with what to protect and understand why it matters to inform decision-making. Given that we are dealing with constrained resources (time, money, headcount), we must anchor our decisions in the financial value that such investments will derive - i.e., how much risk does each investment buy down. We are guided by best practice and frameworks to implement technical and non-technical controls to reduce our vulnerability to threat exploitation, but what matters is the value these investments have on improving both our certainty and effectiveness at achieving our goals.

Risk management begins by determining what assets are at risk (and therefore need protection). This awareness is further bound by calculating exposure – the opportunity space where threats are assessed against the controls we have in place to measure (1) the likelihood of success they would have in exploiting vulnerabilities and (2) the operational, reputational, and ultimately financial impact it would have. Binary controls are foundational but do little to respect the dynamic nature of threats and are often not a useful barometer for determine how effective we are in reducing exposure. Controls have a cost and a benefit that not only can be, but must be measured, understood, and most importantly managed, as this equation evolves as conditions change.

Security Risk Management

A risk-based approach to security posture management aligns the security teams efforts to the same principles guiding the organization’s overall enterprise risk management efforts. It puts risk exposure at the center of decision-making for all security actions because it:

  • Enables continuous assessment of the risk environment to dynamically maintain awareness.
  • Evaluates vulnerabilities against likelihood of exploitability and the financial impact it would have making ensuing actions tailored to the unique considerations of the organization. Not all vulnerabilities are equal in either potential impact or cost to remediate, and decisions against them must be put against the cost-benefit analysis that is consistent with the organization’s risk acceptance and tolerance.
  • It adopts the unifying principle of measuring impact against common metric that executives use – the effect any decision would have revenue and growth.  
  • It enables a more accurate and data-driven approach to determine how effective existing investments are performing because it relies on a continuous and aggregate evaluation of security environment; not just what one or more components of the stack are doing to better protect.
  • It ensures confident prioritization of often constrained resources to focus on achieving the most beneficial impact to reducing the likelihood of threat actor success.

At Pellonium, these principles have guided our efforts to deliver a comprehensive Unified Security Posture Management platform for more effective cybersecurity risk management. To learn more, please visit www.pellonium.com.