Improving your security detection development processes

Attack Range

The Splunk Attack Range is an open-source project maintained by the Splunk Threat Research Team. You can run it on a cloud provider, like AWS, or even locally, with some limitations. By running just a few commands, it builds for you:

• an instrumented Splunk cloud server with dozen of apps and TAs installed, and even Splunk Enterprise Security if you want
• a Windows endpoint, possibly a domain controller, with Atomic Red Team tooling and all logging configured to send to the Splunk server and be properly ingested
• additional endpoints like a Kali Linux machine that you can use to launch attacks or a regular Linux machine instrumented with sysmon

The environment is built in about 20 minutes and is designed to be disposable so you can play around and simulate attacks without risk. You use the environment to develop detections, including referencing specific MITRE attacks, and then test the effectiveness of those detections.

Another way you can benefit from this project is by using the Splunk Attack Data Repo. This repository consists of raw data that was exported from Attack Range simulations and tested in a real Splunk environment. It's a good place to find sample data to test your own detections and see if your environment is set up to ingest it correctly. The YAML files provide information about what is in each data file. 

Detection-as-code principles

Software development processes include linting jobs to ensure that code is formatted correctly, compile jobs to make sure code builds correctly, and unit testing. You can bring these same ideas to detection development to ensure a high level of quality and overcome some common challenges. In your team, define the following:

• Detection language: What should your detections look like when they are stored?
  • Use a file that is easy to read and edit.
  • Include key fields like name, version, description, and search field.
  • Test data with raw data and source type so you know how to feed back into a server.
• Version control system: Store detections somewhere like GitHub. Put new or improved detections on a separate branch so they can get tested without interference.
• Automated workflows: Use for building and testing any apps.
• Test-driven development: Using the data sets discussed previously in this article.

ContentCTL

ContentCTL, a command-line application, is an efficient and scalable way to do end-to-end detection development. It does the following:

• Create. Creates YAML files so you aren't doing all the work from scratch.
• Validate. Shows all the fields present and that the values are in an acceptable range. Errors are explained in simple language that helps you make corrections quickly.
• Package. Builds an app. The Security Research Team builds the Splunk ES Content Update app with ContentCTL.
• Dynamically test. Creates a Splunk environment in Docker with a large number of apps and technical-add-ons installed. It then replays the each piece of content, gets the results, and outputs results that explain how the test went. In addition to this unit testing, if you have Splunk Enterprise Security installed, ContentCTL will conduct integration testing to ensure that risk actions, messages, and objects generate correctly.

Installation information is available on GitHub, but it doesn't require a lot of hardware to run. You can run it on a very basic system, but if you have a large EC2 instance, for example, ContentCTL is capable of testing more than 1,500 detections in under twenty minutes.

It is important to note that because ContentCTL exists entirely outside your Splunk software, getting the tooling to work can be difficult if you aren't working in a mature SOC. At this time, this tool might not be an option for some organizations.