Subject: Re: [mile] Security alert reporting - the firstMILE

From: "Takeshi Takahashi" <[email-masked]>
Date: Tue, 5 Apr 2016 01:52:28 -0300

Hi Bob and all,

My understanding on netconf is rather shallow, but netconf is another
XML-based messaging, and it could be interesting to see how the model
(developed by the XMPP draft) will be applied to the netconf messages.

By the way, in Section 3 (whose title is "Problem Space") of the draft, you
identified the following problem.

"It is recognized that many of these alerts are too detailed to be
actionable. Some implementations of the alert monitor will include analytic
tools to select the actionable information from the alerts.  Alerts which
are too detailed to be actionable or alerts which include analytical tools
are outside of any standardizing process."

IMHO, it is a viable concern, and I am wondering how deeply you are trying
to work on this issue in this draft.
FYI, we have an draft that provides the guideline of the usage of IODEF
document.
https://datatracker.ietf.org/doc/draft-ietf-mile-iodef-guidance/

Current version of the guidance draft does not cope with the issue you
raised.
If you are trying to provide some solution, the guidance draft could refer
your draft.
But if you are trying to provide only a couple of sentences, the guidance
draft could address this issue.

Take

> -----Original Message-----
> From: mile [mailto:[email-masked]] On Behalf Of Robert Moskowitz
> Sent: Friday, March 25, 2016 9:51 AM
> To: Nancy Cam-Winget (ncamwing) <[email-masked]>; Panos Kampanakis
> (pkampana) <[email-masked]>; [email-masked]; [email-masked]
> Subject: Re: [mile] Security alert reporting - the firstMILE
> 
> 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!).
> 
> On 03/24/2016 06:51 PM, Nancy Cam-Winget (ncamwing) wrote:
> > 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).
> 
> 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.
> 
> 
> >
> > Regards, Nancy
> >
> > On 3/22/16, 8:57 PM, "mile on behalf of Robert Moskowitz"
> > <[email-masked] on behalf of [email-masked]> wrote:
> >
> >> 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.
> >>
> >> On 03/22/2016 11:24 PM, Panos Kampanakis (pkampana) 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.
> >>>
> >>>
> >>>
> >>> -----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:
> >>>> 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:
> >>>>> 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:
> >>>>
> >>>>
> >>> _______________________________________________
> >>> mile mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/mile
> >>>
> >> _______________________________________________
> >> mile mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/mile
> >
> 
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 5 Apr 2016 16:51:20 -0300

> (developed by the XMPP draft) will be applied to the netconf messages.

It is YANG which can work with what the defense device can use to model 
what reporting it has.  What the pub side is may probably not be YANG.  
Even though the IETF pub/sub used elsewhere in the IETF is YANG based, 
or so it seems to what I have been told.

> to work on this issue in this draft.

Not really.  It moves elsewhere into the I2NSF environment to do the 
analytics to then perhaps result in a message.  I don't want to get 
buried in what and how to analyze alerts.

> draft could address this issue.

This is work to be done.  But it comes down to how does actionable items 
enter the MILE environment?  Sometimes it is obvious to the attacked 
system.  Othertimes it will take analysis across a number of attacked 
systems to see that there is an attack.