Sharing Incident Data; History, Perspective, and a View for the Future Patrick Cain The Cooper-Cain Group, Inc 29 June 2005 17 th Annual FIRST Conference.

Sharing Incident Data; History, Perspective, and a View

for the Future

Patrick CainThe Cooper-Cain Group, Inc

29 June 200517th Annual FIRST Conference

Member, Consultant,Interoperability Committee IT Security TeamAnti-Phishing Working Group Boston College

Presentation Theme The theme of the conference:

Be part of the global network The theme for Pat:

Things will get worse if we don’t share experiences and incident data

Use history, anecdotes, stories for perspective

Leak the “grand plan”

What is Incident Data? It is Detailed Technical Data on: Network Events

DoS, Worms, etc Widespread scanning activities

Application Adventures Spam, Phishing, Fraud

Malicious, Targeted Activities May include Forensic, Investigative, or

Informational data

Why I Care About Sharing Incident Data

WE get Incident Reports… In different languages trying to tell me

something important That lacked critical details (e.g., IP Address or

Incident Date) Others already saw (and solved) our

problem We fixed/found something first and wanted

to brag The standard “if you don’t do it we’ll make

it a law” problem

Why Do We Share this Data? The goal is to get useful data to

appropriate parties for some action The parties may be ISPs, End-Users, Law

Enforcement Agents, Researchers… Most times we don’t attack ourselves,

so finding the right party and supplying convincing data to them is sometimes hard

We Seem to Have Gone Through Some Phases…

From the old days – B.I. (Before Internet) – until today we’ve wandered through some distinct phases in information sharing

Did we learn anything?

1. In the Beginning… The (Arpa)Net was only a few nodes It was easy to call/email another operator and

find out what happened Most staff was uber-technical

Everybody had government funding to keep the net working

What worked for one got shared to all Note that the Morris worm affected many people “Keeping it working” was a common bond

We’re all in this together…

2. Then came the WWW… Everybody could point, click, infect …

attack Sharing? Keeping up was hard! Events were appearing that nobody

understood DDoS, SSL, Spam arrived

Many things were at the breaking point Everyone was responding differently These responses broke stuff

3. Show me the money… The ‘net went global Everybody had a special secret way to make

money and control the Internet Nobody shared data because it was

“proprietary” – and it made you look bad Incidents were “shared” via personal

contacts (i.e., you called someone you knew) The year 2000 rollover (listening to the world) No real forensic data for the events

E.g., the Yahoo, etc, DoS attacks in 2000

4. Pop Goes the Internet Bubble

New ISPs and Enterprises had the same old problems… E.g., Insecure routers, bad filters, warez bots

… But no money to formally participate in security or incident fora like IOPS or ISPSEC Blacklists became the medium for problem

response Mail lists became the sharing medium

NANOG, Bugtraq, CERT, firewalls

Still no real-time or forensic data

5. It’s the hackers/terrorists… Law Enforcement (LEA) discovered the

‘net It was much easier to “say No to sharing”

than to find a way to make it work and not expose things to the LEA/government

Lots of “if you know about this…” laws were born Formal sharing mostly stopped Many RADIUS and system logs were limited to

short rollover times

6. We’re All in This Together The ‘net is truly global

Other users have an impact on me You can watch malware traverse the globe

Sharing data/experiences can save money So we all don’t rediscover the same solutions So we don’t all chase the same miscreant

Protecting your customers could be a service discriminator But you need to know what you’re protecting

against

So we made the loop… What did we learn?

The bad guys play nicer together than the good guys

Your competitors know your super-secret countermeasures

Nobody has the time to investigate everything Someone else may have time if it impacts them Most people will give incident details when

asked Everyone has been blacklisted for no apparent

reason

What Did I Learn? People need incentives to share data

No sharing without a reason There needs to be a “business reason”

Nobody will volunteer for the heavy lifting Nobody admits bad things easily The “we’re all in it together” seems to

have returned The Good guys versus the hackers/bad

guys/etc [Good and Bad have local definitions]

Two models for Sharing Data Central model

Data goes to a central point and is redistributed E.g., ISAC, CERT Data can be verified and/or anonymized

Peer to Trusted Peer model Data is shared via known friends and peers E.g., NANOG, mail lists, hackers, IRC Data gets dispersed faster, but may be less

accurate Which one is better? (Unclear)

The Model isn’t Important My goal is not to dictate how to share data,

nor even when to share incident data Everybody will decide for themselves I have too many political scars on this topic

But when people share, the incident data appears in many odd forms XML, ASN.1 encoded, hex dumps, mail bodies

My goal is to get a common format used so that when I get data --- I can understand it

A Common Format is Necessary

The APWG embarked on a project to define a common format for phishing activity data You only find out you’ve been phished from

others A straightforward format was needed to support

automation The APWG holds a repository of phishing and

e-crime activities Firms can peruse the database to detect attacks

against them Automatic alerts and blocklists can be generated

The APWG Plan Define a common report format

Started with phishing; added spam, fraud, e-crime Make it easy to send in activity reports Provide some tools to create/read reports

Impede your competitors from gleaning useful data from your reports

Make it east to spot attack trends Let vendors & researchers test their

ideas/products against known attacks Provide believable metrics/numbers

The INCH Extensions We picked the IETF INCH XML format

Flexible (simple through ultra-detailed) Easy to read Some people are concerned about its

complexity XML encoding tools are available

(you could encode by hand, if necessary)

Disadvantages of the Format Can be very verbose and complex

We minimized the required elements We made some tools to try out our format

There is some overhead This should be machine-generated and

processed so extra bytes shouldn’t be a problem

Advantages of the Format The commonality allows for automatic

processing We can real-time parse the input stream for

correctness (and reject bad submissions) We can generate near-real-time alerts from

the input data Database searches return consistent data New Extensions are straightforward

Malware, spam, e-crime, Phraud, etc

An Example Phishing Report<?xml version="1.0" encoding="UTF-8"?><iodef:IODEF-Document xmlns="draft-ietf-inch-iodef-041"

version="0.30" xmlns:iodef="draft-ietf-inch-iodef-041"><iodef:Incident purpose="warning"><iodef:IncidentID Issuer="God" restriction="need-to-know">God-0001</iodef:IncidentID><iodef:Description lang="us-english">It was very bad.</iodef:Description><iodef:Contact contacttype="person" contactrole="creator"> <iodef:NameIdentifier>Pat</iodef:NameIdentifier> <iodef:Email>[email protected]</iodef:Email> <iodef:DetectTime>2004-11-31 14:20-0500</iodef:DetectTime><iodef:AdditionalData dtype="xml"> <phish:PhishingReport xmlns="phish" PhishType="fraudsite"> <phish:PhishedBrandName>My Brand</phish:PhishedBrandName> <phish:DataCollectionType DataCollectionType="web">

<phish:DataCollectionString>Give me your Money!</phish:DataCollectionString> </phish:DataCollectionType> <phish:OriginatingSensorName>Pat's browser</phish:OriginatingSensorName>

<phish:OriginatingSensorIPAddress>192.168.241.147</phish:OriginatingSensorIPAddress>

<phish:OriginatingSensorFirstSeen>2005-04-11 18:10-500</phish:OriginatingSensorFirstSeen>

</phish:OriginatingSensor><phish:TakeDownInfo><phish:PRComments>This was a test. Only a test.</phish:PRComments></phish:PhishingReport> </iodef:AdditionalData></iodef:Incident> </iodef:IODEF-Document>

Conclusion We need to expand sharing incident

data in a repeatable manner Some political problems still remain

Using a common format makes the task easier Supplying free tools may help even more

If we need a specific tool –> please let me know

Comments, guidance, and advice are always welcome

Useful Links The Anti-Phishing Working Group

www.antiphishing.org The IETF INCH Working Group page

http://www.ietf.org/html.charters/inch-charter.html

Phraud Reporting Tools www.coopercain.com/incidents

Thank You

Patrick CainThe Cooper-Cain Group, Inc

[email protected]