|
Re: [sacm] [OPSAWG] Internet Draft: Standardized Parameterization of Intrusion Detection Entities
2015-02-13 11:24:33
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(_at_)gmx(_dot_)net>:
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(_at_)gmx(_dot_)net>:
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(_at_)comcast(_dot_)net
On Jan 18, 2015, at 3:23 AM, B.-C. Boesch <bjoernboesch(_at_)gmx(_dot_)net>
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________
sacm mailing list
sacm(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sacm
|
|