po 2. 12. 2019 o 14:19 Risto Vaarandi <risto.vaara...@gmail.com> napísal(a):
> >> This SEC admin, as I see it, is still also from user perspective, tightly >> bound with SEC technology and user needs to know, how SEC rules and their >> compositions work internally. I am imagining something, that is >> technology-agnostic, just describing logic of correlations, and from that >> "formal description" generating SEC (or something other, >> technology-agnostic means, that it may not to be dependent on SEC or other >> specific technology, user needs just "what", but not "how"). Therefore >> configuration DB should not operate with SEC-specific entities, but rather >> something more general. Maybe something, which could be described with >> something like EMML (Event Management Markup Language - never used that, I >> don't know it, I just found that it exists). >> >> Levels of formal description of correlation types: >> >> - *user (admin) level* (higher-level, less detailed) - containing enough >> information to configure and use described correlation type >> >> - *developer level* (lower-level, more detailed) - containing enough >> information, to generate lower-level code (SEC configurations) from formal >> description (from configuration DB, maybe with support of something like >> EMML) >> >> Hope this helps to undertand what I wanted to say :). >> > > Developing another event correlation language and tools for supporting it > sounds like a separate major software development project to me. > Before embarking on that, have you considered using configuration > management frameworks (e.g., Salt or Ansible)? Among other things, they > allow you to create configuration files in automated fashion after the user > has set some generic parameters. It might not be exactly what you have > envisioned, but it is definitely cheaper workaround than rolling out an > entirely new solution. > Thank you for sharing another look, Risto. I know Ansible, Salt and other tools of this category, and I did not thought about this possibility yet, maybe it would be worth of it. About separate major software development project (related to SEC or maybe other event correlation engines): I see it this way too. Such project would need not only core development of "configuration framework", but also living community, submitting their "correlation modules" in specified format (e.g. some kind of SEC configuration "templates"). Ideologically something, as you have here: https://github.com/simple-evcorr/rulesets/, plus some additional functionalities around: - interface for submitting correlation modules (for review, because submitted modules should be verified before publication on framework site) - catalogue of submitted (and verified) correlation modules, e.g. as table or set of tables (structured by some categories), containing information: - description WHAT module does (user perspective) - (HOW is that functionality implemented is not needed here, reviewer(s) of the module could see it in bundled technical documentation, source code and comments, but I see these implementation details as not needed for publishing in such catalogue... maybe there may be also more alternative implementations of the same correlation algorithms, having their specifics) - high-level picture of correlation algorithm (without low-level concepts, e.g. SEC-related) - list of configurable parameters with their types (constraints) - event source preconditions (format, etc.) Richard
_______________________________________________ Simple-evcorr-users mailing list Simple-evcorr-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
