advise on network security report

I would appreciate a bit of advise on a service I am about to deploy. I've spoken at different venues (including nanog) on global infection rates of bots and the general degradation of well behaved hosts.

I now track around 2.2M abuse events per day and now have the capability to produce reports for the community on which networks have the largest problems. I am prepared to make reports monthly to the community ordering networks by their volume of issues.

I'd like some hints of which might be the most valuable to the community.

    o are hosts counts or issue counts more important

    o is a 7 or 30 day window sufficient for aggregation?

    o I'm not repaired for graphs yet so don't go there.

    o should I post sub-reports for regions, by RIR?

    o which kinds of abuse are more interesting.

I'm expecting to post a weekly report once a month to nanog, would this be disruptive? We have a mailing list set up for weekly reports, once finalized I'll post the location for its list manager.

The global report usually has about 6,000+ networks, the top 100 from last week are below.

again, thanks for your feedback.

-rick

Table 1. Networks with abuse, ordered by #incidents

Far better to simply post a pointer to your new list, IMHO, and let folks subscribe if the so choose. As it is, many of these various automated postings to NANOG are mildly annoying to those who aren't interested or who already receive the information in another form.

Whatever service you end up offering, a a full-text RSS or Atom feed would probably be useful, as well.

Hmmm, a weekly report once a month, this should be interesting. :slight_smile:

-Jim P.

Roland Dobbins wrote:

I'm expecting to post a weekly report once a month to nanog, would this be disruptive?

Far better to simply post a pointer to your new list, IMHO, and let folks subscribe if the so choose. As it is, many of these various automated postings to NANOG are mildly annoying to those who aren't interested or who already receive the information in another form.

the point of the posting are to generate discussion; the list subscription will be made available for those that desire access to higher frequency of reporting.

Whatever service you end up offering, a a full-text RSS or Atom feed would probably be useful, as well.

we do CSV for detail reporting and will be posting these directly to the abuse@ mbox for the nextworks we have contacts for.

-rick

I believe there are those who would argue that there's already a surfeit of discussion on NANOG, quite a bit of it irrelevant and of little interest to many subscribers.

Posting stats and reports to a list which contains people who may not be interested in same often results in those stats and reports being filtered out and ignored. Posting a pointer to said stats and lists so that interested parties can subscribe if they so choose guarantees a community of common interests to whom discussion of the topic(s) at hand will come naturally, without the need for artificial stimulus.

Postings like this to NANOG will not have any impact. So if your goal is
instigate action, posting is not going to work. The core data point is
the weekly CIDR report. It only works if you have peers using the weekly
list to apply peer pressure to the networks listed to act.

Sharing summaries to communities like dshield, NSP-SEC, DA, SANs and
other security mitigation communities along with a subscription web page
that would allow an organization to get enough details to take action.

Also, posting too much hear just helps the criminals/miscreants. Some of
the better ones who have any clue can be assumed to be on NANOG. They
would love details on how well their tools are working and which ones
are going under the detection radar.

Barry Greene (bgreene) wrote:

Postings like this to NANOG will not have any impact. So if your goal is
instigate action, posting is not going to work. The core data point is
the weekly CIDR report. It only works if you have peers using the weekly
list to apply peer pressure to the networks listed to act.

I beg to differ, wither I aggregate my announcements does not impact the $50B charge identity theft puts on the US economy.

would it assist if I associated a dollar value for each bot hosted, we can estimate the number of credit cards stolen per bot and extrapolate in to something with some zeros on it.

Sharing summaries to communities like dshield, NSP-SEC, DA, SANs and
other security mitigation communities along with a subscription web page
that would allow an organization to get enough details to take action.

nsp-sec players still won't let us in their sand-box... but we will share to the communities you have enumerated.

-rick

whichever notification method you use you need to include information that
the abuse@ address folks can actually use. Saying: "machine 1.2.3.4 sent
spam" isn't useful, however sending:

-----------------------------example---------------------
machine 1.2.3.4 delivered this spam:

<full spam mail with headers>

-----------------------------end example----------------

is useful... Extend that to virus/trojan/bot/C&C info of course (send logs
of the abuse). If you don't provide this there is no reasonable way to
affect change. Also, make sure that whatever you send is machine parsable,
it'd be great to send things in some 'standards compliant' manner as well
(INCH perhaps?) sending an email that a human has to process will get that
email deleted/ignored/not-processed-to-your-satisfaction. I also believe
that since you are aiming at something machine parseable you should submit
one email per 'incident' you are reporting, that way abuse@ folks can
judge the volume of the problem in a fairly simple manner.

it's just an opinion or 3... :slight_smile:

Oh, and as Scott said, pleaes tag the subject so it can get procmail'd
appropriately.

-Chris

I beg to differ, wither I aggregate my announcements does not impact the
$50B charge identity theft puts on the US economy.

would it assist if I associated a dollar value for each bot hosted, we
can estimate the number of credit cards stolen per bot and extrapolate
in to something with some zeros on it.

I experimented with a lot of topics on NANOG which the charter suggests,
and found that botnets and $-value only work if they directly impact an
ISP (not its users or immense corporate networks), meaning - something
which helps/stops an ISP from running. I.e., $$$ loss to the ISP.

$ value to the US economy just fascilitates faster move toward the usual
and inevitable forking of the thread and flaming.

> Sharing summaries to communities like dshield, NSP-SEC, DA, SANs and
> other security mitigation communities along with a subscription web page
> that would allow an organization to get enough details to take action.

nsp-sec players still won't let us in their sand-box... but we will
share to the communities you have enumerated.

You heard what people here want/don't want, do your thing. From my
experience, you also got about 10-20 emails off-list, in support. Most
flames come on-list.

Openly available data that will show us which networks we need to worry
about will be valuable.

In the C&C report we now have "networks with 100% resolved". Two years ago
we wouldn't have even considered that category. We didn't even consider
using exact numbers due to "help bad guys scare". We quantified it, found
out what's useful (what ISPs want/ISPs REALLY don't want), and what
would be useless.

Of your data, do you have information which can tell us what ISPs keep
sending out spam despite of continued listing/reporting? Can you tell us
what ISPs do real good work?

A not-too-often coming report would be very interesting, especially
because it is public, if you can make it reliable. For more exact and
regular figures, I'd say go with a private feed.

It is possible we are all wrong. Start with once a month and grow to even
once a day if we find it's just what we have all been looking for.

-rick

  Gadi.

Well.. figure that if you're charging somebody by the megabyte for transit,
there *is* a positive dollar value per bot hosted.

Maybe that's the tactic to take with some of the more bot-infested cable
providers - if they aren't 100% settlement-free, point out the cost savings
at their exchanges if their outbound traffic drops because their bots aren't
spewing.....

Hint, hint, hint. When the abuse and security folks at ISPs give suggestions on how to best work with them, its sometimes a good idea
to listen. If you just want to shout "You Suck" at them, please have
a seat in the waiting room and someone will be with you later, possibly
before the heat death of the universe. If you pay an ISP enough money,
you're paying for the right to shout You Suck at progressively higher
level executives.

ISP security and abuse folks generally know how bad the problems are. That
isn't useful to getting their jobs done. They usually have better information about how bad it is than most third-parties.

ISP security and abuse teams already receive reports from almost every group in existence. After they process the high priority work, e.g. court orders from countries around the world, reports from customers, etc; figuring out how to make the security and abuse teams lives easier is
the key to getting your complaints to the top of the pile. Rankings of other ISPs doesn't change their workload.

Although every ISP security and abuse group is different, I think most of them have their favorite third-party sources. Listening to why they like using particular resources over other third-party resources could
help make your third-party resource more relevant to their work.
"You Suck" doesn't help them get home any earlier.