RBA Migration

[ljstella]

Details

Content migration accompanying changes to contentctl: splunk/contentctl#263

Checklist

• Validate name matches <platform>_<mitre att&ck technique>_<short description> nomenclature
• CI/CD jobs passed ✔️
• Validated SPL logic.
• Validated tags, description, and how to implement.
• Verified references match analytic.
• Confirm updates to lookups are handled properly.

Notes For Submitters and Reviewers

• If you're submitting a PR from a fork, ensuring the box to allow updates from maintainers is checked will help speed up the process of getting it merged.
• Checking the output of the build CI job when it fails will likely show an error about what is failing. You may have a very descriptive error of the specific field(s) in the specific file(s) that is causing an issue. In some cases, its also possible there is an issue with the YAML. Many of these can be caught with the pre-commit hooks if you set them up. These errors will be less descriptive as to what exactly is wrong, but will give you a column and row position in a specific file where the YAML processing breaks. If you're having trouble with this, feel free to add a comment to your PR tagging one of the maintainers and we'll be happy to help troubleshoot it.
• Updates to existing lookup files can be tricky, because of how Splunk handles application updates and the differences between existing lookup files being updated vs new lookups. You can read more here but the short version is that any changes to lookup files need to bump the datestamp in the lookup CSV filename, and the reference to it in the YAML needs to be updated.

[ljstella]

Status update:

I have (temporarily) changed the GitHub Actions config in my PR (splunk/contentctl#263) to run the ESCU smoketest against this branch.

Here are the latest results: https://github.com/splunk/contentctl/actions/runs/11860779327/job/33057262480?pr=263

As of this point, there are now under 100 validation errors against translated content.

The vast majority of these will need to be handled individually. Up until this point, commits have generally been done by subdirectory of detections/ with all of the changes for those in each one to assist in review. If you're reviewing this change at a later point, this is a great time to go refill your coffee ☕ and grab a snack 🍿 . I will attempt to group similar fixes and/or subdirectories together from this point forward, but they may be a bit more spread out.

[ljstella]

Update: as of now, all translated content is building successfully: https://github.com/splunk/contentctl/actions/runs/11863423975?pr=263

Still have to do some cleanup around messages and some risk objects, but they're all technically passing and producing a package "compatible" with the previous releases. I say compatible, as opposed to identical, because as this work was done, some changes have been made where things were threat objects but probably should have been risk objects, vice versa, and some where they just didn't make sense as either and were removed. Some risk messages were updated along the way, although there will be more of that upcoming.

[cmcginley-splunk]

This isn't a fully formed thought, but considering the recent discussions we've had around the notables and risk analysis events in ES 8.0, do we think it makes sense to lump notables under the terminology risk_objects? Does it make sense to explicitly distinguish risk analysis objects from notable objects in the YAML? I'm not convinced it does, just wanna raise a convo around it

[ljstella]

@cmcginley-splunk

do we think it makes sense to lump notables under the terminology risk_objects?

Could you expand on this a bit? I don't think we have anything that does this today, but generally speaking (at least, pre-ES8) notables were extremely simple, especially in comparison to risk events, in form of schema, required bits and bobs, and most importantly, a simple 1:1 relationship between search results and journaled events.

Some of the drivers behind these changes like aligning the terminology in the YAML with that in the product, and a more simplistic representation of the objects in config with fewer levels of abstraction seem at odds with the idea of putting notable-related things into an rba object.

Do I think that at a future point, we should consider a similar effort with a notable object that configures all of the action.notable.param fields based on the detection's deployment? Perhaps, although we can sort of already do that with the in-line deployments.