| Re: [open-regulatory-compliance] OSS wish list disclosure information - possible consideration for EU-CRA technical standards work |
Lars,
CSAF has two profiles for communicating information on software vulnerabilities:
Profile 4: Security Advisories identify products that are affected by a vulnerability.
Profile 5: VEX identifies products that are not affected by vulnerabilities, as its primary purpose. It can also be used like a Security Advisory (profile 4), but that would be redundant.
Thomas Schmidt with the CSAF team made this distinction very clear during a FIRST.org presentation when he said a VEX is an “anti-Security Advisory”.
People I talk with only want to know when that are at risk when a vulnerability is announced and that’s what a Security Advisory provides.
A Vulnerability Disclosure Report is different; it’s product centric and always up to date so that consumers can answer the question “Is my product affected, as of right now”.
A person from the healthcare community used an analogy when describing VEX.
“A VEX is like receiving a tornado warning for Oklahoma in Alaska – it’s just unnecessary noise to the people living in Alaska”
Thanks,
Dick Brooks
Active Member of the CISA Critical Manufacturing Sector,
Sector Coordinating Council – A Public-Private Partnership
Never trust software, always verify and report! ™
Risk always exists, but trust must be earned and awarded.™
https://businesscyberguardian.com/
Email: dick@xxxxxxxxxxxxxxxxxxxxxxxxx
Tel: +1 978-696-1788
From: Lars Francke <lars.francke@xxxxxxxxx>
Sent: Friday, February 7, 2025 10:46 AM
To: dick@xxxxxxxxxxxxxxxxxxxxxxxxx; Open Regulatory Compliance Working Group <open-regulatory-compliance@xxxxxxxxxxx>
Cc: Roman Zhukov <rzhukov@xxxxxxxxxx>
Subject: Re: [open-regulatory-compliance] OSS wish list disclosure information - possible consideration for EU-CRA technical standards work
> Reports from the trenches are that VEX is not viable for either manufacturers of devices or software consumers.
We are using CSAF as a manufacturer and as a consumer and I disagree with that.
> I would think that sending “not affected” advisories would cause not only manufacturer fatigue, but, consumer fatigue resulting in the increased likelihood that an “affected” advisory would be missed/overlooked or automatically deleted when the filters are set.
I wouldn't expect to look at these manually - I expect them to be automatically processed.
I do agree that tooling is not great yet but that's hopefully temporary.
On Fri, Feb 7, 2025 at 4:26 PM Dick Brooks via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:
Reports from the trenches are that VEX is not viable for either manufacturers of devices or software consumers.
Here is one comment regarding VEX concerns:
Thanks Dick,
I would think that sending “not affected” advisories would cause not only manufacturer fatigue, but, consumer fatigue resulting in the increased likelihood that an “affected” advisory would be missed/overlooked or automatically deleted when the filters are set.
Security Advisories that indicate products that are affected by a new vulnerability are valuable to consumers, warning of increased risk.
Palo Alto networks serves as a great model for vulnerability disclosure reporting for products which answers the question that consumers are asking: “Is my software product affected by any vulnerabilities as of right now”
Thanks,
Dick Brooks
Active Member of the CISA Critical Manufacturing Sector,
Sector Coordinating Council – A Public-Private Partnership
Never trust software, always verify and report! ™
Risk always exists, but trust must be earned and awarded.™
https://businesscyberguardian.com/
Email: dick@xxxxxxxxxxxxxxxxxxxxxxxxx
Tel: +1 978-696-1788
From: Roman Zhukov <rzhukov@xxxxxxxxxx>
Sent: Friday, February 7, 2025 10:08 AM
To: dick@xxxxxxxxxxxxxxxxxxxxxxxxx; Open Regulatory Compliance Working Group <open-regulatory-compliance@xxxxxxxxxxx>
Subject: Re: [open-regulatory-compliance] OSS wish list disclosure information - possible consideration for EU-CRA technical standards work
Dick, thanks for sharing it!
We need to make sure that existing established vulnerability reporting/enrichment standards like OpenVEX and CSAF are taken into account, as many vendors have already been using them. There is no contradiction with the wish list above (and compatible with SPDX of course), as current specs are flexible and can be appended by things like IOC, YARA, etc.
--
On Fri, Feb 7, 2025 at 2:48 PM Dick Brooks via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:
Just want to share some insights from colleagues working on the software consumer side with regard to transparency information that would be useful:
OSS Vulnerability wish list would include:
- Version(s) affected – what version(s) does the vulnerability affect.
- Fingerprinting (i.e., how to find) - what are the recommended ways to detect this vuln in a particular environment/what detection tools or mechanisms are most effective (they may not want to get into "endorsing" a particular detection tool which is totally fine but just general if possible).
- Severity - Give the actual CVSS calculator parameters you used to arrive at the severity chosen so if someone wanted to, they could plug them directly into the interface themselves and customize based on their environment. A completely standalone/air-gapped machine is likely not going to have to worry too much about a vulnerability or exposure that relies on a network-based attack vector (so the threat is much less severe)
- Mitigations - If for some reason a patch or update cannot be applied, are there any recommended mitigations that might be able to be made based on configuration of the software or even other components like network or operating system such as blocking a certain port to limit a particular exposure or changing the permissions of a certain file and locking it down, etc.
- Monitoring - What are the indicators of compromise (IoCs) that might be a sign the vulnerability is being exploited and what are the logging/audit recommendations for detecting them and monitoring for the vuln? E.g., YARA rules
The last item, Monitoring, is also discussed in the Vulnerability Disclosure Report interactions that are taking place. The SPDX V 2.3 SBOM spec currently supports discovery of online living Vulnerability Disclosure Reports (VDR) for a specific product SBOM:
Thanks,
Dick Brooks
Active Member of the CISA Critical Manufacturing Sector,
Sector Coordinating Council – A Public-Private Partnership
Never trust software, always verify and report! ™
Risk always exists, but trust must be earned and awarded.™
https://businesscyberguardian.com/
Email: dick@xxxxxxxxxxxxxxxxxxxxxxxxx
Tel: +1 978-696-1788
_______________________________________________
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org_______________________________________________
open-regulatory-compliance mailing list
open-regulatory-compliance@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
