I’m going to come right out and say it: CVSS does NOT equal Risk (CVSS!=Risk). Anyone who thinks otherwise is mistaken and setting themselves up for more work, pain, and stress than they realistically should have to go through. A risk is a potential for loss or damage if a threat exploits a vulnerability (which is a weakness in hardware or software). We’ll talk more about all that momentarily.
Common Vulnerability Scoring System (CVSS) is a toolset and methodology used by many of us in the industry (hardware/software manufacturers, maintainers, etc.) and security researchers to describe the relative severity of security vulnerabilities in a consistent, quantitative way. This data being represented results in a score ranging from lowest 0, to the highest of 10.
Recently the FIRST CVSS SIG updated the released version 3.1 of the framework which is the point of reference for this post. I'd strongly encourage anyone that uses the framework, or is impacted by security flaws (typically documented with a Common Vulnerabilities and Exposures (CVE) entry) to read the updated procedures and guidance.
Why a CVSS score is not the same as risk
So to repeat, CVSS != Risk; a CVSS score helps describe the severity of an issue and give an impression how quickly an impacted application or organization should react to this problem. We’ve talked in previous blogs about risk management and how to really understand risk and consider not sharing your data in certain contexts.
A quick refresh: a risk is a unique problem that could happen. For example, today I could trip on a loose rug that I hand-crafted at my adult education class last month that lays on the floor here in my living room (and really ties the room together).
I trip, fall over, hurt myself, and become unable to move (It’s a great thing I don’t live alone. I’m sure my faithful HangryCat will assist me in my time of need [Me: “He’s such a good boy! Yes he Is! A good, good boy!” Him: ...glares menacingly]).
To break this scenario down… the risk (a unique problem that could happen) is falling and hurting myself, the threat (something/someone that has the potential to do harm) is that loose rug, and the severity (impact of the risk should it happen) is how badly I will likely hurt myself when I fall due to the loose rug. Our CVSS Score might be, well, let’s do the math….
Using the handy dandy CVSSv3.1 calculator let’s derive a base score:
-
I’m going to say the rug’s Attack Vector is Adjacent, it’s on the same network as my floor, but distinct to itself.
-
The Attack Complexity is Low (since it’s my own lack of perception and inherent bear-like reflexes [which are universally known to be orders of magnitude slower than cat-like reflexes]).
-
The “attack” requires no Privileges, since anyone could meet my same fate.
-
This “attack” requires User Interaction, if I never walk over it I would never be subject to falling and the necessity for good, old HangryCat to rescue me like Lassie saving Timmy from the Well wouldn’t exist.
-
For the example right meow, let’s say the Scope is Unchanged through this attack, nothing else gets impacted aside from my body, my pride, and the cold, hard floor as it races to give me a hug (thanks, gravity!).
-
Thinking about the trusty CIA triad (Confidentiality, Integrity, and Availability) we’re going to say that no/None information gets disclosed to unauthorized persons (Confidentiality), but sadly my personal Integrity is impacted Highly (perhaps I could break a hip) and my Availability would also be High (#SAD! I can no longer scamper and play with the Children of the Forest).
How does this vulnerability stack up? Oh dear. According to the math, this vulnerability has a severity of 7.3 (out of 10) that should look like this:
CVSS Base Score 7.3 - CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H/E:H!
Ouch! That sure sounds like something severe that could happen, but that’s not a risk. So what could the risks be? Let’s just scribble a few down here quickly:
-
Newly broken hip and loss of sylvan playtime.
-
Rug gets kicked out from under feet during fall and shoots off and breaks nearby delicate stained glass window depicting the Apollo 11 Lunar Landing.
-
My freshly installed laminate flooring gets a large dent in it from my head and a little bit of blood and spittle on it.
-
Room decor is no longer nicely tied together.
-
The wailing and gnashing of teeth of my woodsy companions.
-
Laughter and mockery from my rescuers...unless…..
-
HangryCat, feeling a bit peckish and unwilling to venture into the darkness outside, decides to sample himself some sweet, sweet me (I’m not saying he’s a Grue, but he’s a Grue).
Egads! I sure wouldn’t want any of that to happen! So yes, I agree that a CVSS severity score of 7.3 feels about right for this particular scenario.
So let’s refer back to the CVSS methodology. Now my scenario describes one vulnerability with one rug. The framework allows for some tweaking and customization based upon factors important to you. You have a few additional dials that a security team can use to tailor this problem to their particular rug:
-
We can look to see if there’s any Exploit Code Maturity around this loose rug. (Yup, it’s been like that for a while, MANY attackers know and have proven how to exploit it, so we can layer on that as HIGH).
-
As a saving grace, there is some Remediation Level we can take to workaround the issue (push that rug into the closet before some clumsy oaf trips over it!).
-
But, sadly, we have confirmed Report Confidence that this rug-slippery has been seen in use “out in the wild”.
Now all those data points slightly adjust the score down to a 7.1. Better, but not awesome. We can further adjust the initial score using the Environmental Score features of the standard: We can set CIA Requirements… for my particular circumstance Confidentiality is not a factor, but Integrity must be protected at a HIGH level (Availability ...meh...we’ll rate that as just a Moderate, since I have hayfever and going out to the forest sometimes gives me the sniffles, so we can take or leave our playdate today).
As illustrated these extra features of the framework allow me to adjust this problem to my life and my rug. Maybe this problem is of greater or lesser concern to you? Great! CVSS is flexible enough that it lets you modify the parameters so your risk appetites and tolerances can be accounted for.
But, to address the bear in the room, what if rugs used on different floors made by different people are affected differently than my rug? Let’s say we have a blue rug made by my friend Marissa from the Doors company. She has these special grippy little footy things on the bottom of her rug, so while her rug might slip, it is far less likely to, so that same vulnerability might get a score of CVSS Base Score 4.6 - CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L (Availability and Integrity are only impacted at a LOW level thanks to her foresight).
What if my other friend Lisa’s green rug is nailed to the floor, and while the issue could happen to her rug, you’d have to circumvent her installation instructions, and rip out the nails to be vulnerable. She might rate this as CVSS Base Score 0.0 - CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:N since she feels customers of her rugs shouldn't be affected in her default rug configuration.
You know what? This is perfectly OK and a normal situation. Rugs that I make and use have different processes behind them and differing implementation guidelines than those other rugs. (Oh man, now that I read it, I fear I’ve given the impression that I don’t make good rugs. That is totally not the case. Unlike those other rugs, my rugs are made with love and so are inherently better!)
Why all this matters (real world application)
Why does this all matter? Risk is a very subjective thing. A risk to me may not be a risk to you or the HangryCat (who sits right meow, staring at me, licking his fuzzy kitty lips). We all have different rules and constraints put upon us. Even if we feel we have the same risk, our lives and needs are very different and could never be identical.
Tools like CVE and CVSS allow us to have a common language so we can understand each other and understand these pesky security vulnerabilities. That being said, CVSS is a great, yet imperfect tool. It does not account for all possible things the Working Group feels it needs to account for (which is why everyone is busy hashing out CVSSv4). Even when CVSSv4 is released, it will still leave room for interpretation between an overall security risk and the specific risk for a specific implementation of software in a specific environment.
Vendors like Red Hat will also provide you a severity rating for the incident. This is more precise guidance from that organization about how they feel the vulnerability affects their particular implementation of that hardware or software. This gives us additional flexibility to escalate the visibility of a given issue as the need arises. It also allows us to provide additional context about features/protections/processes we use that might help alter the severity of the problem.
How open source affects risk assessment
With Open Source having become mainstream in technology, it often happens that products and services from different vendors will have more vulnerabilities in common now with the sharing of the powerful Open Source code. A flaw in X library or Y version of a package can have far-broader impact reaches than they used to have back in the day of trading disks or CDs of your favorite distro.
A problem in “the Linux” can impact servers, workstations, laptops, tablets, clouds, phones, baby monitors, smart toasters, lightbulbs, smart coffee cups, talking bear toys, and WiFi routers. Each provider or user of these projects takes steps to configure that software to meet their unique desires or business needs.
Red Hat focuses on serving Enterprise customers, so we take a lot of time and effort hardening our offerings making them stable; other distros focus on speed or agility or desire to release features and functions to meet a ravenous community demand; all of that is perfectly fine and absolutely normal. My hammer can’t pound in all the nails out there (...yet).
Even for commercial Linux providers, who might have similar goals to Red Hat (stability, security), we likely go about meeting those needs differently. Everyone’s got their unique processes, compiler options, and hardening guidelines that makes what they provide and support unique. That diversity of thought and purpose is a hallmark of open source software (OSS), and OSS is certainly big enough to account for it all. Using that lens, it’s hopefully easier now to see why a vulnerability in a common package might not carry the same level of severity across this diverse and amazing ecosystem.
So, hopefully, while the night and my living room is dark and full of terrors, my brazen initial statement (that I’ll yell here again) CVSS != Risk makes more sense. My outlook is echoed by many fine people within our Information Security community. I’ll leave you with a few additional resources to review to show this is the majority opinion.
CVSS is great, but is a work in progress, and was never intended to be the final word to describe risks you might have. It is up to you and your organization to determine how these threats and vulnerabilities impact your unique business circumstances.
So the next big, scary security vulnerability that comes along, take a few moments and educate yourself. Go to your software provider (hopefully it’s Red Hat, but it might not be...yet), look at how they analyze and rate the flaw. No one knows software produced, maintained and supported by Red Hat better than Red Hat engineers.
By that same token, how Red Hat views a problem might not exactly match software provided to you from other open source providers. It makes sense to initially defer to the vendor or project that provided you the software, then start layering on your individual organization's perspective and needs/wants/requirements to end up with a severity that is applicable to you and your circumstances. So while Marissa’s and Lisa’s rug are nice, they might not tie the room together to meet your particular needs, and they won’t be able to accurately describe how big the problem might be to your rug. Tread carefully, and make sure the cat stays well-fed!
Additional Reading Resources
- Towards Improving CVSS by Deana Shick
- Calling Into Question the CVSS by Abby Ross
- CVSS Scores Often Misleading for ICS Vulnerabilities: Experts by Eduard Kovacs
- Don’t Substitute CVSS for Risk: Scoring System Inflates Importance of CVE-2017-3735 by McAfee Labs
- Common Vulnerability Scoring System SIG
- Understanding Red Hat security ratings
저자 소개
Christopher Robinson, better known as CRob to his colleagues, is a former Product Security Program Architect at Red Hat.
유사한 검색 결과
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
오리지널 쇼
엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리
제품
- Red Hat Enterprise Linux
- Red Hat OpenShift Enterprise
- Red Hat Ansible Automation Platform
- 클라우드 서비스
- 모든 제품 보기
툴
체험, 구매 & 영업
커뮤니케이션
Red Hat 소개
Red Hat은 Linux, 클라우드, 컨테이너, 쿠버네티스 등을 포함한 글로벌 엔터프라이즈 오픈소스 솔루션 공급업체입니다. Red Hat은 코어 데이터센터에서 네트워크 엣지에 이르기까지 다양한 플랫폼과 환경에서 기업의 업무 편의성을 높여 주는 강화된 기능의 솔루션을 제공합니다.