Security Bloggers Network 
SBN

Tracking CVEs in real time

by David Michael Berry on May 24, 2024

Following up on the direction of my last post cves-the-double-edged-sword, where I explored digging for CVEs by vendor, I want to go a step further and stay current with any and all CVEs as they are published.

My rationale is simple. In any environment there are multiple vendors, and it’s not uncommon for companies and departments to be tasked with taking on pre-existing infrastructure via mergers and acquisitions…

Simply put, the environment you manage today may look very different in the near future. Why not already have the data on any CVEs at your fingertips?

Sometimes the best opportunity to “do something” about aging or less than optimal systems is precisely this moment, when it’s being handed over. You could be faced with answering the question of “Is it worth maintaining? If so, should we upgrade? Or, should we replace all this?”

If something is already end-of-life and end-of-support, you’re going to want to go with the replacement option. However, if not, knowing what kind of CVEs are present can help you prioritize an upgrade and maintenance path. These things can take time to plan and execute properly, so knowing where you priorities are will help you focus on the most critical upgrades first.

Staying Current with CVEs

We can continue on with the same basic format of using the NVD API and leveraging python requests to fetch the data. A few prerequisites:

  • We should store the output as json and rotate the logs once a maximum size (I’ve decided on 5MB) is reached.
  • We should retain a certain number of backup files. While the intention should be to ship the logs to a SIEM solution, there may be times where we need to re-populate the data in the SIEM. Once the code proves stable we can expand the number of logs to keep and even look at archival.
  • We will also need to record (separately) the result of a ‘fetch’ in order to debug any issues with API requests or rate limits.
  • We should log the timestamp of the current fetch operation. Then, upon a subsequent iteration, it should use the ‘last fetch’ timestamp as the CVE published start date. This will allow us to pick up CVEs published since our last run. If there is no ‘last fetch’ time recorded, the code should gather a pre-defined interval, such as 1 day.
  • We should also use the current timestamp as the CVE published end date. By defining the start and end dates, we can get all CVEs published in between these times. Referencing the required parameters of the NVD API, we need BOTH the pubStartDate and pubEndDate: https://nvd.nist.gov/developers/vulnerabilities
  • Lastly, we should set the script to run daily via crontab. That way there is never too great a time gap where the CVEs published are too numerous to fetch.

Here is the code I eventually came up with:

https://github.com/David-M-Berry/cve-analyzer/blob/main/nvd-cve-json-polling.py

Test Run

A note about the results. My test machines timezone is set to MDT, however I am using timestamps for the ‘last fetch’, ‘pubStartDate’ and ‘pubEndDate’ in UTC.

Our results are recorded to cve_log.log

We can see published timestamps are our start and end dates:

And… we have some rich data to extract and analyze further:

Next, we’ll explore extracting and plotting details from the CVEs, as well as POCs from the references for each. This may give us valuable insight into whether some of these are actively being exploited…

*** This is a Security Bloggers Network syndicated blog from Berry Networks authored by David Michael Berry. Read the original post at: https://berry-networks.com/2024/05/24/tracking-cves-in-real-time/

David Michael Berry , , , , , ,