by David Snopek on September 15, 2015 - 9:06am
Every Wednesday, the Drupal Security Team publishes "Security Advisories" (or SA's) to tell users about security vulnerabilities in Drupal core and contrib modules, with advice on how to solve the issue so that their site is secure.
This is the first in a series of articles about how to better understand all the information in a security advisory, so that you know how to take the appropriate action for your site!
Not all security vulnerabilities are equal!
Some are highly critical and require immediate action (like SA-CORE-2014-005, aka Drupalgeddon, was) or your site could be irrepairably damaged and you'll have to restore from backups.
And while you should take action on any security advisory that affects your site as soon as possible (or hire someone else to do it), some security vulnerabilities present less risk, so you might choose to delay updating and focus on more important things in your business or personal life.
But how do you make that decision?
However, those labels aren't very instructive because they don't really tell you what you're at risk of.
Each security advisory also includes the full set of values provided to the Risk Calculator - which contain a wealth of information about the vulnerability - you just need to know how to decode and understand it.
That's what this article is about!
Read more to learn how to understand the Risk Calculator used in Drupal Security Advisories!
How to find the "Security risk"
At the top of every Security Advisory, there a number of standard fields. Today, we're looking at the "Security risk" field:
There are three parts:
- A numeric point value out 25 (ex. 18/25). This could potentially be used by an automated system to sort or filter Security Advisories.
- A human-readable label (ex. Critical). This is determined by the point value. It's what most people look at and what's called out in the title of the Security Advisory.
- The exact values provided to the Risk Calculator (ex. AC:Complex/A:User/CI:All/II:All/E:Proof/TD:All). Each part (seperated by a slash) represents a single value provided to the Risk Calculator. For example, "AC:Complex" means that a "complex or highly specific" set of steps is necessary for an attacker to exploit the vulnerability.
While most people focus on #2, there's actually a wealth of information contained in #3 - you just need to know how to decode and understand it!
That's what we're going to focus on in the next two sections.
What is the Risk Calculator?
You can try out the Risk Calculator for yourself on https://security.drupal.org/riskcalc:
It's basically 6 questions about the vulnerability, each having 3 possible answers.
It's based on the NIST calculator used by the US government, and was created by Micheal Hess (the current Drupal Security Team lead) and John Simpkins, with lots of additional review and input from the entire security team (myself included).
Before the calculator, there was much less consistency between the "Security risk" level given for each SA: it was more open to interpretation by each security team member. The calculator has helped to standardize the risk levels, and continues to improve as we gain more experience with it and make changes.
What do each of the Risk Calculator values mean?
Access complexity (AC)
How difficult is it for the attacker to leverage the vulnerability? Does it require a complex set of steps, or does the attacker just need to visit a URL?
- AC:None = User needs only visit a page.
- AC:Basic = Basic or routine. The user must follow a specific path.
- AC:Complex = A complex or highly specific multi-step process, with a high number of dependencies.
What privilege level is required for an exploit to be successful? Does the attacker need special permissions, or can an anonymous user do it?
- A:None = Anonymous users can exploit the site.
- A:User = A user account with basic or common permissions can exploit the site.
- A:Admin = A user account with admin level permissions is required.
Confidentiality impact (CI)
Does this vulnerability cause non-public data to be accessible? Non-public data can include the e-mails of registered users, private content (nodes) and files, or in the worst-case scenario even the password hashes (which could be used to figure out site passwords).
- CI:All = All non-public data can be accessed.
- CI:Some = Certain non-public data is released.
- CI:None = No confidentiality impact at all.
Integrity impact (II)
Can this exploit allow system data (or data handled by the system) to be compromised? In other words, will I need to restore from backups if my site is exploited?
- II:All = All data can be modified or deleted.
- II:Some = Some data can be modified.
- II:None = No data integrity impact at all.
Does a known exploit exist? How long until I can expect attackers to start trying to exploit my site?
- E:Exploit = An exploit is known to exist or is documented in the wild.
- E:Proof = A "proof-of-concept" exists (ie. the methods for developing an exploit exist in the wild).
- E:Theoretical = No public exploit code or documentation exists.
Target distribution (TD)
What percentage of module users are affected? How likely is it that my configuration is affected by the vulnerability?
- TD:All = All users of the module or Drupal core version are affected, regardless of configuration.
- TD:Default = The default or commonly used configurations are affected.
- TD:Uncommon = Only rare or uncommon configurations are exploitable.
Keeping your site secure!
Now that you know what the values provided to the security calculator mean, you can use them to make decisions based on the specifics of your site.
For example, does your site have any confidential data? Or is it just a brouchure site with public information about your business?
If you have private or confidential data, then you need to take special care to check the "Confidentiality impact" of each security advisory. If not, than those vulnerabilities with "CI:Some" are less critical for your site. (Still be weary of "CI:All" if you reuse your e-mail and password on other sites!)
Another example: do you allow untrusted users to login to your site? Or is it only your staff with logins and everyone else is anonymous?
If it's only anonymous users than you probably don't have to worry much about "A:User" or "A:Admin" (unless you assigned a permission you shouldn't have to anonymous users, OR you use really bad passwords for users accounts).
Armed with this new information, you can make more informed decisions about which Security Advisories present a higher or lower risk to your specific site!
Don't want to worry about making security updates yourself, but still want your site to be secure? You can hire myDropWizard.com to take care of security updates for you! Contact us for more information!