risk threat vulnerability

Question

From ENISA - Threat and Risk Management

Identification, analysis and evaluation of these threats and vulnerabilities are the only way to understand and measure the impact of the risk involved and hence to decide on the appropriate measures and controls to manage them.

Is my understanding is correct that to know a risk I need to know the threats and vulnerabilities first?

risk = threat x vulnerability 

If yes, then what should I define first? Threats or vulnerabilities?

As a simple example. Let's say I have a system that allows password authentication via SSH. I'd say that:

Threat – an intruder can exploit the password weakness to break into the system
Vulnerability – password is vulnerable for dictionary attacks 
Risk – the resources within the system are prone for illegal access / modification / deletion by the intruder 

But how can I assume that an intruder can exploit the password weakness (if that even is a threat to me) if I don't even know yet whether weak passwords are allowed (that would be the vulnerability, right?) but what if the system is enforcing a very strict and secure password policy or is even disallowing password authentication (only priv/pub key authentication is allowed).

Answer 1

You are trying to combine a couple of different types of risk that you need to keep separate:

1. inherent risk (risk without treatment/mitigations/controls)
2. residual risk (risk after treatment/mitigations/controls)

You are also defining your threats far too specifically to the vulnerability, which is causing you further chicken/egg confusion.

You state that the threat is "an intruder can exploit". That's not the threat. The threat is that a potential intruder will test passwords using brute force methods.

Also, your risk analysis suddenly expands the scope beyond the threat and vulnerability. Modification and deletion is a potential secondary effect to the unauthorised access risk that the threat and vulnerability describe.

This makes your inherent risk analysis:

Threat – an intruder tests passwords using brute force
Vulnerability – password is discoverable to brute-force methods in a short time frame 
Risk – by exploiting weak passwords, an attacker gains unauthorised access to the system

So, using this modular method, you do not have a chicken/egg problem with threats and vulnerabilities. Threats do what they do. Vulnerabilities exist or not. When they align, then you have a "hazard condition" that can result in harm.

If you do not have this vulnerability (i.e. if you only use key authentication, not password authentication), then this particular threat does not apply to the system. Other threats exist, but there is no risk of this type.

If you have controls in place to treat this risk (2FA, password auditing, brute-force detection and lock-out, etc,.) then your residual risk is lowered: risk = threat x vuln - mitigations

Answer 2

But how can I assume that an intruder can exploit the password weakness (if that even is a threat to me) if I don't even know yet whether weak passwords are allowed (that would be the vulnerability, right? but what if the system is enforcing a very strict and secure password policy or is even disallowing password authentication (only priv/pub key authentication is allowed).

Yes, weak passwords are a vulnerability. Before you can do a risk assessment you need to find out about your vulnerabilities.

One way to go about understanding your vulnerabilities as well as threats would be to have the system undergo penetration testing. This will involve use of penetration tools and scripts that will attempt to exploit vulnerable libraries or insecure programming. But to make the most of a penetration tester, you will want to give them as much information as possible including the application source code. If the tester only needs to make use of basic penetration tools to break into your system, you now know a script-kiddie could compromise your system - that's a pretty high threat. On the other hand if the tester has to devise custom script/program then, while still a threat, it is less likely to happen.

Once you have a much better idea of your vulnerabilities and type of threats who can exploit those vulnerabilities you can do a risk assessment of each weakness. Risk assessments can help prioritize what to fix first.

Skip to the end of the ENISA Risk Assessment document where it states that risk evaluation involves:

• consequences (e.g. impacts),
• the likelihood of events,
• the cumulative impact of a series of events that could occur simultaneously

In other words,

risk = impact x likelihood

This is also exactly what the OWASP Risk Rating Methodology prescribes. I shall demonstrate how application of ENISA guidelines to define the OWASP risk framework. Designating Impact and Likelihood on orthogonal dimensions allows us to do an assessment operation (hence the "x" operator). We assign values to severity of Impact and Likelihood - ENISA refers to this as semi-quantitative analysis - giving us an assessment operation table:

+--------------------------------------------------+
|                  Risk Severity                   |
+--------+------------+--------+--------+----------+
|        | HIGH       | medium | high   | critical |
|        +------------+--------+--------+----------+
| Impact | MEDIUM     | low    | medium | high     |
|        +------------+--------+--------+----------+
|        | LOW        | note   | low    | medium   |
|        +------------+--------+--------+----------+
|        |            |        |        |          |
|        |            |   LOW  | MEDIUM |   HIGH   |
+--------+------------+--------+--------+----------+
|        |                     Likelihood          |
+--------+------------+--------+--------+----------+

E.g. HIGH Impact x HIGH Likelihood = critical Risk

Let's drill down further by characterizing:

likelihood = threat agent factors + vulnerability factors

impact = technical factors + business factors

It makes more sense to define Likelihood as a cumulative aggregation of threat agent and vulnerability factors - these two factors are not orthogonal as your definition seems to suggest.

Let's further breakdown how these factors may be semi-quantified:

• Likelihood factors
  • threat agent factors (each 0-9)
    • skill: no technical skills (1), some technical skills (3), advanced computer user (5), network and programming skills (6), security penetration skills (9)
    • motive: low or no reward (1), possible reward (4), high reward (9)
    • opportunity: full access or expensive resources required (0), special access or resources required (4), some access or resources required (7), no access or resources required (9)
    • size: developers (2), system administrators (2), intranet users (4), partners (5), authenticated users (6), anonymous Internet users (9)
  • vulnerability factors (each also 0-9)
    • ease of discovery: practically impossible (1), difficult (3), easy (7), automated tools available (9)
    • ease of exploit: theoretical (1), difficult (3), easy (5), automated tools available (9)
    • awareness: unknown (1), hidden (4), obvious (6), public knowledge (9)
• Impact factors
  • technical factors
    • loss of confidentiality: non-sensitive data disclosed (2), minimal critical data disclosed (6), extensive non-sensitive data disclosed (6), extensive critical data disclosed (7), all data disclosed (9)
    • loss of integrity: slightly corrupt data (1), minimal seriously corrupt data (3), extensive slightly corrupt data (5), extensive seriously corrupt data (7), all data totally corrupt (9)
    • loss of availability: minimal secondary services interrupted (1), minimal primary services interrupted (5), extensive secondary services interrupted (5), extensive primary services interrupted (7), all services completely lost (9)
  • business factors
    • financial damage: less than the cost to fix the vulnerability (1), minor effect on annual profit (3), significant effect on annual profit (7), bankruptcy (9)
    • reputation: minimal damage (1), Loss of major accounts (4), loss of goodwill (5), brand damage (9)

For the risk assessment, evaluate each factor and assign a value. Values are then averaged and assigned a severity based on the score.

Likelihood and Impact Values
0 to <3    LOW
3 to <6    MEDIUM
6 to 9     HIGH

Password Vulnerable to Dictionary Attacks Risk Assessment

Let us take your example of the password being vulnerable to dictionary attacks and do a risk assessment of it - this just happens to be values I assign to it:

Likelihood: overall=6.1 (HIGH)
  threat
    skill=6
    motive=9
    opportunity=4
    size=2
  vulnerability
    ease of discovery=9
    ease of exploit=9
    awareness=4

Impact: overall=5.6 (MEDIUM)
  technical
    confidentiality loss=9
    integrity loss=7
    availability loss=5
  business
    monetary=3
    reputation=4

HIGH likelihood x MEDIUM impact = HIGH risk

There are of course many ways to customize this. More/less factors. Weightings on the factors. See OWASP Risk Rating Methodology for details.