search

oasis-tcs / csaf

OASIS CSAF TC: Supporting version control for Work Product artifacts developed by members of TC, including prose specifications and secondary artifacts like meeting minutes and productivity code
https://github.com/oasis-tcs/csaf
Other
143 stars 38 forks source link

As a consumer I want every CSAF document to be a security advisory. #193

Closed sthagen closed 3 years ago

sthagen commented 3 years ago

... let us make a real version 2.0! There are tools that can go from XML to JSON schema and back again (mostly) so hopefully we bring more to the table with the new major version than just offering JSON "a la mode" ...

Statement of problem: Although we enhanced the content model a lot (looking back to version 1.2) there is still this itch I really want to scratch at:

For CSAF like with other formats (eg. SARIF) the minimal valid document is ... an absolutely useless one.

What is an advisory not containing at least wun object and wun relation to a vulnerability? Seriously: What would our parents and children think of us if they knew what we are doing here:

Standardizing per hundred(s of) pages rules for advisories, that allow those advisories to contain and provide essentially ... nothing?

So, over the next days and weeks, I will propose an augmented baseline for being a valid CSAF document and I invite all members, esp. from organizations actually producing or consuming security advisories in the wild, to support me in that final attempt of defining such a minimal document content that is worth being called a minimal viable product (MVP).

Currently, what we minimally allow is not an MVP, or is it?

Trying to identify such additional mandatory elements, I find it encouraging, that important use cases for issuing and processing a security advisory can be those, where not much is actually known. Essentially a heads up, important nevertheless. Typically not for every product it is known from news of a vulnerability discovery, if this product is affected by that vulnerability and if so, what measures can be advised. But, we can issue advisories of value to consumers, informing the product users, that there are known unknowns. Like, not yet knowing if that product is affected by this vulnerability or not in an initial version of the advisory.

In my world being actionable is the most important attribute of anything claiming to be advice.

This should be doable for CSAF. Valid advice for me includes (in version 1):

That 👉🏽 plant 🌱 instance may be vulnerable to infection with mites 🔬 we are investigating 🕵🏽‍♀️ ...

Then version 2 issued after inspection:

That 👉🏽 plant 🌱 instance is vulnerable to infection with mites 🔬 working on mitigations 👩🏽‍⚕️ ...

... and so on, simple like that (maybe neither for the plant we take care of nor any mites migrating there though).

Basically, I think that

if creating the next level above a meta data only CSAF document is high in the sky, then there is something wrong with the format or model

In that case, we should IMO consider why and if this is good. My feeling is, that if one needs to fill many more fields to go from zero to wun this is wrong and may hamper adoption.

So, if this is the case, we should correct that and provide with version 2.0 (which already signals per semantic versioning breaking changes).

Ideally we are providing a domain specific language (DSL) offering proportionality of effort where only "the sky is the limit" (for humans and tools):

  1. Nothing to say should not "claim" to be CSAF: Hi. I am spam ... 🚯
  2. Not much to say (yet) should be trivial with CSAF: Heads up! Investigating if product P is affected by vulnerability V 👌🏽
  3. Providing more advice should be easy with CSAF: Action needed: P versions 1, 3, [5-7] are affected by V mitigation M is ... 👍🏽
  4. Issuing complex advice should be possible with CSAF: Action needed: all known P versions before 7.2 are affected by V. So, please install the fixed version 7.2 available from 🔗 (which includes instructions I ... ⭐

Am I pathetic 👴🏽 or does that make sense? I sincerely hope the latter and ... am possibly sorry for the Saturday Morning version of the pwnd international english language used to create this call to action. — Caveat emptor: I borrowed the term wun (meaning 1) from Douglas Crockford without asking for permission and hope for forgiveness.

santosomar commented 3 years ago

There is a use case for a security advisory that will not have a vulnerability (i.e., CVE or the like). That use case is when a vendor is providing an informational advisory or a security response to an event, etc. We may not want to require at least one CVE or vulnerability.

sthagen commented 3 years ago

@santosomar but a product will always be in the SA, right?

... informational advisory or a security response to an event ...

Hm, I understand CSAF as more narrow in providing security advisories (with an AND between the two terms - not an OR).

Question:

Can we provide examples for such security advisories (those without product or vulnerability) from production? Once we have such real-life examples, we can inspect and assess the plausibility of a real need.

I think it would be beneficent to discuss use cases based on real instances ... because use cases may lead us anywhere without a shared interpretation of their applicability.

I know, that I am very far from being a producer or consumer of security advisories but still want to ensure, we do not end up supporting a generic messaging protocol per CSAF :wink:

santosomar commented 3 years ago

Yes indeed! An advisory will contain at least one product. The following are a few examples of security advisories not addressing a vulnerability perse:

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-Expressway-8J3yZ7hV

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-solarwinds-supply-chain-attack

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-racerts-WvuYpxew

Hope this helps.

sthagen commented 3 years ago

@santosomar this helps a lot (at least me). When it comes to configuration advice I sense a CWE is just around the corner :wink: just picking some from the menu at https://cwe.mitre.org/data/definitions/731.html ... or more generic CWEs like

So, it might not be a too far stretch to use a topically matching CWE to anchor the vulnerability inside the CSAF with the product. ... but then security advisories are tricky participants of the market place, I understand:

  1. Vendors do not want to issue too few SAs to be compliant
  2. Vendors do not want to issue too many SAs to not lose reputation

Not only commercial, but also open source "pro bono" vendors like the OpenSSL project can suffer a lot from competitors spreading opinion pieces targeting perceived quality and security posture of the product.

So, I understand, when the content of the CSAF vulnerability part is often some "walking the line"

On something related and IMO very positive when we can define at least extension sets for broad use cases:

That issue #191 reported / requested by Alexandre (asking for a reference parser) reminded me, that we can provide business logic in tools on top of JSON Schema. This would then be a good reference parser IMO.

Together with the current work to include all roles and conformance sets we can define core/profiles or synonymously baseline/extensions for CSAF.

The reference parser could then use such sets of minimal "profile" attributes and offer validation against:

What does the group think? Interesting path ...?

tschmidtb51 commented 3 years ago

Yes indeed! An advisory will contain at least one product. The following are a few examples of security advisories not addressing a vulnerability perse:

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-Expressway-8J3yZ7hV https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-solarwinds-supply-chain-attack https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-racerts-WvuYpxew

Hope this helps.

Thanks @santosomar this helps a lot.

Let me comment on the advisories in detail:

cisco-sa-Expressway-8J3yZ7hV

You provide a CVRF document here with a product_tree as well as a vulnerabilities elements => all good.

CSAF 2.0 version - click to expand

``` { "document": { "csaf_version": "2.0", "publisher": { "type": "vendor", "contact_details": "Emergency Support: +1 877 228 7302 (toll-free within North America) +1 408 525 6532 (International direct-dial) Non-emergency Support: Email: psirt@cisco.com Support requests that are received via e-mail are typically acknowledged within 48 hours.", "issuing_authority": "Cisco product security incident response is the responsibility of the Cisco Product Security Incident Response Team (PSIRT). The Cisco PSIRT is a dedicated, global team that manages the receipt, investigation, and public reporting of security vulnerability information that is related to Cisco products and networks. The on-call Cisco PSIRT works 24x7 with Cisco customers, independent security researchers, consultants, industry organizations, and other vendors to identify possible security issues with Cisco products and networks. More information can be found in Cisco Security Vulnerability Policy available at http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html" }, "title": "Cisco Expressway Software TURN Server Configuration Issue", "tracking": { "current_release_date": "2021-01-20T20:41:10.000Z", "id": "cisco-sa-Expressway-8J3yZ7hV", "initial_release_date": "2020-11-18T16:00:00.000Z", "revision_history": [ { "number": "1.0", "date": "2020-11-18T15:25:21Z", "summary": "Initial public release." }, { "number": "1.1", "date": "2020-11-25T16:44:26Z", "summary": "Included additional information about the vulnerable configuration." }, { "number": "2.0", "date": "2021-01-20T20:41:10Z", "summary": "Changed the advisory SIR from Medium to Informational. Updated throughout to explain that this not a vulnerability. Removed the Fixed Software section." } ], "status": "final", "version": "2.0", "generator": { "engine": "Secvisogram", "date": "2021-03-12T11:49:33.624Z" } }, "type": "Cisco Security Advisory", "notes": [ { "type": "summary", "text": "The Traversal Using Relays around NAT (TURN) server component of Cisco Expressway software supports the relay of media connections through a firewall using proxy services. As a result of this feature, interfaces such as the Cisco Expressway web administrative interface may become accessible from external networks.\n\nAt the time of publication, documentation of the feature did not properly explain that users are able to bypass firewall protections that are designed to restrict access to the Cisco Expressway web administrative interface. However, an attacker must have credentials sufficient to use TURN services to be able to send network requests to the web administrative interface.\n\nThis advisory is available at the following link:\nhttps://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-Expressway-8J3yZ7hV [\"https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-Expressway-8J3yZ7hV\"]", "title": "Summary" }, { "type": "general", "text": "This issue impacts Cisco Expressway Series and Cisco TelePresence Video Communication Server (VCS) with the TURN server feature enabled.", "title": "Vulnerable Products" }, { "type": "general", "text": "Only products listed in the Vulnerable Products [\"#vp\"] section of this advisory are known to be affected.\n\nCisco has confirmed that Cisco Expressway Series and Cisco TelePresence VCS systems that do not have the TURN server feature enabled are not affected.", "title": "Products Confirmed Not Vulnerable" }, { "type": "general", "text": "The Cisco Expressway IP Port Usage Configuration Guide [\"https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/expressway/config_guide/X12-6/Cisco-Expressway-IP-Port-Usage-for-Firewall-Traversal-Deployment-Guide-X12-6.pdf\"] recommends firewall configuration to prevent access to administrative ports from external networks. However, when TURN services are enabled, administrative ports are accessible through the TURN server from external networks. Customers should be aware that enabling the TURN services exposes administrative ports on the Cisco Expressway Series or Cisco TelePresence VCS host.", "title": "Details" }, { "type": "general", "text": "There are no workarounds that address this issue.", "title": "Workarounds" }, { "type": "general", "text": "To learn about Cisco security vulnerability disclosure policies and publications, see the Security Vulnerability Policy [\"http://www.cisco.com/web/about/security/psirt/security_vulnerability_policy.html\"]. This document also contains instructions for obtaining fixed software and receiving security vulnerability information from Cisco.", "title": "Vulnerability Policy" }, { "type": "general", "text": "The Cisco Product Security Incident Response Team (PSIRT) is not aware of any public announcements or malicious use of the issue that is described in this advisory.", "title": "Exploitation and Public Announcements" }, { "type": "general", "text": "Cisco would like to thank Christian Mehlmauer of WienCERT-IT-Security in the City of Vienna for reporting this issue.", "title": "Source" }, { "type": "legal_disclaimer", "text": "THIS DOCUMENT IS PROVIDED ON AN \"AS IS\" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME.\n\nA standalone copy or paraphrase of the text of this document that omits the distribution URL is an uncontrolled copy and may lack important information or contain factual errors. The information in this document is intended for end users of Cisco products.", "title": "Legal Disclaimer" } ], "references": [ { "summary": "Cisco Expressway Software TURN Server Configuration Issue", "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-Expressway-8J3yZ7hV", "type": "self" } ] }, "product_tree": { "branches": [ { "name": "Cisco", "type": "vendor", "branches": [ { "name": "Cisco TelePresence Video Communication Server (VCS) Expressway", "type": "product_name", "product": { "product_id": "CVRFPID-209614", "name": "Cisco TelePresence Video Communication Server (VCS) Expressway" } } ] } ] }, "vulnerabilities": [ { "title": "vuln-CVE-2020-3482", "id": { "system_name": "CSCvt83751", "text": "Cisco Bug ID" }, "notes": [ { "type": "other", "text": "CSCvt83751", "title": "Cisco Bug IDs" } ], "cve": "CVE-2020-3482", "product_status": { "known_affected": [ "CVRFPID-209614" ] }, "remediations": [ { "details": "There are no workarounds that address this issue.", "type": "workaround" } ], "references": [ { "summary": "Cisco Expressway Software TURN Server Configuration Issue", "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-Expressway-8J3yZ7hV", "type": "self" } ] } ] } ```

cisco-sa-racerts-WvuYpxew

This seems to be a configuration issue. One could argue that there are products affected from that. As mentioned in #188 and https://github.com/oasis-tcs/csaf/issues/186#issuecomment-786193004 adding configurations might solve that. However, I have too little information to make a well-wrought suggestion for this. It might more likely be something which we could target in CSAF 2.1.

cisco-sa-solarwinds-supply-chain-attack

This is the real interesting case: One could argue that all Cisco devices are affected if they are installed together with the SolarWinds Orion Platform. (I'm not too familiar with the case so please let me know if I'm wrong.) See example below:

CSAF 2.0 example (excerpt) - click to expand

``` "product_tree": { "branches": [ { "name": "Cisco", "type": "vendor", "branches": [ { "name": "all", "type": "product_version", "product": { "product_id": "CSAFPID-0001", "name": "All Cisco products" } } ] }, { "name": "SolarWinds", "type": "vendor", "branches": [ { "name": "Orion Platform", "type": "product_name", "branches": [ { "name": "2019.4", "type": "product_version", "branches": [ { "name": "HF 5", "type": "service_pack", "product": { "product_id": "CSAFPID-0002", "name": "SolarWinds Orion Platform 2019.4 HF 5" } } ] }, { "name": "2020.2", "type": "product_version", "branches": [ { "name": "unpatched", "type": "patch_level", "product": { "product_id": "CSAFPID-0004", "name": "SolarWinds Orion Platform 2020.2 unpatched" } }, { "name": "HF 1", "type": "service_pack", "product": { "product_id": "CSAFPID-0005", "name": "SolarWinds Orion Platform 2020.2 HF 1" } } ] } ] } ] } ], "relationships": [ { "product_reference": "CSAFPID-0001", "relates_to_product_reference": "CSAFPID-0002", "relationship_type": "installed_with", "full_product_name": { "product_id": "CSAFPID-0006", "name": "All Cisco products installed with SolarWinds Orion Platform 2019.4 HF 5" } }, { "product_reference": "CSAFPID-0001", "relates_to_product_reference": "CSAFPID-0004", "relationship_type": "installed_with", "full_product_name": { "product_id": "CSAFPID-0007", "name": "All Cisco products installed with SolarWinds Orion Platform 2020.2 unpatched" } }, { "product_reference": "CSAFPID-0001", "relates_to_product_reference": "CSAFPID-0005", "relationship_type": "installed_with", "full_product_name": { "product_id": "CSAFPID-0008", "name": "All Cisco products installed with SolarWinds Orion Platform 2020.2 HF 1" } } ] }, ```

Long story short: There might be valid use cases where an advisory has no body (in terms of product_tree and vulnerabilities). IMHO: There is always a way to deal with that which supports the automation. But I'm happy to go with a set of profiles (Security Advisory, Informational Advisory, Security Response,...) which then define (business logic wise) which fields must be present.

BTW: By using this we could easily add a profile for VEX.

Thoughts?

tschmidtb51 commented 3 years ago

Here is a (quick and dirty) draft for the different profiles with their mandatory fields:

CSAF 2.0

(only for completeness)

Response to a security breach / incident

Informational Advisory

I'm still not sure about that category. It could look like:

If the product_tree is a part of this: Where would the products be referenced? And as what? All the classification is done in the vulnerabilities elements. So this one doesn't really help automation - unless we rename the `vulnerabilities' to something different... However, this sounds to me like a bigger change which I wouldn't want to rush...

Thoughts?

Security Advisory

VEX

There is one case, where it actually should use the product status fixed (resp. first_fixed) instead of known_not_affected: If the vulnerability was fixed (e.g. using an open source component but changed the lines with the vulnerability) before it was discovered.

Thoughts?

allan-ntia commented 3 years ago

VEX

Thanks for starting on this! Very excited to engage and bring together two smart groups.

  • inherits all from CSAF 2.0
  • /product_tree: Which products are going to be mentioned in this security advisory?

  • one of:

    • /vulnerabilities/0/product_status/known_not_affected: Which products are known to be not affected?
    • /vulnerabilities/0/product_status/fixed: In which products was the vulnerability fixed before discovered?
    • /vulnerabilities/0/product_status/first_fixed: In which products was the vulnerability fixed before discovered? Was this the first product with this change?

The VEX/SBOM initial approach is to use 'known_not_affected' , 'known_affected' , and 'under_investigation'. Very happy to dive into these more.

  • one of:

    • /vulnerabilities[]/notes: Provide some details about what the vulnerability is about.
    • /vulnerabilities[]/cve: Provide the corresponding CVE number.

While CVEs will be the most common, we'd like to build this agnostic to the type of vulnerability identifier.

There is one case, where it actually should use the product status fixed (resp. first_fixed) instead of known_not_affected: If the vulnerability was fixed (e.g. using an open source component but changed the lines with the vulnerability) before it was discovered.

Hmm. Would love more discussion on this, and input from the CSAF community. Our initial approach is to try to keep things simple from the consumer's perspective: is it affected or not. Futher details can inform how/why/when something is affected or isn't. (e.g. context, config, etc)

santosomar commented 3 years ago

Thank you, Allan!

This is a great discussion and an amazing use case (third-party software security advisories [since this could happen with open source and shared closed source, as well]).

I have included some comments to your questions below (tagged with [os]):

[os] The document creator has the flexibility to use one or more of the ones below:

[os] Another use case is when you have a series of advisories that are linked together. For instance, a vendor may have published several vulnerabilities in “a bundle”, each with a first fixed version, but then congregate the “recommended release” by calculating first_fixed and fixed.

Hope this helps. Any other thoughts from the TC and community? I love this brainstorming!

Regards,

Omar

From: Allan Friedman @.> Reply-To: oasis-tcs/csaf @.> Date: Monday, March 15, 2021 at 1:35 PM To: oasis-tcs/csaf @.> Cc: @." @.>, Mention @.> Subject: Re: [oasis-tcs/csaf] As a consumer I want every CSAF document to be a security advisory. (#193)

VEX

Thanks for starting on this! Very excited to engage and bring together two smart groups.

The VEX/SBOM initial approach is to use 'known_not_affected' , 'known_affected' , and 'under_investigation'. Very happy to dive into these more.

While CVEs will be the most common, we'd like to build this agnostic to the type of vulnerability identifier.

There is one case, where it actually should use the product status fixed (resp. first_fixed) instead of known_not_affected: If the vulnerability was fixed (e.g. using an open source component but changed the lines with the vulnerability) before it was discovered.

Hmm. Would love more discussion on this, and input from the CSAF community. Our initial approach is to try to keep things simple from the consumer's perspective: is it affected or not. Futher details can inform how/why/when something is affected or isn't. (e.g. context, config, etc)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/oasis-tcs/csaf/issues/193#issuecomment-799609467, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAM42EWWUP322WALDPZWA2LTDZAL7ANCNFSM4YWO7TWQ.

tschmidtb51 commented 3 years ago

I added the PR #276 to address this problem. If we decide to use the suggestion, which I recommend, we need to add the business logic tests in #195 - one each per profile.

tschmidtb51 commented 3 years ago

Do we need more profiles? In the examples, we had also:

If so, what are the characteristics of those profiles?