Subject: [mile] Security alert reporting - the firstMILE

From: Robert Moskowitz <[email-masked]>
Date: Tue, 22 Mar 2016 11:37:48 -0400

The MILE charter starts off with:

"The Managed Incident Lightweight Exchange (MILE) working group develops
standards to support computer and network security incident management"

So even though further down it says:

"The MILE WG is focused on two areas: IODEF, the data format and extensions
to represent incident and indicator data, and RID, the policy and
transport for structured data."

I have been puzzled by the lack of a standardized security alert 
reporting process.  After a few discussions and a lot of thought on the 
problem, I have come up with firstMILE:

https://www.ietf.org/internet-drafts/draft-moskowitz-firstmile-00.txt

Which proposes a sub/pub model including initial registration for 
security alerts reporting.

At this point the draft is more a skeleton for hanging how the three 
components:

Registration of security device to monitor(s).
Subscription of monitors for specific reporting.
Publication of security reports to subscribed monitors.

I have covered some of the requirements for these components.  I bring 
this to the MILE workgroup for:

Is this something the MILE wg should talk on?
And am I correct that currently security alert reporting is not covered 
within the IETF.
How much coordination for this should there be with DOTS and I2NSF?
     Note that I have proposed a DOTS messaging protocol and parts of 
firstMILE overlap with i2rs.

For the pub portion, I hold that the requirements align with the DOTS 
requirements, other than the bi-directional communications needs.  Do 
others agree?  If so, I have a DOTS draft:

https://www.ietf.org/internet-drafts/draft-moskowitz-dots-ssls-02.txt

DOTS Secure Session Layer Services

This introduces a real session layer, something really not present in 
the IETF stack, that provides a set of services.  SSLS and its services 
are laid out in:

https://www.ietf.org/internet-drafts/draft-hares-i2nsf-ssls-00.txt

Sue (and I) put the design for SSLS in i2nsf, as it is broadly 
applicable in a number of areas under i2nsf.

Two other drafts that fit into this architecture are:

https://www.ietf.org/internet-drafts/draft-moskowitz-sse-03.txt
and
https://www.ietf.org/internet-drafts/draft-moskowitz-gpcomp-00.txt

SO.....

I open the floor to discussion.

I would be interested in how others see this part of the security 
defense environment.

I am interested in how others see SLS and particularly SSLS and its use 
for firstMILE pub.  I have a slot in the meeting to cover my work.

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 22 Mar 2016 13:15:52 -0400

Hi Bob,

There is a lot of puzzlement to go around.
In trying to track all the parallel universes,
are you creating an alternative to TAXII here?
Or ROLLE come to life?

How would you differentiate firstMILE?

-t

On 2016-03-22 11:37 AM, Robert Moskowitz wrote:
> reporting process.  After a few discussions and a lot of thought on 
> the problem, I have come up with firstMILE:

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 22 Mar 2016 13:41:15 -0400

My reading of ROLLE here, or the limited information I can find googling 
TAXII is that neither address the start of the incident at the 
firewall/IPS/IDS/router.

firstMILE is to get the attack event into the monitoring systems. There 
analytics and/or an admin will determine if mitigation action is needed 
and then start action in RID/ROLLE/TAXII.

Or that is my take on reading existing documents and conversations at 
the past two IETFs.

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 22 Mar 2016 13:55:43 -0400

That sounds a lot like TAXII - especially 2.0
TC CTI is one of the world's most active bodies
and there are a considerable number of companies
and organizations involved with weekly meetings
and dozens of emails/day.  Huawei just joined, by
the way, so you should be able to get access.

The monitoring system part is elsewhere in the
STIX model.

--tony

On 2016-03-22 1:41 PM, Robert Moskowitz wrote:
> My reading of ROLLE here, or the limited information I can find 
> googling TAXII is that neither address the start of the incident at 
> the firewall/IPS/IDS/router.
>
> firstMILE is to get the attack event into the monitoring systems. 
> There analytics and/or an admin will determine if mitigation action is 
> needed and then start action in RID/ROLLE/TAXII.

-- 

________________________________ **

*Anthony Michael Rutkowski*

EVP, Industry Standards & Regulatory Affairs

[email-masked] <mailto:[email-masked]>

+1 703 999 8270 <tel:+1%20703%20999%208270>

________________________________ **

*Yaana Technologies LLC *

542 Gibraltar Drive

Milpitas CA 95035 USA

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 22 Mar 2016 14:08:50 -0400

Thanks for the information on TAXII and STIX, Tony.

Yes, Huawei is my funding.  From their research area, not product. But I 
will see what my contacts there say.

Perhaps they will bring their work out into the open.  Or perhaps just 
another case of my weak search foo.

On 03/22/2016 01:55 PM, Tony Rutkowski wrote:
>> There analytics and/or an admin will determine if mitigation action 
>> is needed and then start action in RID/ROLLE/TAXII.
>
> -- 
>
> [email-masked]

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 23 Mar 2016 03:24:11 +0000

Also overlaps with the XMPP pub/sub model suggested in https://tools.ietf.org/html/draft-appala-mile-xmpp-grid-00 specifically for IODEF.

-----Original Message-----
From: mile [mailto:[email-masked]] On Behalf Of Robert Moskowitz
Sent: Tuesday, March 22, 2016 1:41 PM
To: [email-masked]; [email-masked]
Subject: Re: [mile] Security alert reporting - the firstMILE

My reading of ROLLE here, or the limited information I can find googling TAXII is that neither address the start of the incident at the firewall/IPS/IDS/router.

firstMILE is to get the attack event into the monitoring systems. There analytics and/or an admin will determine if mitigation action is needed and then start action in RID/ROLLE/TAXII.

Or that is my take on reading existing documents and conversations at the past two IETFs.

On 03/22/2016 01:15 PM, Tony Rutkowski wrote:
> In trying to track all the parallel universes, are you creating an 
> alternative to TAXII here?
> Or ROLLE come to life?
>

_______________________________________________
mile mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mile

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 22 Mar 2016 23:57:03 -0400

Which is a more complete effort than firstMILE and covers some more 
areas, but has the challenge of TCP during congestion attacks.  Does not 
leverage NETCONF for configuration.  Has a registration function...

Maybe I just have an historical bias with XMPP as I go back to the 
origin of MQ series from IBM and where they lifted it from work we did 
at Chrysler...  ;)'

But I will read through that draft again.

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Thu, 24 Mar 2016 22:51:35 +0000

Hi Bob,

The general architecture of the xmpp-draft can cover other protocols (like
Netconf or TAXII), but as we are defining it in MILE, the draft speaks to
the applicability for IODEF.

>From your draft, am not sure if you¹re creating yet another pub/sub
mechanism?  If so, would like to see it compared to others (most of which
could be adapted to carry different data models).

Regards, Nancy

On 3/22/16, 8:57 PM, "mile on behalf of Robert Moskowitz"
<[email-masked] on behalf of [email-masked]> wrote:

>> Also overlaps with the XMPP pub/sub model suggested in
>>https://tools.ietf.org/html/draft-appala-mile-xmpp-grid-00 specifically
>>for IODEF.
>>
>>
>>
>>googling TAXII is that neither address the start of the incident at the
>>firewall/IPS/IDS/router.
>>

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 25 Mar 2016 08:50:43 -0400

Past two days I have been busy with the holiday of Purim; next week is 
my youngest son's wedding, so responses from me until IETF will be 
scattered (physically as well as mentally!).

> could be adapted to carry different data models).

I was leaving MOST of the higher layer stuff alone for first.  Only Sub 
is partially done using NETCONF and that is Sue Hares' contribution from 
work being done elsewhere like in I2RS.

So taking your work on XMPP and changing the transport model to UDP and 
the security to SSLS, is of interest to me.  Over in DOTS we have 
discussed extensively messaging challenges during attacks. MILE would 
also benefit from that design work.

Plus the NETCONF for sub has a lot to consider.

As I said, I have a personal bias concerning XMPP; but if the shoe 
fits....  Just want to fix up its soles a bit!  So to speak.