Updated Observable config

[ljstella]

Details

Update: View comments for details of rest of changes
This is the totality of detections from my first pass that would no longer have a valid RBA config with the the staged change in splunk/contentctl#204. Worth noting that all of these are currently either Deprecated or Experimental. In some cases, they already have an invalid RBA config, but are not evaluated against the "Must Have Victim in Observables" check due to their status.

detections/cloud/abnormally_high_number_of_cloud_infrastructure_api_calls.yml
detections/cloud/abnormally_high_number_of_cloud_security_group_api_calls.yml
detections/cloud/cloud_instance_modified_by_previously_unseen_user.yml
detections/deprecated/asl_aws_excessive_security_scanning.yml
detections/deprecated/okta_two_or_more_rejected_okta_pushes.yml

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]

Discovered during splunk/contentctl#234

Not actually dependent on that to merge

[ljstella]

Broke this group out by filepath so the commits would be easier to review:
320 total
231 endpoint
80 deprecated
5 network
4 web

All of these, and now, all of the repo, is not accidentally creating extra risk objects, which means extra risk events, for things we don't really want to be risk objects (process_name, parent_process_name, etc)

edit: Working on a splunk/contentctl change to require either "Attacker" or "Victim" going forward, at least until we convert tags.observable into an rba object.

[ljstella]

Added additional 16 changes after testing with splunk/contentctl#243:

total: 16
endpoint: 11
deprecated: 3
cloud: 1
network: 1

[pyth0n1c]

I have performed an integration test on all of this content with the updated verison of contentctl Lou shared above. It looks like all updated content passes! I have attached a record of that success here. It is a TXT file as GitHub does not allow upload of YML. It contains 234 successful tests (note than non-produciton content, along with some other types, are not tested and that account for the delta between successful tests and changed content).
manual_summary.txt