Subject: [mile] IOCs

From: "Moriarty, Kathleen" <[email-masked]>
Date: Wed, 9 Jan 2013 17:08:37 -0500

Hi Take, et. al,

In looking at SCI, I am not sure where you might include indicators of compromise that are not included in the base IODEF schema and would like to know what others think.

To me, the logical place would be directly in the EventData class using the AdditionalData extension class, maybe using another SCI extension class called Detection.

Is there a place where these would fit already that I am missing or do we need another container?

Thank you!
Kathleen

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Fri, 11 Jan 2013 17:50:12 +0900

Hi Kathleen and all,

Thank you very much for the comments.
I agree that we should consider indicators of compromise that are not
included in the base IODEF schema.
At the same time, perhaps we could clarify what would be these indicators...

If the indicators are something like an XML-based alert/warning of
information leakage, it could be an event that are conveyed in the SCI's
EventReport class, IMHO.

If the indicators are something like an non-XML ones, I guess it could be
conveyed without using SCI draft.
For instance, we could use Impact class of the base IODEF to convey the
indicators.
We could for instance extend the list of indicators of the Impact class, if
needed.

If the indicators are something like the result of penetration test, or
indicators of exposed vulnerabilities, I guess neither SCI classes nor basic
IODEF classes have right place to fit them in at this moment.

Could we elaborate what would be these indicators?
I hope I am not missing the point.

Kind regards,
Take

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Moriarty, Kathleen
Sent: Thursday, January 10, 2013 7:09 AM
To: [email-masked]
Subject: [mile] IOCs

Hi Take, et. al,
 
In looking at SCI, I am not sure where you might include indicators of
compromise that are not included in the base IODEF schema and would like to
know what others think.
 
To me, the logical place would be directly in the EventData class using the
AdditionalData extension class, maybe using another SCI extension class
called Detection.
 
Is there a place where these would fit already that I am missing or do we
need another container?
 
Thank you!
Kathleen

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Fri, 11 Jan 2013 16:53:50 -0500

Hi Take,

Thank you for diving into this a bit more.

If you look at the base IODEF schema, we have a few issues that the working group discussed back in July (leading up to the July IETF) in Rosella's work.  For some of the indicators that are not covered, many of us thought it would make sense to put those directly into the updated version of IODEF.  For instance, including a web site or URI that was part of an attack is not covered, although the schema includes URIs for reference materials.  This one won't be part of the issue described below, but rather the less commonly shared indicators.  We may be better able to address this once we sort out some updates to RFC5070-bis and then we'll have a better handle on what we want to see embedded through other schemas.  I'll list out a few examples that we either have discussed on list or in a meeting before or that we may need to address.

URIs part of an attack - I think we all agreed this just needs to be added to the IODEF schema in RFC5070-bis. 

Registry Keys -- can be included now through the RecordItem class, but it is unclear how to represent them.  This should probably be addressed in RFC5070-bis, but could also be represented in embedded schemas.

Email message -- Could be represented through RFC5901 with more detailed domain information or you could alternatively embed another schema that can also carry that data.  So I think this is covered...

File Hashes -- covered in RFC5901 or another embedded schema.

Rosella questioned if some of the content from RFC5901 should be in the base IODEF schema... I think the best use of embedding other schemas would be for any of the indicators that are not as commonly shared or are introduced between IODEF schema revision cycles or if the representation did not provide enough information and the other schema could convey it better.  

Maybe we should address the updates in RFC5070-bis and discuss what belongs in that document and what belongs in the RFC5901 extension before trying to figure out where to place other indicators unless others have a few good examples.  This may result in guidance to help implementers (reduce their work if we had common guidance).

Thanks,
Kathleen

-----Original Message-----
From: Takeshi Takahashi [mailto:[email-masked]] 
Sent: Friday, January 11, 2013 3:50 AM
To: Moriarty, Kathleen; [email-masked]
Subject: RE: [mile] IOCs

Hi Kathleen and all,

Kind regards,
Take

Hi Take, et. al,

 
 
Thank you!
Kathleen

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Fri, 25 Jan 2013 14:57:43 -0500

Hi Take & all,

Thank you for the detailed response and sorry about the delay in my response!

I like your examples and agree, there are a number of places where SCI already has the placeholders to add indicators that are not covered in the base model.  Some other examples may include specific fields of email messages or if we want to extend using something that would let us express a combination of indicators from higher level analysis tools (network, malware, host-based, etc).  For the discussion below, I was thinking more of combined set with relationships that may be included in a single extension point, so that's why I was thinking about the EventData class, but there may be better locations or a specific area within the EventData.  Paul Stoecker had suggested a "Detection" class as a consideration.

We would need a way to connect the indicators in the base IODEF to the indicators included in other schemas.  Someone had suggested the use of an attribute on IODEF indicators, where we could include a unique ID or reference number - maybe call it indicator_ID or something similar (this would have to be in the RFC5070-bis update if agreed).  We may want this on IODEF included IPs or other elements.  It could correlate then with GUID or reference IDs used in other indicator schemas that include IOCs not in the base IODEF schema.

Any opinions on an Indicator_ID attribute (or some other name) and the best extension point for combined sets of indicators (AdditionalData off of EventData (change just in SCI) or a "Detection" class in the EventData class (change in RFC5070-bis and SCI for this option))?

Thanks,
Kathleen

-----Original Message-----
From: Takeshi Takahashi [mailto:[email-masked]] 
Sent: Friday, January 11, 2013 3:50 AM
To: Moriarty, Kathleen; [email-masked]
Subject: RE: [mile] IOCs

Hi Kathleen and all,

Kind regards,
Take

Hi Take, et. al,

 
 
Thank you!
Kathleen

---

From: "Stoecker, Paul" <[email-masked]>
Date: Sun, 27 Jan 2013 20:52:58 -0500

I would like to look at this from a slightly different perspectiveŠlet's
say I get an XML document that tells me about an incident.  This document
has source IP and destination IP that is being shared.  However, what I
don't know is which IP address is my indicator and which is just a
contextual piece of information.  This means that my detection product
isn't going to know which one to use either, because there is nothing to
tell me which IP is the one, even if the roles are set it still might not
be enough to tell my system which one I should use as the indicator.

If we had something like indicator_id as an attribute, it would allow us
to easily identify indicators from contextual data.  I do admit to being
biased as I have spent much of my career working on the monitoring and
detection side of these things, so I am just thinking of ways to make it
very clear what the indicators are in the XML document and the other data
that may be important as I investigate activity that I have detected off
of those indicators.

I did suggest the detection class, but I think we may get more flexibility
with the indicator_uid.  One thing that I haven't considered is the UID
portion of thisŠhow do we use that UID?  How is the UID created?  Are
there standards for UIDs?

Regards,

Paul

Paul W. Stoecker, Ph.D.
SMC Lead Content Architect
RSA, The Security Division of EMC
cell: 302.379.3375 | e: [email-masked]

On 1/25/13 2:57 PM, "Moriarty, Kathleen" <[email-masked]> wrote:

>I like your examples and agree, there are a number of places where SCI
>already has the placeholders to add indicators that are not covered in
>the base model.  Some other examples may include specific fields of email
>messages or if we want to extend using something that would let us
>express a combination of indicators from higher level analysis tools
>(network, malware, host-based, etc).  For the discussion below, I was
>thinking more of combined set with relationships that may be included in
>a single extension point, so that's why I was thinking about the
>EventData class, but there may be better locations or a specific area
>within the EventData.  Paul Stoecker had suggested a "Detection" class as
>a consideration.
>
>We would need a way to connect the indicators in the base IODEF to the
>indicators included in other schemas.  Someone had suggested the use of
>an attribute on IODEF indicators, where we could include a unique ID or
>reference number - maybe call it indicator_ID or something similar (this
>would have to be in the RFC5070-bis update if agreed).  We may want this
>on IODEF included IPs or other elements.  It could correlate then with
>GUID or reference IDs used in other indicator schemas that include IOCs
>not in the base IODEF schema.
>
>Any opinions on an Indicator_ID attribute (or some other name) and the
>best extension point for combined sets of indicators (AdditionalData off
>of EventData (change just in SCI) or a "Detection" class in the EventData
>class (change in RFC5070-bis and SCI for this option))?
>
>Thanks,
>Kathleen
>
>_______________________________________________
>mile mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mile
>