[anti-abuse-wg] RIPE NCC Anti-Abuse Training: Next Steps & WG Input!

Am 10.02.22 um 10:25 schrieb Brian Nisbet:
> Colleagues,
>
> Since we last spoke about the proposed training the NCC have been working with various community members to put a 
> draft syllabus in place for further discussion.
>
> This is a link to the feedback document for this draft:
>
> https://docs.google.com/document/d/1M9Wrqu-VKGGwMfJQGK0NlTs5UzH6xJ2_HR2MkTBVR2w/edit?usp=sharing
>
Nice!
> What the NCC and the Co-Chairs would love is if everybody could just comment what they think they understand from the 
> learning goals as they’re written and suggest any changes or additions and obviously ask any questions. We’d also like 
> the feedback on the webinar flow design.
>
> It’s important for everybody to understand that the learning objectives are the basis for the training. These are the 
> skills that the learner must acquire. With these skills we also expect a change of attitude towards abuse handling 
> (which is we think the purpose of this training).
>
> While discussion on the list is welcomed and encouraged, we've also planned a Zoom session for any interested parties 
> to discuss this further.

I'll most likely not be able to join the Zoom session, so here are some thoughts. The document draft shows the structure 
(which is good and as far as I can see covers the important areas) but not much detail. My suggestions (from the POV of 
an abuse reporter) go straight into the details, please forgive me if that is out of scope.

  * Abuse handling is not the same as support handling. Abuse reporters don't want help, they expect that it is in your
    own interest as a network operator to curb abuse originating from your network, and their reports are intended to
    help you reach that goal. This results in some Don'ts (I'm seeing all of these in reponse to abuse reports):
      o don't reject their messages because they are not your customers,
      o don't require them to register with some support system,
      o don't send meaningless auto-replies,
      o don't try to teach them (unless they are really doing something wrong).
  * Although there may be conflicts with protecting your user's privacy, reporters really appreciate to know whether
    their reports have a meaningful effect as they sometimes spend considerable amounts of time. Positive feedback
    ("we've terminated that customer", or "we've worked with the customer to fix their exploitable software/account") is
    a huge encouragement to continue reporting abuse. If there is no detectable reaction (either in form of an answer or
    an observable stop of abuse) then an abuse reporter might determine that blocking your network is a more effective
    use of their time.
  * Many types of abuse originating from your network are signs of substandard security and warnings of possibly more
    damaging future exploits. Work proactively with your customers when you find systemic problems. For example, on one
    of the services that I look after, we had one or two mail account password compromises which led to spam bursts. We
    established a strict password policy, checking the password database for easily breakable passwords, and contacting
    all users with weak passwords so they changed them to secure passwords. Similarly, we proactively check customer's
    websites for exploitable plugins. What kinds of proactive abuse prevention works in your case might be vastly
    different, but not doing anything is gross negligence.
  * Abuse desk workers need authority to contact customers and to restrict their use of your resources. One basic
    prerequisite for contacting customers is that you know them. If your operation does not establish appropriate KYC
    rules you're bound to be an attractive provider for abusers. Of course, the amount of info you need for an e-mail
    account and for renting out a server are different, and you may be limited by privacy laws, but if you simply refuse
    to take responsibility while not disclosing information on who *is* actually responsible you're in for blocking.

Cheers,
Hans-Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/anti-abuse-wg/attachments/20220210/a8c9b950/attachment.html>