Subject: Re: [mile] C. Henry's Analytical Attack

From: "C. Henry Adams & BIE" <[email-masked]>
Date: Wed, 6 Feb 2013 10:42:20 -0800 (PST)

Greetings All,

As I stated cautiously optimistic, the Attack Vector scenario from a visual
standpoint could be useful or not.  

Nevertheles, let me point out that if there are issues with say XML identifiers within MILE which was derived from
INCH to help:

1) Coordinate Incident Reports
2) Reference SCAP Enumerations  

Perhaps, looking at different scenarios whether they are way out of scope will help somehow identify a simplified solution.
Thanks, for the consideration.

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: Sat, 9 Feb 2013 07:47:33 -0500

By "this attack", I was talking about attacks on MILE, not attacks on you.  Apologies if it was interpreted that way.

As Kathleen stated, this would be the thread to enumerate the possible attack vectors to MILE.  Not being chartered for security is not the same as ignoring security.  All IETF documents post 1997 must discuss the security implications of whatever is described in the document.  The reason for moving this discussion to a difference subject is that people uninterested in the discussion can quickly delete the messages and people interested can contribute here.  That is the best of both worlds.

So, what attacks to you see?  It would be helpful if you could be more specific than saying a bad person steals a device.  We would need to know what they would do with the device to attack the system.

On Feb 4, 2013, at 11:35 AM, C. Henry Adams & BIE <[email-masked]> wrote:

> Greetings Eric,
> 
> [snip]
> 
> --- On Mon, 2/4/13, Eric Burger <[email-masked]> wrote:
> 
> From: Eric Burger <[email-masked]>
> Subject: C. Henry's Analytical Attack
> To: "C. Henry Adams & BIE" <[email-masked]>
> Cc: "MILE IETF" <[email-masked]>
> Date: Monday, February 4, 2013, 6:18 AM
> 
> 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:
> [snip]
> > 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.
> [snip]
> > From:
> > "Harrington, Christopher" <[email-masked]>
> > To:
> > "Moriarty, Kathleen" <[email-masked]>, "MILE IETF" <[email-masked]>
> > Message contains attachments
> > 1 File (7KB)
> >     • 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.
> > [snip]