SaltStack SecOps Compliance Custom Content

Custom Compliance content allows you to define your own security standards, to supplement the library of security benchmarks and checks built into SaltStack SecOps Compliance. This custom content is useful for enhancing SaltStack SecOps Compliance policies to fit your internal requirements.

A check is a security standard that SaltStack SecOps Compliance assesses for compliance. Benchmarks are categories of security checks.

SaltStack SecOps Compliance includes a Custom Content Software Development Kit (SDK) you can use to create, test, and build your own custom security content. You can import your custom security content to use alongside the SaltStack SecOps Compliance built-in security library for assessment and remediation. The ability to import custom content also allows you to version your content using a version control system of your choice.

To use custom checks, first initialize the SaltStack SecOps Compliance Custom Content SDK. The SDK includes sample files you can modify to create your own custom checks, as well as benchmarks. The SDK also includes a Docker-based testing environment where you can test your new content.

Once your custom content is created and tested, you can build a content file and import it into SaltStack SecOps Compliance to begin assessing and remediating. Custom checks include a user icon custom-checks-user-icon , in contrast with SaltStack checks built-in-checks-shield-icon . SaltStack SecOps Compliance tracks dependencies between policies and your custom content, and provides a list of dependencies that might break if you delete the content.

Prerequisites

Download the SaltStack SecOps Compliance Custom Content SDK.
Install Docker. See the Docker installation documentation.

Initializing the SDK

From the command line, navigate to the directory containing the file and run the following according to your OS.
- Mac OS or Linux
```
./secops_sdk init
```
- Windows
```
secops_sdk.exe init
```
No output shows. This is expected. Your directory now contains the following folders and files:
- benchmarks
- salt/locke/custom
- sample_tests
- README.md
For more on these folders and files, see Folders and files.
(Optional) Commit changes to a version-controlled repository.

Creating custom checks

Note:

Initializing the SDK is a prerequisite to creating custom content. See Initializing the SDK.

In the Custom Content SDK, go to salt/locke/custom. This directory contains various subdirectories with sample state (.sls) and meta (.meta) files.
Note: All custom checks must be configured in both a state ( .sls) and corresponding meta ( .meta) file.
Make a copy of both a sample state (.sls) and its corresponding meta (.meta) file, renaming both with a descriptive name for your custom check.
Both files associated with a check must be in the same directory and start with the same name, for example:
- my_first_check.meta
- my_first_check.sls
You can save these two files together in any subdirectory of salt/locke/custom.
Edit the contents of the meta file to customize the check based on your needs. The file is written in YAML. For a list of the different options included in the file, see Folders and files.
Note: Check meta files contain references to different benchmarks. When creating custom content, make sure to include all associated benchmarks in your check meta file.
Edit the contents of the state file. For more information, see Folders and files.
Ensure both files are saved in the same directory.
You have now completed the minimum steps required to create a custom check. You can continue to test the check, commit to version control, or build your content library.

Creating custom benchmarks

Note: Initializing the SDK is a prerequisite to creating custom content. See Initializing the SDK.

In the Custom Content SDK, go to the benchmarks directory. This contains a sample benchmark meta (.meta) file.
Make a copy of Sample_Benchmark.meta, renaming it with a descriptive name for your benchmark.
Edit the contents of the meta file to customize the benchmark based on your needs. The file is written in YAML. For a description of the different options included in the file, see Folders and files.

Testing custom content

Note: Installing Docker is a prerequisite to the following. For more on downloading and installing Docker, see the Docker installation documentation.

Once you have created your custom content, open the command line and navigate to the Custom Content SDK sample_tests directory.
Build a docker image of CentOS7 with Salt for testing.
```
./build.sh
```
Start the testing container.
```
./up.sh
```
Run sample tests on checks you created in the salt/locke/custom directory. You can execute custom checks as you would normal Salt states, for example:
```
./test.sh salt-call --local state.apply locke.custom.mounts.my_first_check test=True
```
For more testing examples, see Test Custom Content in the SDK README. For more on Salt States, see Salt documentation: How do I use Salt States?.
When testing is complete, shut down the testing container.
```
./down.sh
```

Building the custom content library

Once you have created your custom content, open the command line and navigate to the Custom Content SDK root directory.
Build your custom content library.
```
./secops_sdk build -a
```
The SDK root directory now includes the _dist subdirectory. This includes two tar.gz files you can use to import your content through the SaltStack Config user interface or the API (RaaS). For a description of all files included in the directory, see Folders and files.

Importing custom content

Click Administration > SecOps on the side menu.
Under Compliance Content - SaltStack, click Check for updates.
Note: If you have already downloaded SaltStack SecOps Compliance content during your current session, you can skip this step.
Click Upload Package and select the .tar.gz file from your file explorer.
Note: To make your custom checks easier to navigate, use the file containing a timestamp in the filename. For more on files, see Folders and files.
Your custom content is now available in SaltStack SecOps Compliance for building policies, running assessments, and remediating your systems. Custom checks include a user icon , in contrast with SaltStack checks .

Note:
You can also import content using the API (RaaS), or alternatively, through the command line during installation. See Sec API interface or Enterprise Installation Guide.

Deleting custom checks

In the user interface, go to SecOps > Checks.
Click the menu next to the check you want to delete, and click Delete.
Note: Only custom content can be deleted. Custom content includes a user icon , in contrast with SaltStack content .
In the Delete Check dialog, under In Use, review the list of policies and benchmarks that include the check. This is useful for predicting any dependencies in your environment that might break if you delete the check.
When you have finished reviewing dependencies in use, click Next.
Under Delete Check > Warning, click Delete. The dialog confirms the check was deleted.
Click Done to close the dialog.

Deleting custom benchmarks

In the user interface, go to SecOps > Benchmarks.
Click the menu next to the check you want to delete, and click Delete.
Note:
Only custom content can be deleted. Custom content includes a user icon , in contrast with SaltStack content .
In the Delete Benchmark dialog, under In Use, review the list of policies and checks associated with the benchmark. This is useful for predicting any dependencies in your environment that might break if you delete the benchmark.
When you have finished reviewing dependencies in use, click Next.
Under Delete Benchmark > Warning, click Delete. The dialog confirms the benchmark was deleted.
Click Done to close the dialog.

Folders and files

After initializing the SDK, your directory includes the following folders and files:

benchmarks - contains custom benchmark meta (.meta) files
salt/locke/custom - contains custom check state (.sls) and meta (.meta) files
sample_tests - contains example files for testing using Docker
README.md - provides more detailed information about the SDK

Important files are described in more detail below.

Custom benchmark files

Benchmarks are categories of security checks. SaltStack SecOps Compliance built-in benchmarks are defined by widely-accepted experts. However, custom benchmarks can be defined by your own organization’s standards. Each benchmark contains a list of recommendations, called checks, and has a corresponding .meta file in the benchmarks directory. For more on benchmarks in SaltStack SecOps Compliance, see Benchmarks.

By creating a benchmark meta file, you create a category of checks. You can then add checks to that benchmark by naming the benchmark in a check meta file under benchmark_id. See Folders and files.

The meta file is written in YAML, and includes the following options you can customize for your content:

name: Benchmark name
display_name: Name of benchmark as it will appear in the list of benchmarks in SaltStack SecOps Compliance
desc: Benchmark description

Note:

In addition to the above options, the meta file also includes a variety of reserved items, such as version, authority, and ids. Do not modify these reserved items unless instructed by your administrator.

Custom check files

A check is a security standard that SaltStack SecOps Compliance assesses for compliance. This is a recommendation associated with a benchmark. The recommendation provides description, rationale, audit, and remediation information. Each check is defined by at least two files: a state (.sls) and corresponding meta (.meta) file.

Note:

Both files associated with a check must be in the same directory and start with the same name, for example:

my_first_check.meta
my_first_check.sls

You can save these two files together in any subdirectory of salt/locke/custom.

Each file type is described in further detail below.

Check meta files

Check meta files include a description of a check, as well as additional details related to the check, such as its version, applicable Operating Systems, and more. Meta files are written in YAML and use the .meta file extension.

Custom check meta files include the following options:

version

Version of the check content. Only a value of 1 is supported at this time.

display_name

The name of this check as it will appear in the list of checks in the SaltStack Config user interface.

global_description

A detailed description of the check. This is a chance to give more information than is supplied through the check and benchmark names.

osfinger

List of operating systems that are allowed to run this check. If the host doesn’t have an osfinger value that matches a value in this list, the assessment result of the check will come back as notapplicable.

refs

Cross-reference information about other checks in other benchmarks or security standards that are satisfied with this check.

benchmark_id

List of each benchmark the check belongs to.

Each benchmark entry creates a new section which includes the following sub-options:

type

Type of benchmark. Enter custom when defining a custom check not provided by a specific authority.

desc

Title of the security recommendation as it will appear in the list of checks in the SaltStack Config user interface.

control_id

Recommendation number, for example from a corresponding CIS document.

scored

This field is modeled after CIS recommendations which may be Scored or Not Scored. CIS recommendations that are Not Scored do not count for or against a security score.``true`` indicates scored and false indicates not scored. You might choose to score or not score a check, based on your internal needs.

profile

CIS and other benchmarks are divided into profiles. For example, the CIS CentOS Linux 7 benchmark has four profiles, represented as:

profile:
  server:level1
  workstation:level1
  server:level2
  workstation:level3

information

Description of the check. This may be similar to the check’s global_description field.

rationale

Description of the rationale for implementing the check.

remediation

Instructions on how to remediate a system in a non-compliant state.

Check state files

Check state files apply Salt states to perform assessments and remediations. A state function is a function contained inside a state module which can manage the application of a particular state to a system. State functions frequently call out to one or more execution modules to perform a given task. State files are written in both YAML and Jinja, and use the .sls file extension.

The result of an assessment is the result of running the state file in test=True mode. If the result shows that applying the state would have caused a change, the host is considered non-compliant. If applying the state would not result in a change, the host is considered compliant.

For more on Salt States, see Salt documentation: How do I use Salt States?.

Custom content library files

After building your custom content library, your directory includes the _dist directory, which contains the following additional files:

digest.json - contains hashes and other information about the content
secops_custom.tar.gz - gzip tar file ready for ingestion. This is suitable for upload through the SaltStack Config user interface. For more on content ingestion, see Enterprise Installation Guide.
secops_custom.txt - base64 encoded version of secops_custom.tar.gz. This is useful when making API calls
secops_custom_YYYY-MM-DDTHH:MM:SS.SSSSSS...tar.gz - an identical copy of secops_custom.tar.gz, preferred for upload through the SaltStack Config user interface because of its descriptive filename, which includes the creation date and tarball UUID