© 2021 — PANTHERGON Cyber Security. All Rights Reserved.
As a global security company, Trend Micro is definitely not a stranger to offensive vulnerability discovery and disclosure for bugs. Finding a vulnerability, reporting, and writing about it via responsible disclosure is something that we were very familiar with. Every so often, we would even drop an occasional 0-day if a vendor were not serious about addressing a critical security issue.
However, for some reason, whenever the shoe was on the other foot—meaning researchers came to us with possible vulnerabilities in our own technology—our previous inclination was to try and bury the news and hope it wouldn’t get many eyes.
Being an organization with both offensive and defensive vulnerability responsibilities definitely presents unique challenges. One thing that accelerated our need to better organize and handle incoming vulnerabilities was the acquisition of TippingPoint in late 2015, which included The Zero Day Initiative (ZDI) the world’s largest vendor-agnostic bug bounty program. Like TippingPoint’s previous parent (HP), the acquisition of ZDI put a bullseye squarely on the back of Trend Micro, and shortly thereafter we started to see an influx of vulnerabilities reported against several of our products.
Prior to the acquisition, the number of reported vulnerabilities per year was minimal. But one thing that became a constant was that researchers were not only expecting to be formally recognized via attribution in disclosure, they were expecting a CVE ID to be issued.
Interestingly enough, when ZDI was researching and negotiating to become a CVE Numbering Authority (CNA), they asked if Trend Micro would also be interested in potentially becoming a CNA (note: ZDI and Trend Micro act as completely separate entities when it comes to CVE ID assignments and vulnerability disclosure). As you can imagine, even though it was a slam dunk for ZDI to pursue becoming a CNA, it was not as obvious a path for Trend Micro’s vulnerability response team to pursue. From a defensive perspective, there was still a strong belief by some that trying not to draw attention to vulnerabilities via the exposure of issuing more CVE IDs was the way to go. Frankly, in the beginning, I admittedly was also in this camp.
“It’s going to add too much overhead,” “we are going to get a ton of bad press,” and “we are going to experience a huge surge in case volume” were the chorus of initial pushback that was offered up. But as we begrudgingly started to investigate what the steps were to become a CNA and the benefits, a lightbulb went off:
We would be able to not only control our own destiny, but could show our customers and the security industry that we are not afraid of our faults and weaknesses and can learn and grow stronger from them.
Again, because of our experience with offensive research, we know quite well that even with the best of intentions and the best security coding practices—vulnerabilities are a reality of code development. There are always new and novel ways that researchers (and the bad guys) can analyze code and find weaknesses. By owning up to them and being able to resolve them via responsible disclosure, we can much better protect our customers and users by limiting their exposure as best as possible. Because CVE is the de facto standard (e.g., the “common language” of vulnerability disclosures)—we can ensure that we can effectively communicate to our users the need to mitigate and patch.
Once we became a CNA, it wasn’t just a matter of integrating CVEs into our regular disclosure process—that part was pretty straightforward. In the beginning, the whole process of having to do an additional CVE ID submission with a specific format in additional to our regular security bulletins seemed like it was adding extra overhead; but in retrospect, by frontloading the work—meaning ensuring that our own security bulletins used most of the required CVE ID submission information—we were able to improve the quality of our own bulletins as well as streamlining the overall disclosure process. CVEs are great in that they can just as easily be used for internal cataloging as well as external disclosure.
A lot of the real value we realized in the program was in the interactions with other CNAs—many of our peers (and competitors), as well as those beyond our own industry. Joining some of the ample workgroups in the CVE Program has allowed us to share ideas and realize that some of the challenges we faced were not unique to us. The combination of the largest companies and smaller ones allows many voices to be heard—as well as the inclusion of vulnerability hunters and research organizations that give us insight into what they are looking for and their struggles with vendors such as ourselves. The CNA program is comprised of an organized group of like-minded security professionals, and it is very easy to contribute to, and gain a lot in return. The experiences not only have improved our overall vulnerability response, but we have been able to apply some of our learnings to enrich our overall proactive secure development processes to stamp out potential issues in early development stages.
As security breaches and exploits become an all-too-common headline in recent days, vulnerability discovery and disclosure are an increasingly important and very visible part of the landscape. Accepting and owning up to flaws, as well as learning from the experiences of mitigating them, allows you to become even stronger and more mature.
Being part of a community such as the CNA program tells your customers and your peers that you are serious about vulnerability management and mitigation, as it helps add extra credibility to your words and actions. Becoming a CNA enabled us to not only continue to learn and grow as an organization, but also gives us the opportunity to show leadership in the security community and industry.
Source: CVE Blog