Posted by:

David Greenwood

David Greenwood, Chief of Signal

If you are reading this blog post via a 3rd party source it is very likely that many parts of it will not render correctly. Please view the post on signalscorps.com for the full interactive viewing experience.

In this post I will show you how STIX Sighting and Observed Data Objects can be used to model products you use that are vulnerable.

Note: Vulmatch is an ever evolving product therefore the concepts described in this post might not always be relevant for the latest version.

When Vulmatch detects a product a user has selected has been observed as vulnerable (in a CVE configuration) an alert is raised.

In sticking with the STIX specification, alerts are also represented as STIX Objects in Vulmatch.

If you are new to STIX Sightings, the general concepts are covered in my tutorial OASIS STIX 2.1 102: Relationships.

In Vulmatch, when an alert is raised both a Sighting SRO and Observed Data SDO are created for it in the following format;

Sighting:

        {
            "type": "sighting",
            "spec_version": "2.1",
            "id": "sighting--<GENERATED BY STIX2 LIBRARY>",
            "created_by_ref": "identity--<SIGNALS CORPS IDENTITY ID>",
            "created": "<TIME OF ALERT>",
            "modified": "<TIME OF ALERT>",
            "sighting_of_ref": "indicator--<VULNERABILITY INDICATOR ID THAT TRIGGERED ALERT>",
            "observed_data_refs": [
                "observed-data--<OBSERVED DATA ID FOR ALERT>"
            ]
        }

Observed Data:

        {
            "type": "observed-data",
            "spec_version": "2.1",
            "id": "observed-data--<GENERATED BY STIX2 LIBRARY>",
            "created_by_ref": "identity--<SIGNALS CORPS IDENTITY ID>",
            "created": "<TIME OF ALERT>",
            "modified": "<TIME OF ALERT>",
            "first_observed": "<TIME OF ALERT>",
            "last_observed": "<TIME OF ALERT>",
            "number_observed": 1,
            "object_refs": [
                "software--<SCO ID THAT TRIGGERED ALERT>"
            ]
        }

Single node matches

Let me demonstrate with an example using CVE-2022-29098: https://nvd.nist.gov/vuln/detail/CVE-2022-29098

Here is what the CVE looks like modelled in STIX without alerts shown;

There are 6 alerts triggered by this CVE, all configurations contain one Software Object.

The logic of the CVE CPE configurations reads as follows (also found inside the Indicator SDO Pattern);

  1. Dell PowerScale OneFS (version 9.0.0) (application) [application vulnerable to CVE] OR,
  2. Dell PowerScale OneFS (version 9.1.0) (application) [application vulnerable to CVE] OR,
  3. Dell PowerScale OneFS (version 9.1.1) (application) [application vulnerable to CVE] OR,
  4. Dell PowerScale OneFS (version 9.2.0) (application) [application vulnerable to CVE] OR,
  5. Dell PowerScale OneFS (version 9.2.1) (application) [application vulnerable to CVE] OR,
  6. Dell PowerScale OneFS (version 9.3.0) (application) [application vulnerable to CVE]

It is important to point out here; Vulmatch alerts are not unique to users. A user subscribes to products (via their CPE configurations). Alerts are triggered against products listed as vulnerable in a CVE (which many users can be subscribed too). If a CVE a triggers an alert for a product, any user subscribed to that product gets the same alert (defined by Sighting and Observed Data ID).

Take the same CVE as the previous example, but this time from the point-of-view of a user subscribed to the Dell PowerScale OneFS (version 9.0.0) product (but not any other versions);

They would see one alert (Sighting and Observed data), because the Dell PowerScale OneFS (version 9.0.0) appears once in the CVE CPE configuration as vulnerable.

Put another way, the user only sees alerts for the products to which they are subscribed.

If they were subscribe to Dell PowerScale OneFS 9.0.0 and Dell PowerScale OneFS 9.1.0;

The actual reality is that the CVE has 6 alerts (one for each product configuration in the CVE) linked to it. The user is only exposed to the ones they are subscribed. Here is what the entire CVE looks like showing all possible alerts;

Multi node matches

In the part two of this series of post I described how the Vulmatch logic works to match CVEs to CPEs. In short, it matches user selected CPEs to any CPE shown as vulnerable = true in the CVE configuration.

Let me demonstrate with another example where CVE CPE configurations contain more than one CPE in the flow where only some are vulnerable. I will use CVE-2019-18939 for this; https://nvd.nist.gov/vuln/detail/CVE-2019-18939

Here is what the CVE CPE configurations looks like for this CVE modelled in STIX.

There are 4 possible distinct match configurations for this CVE that can be written like so (see patterns for each inside the Indicator SDO above);

  1. eQ-3 Homematic CCU2 (hardware) (version unspecified -) AND EQ-3 HomeMatic CCU2 version 2.47.20 (firmware) AND HM Print Project HM Print version 1.2a (application) [firmware and application vulnerable to CVE], OR,
  2. eQ-3 Homematic CCU3 (hardware) (version unspecified -) AND EQ-3 HomeMatic CCU3 version 3.47.18 (firmware) AND HM Print Project HM Print version 1.2 (application) [firmware and application vulnerable to CVE], OR,
  3. eQ-3 Homematic CCU3 (hardware) (version unspecified -) AND EQ-3 HomeMatic CCU3 version 3.47.18 (firmware) AND HM Print Project HM Print version 1.2a (application) [firmware and application vulnerable to CVE], OR,
  4. eQ-3 Homematic CCU2 (hardware) (version unspecified -) AND EQ-3 HomeMatic CCU3 version 2.47.20 (firmware) AND HM Print Project HM Print version 1.2 (application) [firmware and application vulnerable to CVE]

As an example to demonstrate an alert, lets assume a user has selected the product EQ-3 HomeMatic CCU2 Firmware 2.47.20 (cpe:2.3:o:eq-3:homematic_ccu2_firmware:2.47.20:*:*:*:*:*:*:*).

This CPE appears in two match configurations (1. and 4. above). Here are these two configurations modelled in STIX (without alerts);

In both configurations in this CVE, EQ-3 HomeMatic CCU2 Firmware 2.47.20 is marked as vulnerable, therefore, the user would receive two distinct alerts (remember an alert is represented by Sighting and Observed Data Objects). These two distinct alerts modelled in STIX look like this;

Finally, changing the example slightly.

This time lets assume a user is only subscribed to eQ-3 Homematic CCU2 (hardware) (version unspecified -).

This CPE appears in two match configurations (1. and 4.) and thus in the Indicator Pattern, however, in both examples it is marked as vulnerable = false in the configuration, thus no alerts would be triggered for this CPE in this CVE.

Next time: Enriching CVEs with other frameworks

Once an alert has been raised, it needs to be triaged, investigated and ultimately patched. There are lots of other open data sources that can be used to further describe and categorise CVEs to help an analyst perform this process.

In the next post I will show you the data sources used by Vulmatch, and how to model these as STIX Objects.




Our brand new Discord!

Like this blog?

Sign up to receive new posts in your inbox.


Stixify

Stixify. Extract machine readable intelligence from unstructured data.

Extract machine readable intelligence from unstructured data.

Obstracts

Obstracts

Turn any blog into structured threat intelligence.


Vulmatch

Vulmatch

Know when software you use is vulnerable, how it is being exploited, and how to detect an attack.

SIEM Rules

SIEM Rules. Your detection engineering database.

View, modify, and deploy SIEM rules for threat hunting.