3.2.3.12.1 Vulnerabilities Property - Remediations - Category

[thomas-proell]

Currently there are these categories:

• mitigation
• no_fix_planned
• none_available
• vendor_fix
• workaround

These are of two different natures. 1st the existing vendor respose:

• vendor_fix - patch, update or new version. Can be multiple as multiple fixes can be available (v1 affected, v2, v3, v4 fixed)
• workaround - countermeasure that solves the problem, prevents exploitation without patch but possibly with other limitations
• mitigation - countermeasure that decreases risk or impact without fully preventing it
• none_available - no vendor_fix, no workaround, no mitigation, nothing. Can be left out because it is implicit when the others are not given.

The second is not existing vendor response but a view into future:

• no_fix_planned
• fix_planned

Both only make sense when "vendor_fix" is not available.

[tschmidtb51]

@thomas-proell Do you already have a suggest for the TC?

[thomas-proell]

@tschmidtb51 Which suggest do you think about? Concrete text proposal or a pull request?

[tschmidtb51]

Currently, I don't think in terms of a PR. The issue you opened describes the current situation and your perception of it. Please state as suggestion, one or more options how to solve the issue. E.g. this could be: - Adding documentation around the topic - Adding a test (e.g. preventing impossible situations of "none_available" and "vendor_fix") - Splitting fields - ... Thanks!

[thomas-proell]

The longer we discuss this here, the more interesting it gets. The current version is mixing many different aspects of a remediation that should be seperated.

I will come with a concrete improvement suggestion.

[thomas-proell]

Here’s a concrete suggestion to be discussed. Currently, we have the following remediations:

mitigation
no_fix_planned
none_available
vendor_fix
workaround

Some people were requesting things similar to:

fix_planned
under_investigation
patch_for_not_affected

There are different issues here:

1.Status of vendor response (fix_planned, no_fix_planned)
2. Actual vendor (or up-stream) response (mitigation, vendor_fix, workaround, patch_for_not_affected, none_available)
3. Ambiguity of the terms “patch”, “fix”, “workaround”, “mitigations”.

For (1) - the status of the vendor response - I suggest to handle fix_planned and no_fix_planned as flags under 3.2.3.5 Vulnerabilities Property – Flags.

I also suggest to add other status reports in the vendor's vulnerability response (“under investigation” or “affected”) as in below image.

“Affected” will come handy for the patch_for_not_affected later and "under investigation" was requested multiple times.

This leaves the remediation section (2) actual vendor response with the following choices:

mitigation
none_available
vendor_fix
workaround
patch_for_not_affected

None_available is clear, but for each of these terms there are conflicting definitions. Instead of coming up with an additional set of definitions, I suggest avoiding these terms and describe:
• What the remediation changes (system changes)
• What the remediation reduces (risk reduction)

3.2.3.12 Vulnerability Property - Remediations
3.2.3.12.1 System changes

code_change
configuration_change
usage_change
deployment_change
no_change
other

The value code_change indicates that the remediation required changes is the code of the product. This is often called “patch” or “update” or “new version” which needs to be installed by the operator of the system.

The value configuration_change indicates that the remediation changed the configuration of the system (“turn off web server”). The vulnerable code is still on the system, but it is either not executed any more or it is executed but the outcome is different. This usually affects functionality, performance or comfort of the system and thus implicitly entails a change in user behavior.

The value user_change indicates that the remediation is not of technical nature but of procedural nature. Often the user needs to avoid certain dangerous operations like clicking on links or using certain features. Changes in the manual often suggest a certain user behavior.

The value deployment_change indicates that the remediation is not on the vulnerable system itself but in the surrounding. This could be configurations for firewalls or intrusion prevention systems (IPS), physical security measures.

The value no_change indicates that no remediation is available at the point in time of advisory release.

The value other indicates that the remediations given do not fall into a single category or are a combination of different categories.

3.2.3.12.1 Risk reduction The following risk reductions are common in different scoring systems:

            "risk_reduction": {
              // ....
              "likelihood_change": {
                // ...
              },
              "impact_change": {
                // ...
            }

Changes in likelihood or impact define the degree to which the remediation changes the likelihood or impact of successful exploitation. Valid values are:

not_reduced
reduced_slightly
reduced_substantially

As the terms “workaround”, “mitigation”, “fix” are not used the same way around the globe, the mapping what they described in the old format must be found by each team for their own definitions. In Siemens we would map our old values:

[tschmidtb51]

For (1) - the status of the vendor response - I suggest to handle fix_planned and no_fix_planned as flags under 3.2.3.5 Vulnerabilities Property – Flags.

@thomas-proell After reading the suggestion again, I feel that #662 is not fully represented - but I might be missing something. #662, when included as remediation category has a text field that is able to convey information like "Fix should be expected next Monday" (very good description as you never have to deliver 😉) or "Fix will be included in Q4 2024 release". Such additional information seems to be missing once its get pushed into flags.

[tschmidtb51]

@thomas-proell Please also state how your suggestion addresses #563 (resp. how this would be represented in your suggestion).

[mreedergithub]

I concur with Thomas Schmidt's assessment on proposed solution for #662 because the vulnerability flag does not have a description field to convey information about when and how the fix will be provided.

[thomas-proell]

I see two different approaches which collide here:

• Looking at 30,000 vulns per year, I opt for "as automatable / scalable as possible", happily removing free text fields, human readers and manual instructions.
• Others bring forward single advisories, single use cases and make very good points why we need free text fields to explain to our human readers what manual actions to perform.

Both approaches are valid for different senarios. CSAF 2.0 is a compromize of these and we cannot change it fundamentally to fulfill either scenario without breaking the other in CSAF 2.1.

[jdstefaniak]

@thomas-proell thanks for offering an opportunity to share more details as to our request. It is indeed multi-faceted and based on 2 perspectives :

1- Practical: Vendors will have the need at times to communicate about a known vulnerability in their product(s) ahead of delivering the remediation. This is done to be transparent with Customers and an acknowledged necessity to increase the bond of trust between Customers and their vendors. Therefore, for a Vendor to be able to publish a CSAF payload with a "Fix_Planned" field and value simply serves this purpose. Dell Security Advisories rely on this strategy every time for one product at least, example to be discussed if necessary (see revision table): dsa-2023-156-dell-bsafe-ssl-j-7-1-1-security-update

2- Industry Guidelines: FIRST.org lists at least one scenario with examples where this option of communicating a vulnerability ahead of delivering the remediation is needed: Use Case 3: Public disclosure of limited vulnerability information prior to remediation ; see practical examples with offering an advanced warning or expected cadence.
That second point further aligns the CSAF standard with the FIRST guidelines for Guidelines and Practices for Multi-Party Vulnerability Coordination and Disclosure

Thanks again for your time and attention.

[thomas-proell]

I close this as the suggestion I proposed does not work.

[jdstefaniak]

@thomas-proell Help us understand how this request is completed in the way you are describing, as:
The suggestion you proposed does not work.

I am looking forward to engage with you and trying to understand your perspective too. You are referencing CSAF 2.1; i have no clue as to what this entails, meaning i can not meaningfully engage with you in a leveled-field & productive conversation either.

Let me know if you can engage in a meeting to help me understand your perspective please as there could be much to gain for us all and the project.
Thank You, Regard, JD Stefaniak

Cc: @mreedergithub , @tschmidtb51

[thomas-proell]

I mistakenly closed it as "completed". I realized my mistake, re-opened it and closed it as "not planned" a few minutes later.

Reason is: The proposal I had would not fully fix the current inconsistencies. Also they do not fulfill the quality expectations. To really fix this, we need more groundbreaking work, which is probably a candidate for CSAF 3.0.

[jdstefaniak]

Thanks @thomas-proell ; is there a specific conversation about CSAF 3.0 that is already started ? if yes, can i join please ?

[thomas-proell]

I am not aware of CSAF 3.0 discussion in OASIS yet. Internally we talk about APIs instead of file formats, but this is still TBD. Thomas From: jdstefaniak ***@***.***> Sent: Tuesday, June 25, 2024 11:22 PM To: oasis-tcs/csaf ***@***.***> Cc: Proell, Thomas (CYS DEF PCERT PVR) ***@***.***>; Mention ***@***.***> Subject: Re: [oasis-tcs/csaf] 3.2.3.12.1 Vulnerabilities Property - Remediations - Category (Issue #665) Thanks @thomas-proell<https://github.com/thomas-proell> ; is there a specific conversation about CSAF 3.0 that is already started ? if yes, can i join please ? - Reply to this email directly, view it on GitHub<#665 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/APS5P3RBH47U53NPKRWPPOLZJHNQLAVCNFSM6AAAAAA7ZCBVTGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBZHE4TCOBTGM>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[tschmidtb51]

I think the none_available could be modeled as:

"system_change": "no_change",
"likelihood_change": "none",
"impact_change": "none"