Subject: Re: [mile] IOCs

From: "Moriarty, Kathleen" <[email-masked]>
Date: Fri, 1 Feb 2013 11:27:57 -0500

All –

I’d like your input and will refocus the thread to get opinions from the list on options to help solve the problems raised in my message and additionally in Paul’s message.

Interesting point, C. Henry.  Our objective here is to have machine automated exchanges, so we rely on encryption rather than obfuscation to achieve the necessary level of confidentiality.

Paul mentioned the need to distinguish indicators of compromise from context information that may also include IP address or other data that could be indicators.  The question I raised was on how to connect sets of indicators in the same IODEF document, assuming the ability to have watchlists that could have several sets of indicators included, as well as to connect indicators that may be included in embedded schemas.

If we add an attribute on all of the relevant indicators, let’s say ‘indicator-uid’ how do we mark the indicators?  Do we use this to mark who sent the indicator as well so that we can prevent forward sharing when it is not permitted or handle that separately?

Then for indicators not included in the base schema that may not fit into a category in the SCI draft, do we create a place for these off of SCI or right off of the IODE schema in EventData? (more details on this in my first message).

Comments and questions encouraged to figure out the right technical solution to have this machine automatable.

Thank you,
Kathleen

From: [email-masked] [mailto:[email-masked]] On Behalf Of C. Henry Adams & BIE
Sent: Monday, January 28, 2013 11:25 PM
To: MILE IETF
Subject: Re: [mile] IOCs

Temporal Dependency sounds interesting.  I remember when I first ran across this particular craft, an experienced colleague asked me a peculiar question.  He said, " How do you stop someone from tracking the IP Address to your computer?"

I replied, "I don't know, how?"

Then he said, "Cut the dog-gone thing off  and the modem that it is connected- which is constantly on!"   LOL

Here's my point (Hypothetical Situation) :  There is a 1st Responder searching a Neighborhood for Survivors which were hit by a Disaster or let's just say "Live" Terrorist Situation.  He /or She needs to communication back to other Officials that he /or somehow is in Danger.  The device used to communicate has been captured by the great minds of the enemy.  It's only a matter of time before they utilize reverse engineering to figure out how it functions.  However, their pride comes before a fall when seeking the location of other similar devices to attack.  Why? Perhaps the less thought of concepts that makes the device function properly, saves the day by disguise or cutting it off (figuratively speaking).

Just a visionary thought.

C. Henry Adams
[email-masked]<mailto:[email-masked]>
http://biemediagroup.com

The information contained herein is for the exclusive use of the original recipient. This information is granted for limited distribution within the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited.

--- On Mon, 1/28/13, Dave Misell <[email-masked]<mailto:[email-masked]>> wrote:

From: Dave Misell <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mile] IOCs
To: "C. Henry Adams & BIE" <[email-masked]<mailto:[email-masked]>>
Date: Monday, January 28, 2013, 9:25 PM
UID could be mirrored with DNS SEC a pemanent and temporal key, with a temporal Id?

Yours Faithfully,

Dave Misell MSc CISSP
SilentCircle  dsm
07710 380044
[email-masked]</mc/compose?to=[email-masked]>

On 29 Jan 2013, at 00:39, C. Henry Adams & BIE <[email-masked]</mc/compose?to=[email-masked]>> wrote:

> Serialization of a particular Lists of XML Classes in a unique way was closely related to what I attempted to express when I stated, "consider to a degree what appears to be illogical in brilliant minds in some instances."
>
> However, I see Dr. Stoecker's point a little clearer.  However, it would be nice if the UID was in some way disguised from those who study this Security Art Form in a negative way.
>
> C. Henry Adams
> [email-masked]</mc/compose?to=[email-masked]> (Direct Email)
> [email-masked]</mc/compose?to=[email-masked]>
>
>
> The information contained herein is for the exclusive use of the original recipient. This information is granted for limited distribution within the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited.
>
> Re: [mile] IOCs
>
> Sunday, January 27, 2013 8:52 PM
> From:
> "Stoecker, Paul" <[email-masked]</mc/compose?to=[email-masked]>>
> To:
> "[email-masked]</mc/compose?to=[email-masked]>" <[email-masked]</mc/compose?to=[email-masked]>>
> 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]</mc/compose?to=[email-masked]>
>
> --- On Sat, 1/26/13, C. Henry Adams & BIE <[email-masked]</mc/compose?to=[email-masked]>> wrote:
>
> From: C. Henry Adams & BIE <[email-masked]</mc/compose?to=[email-masked]>>
> Subject: RE: [mile] IOCs
> To: "KathleenMoriarty" <[email-masked]</mc/compose?to=[email-masked]>>
> Cc: [email-masked]</mc/compose?to=[email-masked]>
> Date: Saturday, January 26, 2013, 6:17 PM
>
> Greetings Kathleen,
>
> Your logic stimulates my visionary brain because I'm amazed at the many avenues you review with this approach at once.  However,  could you share a few advantages and disadvantages to the latter?
>
> --------------------------------------------------------------------------------------------------------------------------
> "we could continue to group items in logical places as is done now in IODEF and then have the extension point for combined indicators via SCI."
>
> -------------------------------------------------------------------------------------------------------------------------
>
> You pointed out what you consider to be logical places, but if I wanted to protect information from parties capable of ascertaining it from your logical places, perhaps we should also consider to a degree what appears to be illogical in brilliant minds in some instances.
>
>
>
> C. Henry Adams
> [email-masked]</mc/compose?to=[email-masked]> (Direct Email)
> [email-masked]</mc/compose?to=[email-masked]>
>
> The information contained herein is for the exclusive use of the original recipient. This information is granted for limited distribution within the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited.
>
> --- On Sat, 1/26/13, Moriarty, Kathleen <[email-masked]</mc/compose?to=[email-masked]>> wrote:
>
> From: Moriarty, Kathleen <[email-masked]</mc/compose?to=[email-masked]>>
> Subject: RE: [mile] IOCs
> To: "C. Henry Adams & BIE" <[email-masked]</mc/compose?to=[email-masked]>>, "[email-masked]</mc/compose?to=[email-masked]>" <[email-masked]</mc/compose?to=[email-masked]>>
> Date: Saturday, January 26, 2013, 10:13 AM
>
> Hello C. Henry & others,
>
> Thanks for taking a look at this.  We have a few considerations in this email thread I would like to hear thoughts on (and there may be more once RFC5070-bis is actively edited).
>
> The AdditionalData class and the RecordItem class both allow for non-XML extensions.  Where you place the extensions should be specific to the logical grouping of the parent elements so you can understand more about the included data in most cases.
>
> The Impact class can be used to provide context information on the included data of the report and also can include a confidence rating on the report as a whole.  Extensions related to impact would be one level higher (at the moment) in the Assessment class using the AdditionalData extension point.
>
> Take asked about including vulnerability information, I would think that would fit under the Vulnerability extension point of the SCI draft in the Method class.  He did ask about non-XML.  RecordItem or AdditionalData do allow for non-XML extension points, we could either have the SCI draft handle these as well or have the extensions that are non-XML come directly off the AdditionalData or RecordItem classes according to what makes sense from a logical standpoint.
>
> As for my question, it was two-fold.
>
> Indicator based schemas have a reference number or a GUID for the various indicators they share.  If we are extending to embed other schemas that include such reference or GUID identifiers, do we want to add an attribute to the various elements in IODEF that could be indicators?  Is this enough to make the connections or is something else else needed?  We could add something like an Indicator_ID in RFC5070-bis which would then correlate to the reference or GUID identifiers.
>
> Then the other question was on how to include indicators that are not in the base schema that may be related or have language with "and" "or" to specify the relationships.  In some cases, you will want to group these indictors in one extension point, where they may fit logically in multiple places if the relationships did not need to be shown in the data format.  If we have cases like this where you need more complex representations, should we use one extension point via the SCI draft off of the EventData class AdditionalData extension point?  Opinions are needed here....
>
> A few people have mentioned wanting to include some commonly shared indictors into the base IODEF document.  We could have a catch-all class that does this and has an extension point off of it in EventData or we could continue to group items in logical places as is done now in IODEF and then have the extension point for combined indicators via SCI.  I think I like the latter approach.
>
> Thank you,
> Kathleen
> ________________________________________
> From: [email-masked]</mc/compose?to=[email-masked]> [[email-masked]</mc/compose?to=[email-masked]>] On Behalf Of C. Henry Adams & BIE [[email-masked]</mc/compose?to=[email-masked]>]
> Sent: Saturday, January 26, 2013 3:05 AM
> To: [email-masked]</mc/compose?to=[email-masked]>
> Cc: C. Henry Adams
> Subject: Re: [mile] IOCs
>
> Greetings Everyone,
>
> Take mentioned two types of indicators based on the :
> ------------------------------------------------------------------------------------------------------
> 1) 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.
>
> 2) 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.
> ------------------------------------------------------------------------------------------------------
>
> In doing so he pointed out the "Impact Class"
>
> Whereas, Kathleen stated,
>
> -----------------------------------------------------------------------------------------------------
> 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.
> ----------------------------------------------------------------------------------------------------
>
> Kathleen thoughts related yet still with other indicators and the EventData Class.
>
> Is there a possible way to create a new XML class which encompass combining the EventData, Detection and base IODEF classes to simplify this issue?
>
>
> C. Henry Adams
> [email-masked]</mc/compose?to=[email-masked]> (Direct Email)
> [email-masked]</mc/compose?to=[email-masked]>
>
>
> The information contained herein is for the exclusive use of the original recipient. This information is granted for limited distribution within the recipient's place of business for planning purposes only. Further dissemination, whether private or public is prohibited.
> _______________________________________________
> mile mailing list
> [email-masked]</mc/compose?to=[email-masked]>
> https://www.ietf.org/mailman/listinfo/mile

---

From: "Harrington, Christopher" <[email-masked]>
Date: Fri, 1 Feb 2013 12:00:56 -0500

I think we have a bigger relationship issue to address. Let use the Watchlist Use Case. A bunch of indicators are sent in one message. In that message we could have groupings of indicators that we need to show are related:

Two or more indicators of different type that relate to the same threat:

The file hash of a malicious file and the URL of the C2 that the file uses. Either or both may be present to indicate a compromise. 

Two or more indicators of the same type that relate to the same threat: 

2 different registry values for the same registry key. If either value is present it is a compromise indicator but both will not be present. 

The problem compounds itself very quickly. Consider the scenario where both groupings above are part of the same threat. I need to show that logical groupings of Indicators are related as well. We can’t send multiple IODEF messages for this from what I remember reading. 

The last one I can think of would be when you have 2 different indicators that represent the same indicator. It’s not uncommon to send both the MD5 and SHA1 hash of a malicious file. The indicator is the file but the IOCs are the 2 hash values. How do we show they are related? If we use a unique Inidcator ID for each hash value there needs to be a higher level grouping. 

Thoughts?

Thanks,

--Chris

Christopher Harrington

Consulting Security Engineer

GSO - Critical Incident Response Center

EMC - Where Information Lives

174 Middlesex Turnpike

Bedford, MA 01730

781-515-5862 (work)

603-583-1585 (cell)

From: [email-masked] [mailto:[email-masked]] On Behalf Of Moriarty, Kathleen
Sent: Friday, February 01, 2013 11:28 AM
To: MILE IETF
Subject: Re: [mile] IOCs

All – 

Thank you,

Kathleen

C. Henry Adams
[email-masked]
http://biemediagroup.com

--- On Mon, 1/28/13, Dave Misell <[email-masked]> wrote:

From: Dave Misell <[email-masked]>
Subject: Re: [mile] IOCs
To: "C. Henry Adams & BIE" <[email-masked]>
Date: Monday, January 28, 2013, 9:25 PM

Yours Faithfully,

Dave Misell MSc CISSP
SilentCircle  dsm
07710 380044
[email-masked]

On 29 Jan 2013, at 00:39, C. Henry Adams & BIE <[email-masked]> wrote:

> [email-masked] (Direct Email)
> [email-masked]
> 
> 
> "Stoecker, Paul" <[email-masked]>
> To:
> "[email-masked]" <[email-masked]>
> cell: 302.379.3375 | e: [email-masked]
> 
> --- On Sat, 1/26/13, C. Henry Adams & BIE <[email-masked]> wrote:
> 
> From: C. Henry Adams & BIE <[email-masked]>
> Subject: RE: [mile] IOCs
> To: "KathleenMoriarty" <[email-masked]>
> Cc: [email-masked]
> [email-masked] (Direct Email)
> [email-masked]
> 
> --- On Sat, 1/26/13, Moriarty, Kathleen <[email-masked]> wrote:
> 
> From: Moriarty, Kathleen <[email-masked]>
> Subject: RE: [mile] IOCs
> To: "C. Henry Adams & BIE" <[email-masked]>, "[email-masked]" <[email-masked]>
> From: [email-masked] [[email-masked]] On Behalf Of C. Henry Adams & BIE [[email-masked]]
> To: [email-masked]
> [email-masked] (Direct Email)
> [email-masked]
> 
> 
> [email-masked]

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Sun, 3 Feb 2013 17:11:36 -0500

Hi Chris,

I agree, we have some work to do in the updated IODEF, RFC5070-bis.

The list has already said they would like to see indicators added to the definitions in RFC5070-bis, to be more explicit about including indicators and sets of indicators in IODE documents as opposed to ‘parts of an incident or the useful information on an incident for sharing purposes.  It was written before we used terms like indicators.  With that in mind, Rosella proposed a number of changes back in July, both for guidance and for format updates.  It may help to have the first draft try to address at least some of these issues so people can understand the problems and at least a proposed solution.

As you point out, we need to be able to show relationships between sets of indicators, where we may have a few sets of indicators that could have a relationship to each other within a document.  In the July presentation, one of the questions was to see if we should add new category attribute values for the System class that would connect the list of included indicators.  I think we should still keep the concept of a Node to a single node, but perhaps within System, list multiple sets of Nodes that may be one type of attack.  Rosella had suggested pulling forward the “FraudType” from RFC5901, this would help solve the issue as NodeRole values would compliment an AttackType (FraudType values could be included in AttackType or some broader term).  It may be better to have the FraudTypes, plus attribute values like “C2-server”, “sinkhole”,  “MalwareDistribution” for added context so you know what to do with the received set of indicators.

I am proposing that we change IODEF to include multiple sets of indicators, add an AttackType attribute (or some other name), a method to connect indicators and indicator sets within an IODEF using an attribute of indicator_uid (or some other name) with a string value to make the connection points, and add a few indicators that are commonly shared into the base IODEF.

Back in July, we talked about adding Registry Key/Value pairs and hashes to the main IODEF document (trying to see if this will help Chris below).  What if we added the Registry Key/Value pairs as a class off of RecordData, using a similar structure to what is in RFC5901, and also added the ability to include hashes in RecordData?  I think if we then had the indicator_uid at the RecordData level, we could connect a set within that structure and repeat the structure for other sets in the same way we would do with Node inside of the System class, using the indicator_uid to tie the set together.  Then at the more specific level for the hash, registry Key/value, IP, etc. use an indicator_uid if we needed them marked at this level as well?  Maybe we want indicator_set at the higher level?  I’d like some opinions on this approach.  +1 if you agree, suggestions if you have other ideas that may work better.

We’ll also need to worry about marking the indicators to prevent forward sharing when not permitted.  We may want to use these values or something else.  

Thank you!
Kathleen  

From: Harrington, Christopher 
Sent: Friday, February 01, 2013 12:01 PM
To: Moriarty, Kathleen; MILE IETF
Subject: RE: [mile] IOCs

Thoughts?

Thanks,

--Chris

Christopher Harrington

174 Middlesex Turnpike

Bedford, MA 01730

781-515-5862 (work)

603-583-1585 (cell)

All – 

Thank you,

Kathleen

C. Henry Adams

Yours Faithfully,

Dave Misell MSc CISSP
SilentCircle  dsm
07710 380044
[email-masked]

---

From: "Stoecker, Paul" <[email-masked]>
Date: Sun, 3 Feb 2013 20:26:02 -0500

What if we added indicator group ID along with the indicator_uid?  This would allow you to group indicators that are related into the same group ID.  Would this resolve the issue?

It is either that or going back to adding a Detection (or Indicators) class that will should be used to take all of the indicators put them into one place and have the ability to group the ones that go together.  I don't mean a place to put indicators that are missing from IODEF…I mean a place in the IODEF document where you put the indicators that are used for detection and prevention of the shared Incident.  I don't know the answer here, but there has got to be a good way for indicators to be identified and being able to group them as Chris has suggested without basically recreating something complicated like STIX.

Paul

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

From: <Moriarty>, Kathleen <[email-masked]<mailto:[email-masked]>>
Date: Sunday, February 3, 2013 5:11 PM
To: "Harrington, Christopher" <[email-masked]<mailto:[email-masked]>>, MILE IETF <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mile] IOCs

Hi Chris,

Thank you!
Kathleen

Thoughts?

Thanks,

--Chris

Christopher Harrington

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Moriarty, Kathleen
Sent: Friday, February 01, 2013 11:28 AM
To: MILE IETF
Subject: Re: [mile] IOCs

All –

Thank you,
Kathleen

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of C. Henry Adams & BIE
Sent: Monday, January 28, 2013 11:25 PM
To: MILE IETF
Subject: Re: [mile] IOCs

C. Henry Adams

Yours Faithfully,

Dave Misell MSc CISSP
SilentCircle  dsm
07710 380044

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Mon, 4 Feb 2013 13:34:51 -0500

Others on the list, please chime in to help on this issue and the possible solutions (agreement or disagreement on approaches).

Paul & others, if we have an indicator group id, (let's say indicator_set_id)  and an indicator unique id (indicator_uid), we might use the indicator_set_id to mark a set and connect a set within an IODEF document as well as between other XML documents.  If we do that, then is the indicator_uid helpful?  I think it could be if we use that to mark where the indicator originated in some way that we also know how it can be used and if it can be shared forward marked at an indicator level (in addition to the sharing group in RID for the whole document or set of documents shared).

What would this look like?

How about the following where you use the set marker at class level for each of the classes that includes indicators or important context on those indicators:

   +------------------+
   | EventData        |
   +------------------+
   | ENUM restriction |<>--{0..*}--[ Description    ]
   |                  |<>--{0..1}--[ DetectTime     ]
   |                  |<>--{0..1}--[ StartTime      ]
   |                  |<>--{0..1}--[ EndTime        ]
   |                  |<>--{0..*}--[ Contact        ]
   |                  |<>--{0..1}--[ Assessment     ]
   |                  |<>--{0..*}--[ Method         ]
   |                  |<>--{0..*}--[ Flow           ]
   |                  |<>--{0..*}--[ Expectation    ]
   |                  |<>--{0..1}--[ Record         ]
   |                  |<>--{0..*}--[ EventData      ]
   |                  |<>--{0..*}--[ AdditionalData ]
   +------------------+

Since you could use the nested EventData instance to include the full set, you would need indicator_set_id as an attribute to the EventData class.  Then Since you can have many of the classes from the above directly in the Incident class, the ones that contain indicators would also need the capability to mark or connect a set of indicators.  That includes:

Method -> Reference (Set at the Reference class so you can tie References to specific indicator sets if there are multiple).
Flow -> System  ( I think the set should start at the System class level, maybe at the Flow too),
                the node should be kept to a single Node that may be represented in many ways, but
                 I think we should add categories to System so we can have a watchlist at that level
                without needing many instances of EventData (thoughts)?  This would just work
                when the Service and OperatingSystem information matched across the watchlist
                or when that data was omitted.
Record -> RecordData (at the RecordData class, where we may add Registry Key/value pairs and file hashes)

Context: Contact, Expectation, DetectTime, StartTime, and EndTime

By having this at the Assessment and Expectation classes, you can set the recommended actions and confidence levels at the indicator set level.  You could alternatively do this by adding more attributes to the individual indicator element/classes.

Then the Node, Address, NodeName, Application, other added indicators (registry key/value pairs, hashes, etc.)  would need the indicator_uid (if this is helpful).

As Paul mentioned, you could have groupings in a new class, but we would need to be able to include all the types of indicators, so it may be complex to have more representation options for the same types of indicators.  Would the above build in the additional flexibility that is needed or what would the proposed Detection class look like in case it is a better option?

Thanks!
Kathleen

From: Stoecker, Paul
Sent: Sunday, February 03, 2013 8:26 PM
To: Moriarty, Kathleen; Harrington, Christopher; MILE IETF
Subject: Re: [mile] IOCs

It is either that or going back to adding a Detection (or Indicators) class that will should be used to take all of the indicators put them into one place and have the ability to group the ones that go together.  I don't mean a place to put indicators that are missing from IODEF...I mean a place in the IODEF document where you put the indicators that are used for detection and prevention of the shared Incident.  I don't know the answer here, but there has got to be a good way for indicators to be identified and being able to group them as Chris has suggested without basically recreating something complicated like STIX.

Paul

Paul W. Stoecker, Ph.D.

Hi Chris,

The list has already said they would like to see indicators added to the definitions in RFC5070-bis, to be more explicit about including indicators and sets of indicators in IODE documents as opposed to 'parts of an incident or the useful information on an incident for sharing purposes.  It was written before we used terms like indicators.  With that in mind, Rosella proposed a number of changes back in July, both for guidance and for format updates.  It may help to have the first draft try to address at least some of these issues so people can understand the problems and at least a proposed solution.

As you point out, we need to be able to show relationships between sets of indicators, where we may have a few sets of indicators that could have a relationship to each other within a document.  In the July presentation, one of the questions was to see if we should add new category attribute values for the System class that would connect the list of included indicators.  I think we should still keep the concept of a Node to a single node, but perhaps within System, list multiple sets of Nodes that may be one type of attack.  Rosella had suggested pulling forward the "FraudType" from RFC5901, this would help solve the issue as NodeRole values would compliment an AttackType (FraudType values could be included in AttackType or some broader term).  It may be better to have the FraudTypes, plus attribute values like "C2-server", "sinkhole",  "MalwareDistribution" for added context so you know what to do with the received set of indicators.

Back in July, we talked about adding Registry Key/Value pairs and hashes to the main IODEF document (trying to see if this will help Chris below).  What if we added the Registry Key/Value pairs as a class off of RecordData, using a similar structure to what is in RFC5901, and also added the ability to include hashes in RecordData?  I think if we then had the indicator_uid at the RecordData level, we could connect a set within that structure and repeat the structure for other sets in the same way we would do with Node inside of the System class, using the indicator_uid to tie the set together.  Then at the more specific level for the hash, registry Key/value, IP, etc. use an indicator_uid if we needed them marked at this level as well?  Maybe we want indicator_set at the higher level?  I'd like some opinions on this approach.  +1 if you agree, suggestions if you have other ideas that may work better.

We'll also need to worry about marking the indicators to prevent forward sharing when not permitted.  We may want to use these values or something else.

Thank you!
Kathleen

The problem compounds itself very quickly. Consider the scenario where both groupings above are part of the same threat. I need to show that logical groupings of Indicators are related as well. We can't send multiple IODEF messages for this from what I remember reading.

The last one I can think of would be when you have 2 different indicators that represent the same indicator. It's not uncommon to send both the MD5 and SHA1 hash of a malicious file. The indicator is the file but the IOCs are the 2 hash values. How do we show they are related? If we use a unique Inidcator ID for each hash value there needs to be a higher level grouping.

Thoughts?

Thanks,

--Chris

Christopher Harrington

All -

I'd like your input and will refocus the thread to get opinions from the list on options to help solve the problems raised in my message and additionally in Paul's message.

If we add an attribute on all of the relevant indicators, let's say 'indicator-uid' how do we mark the indicators?  Do we use this to mark who sent the indicator as well so that we can prevent forward sharing when it is not permitted or handle that separately?

Thank you,
Kathleen

C. Henry Adams

Yours Faithfully,

Dave Misell MSc CISSP
SilentCircle  dsm
07710 380044

---

From: "Harrington, Christopher" <[email-masked]>
Date: Mon, 4 Feb 2013 14:25:10 -0500

I think some sort of group ID would do the trick. We also need a logical and
/ or somewhere to show relationship between indicators. If I give you 2
registry keys do they both have to be present to be an indication of
compromise or is either one by themselves an indicator? Both would have the
same group ID since they are related. 

Thanks,

--Chris

From: Stoecker, Paul 

What if we added indicator group ID along with the indicator_uid?  This
would allow you to group indicators that are related into the same group ID.
Would this resolve the issue?

It is either that or going back to adding a Detection (or Indicators) class
that will should be used to take all of the indicators put them into one
place and have the ability to group the ones that go together.  I don't mean
a place to put indicators that are missing from IODEF.I mean a place in the
IODEF document where you put the indicators that are used for detection and
prevention of the shared Incident.  I don't know the answer here, but there
has got to be a good way for indicators to be identified and being able to
group them as Chris has suggested without basically recreating something
complicated like STIX.

Paul

Paul W. Stoecker, Ph.D.

 

From: <Moriarty>, Kathleen <[email-masked]>
Date: Sunday, February 3, 2013 5:11 PM
To: "Harrington, Christopher" <[email-masked]>, MILE IETF
<[email-masked]>
Subject: Re: [mile] IOCs

Hi Chris,

The list has already said they would like to see indicators added to the
definitions in RFC5070-bis, to be more explicit about including indicators
and sets of indicators in IODE documents as opposed to 'parts of an incident
or the useful information on an incident for sharing purposes.  It was
written before we used terms like indicators.  With that in mind, Rosella
proposed a number of changes back in July, both for guidance and for format
updates.  It may help to have the first draft try to address at least some
of these issues so people can understand the problems and at least a
proposed solution.

As you point out, we need to be able to show relationships between sets of
indicators, where we may have a few sets of indicators that could have a
relationship to each other within a document.  In the July presentation, one
of the questions was to see if we should add new category attribute values
for the System class that would connect the list of included indicators.  I
think we should still keep the concept of a Node to a single node, but
perhaps within System, list multiple sets of Nodes that may be one type of
attack.  Rosella had suggested pulling forward the "FraudType" from RFC5901,
this would help solve the issue as NodeRole values would compliment an
AttackType (FraudType values could be included in AttackType or some broader
term).  It may be better to have the FraudTypes, plus attribute values like
"C2-server", "sinkhole",  "MalwareDistribution" for added context so you
know what to do with the received set of indicators.

I am proposing that we change IODEF to include multiple sets of indicators,
add an AttackType attribute (or some other name), a method to connect
indicators and indicator sets within an IODEF using an attribute of
indicator_uid (or some other name) with a string value to make the
connection points, and add a few indicators that are commonly shared into
the base IODEF.

Back in July, we talked about adding Registry Key/Value pairs and hashes to
the main IODEF document (trying to see if this will help Chris below).  What
if we added the Registry Key/Value pairs as a class off of RecordData, using
a similar structure to what is in RFC5901, and also added the ability to
include hashes in RecordData?  I think if we then had the indicator_uid at
the RecordData level, we could connect a set within that structure and
repeat the structure for other sets in the same way we would do with Node
inside of the System class, using the indicator_uid to tie the set together.
Then at the more specific level for the hash, registry Key/value, IP, etc.
use an indicator_uid if we needed them marked at this level as well?  Maybe
we want indicator_set at the higher level?  I'd like some opinions on this
approach.  +1 if you agree, suggestions if you have other ideas that may
work better.

We'll also need to worry about marking the indicators to prevent forward
sharing when not permitted.  We may want to use these values or something
else.  

Thank you!
Kathleen  

I think we have a bigger relationship issue to address. Let use the
Watchlist Use Case. A bunch of indicators are sent in one message. In that
message we could have groupings of indicators that we need to show are
related:

The file hash of a malicious file and the URL of the C2 that the file uses.
Either or both may be present to indicate a compromise. 

2 different registry values for the same registry key. If either value is
present it is a compromise indicator but both will not be present. 

The problem compounds itself very quickly. Consider the scenario where both
groupings above are part of the same threat. I need to show that logical
groupings of Indicators are related as well. We can't send multiple IODEF
messages for this from what I remember reading. 

The last one I can think of would be when you have 2 different indicators
that represent the same indicator. It's not uncommon to send both the MD5
and SHA1 hash of a malicious file. The indicator is the file but the IOCs
are the 2 hash values. How do we show they are related? If we use a unique
Inidcator ID for each hash value there needs to be a higher level grouping. 

Thoughts?

Thanks,

--Chris

Christopher Harrington

174 Middlesex Turnpike

Bedford, MA 01730

781-515-5862 (work)

603-583-1585 (cell)

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Moriarty, Kathleen
Sent: Friday, February 01, 2013 11:28 AM
To: MILE IETF
Subject: Re: [mile] IOCs

All - 

I'd like your input and will refocus the thread to get opinions from the
list on options to help solve the problems raised in my message and
additionally in Paul's message.

Interesting point, C. Henry.  Our objective here is to have machine
automated exchanges, so we rely on encryption rather than obfuscation to
achieve the necessary level of confidentiality.

Paul mentioned the need to distinguish indicators of compromise from context
information that may also include IP address or other data that could be
indicators.  The question I raised was on how to connect sets of indicators
in the same IODEF document, assuming the ability to have watchlists that
could have several sets of indicators included, as well as to connect
indicators that may be included in embedded schemas.

If we add an attribute on all of the relevant indicators, let's say
'indicator-uid' how do we mark the indicators?  Do we use this to mark who
sent the indicator as well so that we can prevent forward sharing when it is
not permitted or handle that separately?  

Then for indicators not included in the base schema that may not fit into a
category in the SCI draft, do we create a place for these off of SCI or
right off of the IODE schema in EventData? (more details on this in my first
message).

Comments and questions encouraged to figure out the right technical solution
to have this machine automatable.

Thank you,

Kathleen

From: [email-masked] [mailto:[email-masked]] On Behalf Of C.
Henry Adams & BIE
Sent: Monday, January 28, 2013 11:25 PM
To: MILE IETF
Subject: Re: [mile] IOCs

Temporal Dependency sounds interesting.  I remember when I first ran across
this particular craft, an experienced colleague asked me a peculiar
question.  He said, " How do you stop someone from tracking the IP Address
to your computer?"  

Then he said, "Cut the dog-gone thing off  and the modem that it is
connected- which is constantly on!"   LOL

Here's my point (Hypothetical Situation) :  There is a 1st Responder
searching a Neighborhood for Survivors which were hit by a Disaster or let's
just say "Live" Terrorist Situation.  He /or She needs to communication back
to other Officials that he /or somehow is in Danger.  The device used to
communicate has been captured by the great minds of the enemy.  It's only a
matter of time before they utilize reverse engineering to figure out how it
functions.  However, their pride comes before a fall when seeking the
location of other similar devices to attack.  Why? Perhaps the less thought
of concepts that makes the device function properly, saves the day by
disguise or cutting it off (figuratively speaking).

C. Henry Adams

The information contained herein is for the exclusive use of the original
recipient. This information is granted for limited distribution within the
recipient's place of business for planning purposes only. Further
dissemination, whether private or public is prohibited.

UID could be mirrored with DNS SEC a pemanent and temporal key, with a
temporal Id?

Yours Faithfully,

Dave Misell MSc CISSP
SilentCircle  dsm
07710 380044
[email-masked]

On 29 Jan 2013, at 00:39, C. Henry Adams & BIE <[email-masked]>
wrote:

> Serialization of a particular Lists of XML Classes in a unique way was
closely related to what I attempted to express when I stated, "consider to a
degree what appears to be illogical in brilliant minds in some instances."
> 
> However, I see Dr. Stoecker's point a little clearer.  However, it would
be nice if the UID was in some way disguised from those who study this
Security Art Form in a negative way.
> The information contained herein is for the exclusive use of the original
recipient. This information is granted for limited distribution within the
recipient's place of business for planning purposes only. Further
dissemination, whether private or public is prohibited.
> Your logic stimulates my visionary brain because I'm amazed at the many
avenues you review with this approach at once.  However,  could you share a
few advantages and disadvantages to the latter?
----------------------------------------------------------------------------
----------------------------------------------
> "we could continue to group items in logical places as is done now in
IODEF and then have the extension point for combined indicators via SCI."
----------------------------------------------------------------------------
---------------------------------------------
> 
> You pointed out what you consider to be logical places, but if I wanted to
protect information from parties capable of ascertaining it from your
logical places, perhaps we should also consider to a degree what appears to
be illogical in brilliant minds in some instances.
> The information contained herein is for the exclusive use of the original
recipient. This information is granted for limited distribution within the
recipient's place of business for planning purposes only. Further
dissemination, whether private or public is prohibited.
> Thanks for taking a look at this.  We have a few considerations in this
email thread I would like to hear thoughts on (and there may be more once
RFC5070-bis is actively edited).
> 
> The AdditionalData class and the RecordItem class both allow for non-XML
extensions.  Where you place the extensions should be specific to the
logical grouping of the parent elements so you can understand more about the
included data in most cases.  
> 
> The Impact class can be used to provide context information on the
included data of the report and also can include a confidence rating on the
report as a whole.  Extensions related to impact would be one level higher
(at the moment) in the Assessment class using the AdditionalData extension
point.  
> 
> Take asked about including vulnerability information, I would think that
would fit under the Vulnerability extension point of the SCI draft in the
Method class.  He did ask about non-XML.  RecordItem or AdditionalData do
allow for non-XML extension points, we could either have the SCI draft
handle these as well or have the extensions that are non-XML come directly
off the AdditionalData or RecordItem classes according to what makes sense
from a logical standpoint.
> Indicator based schemas have a reference number or a GUID for the various
indicators they share.  If we are extending to embed other schemas that
include such reference or GUID identifiers, do we want to add an attribute
to the various elements in IODEF that could be indicators?  Is this enough
to make the connections or is something else else needed?  We could add
something like an Indicator_ID in RFC5070-bis which would then correlate to
the reference or GUID identifiers.
> 
> Then the other question was on how to include indicators that are not in
the base schema that may be related or have language with "and" "or" to
specify the relationships.  In some cases, you will want to group these
indictors in one extension point, where they may fit logically in multiple
places if the relationships did not need to be shown in the data format.  If
we have cases like this where you need more complex representations, should
we use one extension point via the SCI draft off of the EventData class
AdditionalData extension point?  Opinions are needed here.... 
> 
> A few people have mentioned wanting to include some commonly shared
indictors into the base IODEF document.  We could have a catch-all class
that does this and has an extension point off of it in EventData or we could
continue to group items in logical places as is done now in IODEF and then
have the extension point for combined indicators via SCI.  I think I like
the latter approach.
> Kathleen
----------------------------------------------------------------------------
--------------------------
> We could for instance extend the list of indicators of the Impact class,
if
----------------------------------------------------------------------------
--------------------------
> Whereas, Kathleen stated,
----------------------------------------------------------------------------
-------------------------
> 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.
----------------------------------------------------------------------------
------------------------
> Is there a possible way to create a new XML class which encompass
combining the EventData, Detection and base IODEF classes to simplify this
issue?
> The information contained herein is for the exclusive use of the original
recipient. This information is granted for limited distribution within the
recipient's place of business for planning purposes only. Further
dissemination, whether private or public is prohibited.

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Wed, 6 Feb 2013 02:03:44 +0900

I like this discussion.
I agree, it would be good idea to have indicator identifiers inside the
IOC-related classes.

> Then for indicators not included in the base schema that may not fit into
a category in the SCI draft, do we create a place for these off of SCI or
right off of the IODE schema in EventData? (more details on this in my first
message).

If we could see any indicator of compromise as computer event record, we
could use SCI:EventReport class as the place for the XML-based IOCs that
couldn't fit anywhere else.
For the non-XML IOCs, we could use RecordData class, as suggested.

I agree to have indicator_uid, but I am not sure about the needs of the
indicator_set_id.
I understand we could do some grouping of individual indicator_uids and its
usability, but I am not sure whether we do not have any other way to express
these groupings.
For instance,  a Reference class refers to several indicadtor_uids. In this
case, they could be, in a sense, grouped. Isn't it enough?
I would appreciate if anybody could share expertise on this. Though I think
I have read all the emails in the list, I might have mis-understood some
points.

By the way, I think the indicator_uids should be added to the SCI classes'
attributes so that they can be correlated with another information as well.

Thanks
Take

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Harrington, Christopher
Sent: Tuesday, February 05, 2013 4:25 AM
To: Stoecker, Paul; Moriarty, Kathleen; MILE IETF
Subject: Re: [mile] IOCs

Thanks,
--Chris

From: Stoecker, Paul 

Paul

Paul W. Stoecker, Ph.D.

Hi Chris,

 

Back in July, we talked about adding Registry Key/Value pairs and hashes to
the main IODEF document (trying to see if this will help Chris below).  What
if we added the Registry Key/Value pairs as a class off of RecordData, using
a similar structure to what is in RFC5901, and also added the ability to
include hashes in RecordData?  I think if we then had the indicator_uid at
the RecordData level, we could connect a set within that structure and
repeat the structure for other sets in the same way we would do with Node
inside of the System class, using the indicator_uid to tie the set
together.  Then at the more specific level for the hash, registry Key/value,
IP, etc. use an indicator_uid if we needed them marked at this level as
well?  Maybe we want indicator_set at the higher level?  I'd like some
opinions on this approach.  +1 if you agree, suggestions if you have other
ideas that may work better.

Thank you!
Kathleen  

 
Two or more indicators of different type that relate to the same threat:
       The file hash of a malicious file and the URL of the C2 that the file
uses. Either or both may be present to indicate a compromise. 
 
Two or more indicators of the same type that relate to the same threat: 
       2 different registry values for the same registry key. If either
value is present it is a compromise indicator but both will not be present. 

 
Thoughts?
 
Thanks,
 
--Chris
 
Christopher Harrington

All - 

 

 
 
Thank you,
Kathleen

C. Henry Adams

Yours Faithfully,

Dave Misell MSc CISSP
SilentCircle  dsm
07710 380044
[email-masked]

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Thu, 7 Feb 2013 13:59:46 -0500

Hi Take & others,

Thanks for chiming in, I've been talking about this with Chris and a few others on their use cases and would like more opinions.  I'll provide an option below from what we have discussed from a CIRC view point.  We are also wondering how to also provide logic in IODEF that could cross over into SCI attached schemas or IODEF extensions (the solutions may all tie together with this discussion - or there may be better/more elegant solutions others would like to propose).

-----Original Message-----
From: Takeshi Takahashi [mailto:[email-masked]]
Sent: Tuesday, February 05, 2013 12:04 PM
To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen; 'MILE IETF'
Subject: RE: [mile] IOCs

> I agree, it would be good idea to have indicator identifiers inside the

KMM: At the class level, we may have several indicators listed that should be viewed as a set and may have another instance of that same class that is a related issue, but a separate set.  We could as you say, list the indicator IDs connected through the reference class.  The set IDs might give us other ways to group the values when we get into logic and relationships between sets or indicators.  This could also be a way to connect indicators or sets across XML documents that could have been shared previously.  If there are a large number of indicators in the set, then this becomes useful, for smaller sets, I agree it doesn't make as much sense.

What do others think?

> couldn't fit anywhere else.

KMM: That sounds like a good idea to me.  This should go into guidance in the SCI draft.  Does anyone else want to weigh in?

> For the non-XML IOCs, we could use RecordData class, as suggested.
KMM: Sounds good, thanks!

> case, they could be, in a sense, grouped. Isn't it enough?

KMM: It may be, what do you think about large sets of indicators or subsequent messages that add indicators to existing sets?  Would this happen?  Would it be easier to express relationships with sets of indicators in addition to individual indicators?  By using this, it could give us a unique way to also provide the logic and relationships in a new class of IODEF so we don't have to worry about adding it into the current structure.  If there are better ways to handle that, and others can provide some options, that would be appreciated!

Thank you,
Kathleen

Thanks,
--Chris

From: Stoecker, Paul

Paul

Paul W. Stoecker, Ph.D.

Hi Chris,

Thank you!
Kathleen

Thoughts?

Thanks,

--Chris

Christopher Harrington

All -

Thank you,
Kathleen

C. Henry Adams

Yours Faithfully,

Dave Misell MSc CISSP
SilentCircle  dsm
07710 380044
[email-masked]

---

From: "Harrington, Christopher" <[email-masked]>
Date: Thu, 7 Feb 2013 14:11:06 -0500

With respect to tying things back to threat actors, from what I have seen
and use this is a generally accepted grouping:

Indicator --> Indictor Set --> Campaign --> Threat Actor

Campaign and Threat Actor are where having a "Confidence" attribute would be
beneficial as making those associations is not a perfect science by any
means. 

Thanks,

--Chris

-----Original Message-----
From: Moriarty, Kathleen 
Sent: Thursday, February 07, 2013 2:00 PM
To: Takeshi Takahashi; Harrington, Christopher; Stoecker, Paul; 'MILE IETF'
Subject: RE: [mile] IOCs

Hi Take & others,

Thanks for chiming in, I've been talking about this with Chris and a few
others on their use cases and would like more opinions.  I'll provide an
option below from what we have discussed from a CIRC view point.  We are
also wondering how to also provide logic in IODEF that could cross over into
SCI attached schemas or IODEF extensions (the solutions may all tie together
with this discussion - or there may be better/more elegant solutions others
would like to propose).

-----Original Message-----
From: Takeshi Takahashi [mailto:[email-masked]]
Sent: Tuesday, February 05, 2013 12:04 PM
To: Harrington, Christopher; Stoecker, Paul; Moriarty, Kathleen; 'MILE IETF'
Subject: RE: [mile] IOCs

> I like this discussion.
> I agree, it would be good idea to have indicator identifiers inside 
> the IOC-related classes.

KMM: At the class level, we may have several indicators listed that should
be viewed as a set and may have another instance of that same class that is
a related issue, but a separate set.  We could as you say, list the
indicator IDs connected through the reference class.  The set IDs might give
us other ways to group the values when we get into logic and relationships
between sets or indicators.  This could also be a way to connect indicators
or sets across XML documents that could have been shared previously.  If
there are a large number of indicators in the set, then this becomes useful,
for smaller sets, I agree it doesn't make as much sense.

What do others think?

>> Then for indicators not included in the base schema that may not fit 
>> into a category in the SCI draft, do we create a place for these off 
>> of SCI or right off of the IODE schema in EventData? (more details on 
>> this in my first message).
>
> If we could see any indicator of compromise as computer event record, 
> we could use SCI:EventReport class as the place for the XML-based IOCs 
> that couldn't fit anywhere else.

KMM: That sounds like a good idea to me.  This should go into guidance in
the SCI draft.  Does anyone else want to weigh in?

> I agree to have indicator_uid, but I am not sure about the needs of 
> the indicator_set_id.
> I understand we could do some grouping of individual indicator_uids 
> and its usability, but I am not sure whether we do not have any other 
> way to express these groupings.
> For instance,  a Reference class refers to several indicadtor_uids. In 
> this case, they could be, in a sense, grouped. Isn't it enough?

KMM: It may be, what do you think about large sets of indicators or
subsequent messages that add indicators to existing sets?  Would this
happen?  Would it be easier to express relationships with sets of indicators
in addition to individual indicators?  By using this, it could give us a
unique way to also provide the logic and relationships in a new class of
IODEF so we don't have to worry about adding it into the current structure.
If there are better ways to handle that, and others can provide some
options, that would be appreciated! 

Thank you,
Kathleen

> I would appreciate if anybody could share expertise on this. Though I 
> think I have read all the emails in the list, I might have 
> mis-understood some points.
>

Thanks,
--Chris

From: Stoecker, Paul

Paul

Paul W. Stoecker, Ph.D.

Hi Chris,

 

 
 
Thank you!
Kathleen  

 

 
 
Thoughts?
 
Thanks,
 
--Chris
 
Christopher Harrington

All - 

 

 
 
Thank you,
Kathleen

C. Henry Adams

Yours Faithfully,

Dave Misell MSc CISSP
SilentCircle  dsm
07710 380044
[email-masked]

> 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.
> From: [email-masked] [[email-masked]] On Behalf Of C. 
> Henry
Adams & BIE [[email-masked]]
> information leakage, it could be an event that are conveyed in the 
> SCI's EventReport class, IMHO.
> 
> 2) If the indicators are something like an non-XML ones, I guess it 
> could
be
> 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

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Tue, 12 Feb 2013 18:20:31 +0900

Regarding the indicator_set_id, I agree, it is useful when we need to deal
with large sets of indicators.
Since indicator_set_id attribute is optional (right?), it could be omitted
if we need to deal with only small number of indicators.

Regarding the use case, I like the idea of using the confidence attribute
for the reason Chris kindly described.
I would like to hear a bit more on this: is it going to be numerical? For
instance, 1 means "no confidence" while 5 means "strong confidence", etc?

Thank you.
Take

> From: Harrington, Christopher [mailto:[email-masked]]
> Sent: Friday, February 08, 2013 4:11 AM
> To: Moriarty, Kathleen; Takeshi Takahashi; Stoecker, Paul; 'MILE IETF'
> Subject: RE: [mile] IOCs
> 
> a
> C.

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Tue, 12 Feb 2013 07:03:35 -0500

Hi Take,

Great!

As for Confidence, if you look at the current schema, you can list it as either low, medium, high or provide a numerical value (I think) between 0-100.

Paul is working to get a draft out soon so you and others can look at it and review/comment and we'll see what else requires adjustment.

Thank you,
Kathleen

-----Original Message-----
From: Takeshi Takahashi [mailto:[email-masked]]
Sent: Tuesday, February 12, 2013 4:21 AM
To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul; 'MILE IETF'
Subject: RE: [mile] IOCs

Thank you.
Take

---

From: "Harrington, Christopher" <[email-masked]>
Date: Tue, 12 Feb 2013 09:22:16 -0500

The number of indicators wouldn't necessarily drive the use of
indicator_set_id. The purpose is to show relationship. If I sent 3 IP
addresses that were used as C2 for 3 different campaigns I would have
separate indicator_set_ids, each with one of the 3 C2 IPs

My suggestion would be a simple low, medium, high. I think if we break it
down to more levels than that we would need to provide guidance on scoring,
rating, etc. I think most people should be able to understand low/med/high
without having to have a mathematical method for arriving at the level. 

Low - I am not sure
Medium - I am reasonably sure
High - I am very sure 

Thanks,

--Chris

-----Original Message-----
From: Takeshi Takahashi [mailto:[email-masked]] 
Sent: Tuesday, February 12, 2013 4:21 AM
To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul; 'MILE IETF'
Subject: RE: [mile] IOCs

Thank you.
Take

> With respect to tying things back to threat actors, from what I have 
> seen and use this is a generally accepted grouping:
> 
> Campaign and Threat Actor are where having a "Confidence" attribute 
> would be beneficial as making those associations is not a perfect 
> science by any means.
> 
> Thanks,
> 
> --Chris
> 
> 
> Thanks for chiming in, I've been talking about this with Chris and a 
> few others on their use cases and would like more opinions.  I'll 
> provide an option below from what we have discussed from a CIRC view 
> point.  We are also wondering how to also provide logic in IODEF that 
> could cross over into SCI attached schemas or IODEF extensions (the 
> solutions may all tie together with this discussion - or there may be 
> better/more elegant solutions others would like to propose).
> 
> KMM: At the class level, we may have several indicators listed that 
> should be viewed as a set and may have another instance of that same 
> class that is a related issue, but a separate set.  We could as you 
> say, list the indicator IDs connected through the reference class.  
> The set IDs might give us other ways to group the values when we get 
> into logic and relationships between sets or indicators.  This could 
> also be a way to connect indicators or sets across XML documents that 
> could have been shared previously.  If there are a large number of 
> indicators in the set, then this becomes useful, for smaller sets, I 
> agree it doesn't make as much sense.
> 
> What do others think?
> 
> >> Then for indicators not included in the base schema that may not 
> >> fit into a category in the SCI draft, do we create a place for 
> >> these off of SCI or right off of the IODE schema in EventData? 
> >> (more details
> on
> > If we could see any indicator of compromise as computer event 
> > record, we could use SCI:EventReport class as the place for the 
> > XML-based IOCs that couldn't fit anywhere else.
> 
> KMM: That sounds like a good idea to me.  This should go into guidance 
> in the SCI draft.  Does anyone else want to weigh in?
> 
> >
> > and its usability, but I am not sure whether we do not have any 
> > other way to express these groupings.
> happen?  Would it be easier to express relationships with sets of 
> indicators in addition to individual indicators?  By using this, it 
> could give us a unique way to also provide the logic and relationships 
> in a new class of IODEF so we don't have to worry about adding it into 
> the current
structure.
> > attributes so that they can be correlated with another information 
> > as
> well.
> >
> > Thanks
> > Take
> 
> 
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Harrington, Christopher
> I think some sort of group ID would do the trick. We also need a 
> logical and / or somewhere to show relationship between indicators. If 
> I give you
> 2
> compromise or is either one by themselves an indicator? Both would 
> have the same group ID since they are related.
> 
> Thanks,
> --Chris
> 
> From: Stoecker, Paul
> What if we added indicator group ID along with the indicator_uid?  
> This would allow you to group indicators that are related into the 
> same group ID.
> It is either that or going back to adding a Detection (or Indicators) 
> class that will should be used to take all of the indicators put them 
> into one place and have the ability to group the ones that go 
> together.  I don't mean a place to put indicators that are missing 
> from IODEF.I mean a place in the IODEF document where you put the 
> indicators that are used for detection and prevention of the shared 
> Incident.  I don't know the answer here, but there has got to be a 
> good way for indicators to be identified and being able to group them 
> as Chris has suggested without basically recreating something 
> complicated like STIX.
> 
> Paul
> 
> 
> Paul W. Stoecker, Ph.D.
> To: "Harrington, Christopher" <[email-masked]>, MILE 
> IETF <[email-masked]>
> Subject: Re: [mile] IOCs
> 
> Hi Chris,
> 
> The list has already said they would like to see indicators added to 
> the definitions in RFC5070-bis, to be more explicit about including 
> indicators and sets of indicators in IODE documents as opposed to 
> 'parts of an incident or the useful information on an incident for 
> sharing purposes.  It was written before we used terms like 
> indicators.  With that in mind, Rosella proposed a number of changes 
> back in July, both for guidance and for
format
> updates.  It may help to have the first draft try to address at least 
> some of these issues so people can understand the problems and at 
> least a proposed solution.
> 
> As you point out, we need to be able to show relationships between 
> sets of indicators, where we may have a few sets of indicators that 
> could have a relationship to each other within a document.  In the 
> July presentation, one of the questions was to see if we should add 
> new category attribute values for the System class that would connect 
> the list of included indicators.  I think we should still keep the 
> concept of a Node to a single node, but perhaps within System, list 
> multiple sets of Nodes that may be one type of attack.  Rosella had 
> suggested pulling forward the "FraudType" from RFC5901, this would 
> help solve the issue as NodeRole values would compliment an AttackType 
> (FraudType values could be included in AttackType or some broader 
> term).  It may be better to have the FraudTypes, plus attribute values 
> like "C2-server", "sinkhole",  "MalwareDistribution" for added context 
> so you know what to do with the received set of indicators.
> 
> connection points, and add a few indicators that are commonly shared 
> into the base IODEF.
> 
> Back in July, we talked about adding Registry Key/Value pairs and 
> hashes to the main IODEF document (trying to see if this will help 
> Chris below).  What if we added the Registry Key/Value pairs as a 
> class off of RecordData, using a similar structure to what is in 
> RFC5901, and also added the ability to include hashes in RecordData?  
> I think if we then had the indicator_uid at the RecordData level, we 
> could connect a set within that structure and repeat the structure for 
> other sets in the same way we would do with Node inside of the System 
> class, using the indicator_uid to tie the set together.  Then at the 
> more specific level for the hash, registry Key/value, IP, etc. use an 
> indicator_uid if we needed them marked at this level as well?  Maybe 
> we want indicator_set at the higher level?  I'd like some opinions on 
> this approach.  +1 if you agree, suggestions if you have other ideas 
> that may work better.
> 
> We'll also need to worry about marking the indicators to prevent 
> forward sharing when not permitted.  We may want to use these values 
> or something else.
> 
> Thank you!
> Kathleen
> 
> Watchlist Use Case. A bunch of indicators are sent in one message. In 
> that message we could have groupings of indicators that we need to 
> show are
> related:
> 
>        The file hash of a malicious file and the URL of the C2 that 
> the file uses. Either or both may be present to indicate a compromise.
> 
>        2 different registry values for the same registry key. If 
> either value is present it is a compromise indicator but both will not 
> be
present.
> 
> The problem compounds itself very quickly. Consider the scenario where 
> both groupings above are part of the same threat. I need to show that 
> logical groupings of Indicators are related as well. We can't send 
> multiple IODEF messages for this from what I remember reading.
> 
> The last one I can think of would be when you have 2 different 
> indicators that represent the same indicator. It's not uncommon to 
> send both the
> MD5
> and SHA1 hash of a malicious file. The indicator is the file but the 
> IOCs are the 2 hash values. How do we show they are related? If we use 
> a unique Inidcator ID for each hash value there needs to be a higher 
> level
grouping.
> GSO - Critical Incident Response Center EMC - Where Information Lives
> 174 Middlesex Turnpike
> Bedford, MA 01730
> 781-515-5862 (work)
> 603-583-1585 (cell)
> 
> I'd like your input and will refocus the thread to get opinions from 
> the list on options to help solve the problems raised in my message 
> and additionally in Paul's message.
> 
> automated exchanges, so we rely on encryption rather than obfuscation 
> to achieve the necessary level of confidentiality.
> 
> Paul mentioned the need to distinguish indicators of compromise from 
> context information that may also include IP address or other data 
> that could be indicators.  The question I raised was on how to connect 
> sets of indicators in the same IODEF document, assuming the ability to 
> have watchlists that could have several sets of indicators included, 
> as well as to connect indicators that may be included in embedded 
> schemas.
> 
> 'indicator-uid' how do we mark the indicators?  Do we use this to mark 
> who sent the indicator as well so that we can prevent forward sharing 
> when it is not permitted or handle that separately?
> 
> Comments and questions encouraged to figure out the right technical 
> solution to have this machine automatable.
> 
> Thank you,
> Kathleen
> 
> Temporal Dependency sounds interesting.  I remember when I first ran 
> across this particular craft, an experienced colleague asked me a 
> peculiar question.  He said, " How do you stop someone from tracking 
> the IP Address to your computer?"
> 
> searching a Neighborhood for Survivors which were hit by a Disaster or 
> let's just say "Live" Terrorist Situation.  He /or She needs to 
> communication back to other Officials that he /or somehow is in 
> Danger.  The device used to communicate has been captured by the great 
> minds of the enemy.  It's only a matter of time before they utilize 
> reverse engineering to figure out how it functions.  However, their 
> pride comes before a fall when seeking the location of other similar 
> devices to attack.  Why? Perhaps the less thought of concepts that 
> makes the device function properly, saves the day by disguise or 
> cutting it off (figuratively speaking).
> 
> The information contained herein is for the exclusive use of the 
> original recipient. This information is granted for limited 
> distribution within the recipient's place of business for planning 
> purposes only. Further dissemination, whether private or public is 
> prohibited.
> 
> Date: Monday, January 28, 2013, 9:25 PM UID could be mirrored with DNS 
> SEC a pemanent and temporal key, with a temporal Id?
> 
> Yours Faithfully,
> 
> Dave Misell MSc CISSP
> SilentCircle  dsm
> 07710 380044
> [email-masked]
> 
> 
> closely related to what I attempted to express when I stated, 
> "consider to a degree what appears to be illogical in brilliant minds 
> in some instances."
> >
> > [email-masked] (Direct Email) [email-masked]
> >
> >

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Tue, 12 Feb 2013 09:59:00 -0500

Hi Chris & Take,

I'll just focus on the confidence scoring.  Right now, the schema allows for you to either use a numerical score OR the ratings of low, medium, and high.  Different sharing groups can decide how they want to share the data.  If people were to use the numerical values, I agree it would be helpful to have guidance.  This could go in the IODE guidance document.

I have seen examples of current users that use each of the approaches, so we'll need to keep the option for backwards compatibility and it is nice to keep in flexible options where we can.

Thank you,
Kathleen

-----Original Message-----
From: Harrington, Christopher 
Sent: Tuesday, February 12, 2013 9:22 AM
To: 'Takeshi Takahashi'; Moriarty, Kathleen; Stoecker, Paul; 'MILE IETF'
Subject: RE: [mile] IOCs

Low - I am not sure

Thanks,

--Chris

-----Original Message-----
From: Takeshi Takahashi [mailto:[email-masked]] 
Sent: Tuesday, February 12, 2013 4:21 AM
To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul; 'MILE IETF'
Subject: RE: [mile] IOCs

Thank you.
Take

structure.
format
present.
grouping.
> Of Moriarty, Kathleen
> Of C.
> > original
> > original
> > original

---

From: "Harrington, Christopher" <[email-masked]>
Date: Tue, 12 Feb 2013 13:06:41 -0500

I see some confusion coming down the pike if we start using Confidence the
way it is supported. If I am using low/med/high and someone sends me an IoC
with a score of 70, what does that mean to me? What if I am using a scale of
1 to 4 and someone else is on a scale of 1 to 5? We lose the ability to
describe something with a consistent language. It really gets ugly when we
store IoC from multiple sources. I have confidence values that are numeric
as well as text.  Makes searching / sorting very problematic. 

At this point we have to roll with what we have. I would strongly recommend
that we revisit this at some point. 

Thanks,

--Chris

-----Original Message-----
From: Moriarty, Kathleen 
Sent: Tuesday, February 12, 2013 9:59 AM
To: Harrington, Christopher; 'Takeshi Takahashi'; Stoecker, Paul; 'MILE
IETF'
Subject: RE: [mile] IOCs

Hi Chris & Take,

I'll just focus on the confidence scoring.  Right now, the schema allows for
you to either use a numerical score OR the ratings of low, medium, and high.
Different sharing groups can decide how they want to share the data.  If
people were to use the numerical values, I agree it would be helpful to have
guidance.  This could go in the IODE guidance document.

I have seen examples of current users that use each of the approaches, so
we'll need to keep the option for backwards compatibility and it is nice to
keep in flexible options where we can.

Thank you,
Kathleen

-----Original Message-----
From: Harrington, Christopher 
Sent: Tuesday, February 12, 2013 9:22 AM
To: 'Takeshi Takahashi'; Moriarty, Kathleen; Stoecker, Paul; 'MILE IETF'
Subject: RE: [mile] IOCs

Low - I am not sure

Thanks,

--Chris

-----Original Message-----
From: Takeshi Takahashi [mailto:[email-masked]] 
Sent: Tuesday, February 12, 2013 4:21 AM
To: Harrington, Christopher; Moriarty, Kathleen; Stoecker, Paul; 'MILE IETF'
Subject: RE: [mile] IOCs

Thank you.
Take

structure.
format
present.
grouping.