Subject: Re: [mile] IOCs

From: "C. Henry Adams & BIE" <[email-masked]>
Date: Fri, 1 Feb 2013 11:24:22 -0800 (PST)

Greetings,

It is truly a privileged to be in the midst of so many Intelligent Cyber Security Minds.  Each time I read the threads on Mile, I find myself referencing terminology, acronyms related to computer science and RFCs.

Furthermore, it is my desire to understand and share the Vision of the Author(s) which I'm assuming consist of Kathleen, as well as, others.  So, please forgive me if you completely blow over my head with your logic, fore, I'm not that far behind you in thought.  

Kathleen, I understood your following statement: "Our objective here is to have machine automated 
exchanges, so we rely on encryption rather than obfuscation to achieve 
the necessary level of confidentiality."

Forgive me, but is not Encryption and Obfuscation one in the same depending on how you look at it.

Furthermore,  if I was to tell you that a "Simple Minded Computer Technician" like myself could figure out analytically how to attack your indicators to set up a simple plan to disable your automated machine's communications, would you not believe me?  Oh, one more thing, the fact of the matter that the capabilities would be there- would be based on say the protocol you put into place by complexity rather than simplicity.

Paul has great points.  Chris and Dave are on point as well.   I'm clearly not a technical writer, but I'm a visionary that enjoys putting things into action.  No offense or disrespect, just being counter intuitive when comes to a train wreck.

            
            From: 
            "Harrington, Christopher" <[email-masked]>

        	To: 
        	"Moriarty, Kathleen" <[email-masked]>, "MILE IETF" <[email-masked]>
            	
                Message contains attachments
                
                1 File (7KB)

        smime.p7sI
 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 HarringtonConsulting Security EngineerGSO - Critical Incident Response CenterEMC - Where Information Lives174 Middlesex TurnpikeBedford, MA 01730781-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?"  

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]
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]> wrote:
From: Dave Misell <[email-masked]>
Subject: Re: [mile] IOCs
To: "C. Henry Adams & BIE" <[email-masked]>
Date: Monday, January 28, 2013, 9:25 PMUID 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.
> 
> C. Henry Adams
> [email-masked] (Direct Email)
> [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]>
> To:
> "[email-masked]" <[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]
> 
> --- 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]
> 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] (Direct Email)
> [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]> wrote:
> 
> From: Moriarty, Kathleen <[email-masked]>
> Subject: RE: [mile] IOCs
> To: "C. Henry Adams & BIE" <[email-masked]>, "[email-masked]" <[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] [[email-masked]] On Behalf Of C. Henry Adams & BIE [[email-masked]]
> Sent: Saturday, January 26, 2013 3:05 AM
> 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] (Direct Email)
> [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]
> https://www.ietf.org/mailman/listinfo/mile

C. Henry Adams

[email-masked] (Direct Email)

[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.

---

From: Eric Burger <[email-masked]>
Date: Mon, 4 Feb 2013 06:18:30 -0500

I am not quite sure this attack is relevant in the MILE use case.  I would be curious if you could explain in further detail how you would disrupt MILE communications.  If there is a fatal flaw (beyond the known flaws in TCP), it would be good to get them out in the open.

Considering the Computer Science perspective, if we are modeling a complex world, our model will be complex.  Check out McCabe.  However, one can add more complexity than necessary to model our domain.  That is what we seek to avoid here.

Note that I changed the subject of the thread, as this has nothing to do with indicator correlation.

On Feb 1, 2013, at 2:24 PM, C. Henry Adams & BIE <[email-masked]> wrote:

> Kathleen, I understood your following statement: "Our objective here is to have machine automated exchanges, so we rely on encryption rather than obfuscation to achieve the necessary level of confidentiality."
> 
> 	• smime.p7s
> 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
> 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
> 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?"  
> 
> 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).
> 
> 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]
> 
> 
> > 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
> > 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
> > 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.
> > 
> > Thank you,
> > Kathleen
> > 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.
> > 
> > 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