Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Import content from conf files #275

Open
pyth0n1c opened this issue Aug 30, 2024 · 1 comment
Open

Import content from conf files #275

pyth0n1c opened this issue Aug 30, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@pyth0n1c
Copy link
Contributor

pyth0n1c commented Aug 30, 2024

A great feature in contentctl which would enable faster onboarding of content from a splunk environment is import from existing conf files.
There was initial work towards that here: #84
But since that was opened the structure of the codebase has changed significantly. As such, that PR has been closed out.
Let's track this as it is an oft-requested feature, especially for new users.

I will tag @0xC0FFEEEE directly in this issue so that they can provide comments and feedback if they would like 😄

@pyth0n1c pyth0n1c added the enhancement New feature or request label Aug 30, 2024
@0xC0FFEEEE
Copy link
Contributor

0xC0FFEEEE commented Sep 2, 2024

Some context as to why this would be a great feature from the perspective of a Splunk cloud customer w/ >950 ESCU rules enabled:

When we adopted Splunk ES, we opted to enable, tune and tweak ESCU rules in-place, as there was no clear benefit to cloning detections given that ES does not provide any means to merge changes from upstream security_content updates.

Over time we've modified a number of these rules to various extents and it's simply not worth the time/effort to manually compare and merge in changes from an updated ESCU detection, meaning we are likely missing out on some beneficial updates. If I could access the Splunk ES filesystem to diff the default and local configs I probably would!

Our eventual goal with DaC is to maintain our own fork of security_content, and for the eventual switchover to happen, we will need to import our local savedsearches.conf before merging in changes from ESCU v4.16 (IIRC) to date.

I'm also considering whether we should manage our filter macros as code, so importing macros.conf would also be nice, and would certainly help with the switch to our forked content pack.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants