Advisories and How to Use Them

All these topics are crucial for the OT vulnerability management database that we provide – which is included in GridOps, the central management system of our OT intrusion detection system (IDS) StationGuard. If you are planning on implementing a vulnerability management in your own system, this article will be particularly helpful.

First, let’s clarify what an advisory and CSAF are. An advisory is a document detailing known security issues and vulnerabilities affecting products, typically published by the vendor developing the product. CSAF, or the Common Security Advisory Framework, is a machine-readable standardized format for advisories, making it easier to handle and process this information. CSAF utilizes the JSON format.

Identifying which vulnerabilities affect your systems is a critical step after identifying the devices within your network. But how do you gather all the relevant security information about your network devices? Through advisories, of course. They help identify the actual vulnerabilities a system faces, assuming the asset information is accurate. Instead of manually determining which CVEs (Common Vulnerabilities and Exposures) apply to you, advisories allow you to simply compare your asset information with the advisories' content. So, how do vendors provide these advisories?

Often, we encounter PDFs and HTML sites with security advisories. But relying on PDFs and HTMLs alone is not efficient. This is where CSAF comes in. As the successor of the CVRF (Common Vulnerability Reporting Framework), CSAF aims to standardize the way advisories are written and provided in a machine-readable format. This allows customers to identify and handle vulnerabilities in their systems automatically, without spending countless hours sifting through PDFs and HTML pages. With CSAF adoption by some vendors, vulnerabilities can be tracked more efficiently, significantly reducing the number of advisories you need to manually review. For everyone who works with vulnerability matching, the time-saving is incredible.

However, creating CSAF advisories is a step in the right direction, but it doesn’t solve all problems. Poorly written CSAFs can’t be effectively used in an automated manner without prior cleanup. And as with every framework, it will be used differently by various companies and individuals – and as more people work with it, more individual interpretations will arise.

Now that we have covered the basics, let us address the common pitfalls with advisories and the specific problems you might encounter with CSAF. 

Advisories can be unpredictable – you never know what you're going to get. While most advisories are useful and well-written, making it clear what the problem is, some can be problematic.

Occasionally, we come across advisories that disrupt our matching process due to unconventional decisions behind the product development or the advisory itself. For instance, some products might consider version 8.2 to be higher than 8.10, which complicates numerical sorting. Changes in versioning schema during a product’s lifecycle can also create automation issues. These examples highlight why vulnerability matching can be tricky to get right.

Besides errors or poor practices in the content of advisories, there are challenges related to how these advisories are published. As a group interested in collecting advisories, we face three main problems:

First, rate limiters on webpage access prevent automatic retrieval of advisories from some vendors. This is especially frustrating for vendors who don't provide RSS feeds or similar notifications for advisory updates. Most of the time, we can address this by throttling downloads, but being denied access when trying to download advisories is frustrating. Providing advisories through other means than website downloads could be beneficial.

Next, JavaScript redirects make automated downloads of advisories a real pain. For example, downloading of the advisories via a tool like curl will just result in a bunch of redirect pages instead of CSAF files. There’s a reason why CSAF recommends against using redirects for advisory publications and only allows HTTP redirects if they are inevitable.

Lastly, and perhaps most annoyingly, is localization. Some advisories are published differently in other languages or not at all. This isn’t the first time this vulnerability has been published, but it might be the first time you’ve encountered it. There is nothing more frustrating than finding a new advisory that’s actually an old one, simply because it wasn't published on the page you were looking at due to localization differences.

Additionally, vendors still don’t properly notify users about new advisories or changes. We have explored all the options, from web table entries to email notifications and RSS or Atom feeds. Of all these methods, RSS and Atom feeds are the most user-friendly because they notify you of changes. With other methods, you often have to manually check for updates. Of course, this is high-level complaining, especially since everyone is still busy refining the CSAF publication infrastructure.

All the challenges mentioned above could be significantly improved with the introduction of a CSAF publisher infrastructure. Being a CSAF provider ensures easy and proper access to advisories without the previously mentioned issues. 

However, CSAF itself isn’t a one-size-fits-all solution. Publishing CSAF doesn’t automatically make advisories machine-readable. That’s where we come in. We collect advisories from relevant vendors within our field, then create, validate, and sanitize these advisories to ensure they can be matched to our users' asset inventories.

CSAF is the best format we currently have to automate vulnerability matching and management. Naturally, this approach can present a range of challenges, both new and familiar. But we have been there, done that, and we are committed to making it work effectively for you.

So, let us elaborate on the challenges we have encountered with CSAF. Because, even if you thoroughly follow CSAF, you might still end up vulnerable. 

CSAF divides the files into three sections: Document, Product Tree, and Vulnerabilities.

Let us go through these one by one.

This approach uses CSAF’s full potential by clearly defining the relationships between products and their components. There are numerous other known pitfalls within the product_tree section. If you're interested, feel free to reach out. We have plenty of stories and insights to share.

One example that comes to mind is referencing wrong or too generously, which can render specific entries in the affected products field obsolete. Additionally, referencing all versions along with specific ranges in the known affected field can cancel out other version references, causing problems when trying to match them later. These are but a few special cases, and these are definitely not all of them. So, how does a system administrator use all the information collected via PDFs, HTML advisories, and hopefully quite a few CSAFs? 

They usually utilize specialized tools that leverage experience and knowledge collected while working with these advisories. We have assembled over 4000 advisories and adapted, created, and fixed more than a thousand of them. With all this accumulated experience and knowledge, we can support our customers and propagate the problems we encounter in these advisories to the respective vendors to ensure that critical infrastructure can be protected to the best of our collective ability.

And because we have to end it somewhere, we’re stopping here. Not because we don’t have more observations to share or special cases to look at. We could do this all day. But if you read this far, you might be interested in either reading more about CSAF – maybe even writing one yourself – or start looking for ways to actually work with them. You might be interested how the OMICRON cybersecurity products incorporate all our expert knowledge – if so, you can take a look at our StationGuard and GridOps solution.