Getting to Know: macOS Security Compliance Project - Part 2

4 min readApr 8, 2021

In my previous post, I walked through how to get started with the macOS Security Compliance Project (MSCP). While conceptualizing and planning the project, we all agreed that one of the primary objectives would be to ensure that admins would have the flexibility to modify or add rules as necessary to meet their organizations’ requirements.

In this post, I’ll show you how to customize one of the existing rule files; I’ll also provide the steps you’ll want to perform to verify that your changes have been made to the final product. Before I go through the process, let’s take a closer look at the anatomy of a rule file.

Rules

A rule file is broken up into the following fields:

id: must match the filename, but do not include the YAML extension.
title: a human-readable title for the rule.
discussion: concise description for the intended use of the rule and how it relates to the NIST SP 800–53 control it is mapped to.
check: every rule will have a check; most rules can be validated and checked with a shell-based check.
result: the expected result for the check.
fix: instructions for remediating a rule if the expected results are not met; if this field contains [source,bash], then the fix will be used in the compliance script.
references: includes a Common Configuration Enumeration (CCE) and mappings of the security frameworks, guidance, and individual controls that are mapped to the rule.
macOS: the version of macOS for which this rule is validated.
tags: metadata used to categorize and identify related rules. Tags are primarily used to identify which baseline a rule falls under, but can include any additional information that can be used to make index-based searching of the rules faster and easier.
mobileconfig/mobileconfig_info: contains the values required to generate a configuration profile.

Customization

Customization allows an individual or organization to set their preferred values for existing rules as well as to create rules that are not already included in the project. All custom files should be stored within the custom/rules folder; when the generate_guidance.py script runs, it will either overwrite or add a rule to the output. For existing rules, only the fields that are being customized need to remain — this ensures that your custom rules will continue working as the project is updated (including updates to meet the needs of future OS releases).

Example

A common rule that is customized to meet an organization’s value is “Configure macOS to Use an Authorized Time Server”.

1.Copy the existing rule from rules/sysprefs/sysprefs_time_server_configure.yaml to custom/rules/, and remove everything but the following fields:

results
references
mobileconfig_info

2.In the results and mobileconfig_info fields, replace the time servers defined by the project (time-a.nist.gov & time-b.nist.gov) with your organization’s approved time server.

For this example we’re also going to add some custom references. Custom references can be used to map a rule to additional resources, such as internal guidance or developer documentation; they can also be used as a means to document how a rule is audited and remediated.

3.Now that we have a custom version of “Configure macOS to Use an Authorized Time Server”, run generate_guidance.py against the NIST SP 800–53_high baseline (which is already included in the project).

./scripts/generate_guidance.py baselines/800-53_high.yaml -s -p -x

As you can see, the script recognizes that sysprefs_time_server_configure.yaml contains custom values. When we take a peek below, you can see that the custom values are now defined in the output.
Note that the Modified Rule field will also now appear in the spreadsheet, which indicates which fields in your rules are customized.