• No results found

Managed Incident Lightweight Exchange (MILE): Standards for Cross- Domain Incident Handling

N/A
N/A
Protected

Academic year: 2021

Share "Managed Incident Lightweight Exchange (MILE): Standards for Cross- Domain Incident Handling"

Copied!
15
0
0

Loading.... (view fulltext now)

Full text

(1)

Managed  Incident  Lightweight  Exchange  

(MILE):  Standards  for  Cross-­‐Domain    

Incident  Handling  

Brian  Trammell,  ETH  Zürich  

Co-­‐chair,  IETF  MILE  Working  Group  

CollaboraKve  Security  and  Privacy  Technologies   Berlin,  25  April  2012  

(2)

The  Problem  

ATack  landscape  becomes  more  

complex

 and  

coopera*ve

 over  Kme  

– botnets,  XSS,  APT,  etc.,  etc.  

Single  incidents  affect  mulKple  domains  

– Tools  and  processes  for  defense  must  become  

more  cooperaKve  than  implicit  processes  for  aTack.  

Efforts  to  coordinate  response  within  consorKa  

– Concerns  about  confidenKality  and  privacy  

(3)

to  2006:  IETF  INCH  WG  

(INCident  Handling)  

Incident  Object  DescripKon  Format  (IODEF,  RFC  

5070)  

–  XML  schema  for  describing  network  security  incidents  

–  Based  on  classes  defined  in  IDMEF  (RFC  4765)  for  IDS  

alerts  

IniKal  work  on  RID  (Real-­‐Kme  Inter-­‐network  

Defense)  

–  Inter-­‐domain  exchange  of  IODEF  messages  

–  Published  InformaKonal  in  2010  (RFC  6045/6046)  

(4)

RepresenKng  Incidents:  

IODEF  –  AssumpKons  

•  Incidents  are  not  merely  IDS  alerts.  

–  composed  of  related  events    

(either  automaKcally  or  manually  detected)  

•  Incidents  are  idenKfied  and  stored…  

–  these  idenKfiers  can  be  used  to  reference  them  

–  each  organizaKon  has  its  own  idenKfiers  and  handling  processes  

•  …  but  IODEF  provides  only  a  wire  format.  

–  sharing  is  fundamentally  different  than  archiving  

–  storage  requirements  are  ogen  specific  to  an  organizaKon’s  process  

•  Incident  informaKon  changes  over  Kme.  

–  more  informaKon  available  ager  invesKgaKon  

–  must  be  able  to  represent  incomplete  informaKon  and  ask  for  more  

(5)

RepresenKng  Incidents:  

IODEF  –  Classes  

Represents  Incidents  of  mulKple  Events  

Provides  basic  classes  for  incident  data  

–  IdenKfiers  (IncidentID,  AlternaKveID)  

–  Timestamps  ({Start|End|Detect|Report}Time)  

–  Handling  (Assessment,  Impact,  Method,  and  History)  

–  Flow  

–  Contact  

Incident  and  EventData  containers  

(6)

Exchanging  Incidents:    

RID  –  CapabiliKes  

Adds  exchange  semanKcs  to  IODEF  messages  

–  Enables  incident  tracing  and  miKgaKon  

–  Enables  tracking  of  incidents  as  they  evolve  

–  Supports  query/response,  delayed  response,  and  

asynchronous  reporKng  

–  Generalizable  beyond  IODEF  

Explicit  support  for  security  and  privacy  

–  XML  digital  signature  and  XML  encrypKon  support  

–  AuthenKcaKon,  confidenKality,  and  integrity  for  single-­‐

hop  and  mulK-­‐hop  relay  

(7)

Exchanging  Incidents:    

RID  –  Messages  

•  Request  

–  InvesKgaKon:  “Can  you  help  us  look  into  this?”  

–  Trace:  “Can  you  help  us  find  the  source  of  this?”  

•  Query  

–  “What  do  you  know  about  this  incident?”  

–  “What  do  you  know  about  similar  incidents?”  

•  Acknowledgment  

–  “We’re  on  it,  but  it  might  take  a  while.  Expect  a  follow-­‐up.”  

•  Result  

–  “We’ve  handled  your  request:  here’s  what  happened.”  

•  Report  

–  “Here’s  some  informaKon  related  to  that  incident.”  

(8)

Exchanging  Incidents:  

RID  –  Transport  

Exchange  of  RID  messages  over  HTTP/TLS  

HTTP  allows  easy  implementaKon  on  most  

plaporms.  

Supports  callback  for  Acknowledgment  with  

later  follow-­‐up.  

Provides  hop-­‐by-­‐hop  security  with  a  

(9)

ApplicaKon:  

Shared  Incident  Reports  

Provider  sends  a  RID  Report  message  

– to  involved  consorKum  members  that  may  not  have  

detected  the  incident  

– to  a  central  clearinghouse  for  the  consorKum  

– to  compromised  consorKum  members  from  a  

clearinghouse  

– to  client  of  an  incident  reporKng  service  within  the  

consorKum  

(10)

ApplicaKon:  CooperaKve  

Incident  Handling  

•  Requestor  sends  a  RID  Request  to  another  consorKum  

member.  

–  IODEF  message  contains  enough  informaKon  to  idenKfy  the   incident  to  be  invesKgated.  

•  Responder  sends  RID  Acknowledgment,  invesKgates  

incident.  

–  …in  keeping  with  the  responder’s  own  incident  handling  

processes  

•  Responder  sends  a  Result  back  to  requestor  when  

invesKgaKon  complete.  

–  …and  the  process  iterates  should  more  informaKon  be  

(11)

Today:  IETF  MILE  WG    

Standardized  RID  as  RFC  6545/6546  

Focused  on  extensions  to  IODEF  and  RID  

–  Handle  changes  to  threats  and  processes  since  

publicaKon  of  IODEF.  

–  Incorporate  implementaKon  experience  in  inter-­‐

domain  incident  handling.  

Provides  a  home  for  coordinaKon  of  this  work  with  

other  SDOs  

–  referenced  from  ITU-­‐T  SG17/4  

Charter  includes  work  from  a  large  community  of  

(12)

IETF  MILE  WG:  

Current  Work  (1)  

drag-­‐iep-­‐mile-­‐sci  

– Represent  structured  cybersecurity  informaKon  by  

inclusion  in  IODEF  documents.  

– Allows  exchange  by  consorKa  already  using  these  

external  specificaKons.  

– Supports  CAPEC,  CCE,  CCSS,  CEE,  CPE,  CVE,  CVRF,  

(13)

IETF  MILE  WG:    

Current  Work  (2)  

drag-­‐inacio-­‐mile-­‐forensics  

– Represent  forensic  invesKgaKon  results  in  IODEF  

documents.  

drag-­‐moriarty-­‐mile-­‐grc-­‐exchange  

– Generalize  RID  to  allow  exchange  of  governance,  

risk,  and  compliance  informaKon.  

drag-­‐goodier-­‐mile-­‐data-­‐markets  

(14)

Learn  more,  get  involved  

IODEF  (RFC5070)  

– tools.iep.org/html/5070  

RID  (RFC6545/6546)  

– (sKll  in  editor  queue  due  to  CVRF  references)  

– tools.iep.org/html/drag-­‐iep-­‐mile-­‐rfc6045-­‐bis  

– tools.iep.org/html/drag-­‐iep-­‐mile-­‐rfc6046-­‐bis  

(15)

Acknowledgments  

FP7-­‐DEMONS  project  

Kathleen  Moriarty,  co-­‐chair,  MILE  

–  (Some  organizaKon  and  content  derived  from  her    

previous  presentaKons,  ©2011  EMC  CorporaKon,  her  employer.)  

Roman  Danyliw,  editor,  RFC5070  

the  IETF  MILE  working  group  

References

Related documents

Cawangan Jalan, Ibu Pejabat JKR, K.L CONTENTS Introduction A. Technical requirements and constructional details for all contracts are given in the Specification and the Drawings

Barnes intends to stay, treaty oaks distillery springs rental retreat for hill country west of the americas and organizations share this on facebook account, measure and

Patient safety is one of the most important objectives which can promote the quality of nursing care. Besides, patient safety culture is regarded as an important strategy and

• Created in 1997 to receive, review and respond to computer security incident reports and activities related to networks connected to the Internet in Brazil. – National focal point

The argument has been made that the POLST document may have been signed and decided on prior to a health care crisis so that when an emergency arises, the document can be used

The Parliament’s response to an incident is managed by the following teams; • Strategic - Incident Management Team. • Tactical - Emergency Response Team, -

your other hand as a pivot and gently step down in the opposite direction.(example: lift your  lift your  left hand, turn clockwise for 180 degrees, put it down again, lower one

The incident will then be recorded by the IT staff member on the VCCS Incident Reporting form, (attachment I 2.1 SVCC Security Plan) The objective of the Incident Response Plan is