"Is it a security issue?"

[Kurt Seifried]

In line with "Will it blend?" I'd like to start a series of conversations on "is it a security issue?" (please note I'm very specifically NOT using the word vulnerability).

To start off, I ran across this a while ago:

https://news.ycombinator.com/item?id=32524702

https://blog.ando.fyi/posts/diagnosing-an-unsual-wifi-issue/

TL;DR: If you run the app MediBang Paint Pro it cripples WiFi on Qt5. Effectively a denial of service.

I think this qualifies, e.g. if an attacker were able to cause this we'd all agree it's a vulnerability, but in this case, it can't be triggered as such, but numerous apps trigger this, causing severe usability problems, and it's common enough that it clearly should have some better visibility, I can only imagine how many people years have been wasted chasing this issue down. I'd like to propose that the GSD scope of coverage include things like this. Thoughts/comments?

Kurt Seifried (He/Him) Chief Blockchain Officer and Director of Special Projects Cloud Security Alliance e: ksei...@cloudsecurityalliance.org

[Josh Buker]

My thoughts are that if the data is clearly labelled, consistent, and filterable - including a more broad category of security relevant IDs makes sense. The crux being that folks can easily and automatedly ignore things that aren't relevant to their use-case.

--

Joshua Buker Research Analyst Cloud Security Alliance e: jbu...@cloudsecurityalliance.org

This e-mail account is used only for work-related purposes; it is not guaranteed that any correspondence sent to this address will be read by the addressee only, as it may be necessary, under certain circumstances, for third parties appointed by the Cloud Security Alliance to access this e-mail account. Please do not send any messages of a personal nature to this address.

[Kurt Seifried]

On Thu, Sep 1, 2022 at 1:41 PM Josh Buker <jbu...@cloudsecurityalliance.org> wrote:

My thoughts are that if the data is clearly labelled, consistent, and filterable - including a more broad category of security relevant IDs makes sense. The crux being that folks can easily and automatedly ignore things that aren't relevant to their use-case.

My thinking here is pretty simple, we have a variety of "compatibility modes" for the API and data tagging:

1) We have a "CVE only" data feed, easy, everything with a CVE alias.

2) We have a "CVE compatible" data feed, everything that matches https://www.cve.org/ResourcesSupport/AllResources/CNARules#section_7_assignment_rules basically, 

3) We have a "vulnerability" data feed which is stuff that is generally attacker exploitable/triggerable, wider scope of coverage than CVE (e.g. better service coverage)

4) Everything else (the less well defined stuff)

in combination with this I'm also hoping to start collecting and analyzing the data to get things like confidence scores around how correct and/or complete an entry it, how likely is it to be exploitable (e.g. EPSS https://www.first.org/epss/ or https://inthewild.io/ who might hopefully start feeding data to us soon) so e.g. someone can say "I just want the stuff that is actually being exploited/seen/has exploit code/PoC code" vs "give me all the vulns" vs "give me everything".