Thanks for your quick feedback, Michele. On 21/1/16 12:05, Michele Neylon - Blacknight wrote:

Brian

Thanks for sharing this

A couple of notes:

- there seems to be an assumption that “quality” and “responsiveness” are somehow linked.

That wasn't the intention. We will clarify this in the text.

- the flow for ccTLD domain lookups seems to jump from the IANA DB directly to the CERT, which seems like overkill. The whois data *might* provide contact information that would be useful or failing that the hostname lookup would give the hosting provider / ISP. (or maybe I’ve misread the chart?)

This was just meant a one example of how the process could go from query to data sets to result. We will try to clarify this in the chart itself or add some explanatory text. Regards, Mirjam

Regards

Michele

-- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains http://www.blacknight.host/ http://blog.blacknight.com/ http://ceo.hosting/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845

On 20/01/2016, 16:22, "anti-abuse-wg on behalf of Brian Nisbet" <anti-abuse-wg-bounces@ripe.net on behalf of brian.nisbet@heanet.ie> 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

Dear Gunther, dear anti abuse wg list,

On 22 Jan 2016, at 13:48, Gunther Nitzsche <gnitzsche@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@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