Re: Researcher Activities

[Mark Poepping <poepping () CMU EDU>]

John's comments are right on as usual..

More to the general issue of researchers asking for help..  A few other
ideas to consider, having worked with lots of researchers over the years...
 . Many 'researchers' are grad students starting with a simple idea from a
professor.  Most aren't very good about designing their experiment and you
might be on the wrong end of the result, so it's a good idea to 'talk with
them'.  We put together a consulting two-pager to try to help represent the
issues we care about and can help them with - stuff like data quantity, IRB
interactions on sensitivity, etc..  Most folks start with an assumption of
packet capture (just give me everything) because they don't know any better.
 . Speaking of 'wrong end of the result'..  As more 'automation of responses
to bad behavior' happens, the complaints may go underground in favor of
automated blocklisting - this is what happens with email today, and most
email admins spend a fair amount of their time trying to keep their domains
off of these things.
 . I try hard to not represent myself as any 'judge of legitimate research'.
There's lots of stuff I think is nonsensical and much more I wouldn't bother
with on any account, but I'm often amazed by what gets funded too so I don't
claim any high ground - I just try to help them understand my perspective on
the potential value of what I understand that they're trying to do and any
other methods that may provide as good (or better) semantics for much less
work (and risk) overall.

Mark.


> -----Original Message-----
> From: The EDUCAUSE Security Constituent Group Listserv
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of John Kristoff
> Sent: Wednesday, June 11, 2008 11:42 AM
> To: SECURITY () LISTSERV EDUCAUSE EDU
> Subject: Re: [SECURITY] Researcher Activities
>
> On Wed, 11 Jun 2008 10:25:33 -0500
> Willis Marti <wmarti () TAMU EDU> wrote:
>
> > A lot of those and similar activities may set off (false) warnings
> > about attacks or infected machines and can be considered
> > "unfriendly". Certainly we don't let students play around that way.
>
> If it is legitimate research I would support it.  I've done this sort
> of thing so I'll share more based on my experience.
>
> > Do you support that kind of research? Ban it? Ignore it?
> > How about complaint handling?
>
> The source of the probes should come from a host that can be easily
> identified with a PTR query as being part of a research project (e.g.
> research-icmp-prober.cs.tamu.edu).  There should be a default web page
> at the source that identified the project, the researchers and contact
> information.  You should pre-notify a select group of ops people that
> this will be happening (e.g. this list, NANOG, UNISOG, nsp-security and
> so on).  Have a standard template response related to probes ready to
> go.  Something along the lines of "We are sorry for any concern this
> may have caused.  You may filter these packets or that host if you
> desire, but we prefer you did not.  They are intended to be benign and
> not cause any operational problems. This is related to an Internet
> mapping/discovery/research project by <insert name/group>. etc..."
>
> You will surely get some emails.  When you reply, and you absolutely
> must do so, most if not all will simply accept the reason and move on.
> You might have someone that is too annoyed and wants you to blacklist
> their address space.  I don't think you're under any obligation to do
> that, but it is something to consider if this will be a recurring
> practice.
>
> Note, some type of probes are likely to generate more complaints than
> others.  A TCP port 80 SYN may not attract much attention.  A TCP 22
> may attract more.  If the probes hit a netblock in sequential order and
> quickly, that will attract more attention than if the destination
> addresses are highly randomized and spread out over a significant
> length of time.
>
> John