Re: [mile] Security alert reporting - the firstMILE

Robert Moskowitz <rgm-sec@htt-consult.com> Tue, 05 April 2016 19:51 UTC

Return-Path: <rgm-sec@htt-consult.com>
X-Original-To: mile@ietfa.amsl.com
Delivered-To: mile@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7883912D6FD for <mile@ietfa.amsl.com>; Tue, 5 Apr 2016 12:51:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQh5fLjcDJhh for <mile@ietfa.amsl.com>; Tue, 5 Apr 2016 12:51:46 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FE0E12D644 for <mile@ietf.org>; Tue, 5 Apr 2016 12:51:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 0757D6222F; Tue, 5 Apr 2016 15:51:43 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 022-GdNxMQa1; Tue, 5 Apr 2016 15:51:28 -0400 (EDT)
Received: from lx120e.htt-consult.com (dhcp-a3c1.meeting.ietf.org [31.133.163.193]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 58E7F6222C; Tue, 5 Apr 2016 15:51:24 -0400 (EDT)
To: Takeshi Takahashi <takeshi_takahashi@nict.go.jp>, "'Nancy Cam-Winget (ncamwing)'" <ncamwing@cisco.com>, "'Panos Kampanakis (pkampana)'" <pkampana@cisco.com>, tony@yaanatech.com, mile@ietf.org
References: <56F166CC.4020103@htt-consult.com> <56F17DC8.8000800@yaanatech.com> <56F183BB.1020306@htt-consult.com> <653a830eff764cf382a3ea10b0b90273@XCH-ALN-010.cisco.com> <56F2140F.9020706@htt-consult.com> <D319BD0B.16101F%ncamwing@cisco.com> <56F53423.7050005@htt-consult.com> <075301d18ef6$f66c0b70$e3442250$@nict.go.jp>
From: Robert Moskowitz <rgm-sec@htt-consult.com>
Message-ID: <57041738.309@htt-consult.com>
Date: Tue, 05 Apr 2016 16:51:20 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <075301d18ef6$f66c0b70$e3442250$@nict.go.jp>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mile/2KQP6T9P3m7lx613tB1z-Sbo3II>
Subject: Re: [mile] Security alert reporting - the firstMILE
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mile/>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2016 19:51:49 -0000


On 04/05/2016 01:52 AM, Takeshi Takahashi wrote:
> 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.

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.

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

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.

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

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.

>
> Take
>
>> -----Original Message-----
>> From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Robert Moskowitz
>> Sent: Friday, March 25, 2016 9:51 AM
>> To: Nancy Cam-Winget (ncamwing) <ncamwing@cisco.com>; Panos Kampanakis
>> (pkampana) <pkampana@cisco.com>; tony@yaanatech.com; mile@ietf.org
>> 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"
>>> <mile-bounces@ietf.org on behalf of rgm-sec@htt-consult.com> 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:mile-bounces@ietf.org] On Behalf Of Robert
> Moskowitz
>>>>> Sent: Tuesday, March 22, 2016 1:41 PM
>>>>> To: tony@yaanatech.com; mile@ietf.org
>>>>> 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
>>>>> mile@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/mile
>>>>>
>>>> _______________________________________________
>>>> mile mailing list
>>>> mile@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/mile
>> _______________________________________________
>> mile mailing list
>> mile@ietf.org
>> https://www.ietf.org/mailman/listinfo/mile
>