stix-shifter
stix-shifter copied to clipboard
opencybersecurityalliance
Conversion to/from Sigma
Very promising project, we've been struggling a fair bit with how to make stix 2 patterns actionable, so this project definitely is a step in the right direction. Considering how most of the CERT community has adopted Sigma, would including a converter to/from Sigma be an option for future enhancements?
Thank you for all the work that's gone in to this!
Hi Andras - I have been thinking about was we might be able to support Sigma in the project. In theory it could be an output format, but I am not sure what the query destination would be.
The main problem with Sigma of course is as I stated in the README - it is SIEM / logs only. We're reaching beyond just SIEM.
@iglocska If you or the MISP team have thoughts on how we could go about this, I would love your input, as supporting Sigma via some kind of method would be valuable. I am just unsure how to proceed.
Also let us know if there are other things in the project that MISP has input on WRT consumption. Feel free to either reach out or open Github issues. I have the idea to perhaps make a MISP expansion module to illustrate how it can be useful.
I would like to see SIGMA be an option for query. Specifically the "detection" section. Response part can remain in STIX since SIGMA doesn't handle it. Best of both worlds.
We're currently working on this in VAST. Our goal is to accept Sigma and STIX Patterns transparently by compiling either representation into a canonical query.
A direct translation of Sigma rules into STIX patterns might be feasible, but not the other way around, e.g., due to the FOLLOWED BY and WITHIN operator. I've noticed how SEKOIA.IO shifted away from STIX patterns and now implements Sigma correlations. Sigma without correlations can be expressed by STIX patterns, but Sigma with correlations not.
Bottom line: it's probably not going to be effective to attempt a conversion between the two. We're facing the usual problem in infosec land: lack of standardization.
@mavam Agreed. I don't want ro convert the pattern at all. I want to use the native Sigma backend. Since both of these projects are python there is no reason we can't just load the backend and use it for the translation phase. We then execute the other 4 phases using the existing code modules and get STIX out the other side.
Sigma correlations is still a bit unproven to me, no one really uses it and content is extremely sparse in the community, I haven't seen many backends properly supporting it
I don't want ro convert the pattern at all. I want to use the native Sigma backend. Since both of these projects are python there is no reason we can't just load the backend and use it for the translation phase. We then execute the other 4 phases using the existing code modules and get STIX out the other side.
That approach makes sense to me. With a multi-backend strategy, as it is inherently with STIX-Shifter, using the native Sigma library for translation makes the most sense. You have the rest already.
Sigma correlations is still a bit unproven to me, no one really uses it
Yeah, it's too early to bank on it. But this enhancement also deprecated some aggregation functionality that used to exist within "legacy Sigma." So as of today, the utility of Sigma without correlations is there from a point of standardization, but not from a point of expressiveness.
That's more an issue with Sigma than with STIX-Shifter, though. 🙂