Every other day I find myself reading about a new breach, hack, leak of data, nation-state attack or vulnerability being actively exploited––I think it’s fair to say that cybersecurity has become mainstream. This brings a lot of benefits to our industry as more and more people will begin to understand or at the very least, consider security as they go about their days.
With the increased public attention, it’s only natural that the ways in which we communicate our going to evolve. One trend that I’ve recently noticed some security researchers doing is to treat their vulnerability findings like a product release. That is to say, they have a dedicated website complete with copy, demos, logos and frequently asked questions. While some mock this approach, as a product manager and security practitioner, I see a lot of benefits to marketing vulnerabilities.
But don’t you speak CVE?
If you work in security long enough, you eventually find yourself speaking the wonderful language of Common Vulnerabilities and Exposures, lovingly referred to as CVEs, in order to communicate about vulnerabilities. It could be your manager asking, “Have we seen 2019-0708 actively exploited against our systems yet”, or a peer claiming it’s just another “0158” attachment. On the surface, these numbers give little context, but if you’re in the know, you recognize the vast complexity they represent.
As a practitioner, I find CVEs to be a wonderful reference, but recognize they are not perfect and come with a few challenges.
- Every year, thousands of new unique identifiers (CVEs) are created to encompass vulnerabilities that have been disclosed. When a severe bug is identified, it gets the same treatment as any other in terms of publishing, thus, sometimes being lost in the noise.
- Absent a “friendly” name, I am left to use the assigned unique identifier or attempt to describe (ex. “the new RDP bug”) the vulnerability when engaging with my peers or management.
- The source of truth for a CVE depends a bit on the CVE Numbering Authority and what they choose to include along with how they format their publishing. Not all the information I may want will be at the source and I may need to seek information elsewhere.
I personally find a lot of value in CVEs despite these issues, though believe the recent supplemental marketing approach aids in improving our dialog as professionals.
To illustrate the value in marketing vulnerabilities, I’d like to use the recent example of ZombieLoad — officially assigned CVE-2018–12130. Unlike most CVEs which just remain an identifier, Graz University of Technology––those behind the disclosure––decided to label the bug with a catchy name and creation of a formal website.
Benefits Within the Marketing
- A catchy or formal name is easier for communication. The use of ZombieLoad in this example has a number of surface benefits. It’s a name that is unexpected and likely to draw attention, it’s far easier to recall than using CVE-2018–12130, and it cleverly describes the vulnerability that can be exploited.
- A dedicated website serves as a single source-of-truth. The first search result for “ZombieLoad” is a dedicated website for the vulnerability. Users can download the research paper, test the attack (linked directly to code in Github) or begin answering questions they may have.
- Messaging is impact driven, less technical driven. The ZombieLoad website is well-formed and describes the vulnerability in a straight-forward way. Instead of focusing on the technical nuances of the vulnerability, its authors summarize their findings and put the common questions most people may have upfront.
- Credits and acknowledgments are clear. Finding vulnerabilities can be a laborious process that doesn’t always result in success. Those who find a bug should get proper credit for doing so along with anyone else who aided their research or helped fix the bug.
So…Market All the Vulnerabilities?
All the vulnerabilities, no, I don’t think that’s worth the effort. But major vulnerabilities that could impact millions of users, yes, I think it makes sense. In the case of ZombieLoad, Spectre, Heartbleed, and Meltdown, I believe the industry benefitted from the marketing efforts that took place. At the very least, I can say for sure that I’ve heard those names come up far more in conversations than any given set of CVE identifiers.
The million dollar question is if the marketing efforts were successful in getting patches applied any faster than without. I am not qualified to answer that question, but want to believe up-leveling our communications around vulnerabilities can lead to improved adoption of security controls.
At the time of writing this post, CVE-2019–0708 (ironically being called BlueKeep), a serious flaw found within Microsoft’s Remote Desktop Protocol (RDP) that could allow for an attacker to perform remote code execution (RCE) without any user interaction, is top of mind. Would we benefit from giving that vulnerability a website, logo, and detailed explanation of the risk with FAQ? Again, it’s not clear, but a company like Microsoft is in the best possible position to test the idea and measure results. It would be interesting if they ran with the idea!