Subject: [mile] Incident/Indicators

From: "Moriarty, Kathleen" <[email-masked]>
Date: Thu, 15 Nov 2012 15:43:30 -0500

Hello,

I'd like to hear some opinions on the way that INCH and MILE have used and defined the term incident and if we should change or update the definition for the update of RFC5070.  I have been asked a few times if IODEF covers indicators.   From INCH, the understanding was that we broadly referred to an incident and it could use IODEF to exchange selected parts of an incident and not just the full incident information.  The IODEF format could be used to encompass a full incident report or just a few helpful parts of that incident, today called indicators.

As we start an RFC5070-bis, do we update the definition of an incident to include this newer term or use the word indicator in the document more?  Here is the current intended use of the term from RFC5070:

1.3.  About the IODEF Data Model

   The IODEF data model is a data representation that provides a
   framework for sharing information commonly exchanged by CSIRTs about
   computer security incidents.  A number of considerations were made in
   the design of the data model.

   o  The data model serves as a transport format.  Therefore, its
      specific representation is not the optimal representation for on-
      disk storage, long-term archiving, or in-memory processing.

   o  As there is no precise widely agreed upon definition for an
      incident, the data model does not attempt to dictate one through
      its implementation.  Rather, a broad understanding is assumed in
      the IODEF that is flexible enough to encompass most operators.

   o  Describing an incident for all definitions would require an
      extremely complex data model.  Therefore, the IODEF only intends
      to be a framework to convey commonly exchanged incident
      information.  It ensures that there are ample mechanisms for
      extensibility to support organization-specific information, and
      techniques to reference information kept outside of the explicit
      data model.

   o  The domain of security analysis is not fully standardized and must
      rely on free-form textual descriptions.  The IODEF attempts to
      strike a balance between supporting this free-form content, while
      still allowing automated processing of incident information.

   o  The IODEF is only one of several security relevant data
      representations being standardized.  Attempts were made to ensure
      they were complimentary.  The data model of the Intrusion
      Detection Message Exchange Format [17] influenced the design of
      the IODEF.

   Further discussion of the desirable properties for the IODEF can be
   found in the Requirements for the Format for Incident Information
   Exchange (FINE) [16].

Thank you,
Kathleen

---

From: "Black, David" <[email-masked]>
Date: Sat, 17 Nov 2012 10:13:38 -0500

Hi Kathleen,

Here's my 0.02 ...

> The IODEF format could be used to encompass a full incident report or

> just a few helpful parts of that incident, today called indicators.

> As we start an RFC5070-bis, do we update the definition of an incident to

> include this newer term or use the word indicator in the document more?

IMHO - yes, both sound like good ideas :-).

An update to use current terminology certainly sounds like a good thing

to do.  In addition to using "indicator" in the definition of "incident",

I'd suggest adding a definition of "indicator" as a part or an aspect of

an incident and using that term as appropriate in the body of the draft,

as that should help readers who are more familiar with current terminology.

It might also be useful to discuss use of an IODEF Incident instance

as a lightweight container for selected indicators - the incident ID

would serve only as part of wrapping the indicators in a collection,

and in the simple case where there's only one indicator, that incident

ID effectively provides an identifier for the indicator.

Anyone else care to comment?

Thanks,
--David

From: [email-masked] [mailto:[email-masked]] On Behalf Of Moriarty, Kathleen
Sent: Thursday, November 15, 2012 3:44 PM
To: [email-masked]
Cc: Roman D. Danyliw; Stoecker, Paul
Subject: [mile] Incident/Indicators

Hello,

Thank you,
Kathleen

---

From: "Waltermire, David A." <[email-masked]>
Date: Tue, 20 Nov 2012 14:22:45 -0500

David,

+1.  What you are suggesting sounds like a reasonable approach.

Sincerely,
Dave

From: [email-masked] [mailto:[email-masked]] On Behalf Of Black, David
Sent: Saturday, November 17, 2012 10:14 AM
To: Moriarty, Kathleen; [email-masked]
Cc: Roman D. Danyliw; Stoecker, Paul
Subject: Re: [mile] Incident/Indicators

Hi Kathleen,

Here's my 0.02 ...

Thanks,
--David

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Moriarty, Kathleen
Sent: Thursday, November 15, 2012 3:44 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Roman D. Danyliw; Stoecker, Paul
Subject: [mile] Incident/Indicators

Hello,

Thank you,
Kathleen

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Tue, 20 Nov 2012 21:24:32 +0000

+1.
I also think Indicators sound more suitable.
Panos

Hello,

Thank you,
Kathleen