1 / 27

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

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 Member, Consultant, Interoperability Committee IT Security Team Anti-Phishing Working Group Boston College. Presentation Theme.

susan
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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>

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

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

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

More Related