Re: [saag] results of IETF LC for draft-foudil-securitytxt-08 and next steps

[Yakov Shafranovich <[e-mail]>]

On Wed, Jul 1, 2020 at 11:48 PM Benjamin Kaduk <[e-mail]> wrote:
>
> Hi Michael,
>
> On Tue, Jun 30, 2020 at 11:03:44PM -0400, Michael Richardson wrote:
> >
> > Benjamin Kaduk <[e-mail]> wrote:
> >     > The topic of use for reporting compromise vs. vulnerability was raised by
> >     > many reviewers, to the extent that it seems like it would be very
> >     > challenging to craft text that would definitively convince the reader to not
> >     > use the contents of the files for reporting cases of active compromise,
> >
> > When you say, "reporting compromise" do you think that reviewers/commenters
> > were limiting this to talking about reporting that example.com (where you
> > found security.txt) is compromised, or is it about any part of example.com?
>
> My understanding is that that's what was so controversial, yes.  (Note that
> the draft is quite clear that https://example.com/.well-known/security.txt
> does not apply to *.example.com, and one of the points I'd like further
> clarifying text on is whether the file on the web is useful for non-web
> stuff.)
>
> > I ask because there is a continuity of things between for instance,
> >   1) reporting that Example.COM "Smart" refriderators are vulnerable (and
> >      maybe have been compromised already),
> >   2) to reporting that gitlab.example.com (where the fridge source code is
> >      kept) is running a potentially vulnerable version of gitoris,
> >   3) to reporting that update.example.com (where the signed images are kept)
> >      is full of trojaned code
> >   4) to reporting that smtp.example.com seems to forward malware through
> >      the mailing lists maintained there
> >   5) to reporting that www.example.com has been p0wned.
>
> Indeed, and well said.
>
> > My observation is that most of the discussion ratholed around (5),
> > completely ignoring other benefits.  I don't think that any amount of text we
>
> I agree.  Note that I myself was not fully clear on these cases in my
> writeup -- I mentioned compromise in the context of "systems involved in
> retrieving security.txt" in one place but just the (presumed broader scope)
> "compromise" in the high-level summary.
>

This is why CERT's CVD makes the distinction between "vulnerability
response" and "incident response":
https://vuls.cert.org/confluence/display/CVD/1.2.+CVD+Context+and+Terminology+Notes

"These two concepts are related, but different; Vulnerability Response
specifically indicates responding to reports of product
vulnerabilities, usually via the CVD process, whereas Incident
Response is more general and can also include other security events
such as network intrusions."

In our case, #1 and #2 and possibly #3 are "vulnerability response",
while #4-5 are "incident response". Our proposal is geared towards
"vulnerability response", although it can be used for both. I tried to
add additional verbiage to the next draft to make that more clear.

Thanks