Subject: Re: [mile] IOCs

From: "C. Henry Adams & BIE" <[email-masked]>
Date: Mon, 28 Jan 2013 20:24:57 -0800 (PST)

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 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]

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