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 https://tools.ietf.org/html/draft-ietf-mile-rfc5070-bis-10 2015-02-03 20:29 GMT+01:00 B.-C. Boesch <bjoernboesch@xxxxxxx>: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 http://stix.mitre.org/ 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 http://making-security-measurable.1364806.n2.nabble.com/STIX-Discussion-List-f7579090.html 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 <bjoernboesch@xxxxxxx>: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 ietfdbh@xxxxxxxxxxx On Jan 18, 2015, at 3:23 AM, B.-C. Boesch <bjoernboesch@xxxxxxx> 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: http://www.ietf.org/id/draft-boesch-idxp-idpef-00.txt Kind regards, B.-C. Boesch _______________________________________________ OPSAWG mailing list OPSAWG@xxxxxxxx https://www.ietf.org/mailman/listinfo/opsawg_______________________________________________ sacm mailing list sacm@xxxxxxxx https://www.ietf.org/mailman/listinfo/sacm |