Skip to main content
Do you build apps on Splunk or are a Splunk admin? If so, we want to hear from you. Help shape the future of Splunk and win a $35 gift card!

Take the Survey
Lantern Home
 
 
Splunk Lantern

Using contentctl to speed up your SOC

  1. Last updated
  2. Save as PDF

 

Setting up a security operations center (SOC) with Splunk software generally follows this simplified overview structure:

  • Deploy the Splunk platform and Splunk Enterprise Security
  • Onboard relevant data
  • Set up detections
  • Respond to alerts, perform threat hunts, etc.

 While this manual set up can work well enough at first if good processes are established and followed, it can start to become difficult and complex. For example, you might:

  • Have personnel leave or join your team
  • Have detections stored across different apps
  • Not use standardized naming conventions for detections and other knowledge objects
  • Configure your adaptive responses in different ways per detection

All of this can make your SOC difficult to manage as the number of detections in your environment grows. What would be better is deploying and managing detections in a standardized and consistent way. You should also have a way that gives you a history of changes, who made what change, and other key auditing data points. 

Solution

One way of making the set up and management of a SOC more effective is by implementing the concept of detection as code. The idea is to:

  • Store detections in a code repository such as GitHub or GitLab
  • Store detections in easy-to-read YAML files
  • Deploy detections to Splunk Enterprise Security via a code deployment pipeline
    • Contain detections in a single app
    • Standardize naming conventions
  • Have a review or approval before deployment
    • This allows for changes to be more easily controlled

One tool you can leverage to implement detection as code is contentctl, which stands for Content Control Tool. It is a free and open source tool developed and supported by the Splunk Threat Research team, and it is used to deploy the Enterprise Security Content Updates (ESCU) Splunk app. At a high level, this is a tool that converts detections from YAML to Splunk .conf files.

  • This conversion includes baseline searches, analytic stories, correlation searches, and even macros.
  • It can validate macros used in your SPL and test your detections against sample data, and it has support for Sigma detection rules.
  • It has support for deploying to Splunk Cloud Platform via REST API.

An example, high-level workflow you can use to implement detection as code using contentctl is the following:

clipboard_eb6188b1f02173684417e12ab3c433c1e.png

To run it, do the following:

  1. On the GitLab side, set up your .gitlab-ci.yml file with something like:aws deploy push --application-name <application_name> --s3-location s3://<your_s3_bucket_name>/artifacts.zip

    aws deploy create-deployment --application-name <application_name> --deployment-group-name <deployment_group_name> --s3-location bucket=<your_s3_bucket_name>,bundleType=zip,key=artifacts.zip
     
  2. On the CodeDeploy side:
    1. Copy the files to your Splunk Enterprise Security machine.
    2. Make any necessary changes, such as file ownership and file permission modifications.
    3. Run contentctl build to convert your YAML files to Splunk .conf files.
    4. Refresh the Splunk app that hosts your detections to ensure your changes go into effect.

Keep in mind that the tools, processes, and requirements might be different in your environment, so you’ll need to adapt the workflow accordingly.

Using contentctl and detection as code gives you the following benefits:

  • Very quickly create, update, and deploy detections (especially from ESCU)
  • Tuning detections becomes simple
  • Analysts and others can freely submit pull requests to make changes, enhancing collaboration and efficiency

Next steps

The GitHub repository for contentctl, along with full installation and configuration instructions can be found here.