Month: November 2023

Will CVSS 4.0 Help Companies Manage Vulnerabilities Better?

About two weeks ago FIRST published version 4.0 of the Common Vulnerability Scoring Standard (CVSS), largely in response to feedback from the industry on the shortcomings of CVSS 3.1 and previous versions. The main complaint from industry with version 3.1 was that it didn’t offer any way to add additional context in a way that could help determine and prioritize risk. This led to companies to come up with their own processes to add context. In a previous blog about The Problem With Vulnerability Scanners I specifically highlighted how CVSS scores weren’t very useful and needed additional business context to make a risk prioritization decision. With that in mind, CVSS 4.0 attempts to address these shortcomings. Let’s take a look at what they changed and if it will help.

What’s New?

Both CVSS 3.1 and CVSS 4.0 include ways to evaluate vulnerabilities using the intrinsic characteristics of the vulnerability (Based), how the vulnerability changes over time (Temporal v3 or Threat v4) and how the vulnerability specifically applies to your environment (Environment). New for v4 is a Supplemental section which doesn’t impact the CVSS score, but allows you to add additional context for the vulnerability.

Additionally, CVSS 4.0 promises the ability to add real time threat context by allowing teams to use Threat Intelligence as an input to the CVSS score for a vulnerability. This additional context can be provided in new sections such as Attack Complexity, Attack Requirements, Vulnerable System and Subsequent System. CVSS 4.0 attempts to acknowledge unique environments by allowing additional fields for things like safety, ICS systems, etc. You can read about the full CVSS 4.0 specification here.

Finally! A Way To Prioritize Vulnerabilities!

CVSS 4.0 definitely seems like a huge step towards allowing teams to provide additional context to a vulnerability with the ultimate goal of influencing the score for better risk prioritization. The most common complaint I hear from engineering teams is there are too many vulnerabilities with the same criticality and they are unsure where to start. This was also feedback provided by industry to FIRST because it seemed like vulnerabilities were clustered more towards the critical and high range after the changes from v2 to v3.

CVSS 4.0 definitely answers some of the previous shortcomings and allows teams to add additional context to help make better decisions about which vulnerabilities should be prioritized for remediation over others. I know it is fairly common for the top priority to be given to external, publicly facing systems. The problem was CVSS 3.0 didn’t really provide a way to delineate between internal and external systems very well. So overall, the changes introduced in v4 are very welcome and should help teams really focus on what matters.

Is More Choice A Good Thing?

While it may seem like a good thing to be able to adjust the CVSS score for a vulnerability I do see this causing issues, particularly with external reporting. Security teams will need to have a robust process documented for how they are adjusting the score of a vulnerability and I can see situations in the future where companies are accused of subjectively adjusting their vulnerability scores down to paint a better picture than the reality.

Additionally, more choice comes with less transparency. Over the past year I have seen the volume and complexity of security questionnaires increase. The top questions focus around vulnerability remediation SLAs, incident response times and software supply chain security. Adding additional complexity into the CVSS scoring process, that allows companies to subjectively adjust the score up or down, will be extremely difficult for customers and regulators to navigate. Think back to Log4j and the reaction from your customers if you said you had Log4j vulnerabilities, but weren’t prioritizing remediation because they were on internal systems only. This may be a reasonable risk response for the business, but the perception from your customers will be difficult to manage.

Time Will Tell

Overall, it seems like CVSS 4.0 is attempting to become more of an overall risk score, rather than just a severity score. It is certainly welcome to be able to add additional context and take additional input to adjust the CVSS score as it applies to your environment and business. However, the new standard adds additional complexity and subjectivity that will make it difficult for customers and regulators to assess the true risk of a vulnerability to the business in a common way across the industry. Security teams will need to be particularly diligent in documenting a robust process for how they are adjusting the CVSS score to avoid being accused of arbitrarily adjusting the CVSS score down to make their company look better.

Chief Incident Scapegoat Officer (CISO)?

Last week the SEC filed a complaint in the Southern District of New York charging SolarWinds and specifically its CISO, Timothy Brown, with fraud. According to the compliant, the SEC alleges the company and Brown made false statements about its security posture to investors. Along with the Uber CISO, Joseph Sullivan, this is the second CISO in the past year to be specifically charged for failing to do their job. In my opinion, these court cases are going to negatively impact the CISO role and make security less transparent to investors. Let’s dive in.

What About The Other C-Levels?

Both cases are unique, however the first thing that stands out to me is only the CISOs are being named and charged. I find this odd because in an ideal organization the CISO still has to partner closely with the other C-Level execs to achieve security objectives. Things like external messaging to customers, SEC filings, etc. all require the coordination and knowledge of other C-Level execs like the CFO, Legal, Marketing and even the CEO. Why aren’t these individuals being named and charged for also contributing to the fraud?

In the worst case scenario, a CISO is poorly supported and struggles to get any of their security objectives funded or implemented. Is the CISO to blame in this scenario? What about the CEO and CFO who withheld funding? How about the Engineering leader who failed to prioritize the security recommendations of the CISO? The point is, I have never found a situation where a CISO is able to operate in a vacuum and so the other C-Level execs also have a responsibility to make sure the company is making true statements and not perpetrating fraud. They should all be held equally accountable.

Responsibility Without Authority

The CISO role has had a lot of press and a surge in visibility over the past few years, but the role still has a long way to go to be on par with other C-Level roles. It is common for the CISO role to report to the CTO, CIO or Chief Legal Counsel. It is uncommon for the CISO role to have a direct reporting line to the CEO. We can discuss who the CISO should report to, but in my opinion, the CISO role still needs to mature compared to the other legacy C-Level roles. The position is currently not on the same level as a CTO or CIO role and this impacts the scope and authority of the role.

Additionally, most CISOs don’t actually own the things they are trying to improve the security posture of. There is always a business or engineering owner that is actually responsible for building and operating the systems that make the company money. As a result, the CISO role typically ends of with all of the responsibility for security, but none of the authority. If the CISO makes a recommendation to fix something and the engineering leader rejects it, who is held accountable for that decision?

Chilling Effect On Open Discussion

My biggest concern with the SEC complaint is the reference to emails that are pointing out the known security issues with the Orion system. Matt Levine wrote a great article in Bloomberg questioning the SEC’s logic and I agree with his assessments. I have never read an SEC filing or investment statement expecting the company to highlight their massive security investments. In fact, I would question if a company should disclose that in a filing at all (unless it is material) because you may inadvertently provide information to attackers that could be used to hack the company.

Additionally, most security teams openly discuss security issues via chat or email. I find these discussions are almost always expressing frustration with current situations with the goal of gaining support for investment to remedy the issue. However, discussions via chat and email also happen to be legally discoverable forms of communication. This means every single email about how much your security sucks will be taken out of context by lawyers and used against you. The obvious solution is to never put your current security failings in writing, which means you can never create a presentation to convince the company to invest in improving security. Or alternatively, if you do place things in writing you frame them in a way that they are asking for legal advice so they can be protected by legal privilege.

Predictions For the CISO Role

I wrote a blog post after the Uber verdict, but both the Uber and SolarWinds cases have caused significant anxiety within the CISO community, which I think will impact the CISO in the following ways going forward:

  1. New CISOs hiring into a role will require companies to list them on their Directors and Officers (D&O) Liability Policy. Also, based on this Bloomberg Law Article about FTX, I recommend making sure the D&O policy specifies how much you will get if all the executives are trying to use the policy at the same time for legal fees.
  2. It will become standard for companies to cover the costs for legal counsel specified by the CISO, should they be individually named in a lawsuit.
  3. As these cases become more common, CISOs will demand higher compensation and protect themselves contractually to minimize their personal risk.
  4. Companies will (hopefully) prioritize security investments to minimize the risk of lawsuits, regulatory actions or security incidents.
  5. Costs for companies to employ and retain a CISO will go up over time.
  6. In extreme cases, the CISO role may shift from a salaried employee to a consultant (I-9) to offload the accountability for security to the company and protect themselves.

Final Thoughts

I can’t recall the last time I saw a CTO or CIO charged with investor fraud for making false statements about their products or enterprise environment. Yet, the CISO role has been getting a lot of scrutiny from regulators recently. I’m all for holding people accountable, but the CISO role doesn’t seem to carry the same weight as the CTO or CIO. The role still struggles with gaining support and funding to place security first. If a company culture is weak or the other executives minimize security, then the CISO will fail to make any meaningful progress. In my opinion, if the CISO of the company is named, then all the officers should be named to drive home the message that they are all accountable for the security of the company.