IODEF Incident Data Exchange Format Rhodes, 8 June 2004 Jan Meijer.

IODEFIncident Data Exchange Formathttp://www.iodef.org/

Rhodes, 8 June 2004

Jan Meijer <jan dot meijer at surfnet dot nl>

2

The Problem

Security incidents DO occur

and

DO NOT magically disappear

This requires...people

3

Many actors involved in handling incidents

•CSIRT capabilities

•Sysadmins

•Endusers

Management, legal, police, propaganda

4

They all communicate

•What

•Where

•When

•How

•Who

•Why

to fix a problem and get on with 'it'

5

Example reportFrom [email protected]: Tue, 2 May 2004 01:27:10 +0000 (GMT)From: [email protected]: [email protected], [email protected], [email protected], [email protected], [email protected]: Report of abuse from x.x.x.196 (196pc223.xxxxxxxx.nl) Dear Sirs, We would wish to report abuse from one of your users. This user hasattempted a hack technique upon our server. The attack occured at5-Jun-04 00h57GMT, and was from IP x.x.x.196 (196pc223.xxxxxxxxx.nl) We would be grateful if you could investigate this user and takeappropriate action. Please inform us of the result of yourinvestigation. We appreciate your cooperation in reporting thisincident to the proper authorities. Best regards, <anonimized>

6

The IODEF idea

•Exchange format

•Unambiguous

•Codify how to 'say' what, where, how, when, who

•Machine parseable

•Automate the load and generalize the automation

•Enabler for all sorts of niceties: statistics, trend-prediction etc.

7

<Incident purpose="handling"> <IncidentID name="SURFnet-CERT">SURFnet-CERT#99999</IncidentID> <IncidentData restriction="default"> <Description>Scan from xxx.xxx.223.75 on port 2745/tcp (6 attempts)</Description> <Assessment><Impact severity="low" type="recon" completion="failed">None</Impact></Assessment> <ReportTime ntpstamp="0xc45554c5.0x0">2004-05-19T03:36:37+0000</ReportTime> <Contact role="irt" type="organization"> <name>SURFnet-CERT</name> <Email>[email protected]</Email> <Telephone>(+31)302305305</Telephone> <Timezone>GMT+0200</Timezone></Contact> <Expectation priority="low" category="nothing"> <Description>We would most appreciate if you could investigate, and deal with the offender as per your internal policies</Description></Expectation> <EventData> <StartTime ntpstamp="0xc4544153.0x0">2004-05-18T08:01:23+0000</StartTime> <System category="source"><Node><Address category="ipv4-addr"><address>xxx.xxx.223.75</address></Address></Node></System> <Record><RecordData> <Description>Logs (5 lines at the most)</Description> <RecordItem type="string"> May 18 10:01:23 6W:gate.xxx.xxxx.xx KERN: TCP Not-Estb: 1-4093 xxx.xxx.223.75:3703->xxx.xx.84.83:2745 May 18 10:50:26 6W:gate.xxx.xxxx.xx KERN: TCP Not-Estb: 1-4093 xxx.xxx.223.75:1621->xxx.xx.84.39:2745 May 18 10:52:03 6W:gate.xxx.xxxx.xx KERN: TCP Not-Estb: 1-4093 xxx.xxx.223.75:4408->xxx.xx.84.244:2745 May 18 11:00:42 6W:gate.xxx.xxxx.xx KERN: TCP Not-Estb: 1-4093 xxx.xxx.223.75:4352->xxx.xx.85.15:2745 May 18 11:20:44 6W:gate.xxx.xxxx.xx KERN: TCP Not-Estb: 1-4093 xxx.xxx.223.75:3727->xxx.xx.85.78:2745 </RecordItem> </RecordData></Record> </EventData> </IncidentData></Incident>

8

Chronology

•1999: IODEF WG@TF-CSIRT

•2001: RFC 3067, Requirements for IODEF

•2002: Established IETF-INCH WG

•2003: libIH (AirCERT), eCSIRT.net, AsiaPac activities

•2004: RID, simplification drive and need for exchange protocol in INCH

9

Deficiencies

•Datamodel is large, and complex

•Ambiguous

•Need profiling for use

•Not all data is easily mapped in IODEF

•Does IODEF make daily life (handling incidents) easier?

•“Overengineered”

10

Outlook

•INCH continues

•TF-CSIRT will experiment with buildingblocks for an incident-data exchange network

•TF-CSIRT will closely follow INCH

•We need to (and will) revisit our assumptions and will make something work to make life easier

•Which might actually turn out to be IODEF :)

IODEF Incident Data Exchange Format Rhodes, 8 June 2004 Jan Meijer.

Documents

Transcript of IODEF Incident Data Exchange Format Rhodes, 8 June 2004 Jan Meijer.