[anti-abuse-wg] Updated Document: Abuse Contact Data Sets

Dear Gunther,
dear anti abuse wg list,


> On 22 Jan 2016, at 13:48, Gunther Nitzsche <gnitzsche at netcologne.de> wrote:
> 
> On 01/20/2016 05:22 PM, Brian Nisbet wrote:
>> Colleagues,
>> 
>> The group working on this document (L. Aaron Kaplan, Mirjam Kühne,
>> Christian Teuschel) have produced a new draft. This draft contains a
>> number of updates, based on feedback from the community.
>> 

I am one of the co-authors. First of all let me say a big "thank you" to Gunther and everyone who gave us feedback.
While we were able to incorporate most feedback and suggestions , we are very well aware that this is just a first version of the document and that the contents discussed in the document is bound to change frequently. So, in case some feedback did not make it yet, we apologise and aim to add it to the next version.

Please also find some comments to Gunther's mail below inline.

> 
(...)

> 
> 
> Some notes to the text:
> 
> . Problem Statement
> CERTs need to look up contact information frequently
> 
> 
> that might not hit the problem completely. Abuse-contacts are usually
> contacted by victims, spamtrap/honeypot/incident reporters
> or just by abuse-aware mailserver providers. CERTs are a very small
> sub-section of contacts - important, but definitely not the main
> abuse-contact searchers.

Well, you are right but this document focuses on CERTs and incident handlers as target audience of the document. The document has a special focus on tools which yield themselves to automation (APIs). So that's why we left it as it is right now.
Open to new suggestions (as noted above)  to expand the target audience of course...

> 
> 
> The first example - hacked webpages - is also not completely the way how
> reporters (the ones I know) work.

For CERTs i can assure that that's the way they work :)

> admin-c and tech-c are good targets for the complaint; but there is no
> need to find more and more hacked
> webspaces in the same ip-range before contacting the ip-address owner.


Please note that we should not get stuck on this one specific text. It was an example.

> That means: the reporter resolves
> the (first (!)) webpage address to an ip-address and contacts the owner
> of this ip-address (who is either
> responsible for the content by himself or has some kind of contract with
> the domain-owner)
> In the end it is always the owner of the ip-address who can put an end
> to abuse.
> 
> In the end of "4" it says:  "his document aims at describing these
> different datasets "
> but it is not described what "these" datasets are. In the lines before
> that only problems with existing
> sourced are listed.

Fixed, thank you for the suggestion.

> 
> 
> 
> In the end of section 5 it reads:
> 
> "Sometimes an incident reporter might want to contact a single point of
> contact (PoC) for a whole country."
> 
> I would change that to: "in very rare cases.."

We left it because many CERTs address other national CERTs as a super-remediator.
Again - it's a matter of how you define the target audience :)
> 
> 
> *6. Existing Datasets
> *
> 
> If you say:  we list various datasets that can be used by incident
> reporters to determine the right contact information
> 
> then it might not be the right idea to list sources who are "member
> only" restricted or
> give only information about listed members like the 6.1. This list maybe
> helpful (?) for
> CERTs contacting other CERTs, but it is not an obvious source for "the
> incident reporter"

Please note that nearly all of them are not members only. What a members only section contains is *additional* information.
But that's a good point... noted for the next iteration. Thank you.


> 
> Same problem with 6.2:https://www.first.org/ <https://www.first.org/>
> This list maybe helpful (?) for CERTs contacting other CERTs, but it is
> not an obvious source
> for "the incident reporter". It is "the global Forum for Incident
> Response and Security Teams",
> not a source for an "incident reporter" to determine an abuse address.
> The API only lists
> FIRST members. Not very helpful in the day-to-day abuse contact search.
> 
Again. Depends on the target audience of the document. For us (CERTs) it is :)

> 6.3 CSIRT Database...yes, nice..but ..it has nothing to do with the
> search for a direct
> abuse contact for a given incident.
> 
see above.

> 6.4. Enisa .. even more CERTs...no api
> 
unfortunately no API yet. Yes. But...

> 6.5 even more CERTs ..
> 
> 6.6 here we go..there is a source!
> 
:)
(..)


> --------------
> What I am missing:
> 
> * name based search: which whois databases are out there; maybe which format
> do they use in the output, which email-address in the output should be
> used as contact.
> 
We discussed this. Yes. However, is it really important to document
name based (domain) whois?
I mean - that technology just works out of the box when you apt-get install whois.
(in OSX it comes by default on the cmd line, same for windows)

So, what would be the point in documenting plain old good whois for domains?
"yes it exists!" :) That's sort of the only thing that comes to my mind :)


> * ip-based search: which sources can really be asked (by the public
> and/or by CERTs)
> (like abusix, which was for some strange reasons not included. (Some
> Data Sets mentioned
> in the document include also "second hand sources" - can't see a
> difference to
> abusix)
> 
-> next version. We have been talking to abusix already. But good catch.

> 
> While there might be a need or at least interest in a document like this
> I would
> change the targeted audience from
> 
> " This document is targeted towards CERTs and abuse handlers as well as
> professionals working
> on automating IT security incident handling."
> 
> to something like
> 
> " This document is targeted towards CERTs and professional IT security
> teams working on incident handling."

Well, actually I like the part about automating IT security incident handling.
Because that is *exactly* why we started to document this.
The next step will be a client library which is capable of querying all these APIs
(if they exist - see ENISA case) and offer that as a plugin in lib for automation tools.

> 
> 
> Also I would change the purpose of the document:
> 
> "this document is intended to document existing data sources for abuse
> handlers."
> 
> to something like:
> 
> "this document is intended to document existing CERT and security team
> contacts"

No. I do not agree here. Because it also tries to document for example stats.ripe.net
And that is not only a CERT contact DB.

> 
> The example (hacked webpage) mentioned in section 1 shows the problem:
> If an incident reporter wants to report that incident, he has no
> advantages to
> find the right abuse contact by scrolling through the CERT-list in this
> document.
> That example shows that either the targeted audience or the description
> of the
> purpose should be adapted.
> 
> 
> Sorry to sound so destructive :-/
> 

Not at all.
Thank you very much for the feedback. Measuring our document against critique makes it better.
That does not mean, I agree with every point you made (I agree with some). But it got us thinking.

Thank you very much for taking so much time in answering.

We decided to push out the document - we can still make another iteration for the next version :)
This topic is changing regularly.


Thank you all for the feedback!

L. Aaron Kaplan

--
//  CERT Austria
//  L. Aaron Kaplan <kaplan at cert.at>
//  T: +43 1 505 64 16 78
//  http://www.cert.at
//  Eine Initiative der NIC.at Internet Verwaltungs- und Betriebs GmbH
//  http://www.nic.at/ - Firmenbuchnummer 172568b, LG Salzburg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.ripe.net/ripe/mail/archives/anti-abuse-wg/attachments/20160210/1d06fbc7/attachment.sig>