Sharing Incident Data; History, Perspective, and a View for the Future

1. Sharing Incident Data; History, Perspective, and a View for the Future Patrick Cain The Cooper-Cain Group, Inc 29 June 2005 17th Annual FIRST Conference Member, Consultant, Interoperability Committee IT Security Team Anti-Phishing Working Group Boston College

2. 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”

3. 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

4. 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

5. 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

6. 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?

7. 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…

8. 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

9. 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

10. 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 

11. 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

12. 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

13. 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

14. 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]

15. 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)

16. 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

17. 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

18. 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

19. 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)

20. 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

21. 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

22. 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>god@heaven.uni</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>

25. 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

26. 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

27. Thank You Patrick Cain The Cooper-Cain Group, Inc pcain@coopercain.com