Part 3

In a continuation of previous entries (http://isc.sans.org/diary.html?storyid=8719 and http://isc.sans.org/diary.html?storyid=8863) I wanted to inject a little scope-creep and share what others have sent in.
 

Scope-Creep

Although the original question was about malicious websites which lent the proposed solution to favor malware intelligence, the framework should include more fraud and crime information.  This need arose while considering how we would import DShield data.  We will need to add a couple more categories:

• Attacker/Scanner-- This would be the default category for DShield submissions due to the nature of the data sources.  This could also be imported from your own environment's firewall logs and IDS.
• Fruad-- To help encourage victim organizations and law-enforcement organization share details about where cyber-crime is being omitted from.  This entry would require a timestamp of the incident.

The date/timestamp of the attack and particularly the fraud is especially important.  Without this information, the report is largely un-actionable by most consumers.  I will commonly receive a list of 100+ IP addresses that were involved in fraudulent transactions from some government or law-enforcement agency and it is largely a waste of time.  Typically months have already passed since the fraud was committed and when the list is released.  Compound that with the list being full of ISP-consumer IP addresses and all you are going to find are false-positives.  Now, if there were date/timestamps provided in this list, one could then identify if they also had similar activity and provide a better-targeted list of accounts to flag and further inspect.

URLvoid

A few readers have recommended urlvoid.com as a “VirusTotal for URLs.”  It does a nice job of interfacing with 20 or so URL-checkers.  It's unclear if they share submissions with all of these vendors like VirusTotal does.  If so, they're missing an opportunity to capture additional details from the submission.

Most users just want a good/bad or safe/dangerous determination.  It's not always that easy, we'll see below.
 

Defining “Bad”

There are a lot of groups that collect this kind of information and they all have their own particular focuses.  Mixing and matching the data from these various repositories can result in some unfortunate consequences.  I'll continue to use DShield as an example.  It is simply a list of dropped sessions, submitted from the public.  It's easy to end up on this list since UDP is trivial to spoof, and folks running P2P applications cause afterglow that can result in dropped connection-attempts that get classified as malicious in some environments.  As long as you're aware of how the data are collected, this isn't a problem-- until you blindly use it to block email.

Having access to the “why” helps you interpret the potential impact of blocks.  Sometimes blocking the request isn't enough.  Blocking an outbound connection to an exploit site is a good thing.  Seeing blocked attempts out to a command-and-control server is a not-so-good thing.