Historically when I pointed out problems in anything, I wasn’t the best at offering solutions. Sometimes I simply had none because the problem was complex and the solutions I came up with were problematic themselves. Other times I had ideas, but they were fairly high-level and abstract and I didn’t want to be like the vulnerability disclosers offering the vendor fix ideas ala “sanitize input“. Yeah, thanks buddy! In recent years I have begun to have a section at the end that acts as a conclusion along with any suggestions I have for fixing the problem. It’s not that I ever wanted to shout out problems and refuse to try to fix it, quite the opposite.
Jump to the last few years and my uptick in formal blogs and increasing number of LinkedIn posts or replies pointing out systemic flaws in the CVE ecosystem and MITRE’s program. These largely aren’t new problems at all. Rather, it is me trying to formalize the complaint and reach a broader audience to make people aware of the how and why things are as bad as they are because I frequently see a lack of understanding around the CVE ecosystem.
Weeks back someone replied to me asking “Why don’t you propose solutions?” in so many words. I’ve heard it before but usually in a more genuine way such as “do you have ideas on how to begin to fix the problem?” To the five word version of that question I will say non sequitur. My two word reply is considerably more valid than that cop-out of a question. Those words show a deep misunderstanding of the CVE ecosystem and suggest that any one person can fix it. If a single person can, it is the program director of CVE at MITRE. They actually have the power to begin to fix things and slow this sinking battleship; maybe even turn it around too.
But, let’s play this game anyway! I’ll give you the long answer and in the future I ask that you offer up a few more seconds of your time to give me and others a more realistic question. I also encourage you to at least read my profile and notice that I literally have a bit of relevant experience listed. So, where to begin…
I Tried, Part One
Let’s begin with the fact that I was on the CVE Editorial Board (now called the ‘CVE Board’) for 10 years. That is one decade I gave input, in a vocal fashion, on where CVE was falling short and offering solutions. For years I was more vocal and active than the next five people combined. I frequently brought attention to matters that were not being discussed and were often new to other board members. I pointed out when some board members would vote on something in a way that clearly benefited their organization, not the broader community and ecosystem. In some cases they literally said the way they were voting was best for them.
You may say “but you were kicked off the board!” Yes, you are right. But look at the bigger picture there by starting to see who else was kicked off the board at the exact same time. See what we had in common (we both worked at RBS), despite me being an individual representation on the board officially. The other person had a flawless history of not being overly vocal, not digitally screaming trying to get people to listen, and was a model board member for ten years. You can dig up the official reason given on the board list if you’d like, it’s public, but I can assure you that it is an anemic cop-out answer that does not speak to the real reason we both got booted.
I then invite anyone from MITRE to publish the actual reason we did. Something I have stayed quiet on for now but will go public with at some point. The cliff notes answer was a form of financial politics at play, and booting the two of us from the board had no bearing on anything to do with it. That action could not serve any purpose in addressing MITRE’s real concerns and was extremely shortsighted.
I Tried, Part Two
Out of respect for this individual at MITRE, I won’t provide a name or go into much detail, other than to illustrate a point. For most of the time I was on the CVE Board, it was seen as a conflict of interest by my business partner at RBS. He was frequently not happy with my participation because I was telling MITRE how to improve CVE, while CVE was our primary competitor. Not because the data was good, simply because it was free. To this day I have certain obligations through work that restrict me in a few ways. Not many mind you, because I will continue to be vocal even if it costs me my job.
Somewhat recently, someone from the CVE team reached out asking if I would be willing to come talk to their team. Basically to “show them what’s wrong” and offer my ideas how to fix it. I was surprised and suggested that would never happen, that specific people at MITRE still don’t care for me. They indicated they were in charge enough to guarantee that could happen and asked if I would fly there to do it. I said unfortunately due to those limited work conflicts, I couldn’t take time to fly across the country to help a competitor. So I offered to do it via Zoom instead, and said I was happy to spend whatever time needed to assist. That offer was already borderline career limiting as I was still offering to help a competitor.
They replied no, it had to be in person, so we were at an impasse. To this day I genuinely do not understand why that help had to be done face-to-face, why doing a presentation or a group Q&A over a virtual meeting was a show-stopper. So that glimmer of hope fell through quickly. I would still be more than happy to do it virtually, to this day. The help I have to offer isn’t really helping the competition in a meaningful way, as pertains to the database I work on. It helps the entire community, us included, but wouldn’t cause any of our customers to leave us for CVE. The difference in our offering is substantial in depth, breadth, and timeliness.
I’m Trying, Part Three
As many have seen, I spend a lot of time writing lengthy blogs full of citations and supporting data to back my points. That time spent is considerable and it is free for everyone, MITRE included. I know that some of my blogs have been passed around internally there and I know some have been shared in the CNA circles. I’m glad to hear that and I hope they help bring a better understanding to not only the problem, but the immediate resulting impact it has on the ecosystem.
The handful of presentations I have given, one with a co-founder of CVE while he was managing the program no less, are another way I try to help. If he saw value in my input that is a glowing endorsement in my eyes, as he is one of the top vulnerability database experts in the world. I hope that anyone reading this appreciates how much time goes into a blog, let alone a 45 minute presentation, all without real compensation. I don’t blog and present to make money; you’ll notice my web site never had ads on it, not for 25 years now including when we enjoyed 1+ million hits a day (a lot at the time).
What If It Can’t Be Fixed?
It constantly amazes me that people in our industry have a defective device, send it in for warranty, and find out the device can’t be repaired. It gets thrown out and they get a new one if covered or go out of pocket to replace it. Things break in ways that cannot be fixed. Sure, that cell phone or laptop are complicated pieces of technology yet we don’t have the power to fix some problems that routinely surface on them. When a bad power supply melts a component? You bet it won’t be fixed, it will be replaced.
So why does everyone assume that the CVE ecosystem can be replaced? This isn’t necessarily a “devil’s advocate” question either. While it is designed to make you think, it may be a no-bullshit assessment in the form of a question. Some complex systems cannot be fixed, or if they can, it takes a miracle of unseen size to do so. Society can’t diagnose or treat a wide variety of physical and mental issues to this day. If we can’t “fix” one person, it stands to reason that a hybrid human/technical system like CVE might be unfixable as well.
Let’s look at a brief case study of sorts that illustrates my point. Consider ‘Echobot’, a piece of malware that exploits a considerable number of vulnerabilities in an automated fashion. At the time of that article it was exploiting 71 different vulnerabilities, all being actively exploited, all the definition of ‘KEV’ (Known Exploited Vulnerabilities), and most of them more than a few years old. Now look more closely at the list and notice that we see ‘Unassigned’ for many, meaning they don’t have a CVE ID. One of them without a CVE ID goes back over twenty years. How does that happen? How many opportunities were there for a CVE ID to be assigned to them? This is a case of many, many people falling asleep on duty.
We know MITRE isn’t proactive, they don’t monitor any sources and solely rely on people coming to them. That is the first problem that has to be fixed. Second, that article was written by a company that is a CNA. While the software in question is out of their scope, they apparently never reported it to the CNA of last resort, which is MITRE. If you can’t trust CVE to track well-documented KEV, how can you trust it for its intended purpose? How can so many people not understand how far it falls short?
MITRE Has to Want It
Even if the CVE ecosystem can be fixed, it can’t be done unless MITRE wants that to happen. During my time on the board I gave considerable feedback on ways to improve the ecosystem, some fairly easy, some requiring a larger effort. I cannot remember a single time my advice was acted on; instead, MITRE seemed to actively resist that input and in some cases, attempted to silence me. I was told by someone internally that they also sent my emails directly to them to /dev/null, meaning they ignored me pointing out errors, typos, and more.
It is important to remember that MITRE exclusively enjoys government contracts that are non-compete, and have very little oversight. The last time MITRE had oversight on the CVE program was around seven years ago and it passed quickly when MITRE responded to Congress in a letter that they refused to share with the community, even the CVE Board. That brings up the point that the community is the only real oversight. During my tenure on the board, one term MITRE consistently used was ‘stakeholders’, speaking to those who used or participated in the CVE ecosystem. That means users, CNAs, and companies that rely on the data. Those are the ones that need to step up and demand better from MITRE.
