To maximize the impact of your security advisories, here are some key steps vendors can take to support automated workflows and timely remediation efforts.
Over the years we’ve seen every variation of security advisory imaginable: plain text, good HTML, bad HTML, machine readable, machine readable with giant blobs of embedded text (which potentially negates the value of the machine readable parts). Regardless of the format in which they are delivered, security advisories are a critical mechanism for providing customers as well as infosec vendors and practitioners the necessary knowledge to ensure vulnerabilities are identified, reviewed and remediated as quickly as possible.
What makes a good security advisory? There are three core data points: vulnerability information, affected versions and potential remediations.
Within each of these is a subset of data that helps communicate clearly the impact and risk, how to know if you are vulnerable, and what specific actions you can take to remediate or mitigate the relevant threats. It’s critical that vendors provide all the necessary information and follow best practices to ensure that their advisories can support automated workflows and timely discovery and remediation of new vulnerabilities.
1. Disclose specific vulnerability details
First off, each vulnerability should be clearly associated with a unique identifier. Ideally this would be a common vulnerability and exposure (CVE) number issued by a CVE Numbering Authority (CNA). When that is not possible, a vendor should provide an internally unique identifier such as a Bugtraq ID. This makes it possible for multiple parties to communicate about the vulnerability without wondering if everyone is talking about the same issue.
For each vulnerability disclosure, the security advisory should also include a detailed description of the issue and the CVSSv3 metrics. This ensures that customers and security vendors are able to clearly understand the impact of the vulnerability and communicate that with others using the industry-standard CVSS metrics, such as Attack Vector (AV) or Exploit Code Maturity (E). Two common pitfalls we see with severity metrics are vendors not including any metrics or developing their own. Both of those force customers to invest additional time in translating these security advisories into usable information.
Ideally, vendors will also include data on the vulnerability disclosure timeline, as well as who disclosed the vulnerability.
2. Identify affected versions and devices
In addition to benchmarking technical severity, customers need to know which versions of a product are impacted by a particular vulnerability to understand whether or not they need to take action. For example, a vulnerability may only exist in a newer version of an impacted product that the customer is not currently running.
It is also critical to communicate any special conditions that must be met for the software to be affected, as well as how customers can determine if that special condition is met. This is particularly true with hardware vulnerabilities. For example, many vulnerabilities in Cisco and Juniper devices are only present if the device is running with a particular feature enabled. Advisories from these vendors will typically include an example of the command users should run to determine if the device has the impacted feature enabled.
3. Clearly explain the remediation options
Unless no fix is available, each affected branch or version should have a clear link to the minimum required version to which a customer needs to upgrade to remediate the vulnerability. If a particular branch does not have a fix, it is equally important to communicate that no fix is available and that customers need to upgrade to a more recent release.
We have encountered many situations where a security advisory is vague about whether a branch has a fix or not, and that leads to many back-and-forth discussions between our support teams and customers. In many cases, the customer is also working with the vendor support team, leading to a significant amount of email and phone tag to untangle what should be a simple and easily available answer.
4. Format your information for both humans and machines
Nearly as important as the content within a security advisory is how that information is communicated. It is important to format security advisories in a way that is useful for humans as well as automation processes. Many vendors succeed at providing the former, but despite several standardized industry reporting frameworks, few provide security advisories in a machine-readable format. (Popular standards include the Open Vulnerability and Assessment Language (OVAL), Common Vulnerability Reporting Framework (CVRF), and Common Security Advisory Framework (CSAF).)
When machine-readable formats are available, it allows security providers and customers to build automated processes around those security advisories. These automated processes can reduce the time to remediate or, at a minimum, reduce the amount of overhead for reviewing and prioritizing newly published advisories. The reductions typically come in the form of automatic prioritization based on the severity of the vulnerability, the impacted versions and the availability of a fix. Any steps that we as an industry can take to reduce the amount of effort required to review and remediate newly published vulnerabilities allow customers to better reduce their overall exposure.
5. Improve accessibility with a centrally indexed dataset
Another component in which we have seen varying levels of maturity is how and where security advisories are hosted. Common channels include mailing lists, forum posts, blog posts, indexed HTML pages and APIs.
While mailing lists are useful for pushing the advisory out to subscribers, any archive of those notifications tends to be plain text, which is challenging for automation and human readers alike. Forum posts suffer from this same limitation, and also tend to get lost in the noise of other forum posts. Blog posts and indexed HTML pages are great, particularly when they are served up from a page that contains an index of previous and new security advisories that users can subscribe to with an RSS feed. From an automation perspective, APIs are extremely useful as they allow us to build targeted queries.
In all of these cases, it is critical to have an easy-to-find location that centralizes access for past and present security advisories. Without a centralized index, it can be a challenging search for customers, which in turn increases the amount of effort required to review and remediate newly published vulnerabilities.
Stronger advisory practices narrow the attacker’s advantage
Providing detailed, well-formatted and easily accessible security advisories makes a significant difference in the customer experience and their ability to quickly identify and remediate new vulnerabilities. When vendors fall short on any of the aspects discussed here, it increases the level of effort for a customer to become aware of new security advisories, understand their associated risks and make informed decisions regarding remediation.
A bad security advisory can make the difference between quick coverage and no coverage. Every delay increases the customer’s exposure time, which in turn increases the risk that the vulnerability in question is exploited by an attacker. Good security advisories empower customers with the information they need to close these critical exposure gaps and reduce risk across their attack surface.
Learn more
- View our Edge Week session, “Tenable Research: Tales of Disclosure”