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