Closed 0xC0FFEEEE closed 1 week ago
Hey @0xC0FFEEEE
Thanks for creating this issue. We have moved it over to the contentctl repo- we're the same team building both, so it would get the right people either way.
What version of contentctl have you tried doing this with? I've just tested with the 4.1 result, and while we don't automatically generate yaml files for the macros to go with each detection, they can be overridden. If you create a macro yaml for the filter macro in a detection, with the correct name matching the filter macro from a search, it will override the value in the generated app instead of the default search *
definition.
Hi @0xC0FFEEEE - let me know what you think about @ljstella's suggestion. I think this is a good balance between allowing the power you're looking for an not creating clutter by having many macros which would have the default values.
If we decide to maintain this behavior, I think we have an opportunity for improved documentation. For example, during contentctl new -t detection
we could provide guidance about how to override the default-empty filter macro (or we could include this documentation elsewhere).
@ljstella @pyth0n1c Thanks for your responses. Admittedly I haven't tried again since V3.something where this wasn't the case.
I agree that there would be unnecessary clutter by creating the filter macros by default and that the ability to override them is a happy medium.
Updated documentation on this behaviour would be good. I know you've been busy with some rather big updates and I've fallen behind in understanding the codebase and latest changes.
Thanks again for your replies and kudos for all the work you've been putting into contentctl. I'm going to take a fresh look at migrating us to DaC in the coming weeks.
Is your feature request related to a problem? Please describe.
This is probably something that could be raised to the contentctl repo but it's probably more relevant to the content team.
Currently, detection macros are generated by contentctl during compilation of the ESCU app. This presents a challenge for migrating to detections as code as these macros can not be customized prior to deployment or managed via pull requests.
Describe the solution you'd like Create detection filter macros by default.
Beyond simplifying the adoption of DaC, one added benefit of this would be that it would be possible to contribute common false postitives to security_content, defined as comments within the yaml definition or a list under a new false_positives stanza.
Describe alternatives you've considered This behaviour can probably be accounted for in contentctl, e.g. don't try to create the macro if it already exists.