Re: [sacm] [OPSAWG] Internet Draft: Standardized Parameterization of Intrusion Detection Entities

"B.-C. Boesch" <> Fri, 13 February 2015 17:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4ABDD1A8761; Fri, 13 Feb 2015 09:23:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.622
X-Spam-Level: **
X-Spam-Status: No, score=2.622 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01, URI_HEX=1.122] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5qaoksSko2VU; Fri, 13 Feb 2015 09:23:19 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9DA201A0162; Fri, 13 Feb 2015 09:23:18 -0800 (PST)
Received: from [] ([]) by (mrgmx102) with ESMTPSA (Nemesis) id 0M3d9B-1XW0O20QQD-00rHSb; Fri, 13 Feb 2015 18:23:15 +0100
Message-ID: <>
Date: Fri, 13 Feb 2015 18:23:11 +0100
From: "B.-C. Boesch" <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Jerome Athias <>,,,,
Subject: Re: [sacm] [OPSAWG] Internet Draft: Standardized Parameterization of Intrusion Detection Entities
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------040006060109020703050002"
X-Provags-ID: V03:K0:axO4E17ajvDU1oagUwCaFzpMyMr+mQrEWbN7PSE28lnqRF2iWPs MOeHXgchTlbKCLhK4yGQ55flks72ZZd8m6ylbmqrEPFf6U9/N3UL8r/bbogVarLoJ81Yr5t RfpaGQ4DQUovy85f3X6D62Bxs9gCvI2Z62aj+bDDqX6SQ83dTWqhw8QsxaXcpJnn4GPk9Tu o5XhXsctsgwHiDB2jMYpA==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Feb 2015 17:23:22 -0000

Hi Jerome,

thanks for your feedback and support to align "contact" with "3.10. Contact Class" of RfC 5070 (IODEFv2). I had lots of thoughts about**your recommendation and currently I am not sure if this is the best choice. The IODEFv2 is focussed on exchange and handle of incident information by CSIRT humans (maybe with systems support and so it should be parsable). So more than one contact could be helpful to handle the incident. Also it must be flexible to use it for any kind of contact.

IDMEF (RfC 4765) is focused on signalling of events / incidents within an IDS or its user interface. The IDPEF as Internet Draft is intended to parametrize the Analyzer of an IDS (communication between Manager and Manager or Analyzer). The information handler use the information which is presented to him by the format.

Focused on the contact class for the field service and the technical contact there will be a single point of contact. The contact node of IDPEF provides multiple contact channels for the field service or a second level service / technical administration where other information like postal address or contact name is located in upper nodes. So This could be the input for IDMEF / IODEF and should predefine to information for this two support contacts of an entity. And there is always one group exclusive responsible for this job.

IMHO this kind of detailed structured information supports that all information are present. With a machine-machine interaction this could be checked automatically. On the other hand an Analyzer is able to combine or chain these values for IDMEF / IODEF with less efforts, but maybe in any cases not the complete information is needed.

I am aware that IDPEF and its structure (especially the contact section) could be change in the next years be new communication methods and channels but I believe that at this point it will be time to update IDPEF to a new version. Did you (or the community) have any example, what information for field services or technical administration could be necessary which is currently not addressed by IDPEF with could be valuable for incident handling?

Thanks for the feedback and the start of discussion.

Kind regards.

B.-C. Boesch

Am 03.02.2015 um 22:21 schrieb Jerome Athias:
> after partial second review, I would suggest reviewing "contact" to
> align it on "3.10. Contact Class" that you can find here
> 2015-02-03 20:29 GMT+01:00 B.-C. Boesch <>et>:
>> Hi Jerome,
>> thanks for your feedback and the post to the STIX community. This is very
>> useful to me.
>> Currently I am not familiar with the STIX specifications but I hope that I
>> will be become acquainted with it in the next time. At the first view it
>> seems that STIX is focused on signalizing and correlation of events like
>> IDMEF. My approach is more a parametrization of IDS entities (Analyzers). I
>> keep to make some Data model mappings with STIX. I hope that I will be able
>> to spend some time on it next weekend to get familiar with STIX.
>> I am looking forward to a valuable feedback from the STIX community.
>> kind regards
>> Bjoern.-C. Boesch
>> Am 02.02.2015 um 22:40 schrieb Jerome Athias:
>>> Hi,
>>> very interesting idea and document.
>>> Congratulations, and thanks!
>>> After a first review, I think I would have quite a lot of comments.
>>> Unfortunately I would not have time for proper review before this
>>> week-end.
>>> Meantime, I would think that there is an opportunity to suggest your
>>> work as an extension for STIX, and CybOX
>>> Are you familiar with these specifications?
>>> I would mainly recommend trying some mappings, etc. I'll be able to help
>>> I understand the importance for you to obtain feedbacks, so I should
>>> introduce your draft into the STIX community
>>> I hope it's ok for you, and I'm pretty sure you could obtain valuable
>>> feedback from there (even if this community is not working with the
>>> same requirements as IETF)
>>> Best regards
>>> 2015-02-02 20:13 GMT+01:00 B.-C. Boesch <>et>:
>>>> Dear David,
>>>> thanks for your hint to the SACM WG. I have also posted it within the
>>>> SACM
>>>> community for any comments, feedback, suggestions, notations, hints,
>>>> recommendations, etc. but haven´t  received any response or feedback to
>>>> the
>>>> Internet Draft so far. I hope this will change and a lively discussion is
>>>> going to come up.
>>>> Kind regards
>>>> B.-C. Boesch
>>>> Am 02.02.2015 um 18:32 schrieb David Harrington:
>>>>> I think similar work is being addressed in the sacm wg.
>>>>> David Harrington
>>>>> On Jan 18, 2015, at 3:23 AM, B.-C. Boesch <> wrote:
>>>>>> Dear Community,
>>>>>> Efficiency of Intrusion Detection Systems (IDS) depends on their
>>>>>> configuration and coverage of services. The coverage depends on used
>>>>>> IDS
>>>>>> with currently vendor-specific configurations. In case of usage of
>>>>>> multiple
>>>>>> systems the operations could become complex. Individual Communication
>>>>>> between management interface and the IDS entities results that current
>>>>>> multi-vendor IDS architectures do not interact with each other. They
>>>>>> are
>>>>>> independent coexistent.
>>>>>> The Internet Draft defines data formats and exchange procedures to
>>>>>> standardize parametrization information exchange into intrusion
>>>>>> detection
>>>>>> and response systems from a Manager to an Analyzer.
>>>>>> The created Intrusion Detection Parametrization Exchange Format (IDPEF)
>>>>>> is intended to be a standard data format to parametrize IDS. The
>>>>>> development
>>>>>> of this open standardized format and the Intrusion Detection Message
>>>>>> Exchange Format (IDMEF) will be enable in combination interoperability
>>>>>> among
>>>>>> commercial, open source, and research systems, allowing users to
>>>>>> mix-and-match the deployment of these systems according to their strong
>>>>>> and
>>>>>> weak points to obtain an optimal IDS implementation.
>>>>>> The most obvious place to implement IDPEF is in the data channel
>>>>>> between
>>>>>> a Manager and an Analyzer of an IDS within this data channel where the
>>>>>> Manager sends the configuration parameters to the Analyzers. But there
>>>>>> are
>>>>>> other places where the IDPEF can be useful:
>>>>>> - Combination of specialized IDS like application-IDS with server-IDS,
>>>>>> WLAN-IDS and network-IDS to one functional interacting meta-IDS.
>>>>>> - Management of different IDS vendors with one central management
>>>>>> interface.
>>>>>> - Interaction of different IDS by using IDPEF and IDMEF.
>>>>>> - Parametrization backups and restore of parametrized IDS entities.
>>>>>> - For a communication between a Manager and a Manager in a multi-stage
>>>>>> management architecture.
>>>>>> I am happy to invite you to give me feedback, suggestions, notations,
>>>>>> hints, recommendations, etc. to improve the Internet Draft. The initial
>>>>>> version of the Internet Draft could be found at:
>>>>>> Kind regards,
>>>>>> B.-C. Boesch
>>>>>> _______________________________________________
>>>>>> OPSAWG mailing list
>>>> _______________________________________________
>>>> sacm mailing list