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

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.
>
> The main changes are:
>
> - clarified terminology such as abuse handler, security incident,
> registrant, national CERT, etc.
> - clarified problem statement
> - removed specific mentioning of name-based services in the problem
> statement
> - used "European" examples
> - added API details for Nation CSIRT DB
> - elaborated on conclusion and next steps
>
> This document was sent to me earlier in the week, but for various
> reasons I didn't manage to forward it on to you all until now. With
> the TF-CSIRT meeting happening next week it would be great if we could
> gather any further feedback before the end of this week, but I realise
> that is quite a short term period, for which I apologise. So I'm not
> proposing a hard cut-off by end of day on Friday, but I think it would
> be extremely useful if people could try to post to the list before then.
>
> This would hopefully allow the authors to go to the TF-CSIRT meeting
> with a very nearly final draft and then complete it shortly afterwards.
>
> Certainly I would propose no more than a working week to receive other
> feedback, so we'd be looking at the end of Wednesday 27th.
>
> Thanks,
>
> Brian
> Co-Chair, RIPE AA-WG



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.
 

The first example - hacked webpages - is also not completely the way how
reporters (the ones I know) 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.
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.



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.." 


*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"

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.

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

6.4. Enisa .. even more CERTs...no api

6.5 even more CERTs ..

6.6 here we go..there is a source!

6.7. again: CERTs...

I would mention the CERT-stuff, but the only important contact for the
"incident reporter" in
this list is RIPE.

So the conclusion of the document:

"This document lists a number of known datasets that contain abuse
contacts.."

does not really fit the intention and the content of the document.

--------------
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.

* 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)


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."


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"

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 :-/

Just my 0,03 cents.. and thanks for the work!


best greetings,

Gunther

NetCologne Systemadministration
-- 
NetCologne Gesellschaft für Telekommunikation mbH
Am Coloneum 9 ; 50829 Köln
Geschäftsführer:   
  Jost Hermanns,
  Mario Wilhelm  
Vorsitzender des Aufsichtsrates:
  Dr. Andreas Cerbe
  HRB 25580, AG Köln