NextEuropa Security Risk Metrics

In the European Commission sometimes we need to adopt Drupal standards, especially when it comes to tackle security issues. In order to properly evaluate risk of a drupal security advisory, the team which is in charge of keeping our systems secure, following advices by the Drupal community, came up with the proposal of create our adaption of the Drupal Security Risk Metric. Below you can read the edited version of the official documentation of how we currently calculate all the advisories that are announced usually on Wednesdays.

 

Based on a previous version where we used to use a simple mapping, the NextEuropa Security Task Force extended it to a 2-dimensional version, independently measuring infrastructure impact (Category1) and technical risk (Category2). The following documentation is in use to evaluate the risk and impact for Drupal Security Team announced Security Advisories (SA). 

 

Category1 (CAT1)

It combines the Authentication and Platform impact items that are counted as following:

  • Authentication is given by Drupal Security Advisory with the following rules:
    • If SA says A:None, NESA will have to follow it: AU:N.
    • If SA says A:User then NESA will have to follow it: AU:UT.
    • If SA says A:Admin then NESA has to investigate does the authentication needs full UID1 access for the exploit or any trusted user roles is enough to execute it.
      • If any user role is enough for the authentication of the security issue that is considered trusted then the NESA Code goes to AU:A. Trusted roles: Any user roles that gives higher permissions that are given to authenticated users are considered trusted ones. Untrusted roles are currently: non authenticated (anonymous) users and authenticated users.
      • If UID1 access is needed then the NESA Code goes to the lowest one: AU:ID.
  • Platform Impact value is not given by Drupal Security Advisory and has to be handled following these rules:
    • If the project is enabled on all instances then NESA Code goes to the highest level: PI:A.
    • If the project is present on all instances but independently enabled, it means the project is delivered by Platform but instances can decide to have it enabled or not. In this case the impact is lower, NESA Code goes to PI:SD.
    • If the project is not present on all instances but enabled on at least 1, it means the project is not delivered by Platform, but by intances and the infrastructure impact is low, NESA Code goes to PI:SS.
    • It the project is not present and enabled on any instances then there is no impact, NESA Code goes to PI:N

The values are the following:

Item

Value

Description

NESA Code

NESA Score

Authentication

 

 

 

 

 

None

Authentication is not needed

AU:N

10

 

Untrusted user roles

Untrusted user roles (authenticated users)

AU:UT

7

 

Administrator

Trusted user roles

AU:A

3

 

UID1

Superadmin

AU:ID

1

Platform Impact

 

 

 

 

 

All

Module is enabled everywhere

PI:A

10

 

Subsite defined

Module is present but not enabled everywhere.

PI:SD

5

 

Subsite specific

Module is not present everywhere but enabled on at least 1 instance.

PI:SS

2

 

None

Module is not present and enabled anywhere.

PI:N

0

The Category 1 final score is counted as the multiplication of the individual items.

Levels of the results:

#1 - 50-100: Critical Infrastructure impact. (Possible combinations: AU:N+PI:A, AU:UT+PI:A, AU:N+PI:SD)

#2 - 20-35: Significant Infrastructure impact. (Possible combinations: AU:UT+PI:SD, AU:A+PI:A, AU:N+PI:SS)

#3 - 10-15 Moderately Infrastructure impact. (Possible combinations: AU:A+PI:SD, AU:UT+PI:SS, AU:ID+PI:A)

#4 - 2-6 Low infrastructure impact. (Possible combinations: AU:A+PI:SS, AU:ID+PI:SD, AU:ID+PI:SS)

#5 - 0 No infrastructure impact. (Possible combinations: AU:X+PI:N)

 

Category2 (CAT2)

It combines the Access ComplexityConfidentially Impact, Integrity Impact, Exploit and Target Distribution items as following:

  • Access Complexity is given directly by Drupal Security Advisory without change as it covers our use-cases - different scores (higher then official ones) are applied as agreed already on this metrics v1.
  • Confidentially Impact is given directly by Drupal Security Advisory without change as it covers our use cases - lower scored are applied then the official ones as NextEuropa is a public information system, meaning all our handled data are supposed to be public.
  • Integrity Impact is given directly by Drupal Security Advisory with the same scores as they cover our use cases.
  • Exploit is given by Drupal Security Advisory changing the value of it to at least Proof high. The scores are also increased.
    • If SA says E:Theoretical, NESA will have to increase it to EX:P (Proof), as issue got published with the code that fixes it.
    • If SA says E:Proof, NESA will have follow it: EX:P (Proof), as even issue is documented and the fix is available, there is no published exploit that we can rely on. In very special cases (mainly drupal core SA) we should consider to increase the level to the highest one (EX:E)
    • If SA says E:Exploit, NESA will have to follow it: EX-E (Exploit).
  • Exploit that is not given by Drupal Security Advisory but got reported internally in NextEuropa project will arrive to EX:I (Internal) as only internally available until it's not by a publicly announced advisory (3rd party disclosure or zero day incidents).
  • Target Distribution is given by Drupal Security Advisory with increased scores and possibly needs further investigation to decide the validity of it as following:
    • If SA says TD:All, NESA doesn't need any investigation as the security issue doesn't depend on special settings by the project.
    • If SA says TD:Default, NESA needs investigation to check the settings that are vulnerable by the project are commonly used on the affected systems or not.
      • If those settings are provided (by platform or subsite code base) that allows the exploit to be executed, NESA has to follow the original value.
      • In any other cases NESA has to decrease the risk to TD:U (Uncommon).
    • If SA says TD:Uncommon, NESA needs investigation to check the settings that are vulnerable by the project are commonly used on the affected system or not.
      • If those settings are provided that allows the exploit to be executed, NESA has to increase the item to TD:D (Default).
      • In any other cases NESA has to follow the original value.

The values are the following:

Item

Value

Description

NESA Code

NESA Score

Access Complexity

 

 

 

 

 

None

User visits page

AC:N

5

 

Basic

User follows a specific path

AC:B

3

 

Complex

Multi-step with possible dependencies

AC:C

2

Confidentiality Impact

 

 

 

 

 

All

All none-public data is accessible

CI:A

4

 

Some

Certain non-public data is released

CI:S

2

 

None

No leaked data

CI:N

0

Integrity Impact

 

 

 

 

 

All

All data can be modified or deleted

II:A

5

 

Some

Some data can be modified or deleted

II:S

3

 

None

Data integrity remains intact

II:N

0

Exploit

 

 

 

 

 

Exploit

Exploit exist, documented or code is available

EX:E

5

 

Proof

Proof of concept exists

EX:P

4

 

Internal

Internal, non-published concept exists

EX:I

2

Target Distribution

 

 

 

 

 

All

All module configuration are exploitable

TD:A

5

 

Default

Default or common configurations are exploitable

TD:D

3

 

Uncommon

Only uncommon module configurations are exploitable

TD:U

2

The Category 2 final score is counted as the sum of the individual items.

Levels of the results:

#1 - 24-21: Highly Critical Technical risk. (For reaching this level either all items has to be on the highest level, or at most 2 of them can be decreased to its one less highest level, or at most 1 which is not the Integrity Impact can go to its lowest level.)

#2 - 20-18: Critical Technical risk. (For this level at most 3 items can reach their highest level.)

#3 - 17-14: Moderately Critical Technical risk. (For this level less then 3 items can reach their highest level.)

#4 - 13-11 Less Critical Technical risk. (For this level none of the items can reach their highest level.)

#5 - 10-6 No technical risk.

 

The final result

It has to contain the full risk string with the results of the Categories, reporting their levels. Based on the levels, further actions can be decided as following:

 

CRITICAL Inf. Imp.

SIGNIFICANT Inf. Imp.

MODERATELY Inf. Imp.

LOW Inf. Imp.

NO Inf. Imp.

HIGHLY CRITICAL Tech. risk

XXX

XXX

XX

X

X

CRITICAL Tech. risk

XXX

XX

XX

X

X

MODERATELY CRITICAL Tech. risk

XX

XX

X

X

X

LESS CRITICAL Tech. risk

XX

X

X

X

X

NO Tech. risk

X

X

X

X

X

 

Reaction plan

HIGH PRIORITY XXX - Immediate reaction is needed when the Security Advisory gets published, use Cookbook related chapter, apply the workaround to lower the risk/impact and the fix has to arrive in 1 working week (by the next DSA).

MEDIUM PRIORITY XX -  Validation of the issue has to be done next day, resolution has to be done within not more then 1 month.

LOW PRIORITY X - No reaction is needed immediately, investigation can be done in the coming days and fix can arrive later, at most in 3 months.

 

The NextEuropa Security Advisories Cookbook

When the final result reaches High priority, the team has to lower the risk or impact that is present by the vulnerable component. Currently we have 3 different ways to manage workarounds that are individually executed on the unsecure websites. Without giving too many details, we evaluate the followings:

  • If we limit the access until the component can be properly updated on production, do we also limit consideably the business?
  • If the component has any known way to limit its exploit like dedicated permission that can be temporary revoked from untrusted user roles?
  • Can we as a last resort immediately deploy the patch without having troubles in the pipelines?

The golden rule is to try to avoid out-of-working-hours deployment when we have no development resource present, also our Behat and Unit test coverage can't really cover the use cases that can be caused by exploits. So with chosing the proper chapter of the Cookbook, we temporary lower the final result to Medium or Low that gives enough time to development teams to evaluate the possible side effects, if any, in order to deliver the final solution which is usually either a corrected patch on the website used version or update to the latest version of the component.