Re: new CNA guidelines

[Kurt Seifried <kurt@seifried.org>]

On Sun, Oct 8, 2017 at 8:34 PM, Art Manion <amanion@cert.org> wrote:

On 2017-10-07 21:50, Kurt Seifried wrote:

> https://securitytxt.org/
>
> TL;DR: security.txt for reporting security issues, like robots.txt
> for telling web robots how to behave.
...

Generally a big fan, there's similar work going on in FIRST, and I plan to actually talk to the author/developer.

A few thoughts:

> # Our disclosure policy
>
> Disclosure: Full

Not sure that disclosure policies are modular/structured well-enough yet to work like this.  Also the three options are too gross.  A suggestion is to provide a pointer to the policy (having and publishing a policy is a great start).

There are some norms/standards developing around coordinated vulnerability disclosure.  We primarily ask vendors to do crazy things like:

1. Develop and publish a policy
2. Have a way to receive reports
3. Analyze and fix/publish

CNAs should be held to the same standard.

Note: #1 says to have and publish a policy, not what the policy says.  CVE the boundary of disclosure, CVE shouldn't bother itself too much with disclosure politics.

I think it's safe to drop the disclosure policy becuase

1) it doesn't really matter, usually what matters is the disclosure policy of the researcher

2) "upstream" is reportedly dropping it as well based on similar concerns (see hackernews thread)

 

> This would make it much easier for people to discover how to report
> things (99% of the time you can plug a product name in and get the
> web page no problem, then the problem becomes finding the contact
> details for reporting your security vulnerability).
>
> This is a very nice KISS solution, it requires minimal to no
> maintenance (most places do not change the web page for their PGP key
> to often, or the reporting email address, with the exception for
> corporate mergers/divestitures).
It should work great for web site reporting (I think the location on a site is /security.txt, or /.well-known/security.txt).  A little less clear for product vulnerabilities (I might know I need to talk to Red Hat, but what web site holds the correct security.txt for Digital Alert Systems?

mjc@ mentioned this to me, e.g. do we just do (www.)redhat.com or also access.redhat.com (the "main" site for support docs/info/etc.), also how do we separate site specific things from products? 

I think the main thing would be to suggest people publish the security.txt at the root of their "main" site (e.g. redhat.com), and optionally at other locations, based on the presumption that the contact listed can do message routing to the appropriate group. Which raises a concern, do we then have a lot of vendors with many contacts that don't want to do this? I haven't really seen to many vendors with more than 2 contacts (usually one for the sites and one for products). 

 

The FIRST work focuses on the content and format but stops short of recommending a single/specific location for the contact information.

This is something that drives me nuts, maybe suggest something like an eicar.com type string so savvy people can google site:example.org "magic string". I know myself and a lot of other security people spend a lot of time trying to contact other vendors/projects. 

 

 - Art

--

Kurt Seifried
kurt@seifried.org