An important part of looking at risk is to understand threats,
understand the enemy if you want to call it that.
This is often done today through something we call threat modeling.
Threat can be defined as any circumstance or event with a potential to
adversely impact organizational operations including mission,
function, image, or reputation, organizational assets,
individuals, other organizations,
or even the nation itself, through an information
system via unauthorized access, disclosure,
destruction, modification of information,
and/or denial of service.
The threat source or threat agent is the element or entity which
alone or in combination has the potential to give rise to risk, the
intent and method targeted at the intentional exploitation of a
vulnerability, or a threat source could also be an accidental
exploitation of a vulnerability.
We have many man‑made threat sources or threat agents,
hostile actions, and when we're looking at hackers,
for example, we have to understand their motivation,
capabilities, and intent.
Are they an advanced persistent threat, a very skilled attacker,
or someone who is just casually trying to make a few
bucks by stealing from somebody else?
We should also become familiar with the tools,
the techniques, tactics, and procedures that the adversary uses.
But we also know that man‑made threats could be entirely accidental,
an error of omission or commission that a person has then enacted.
Threat sources can include environmental,
natural events, storms, floods, power failure,
telecommunications lines being cut, or for example,
a failure of DNS and that people can't reach the websites they need to get to.
Threat source could be structural, equipment failures,
software bugs, for example,
but this is where we have to understand how can these threats attack us?
What are the attack vectors or the channels that could
be used by these threats sources?
And this is where we have to understand what is our exposure or attack surface.
Could they attack through the building, the facility?
Could they attack through the networks?
Could they attack through hardware such as we saw with meltdown inspector,
for example?
Could they attack through our web‑based applications or user inputs?
Could they attack through the administrator interfaces or maybe
through socially engineering convincing our staff to do something
that they really shouldn't have done, for example.
The key point to review is that if I really want to understand risk,
I also need to understand the enemy, and that is,
of course, threat modeling.
And this is why risk identification should be
methodical and a step‑by‑step process.
Identify the assets and what those assets are worth because never
pay more to protect something than it's worth.
Do the threat modeling, and then as we'll look at,
do the vulnerability assessment, what are the gaps or weaknesses?
What are the likelihood and impact of something happening?
And from this, be able to calculate the risk level.
Then what are some suggestions you have?
What is an appropriate response to the risk? And
communicate those to management.