Author: sammyosan

Learning to Embrace Recognition and Mitigations of Vulnerabilities as a Strength

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

Virtual Events Amplify NIST’s Cybersecurity and Privacy International Engagements

For the past many months, NIST has taken advantage of the shift to online events to deepen our international engagement. NIST looked overseas as we kicked off our virtual Cybersecurity Risk Management webinar series in May, along with our co-hosts from the Center for Cybersecurity Policy and Law.  The event on May 25 drew registrants from over 70 countries and we shared and heard perspectives on international cybersecurity risk management.  The event featured a panel discussion with speakers from Microsoft, NTT, the National Cyber Security Centre Ireland, and NIST focusing on the release of Technical Specification 27110: Information technology, cybersecurity and privacy protection — Cybersecurity framework development guidelines published by the International Organization for Standardization (ISO), in conjunction with the International Electrotechnical Commission (IEC) in February 2021.  As noted in a recent international engagement update, this technical specification provides guidelines for developing a cybersecurity framework, including the consideration of concepts that align with the NIST Cybersecurity Framework’s (CSF) five functions: Identify, Protect, Detect, Respond, Recover.  The event also included a fireside chat with participants from the National Cyber Security Centre UK, the Global Forum on Cyber Expertise Foundation, and Rapid7 to further explore these themes.  If you were unable to attend, you can view the recording here

.

We also co-hosted a virtual event

open to our stakeholders throughout the world on August 4 focusing on Cyber Supply Chain Risk Management. Senior leaders at NIST and the Office of Management and Budget (OMB) provided updates on the tasks in the President’s May 12 executive order on strengthening cybersecurity related to supply chain security and discussed the work of the Federal Acquisition Security Council (FASC). Additionally, panels comprising government and industry professionals from NIST, the Office of the Director of National Intelligence (ODNI), Lumen, and Microsoft discussed their efforts to help federal agencies manage cybersecurity risks to supply chains. Other experts from industry, including Intel, ITI, and Palo Alto, highlighted some of the best practices they use to secure their own supply chains as well as those of their customers.  If you missed it, please check out the recording of the event here

.  Information on the next event in the series will be available soon.

The NIST CSF increasingly is being used around the world.  The Israel National Cyber Directorate (INCD) leveraged the CSF for its Cyber Defense Methodology; the directorate recently released Version 2.0 of that document, which we link to on our Cybersecurity Framework international resources page. More information on the approach for developing the initial version of this methodology is also outlined in the Success Story that INCD shared.

NIST continues to add new translations to our toolkit of resources, including the latest: a Portuguese translation of the 2020 revision to the National Initiative for Cybersecurity Education (NICE) Framework (SP 800-181r1).  We also now have a Bahasa Indonesian translation of the Privacy Framework. NIST participated in a workshop hosted by the International Trade Administration (ITA) this past May to discuss the Privacy Framework ahead of the release of the translation.

Recognizing the expanded international interest in NIST’s cybersecurity and privacy resources – and NIST’s efforts to engage more deeply in communications with others around the globe – stay tuned for news about updates to NIST’s webpage to offer easier access to these documents as well as links to workshops and other activities relevant to the international audience.

If you have any questions or ideas about our ongoing international engagement or how you can become more involved, please reach out to amy.mahn@nist.gov for more information.

Source: NIST

CISA and NSA Release Guidance on Selecting and Hardening VPNs