Vulnerability Symptoms

[tschmidtb51]

This issue is meant to provide more details to the Vulnerability Symptoms proposed in #185 by @wrideout.

---

Vulnerability Symptoms

Currently any symptoms which accompany or otherwise indicate a vulnerability or exploit may be recorded via the use of the Notes attribute of the Vulnerability type. In some cases it may be advantageous to provide an optional, dedicated attribute for symptoms in the Vulnerability type. Information which may benefit from a dedicated "symptoms" attribute include but are not limited to logs which indicate exploits, and configuration which exposes the vulnerability.

Required Configuration

This attribute specifies that the data following is device configuration which is required for the vulnerability to exist. In the event that a device does not have a text-based configuration or command-line-interface, this may be a description of configuration actions which need to be taken in order to expose the vulnerability, i.e. steps taken within a graphical UI.

Exploitation Logs

This attribute specifies logs, as a regular expression, which would indicate that the exploit has been carried out. This attribute does not specify the location of the logs, as that is implementation and vendor-specific.

The use of a dedicated "symptoms" attribute could resemble the following example:

"vulnerabilities": [
    {
       "symptoms": [
          {
             "type": "log",
             "detail": "a regular expression which matches a log string"
          },
          {
             "type": "configuration",
             "detail": "some config which exposes the vulnerability for exploitation"
          }
       ]
...

The use of the types "log" and "configuration" would be specified by an enum for use with the new symptom type enclosed by the "symptoms" attribute above.

[tschmidtb51]

@wrideout: Thank you for your contribution.

[tschmidtb51]

Regarding the required configuration: This is a very good point. However, I think that it should not be part of the vulnerability section. To me that should be addressed somewhere else, e.g. the product_tree or a new sibling property configuration_tree. This would allow to form a new product_id which than can be referenced in multiple fields across the vulnerability section. See example:

  "product_tree": {
    "branches": [
     // ...
                    "name": "C.D",
                    "type": "product_version",
                    "product": {
                      "product_id": "CSAFPID-0001",
                      "name": "Example Company Family A Product B C.D"
                    }
    ],
     // ...
    "configurations": [
      {
        "full_product_name": {
          "name": "Example Company Family A Product B C.D with configuration E",
          "product_id": "CSAFPID-0002"
        },
        "product_reference": "CSAFPID-0001",
        "relates_to_configuration_reference": "CSAFCID-0002",
        "relationship_type": "installed_with"
      }
    ],
     // ...
   },
   "configurations": [
     // ...
    {
       "configuration_id": "CSAFCID-0002",
       "name": "Configuration E",
       "type": "user"
       // other configuration information here
     }

I remember that configuration management is not an easy task - are there any standard that we can refer to?

[tschmidtb51]

Regarding the Exploitation Logs: What is the difference between your suggestion and an IoC? Could you please provide an example? I feel like I'm missing something...

IMHO: If you find an exploit string in your log it doesn't tell anything about a vulnerability being present or not. I find various Wordpress exploits in my web server log - but I don't even run Wordpress... Even if I did, I could have already patched it which means I still log the exploit string but it has no effect...

[erahn]

The intention behind the exploitation log is to treat this as an indicator of compromise (IoC), if I am understanding you correctly. tschmidtb51, you are correct that just the presence of a log, say for a malformed HTTP GET, does not indicate a vulnerability being present. The intention behind this is to let an administrator understand if they device they are in charge of is being attacked by the vulnerability.

As an example, lets use CVE-2020-9283 ( https://groups.google.com/g/golang-announce/c/3L45YRc91SY/m/ywEPcKLnGQAJ ). This is a panic in Golang's SSH package caused by passing a malformed key. The exploit log in this case would be to show the traceback caused by the panic when the CVE is exploited. This seems to be the same in intention as an IoC. From what I can grok from the standard, there is no current IoC field. Would it make sense to rename this as some sort of "IoC" field and add it that way?

[wrideout]

@tschmidtb51 I think your suggestion that a new property "configuration_tree" be added is a good one, especially since it would mean the configs therein would be reference-able via product_ids elsewhere in the doc. I'm not aware of a standard for configuration management as of yet, but I'm not sure that it is needed here? If company A puts out a CSAF document for some issue, then the config would be only applicable to devices from company A. That is, of course, assuming you were thinking about a cross-vendor configuration specification-- if you weren't I apologize and the point is moot.

Perhaps given the (perceived) lack of specifications for config management, we should instead specify one for CSAF? Something like the following may be a good starting point:

{
       "configuration_id": "CSAFCID-0002",
       "name": "Configuration E",
       "description": "Some short description of the configuration changes herein"
       "config": "Either text description of steps in a GUI, or text for use in a CLI."
}

The use of "free-form" text is a bit gross IMHO, but I don't know how else to accommodate both backend-CLI systems and systems which are only/primarily configured via a GUI. It's hard to automate, but if the intent here is to provide instructions which also may be read, then it's ok?

I did omit the "type" attribute that you had suggested, mainly because I'm not 100% what the intent of including it was. Can you elaborate?

[tschmidtb51]

@wrideout:

I'm not aware of a standard for configuration management as of yet, but I'm not sure that it is needed here? If company A puts out a CSAF document for some issue, then the config would be only applicable to devices from company A. [...] Perhaps given the (perceived) lack of specifications for config management, we should instead specify one for CSAF?

Where ever possible, I would like to stick to existing standards. This prevents reinvent the wheel and making the same mistakes other have done before. Moreover, it is a hard problem for an end user if he needs for each company an extra parser to interpret the content of this object. (It didn't workout well for the human-readable advisories that's why CSAF was started ;-)) We are looking a hundreds of issuers of CSAF documents - therefore this should be well-wrought. Furthermore, we need the tool support on both sides (issuer and end user) which becomes more complex if you can use it only for CSAF.

The use of "free-form" text is a bit gross IMHO, but I don't know how else to accommodate both backend-CLI systems and systems which are only/primarily configured via a GUI.

We could use a type-of-system approach here: Defining certain attributes for the configuration itself and having the system-specific ones below:

{
   "configuration_id": "CSAFCID-0002",
   "name": "Configuration E",
   "type": "user"
   // other configuration information here
   "cli": {
       // cli configuration information here
   },
   "gui": {
       "details": "Details how to configure"
       // gui configuration information here
   },
 }

I did omit the "type" attribute that you had suggested, mainly because I'm not 100% what the intent of including it was. Can you elaborate?

Sure. Sometimes there are different levels of configuration. Git for example knows 3 of them:

• global (which is in ~/.gitconfig)
• system (which is in $(prefix)/etc/gitconfig)
• local(which is in .git/config)

Other programs also have a system-wide, user-specific and project-specific config (e.g. IDE like VSCode). The problem might be only in one of them or in a (certain) combination of them. Does this explain my thoughts?

[tschmidtb51]

@erahn: Thank you for your participation in the discussion.

From what I can grok from the standard, there is no current IoC field. Would it make sense to rename this as some sort of "IoC" field and add it that way?

This is correct - we don't have an IoC field. However, there are quite a few standards out there which support IoC sharing (just naming a few):

• MISP
• STIX/TAXII
• YARA

IMHO IoC sharing should not be the focus of CSAF since other solutions exist and work well. I would probably prefer to link to such events / items / rules via references[].

Thoughts?

[sthagen]

Yes. References to me just sits right!

[tschmidtb51]

If we find later on that it is used extensively, we could introduce an property ioc:

"ioc": {
   "$ref": "#/definitions/references_t"
},

[wrideout]

Hi all, apologies for the time gap since my last participation.

My understanding of this is that with regard to the ioc, we could either put it under the references list under the vulnerabilities property, or create a new ioc property under vulnerabilities. It may be nice to have a dedicated ioc property under the vulnerabilities property, but I don't think it's necessarily a thing we NEED to have. The summary attribute of the references property entries could indicate which ref is an ioc.

With regard to the configuration_tree: I am totally in favor of a new property which can be referenced elsewhere in the document. Your point regarding configuration types makes sense to me as well-- thanks for explaining that. I'm still stuck on the unified-configuration-model point. We don't really want to just push raw config in here since that won't make much sense to a system reading the JSON file, and we could make the argument that such text is executable content and therefore should be omitted from the JSON file, period. The sheer number of devices to which CSAF will be applicable, combined with the number of competing configuration standards results in a huge potential matrix. We need to specify just enough detail to allow a human operator to determine which configuration applies to them and how to apply it.

I think the best way to accomplish this may be to make the configurations entry discussed here, named "CSAFCID-0002", contain a references_t object which points to configuration as provided (ideally with instructions for using said config) by the issuing authority.

Thoughts? Again, apologies for the time-delay since my last participation here.

[tschmidtb51]

As it gets quite complex discussing two different topics in one ticket I opened a dedicated ticket for the configuration management (see #291).

Regarding the ioc object: At the moment, I suggest to use references for CSAF 2.0 and than for CSAF 2.x get back to that. This gives us the opportunity to collect data ans see what is needed and think about how this can be automated best. I opened a dedicated ticket for that (see #292).

[wrideout]

Great, thank you! We will pursue these in the new issues.