Policies & CIS Compliance

Relevant source files

The following files were used as context for generating this wiki page:

• ee/cis/CIS-BENCHMARKS.md
• ee/cis/prompt.md
• articles/cis-benchmarks.md
• articles/understanding-the-intricacies-of-fleet-policies.md
• articles/what-are-fleet-policies.md
• ee/cis/macos-26/cis-policy-queries.yml
• ee/cis/macos-26/README.md

Fleet Policies provide a mechanism to monitor device security posture by executing osquery SQL queries that return a boolean "Yes/No" (Passing/Failing) result. These policies allow IT and security teams to maintain data integrity, confidentiality, and security across a fleet of thousands of devices. Within this framework, Fleet implements native support for CIS (Center for Internet Security) Benchmarks, which are consensus-based standards for protecting systems against cybersecurity threats.

Sources: articles/what-are-fleet-policies.md:1-10, articles/cis-benchmarks.md:5-15

Policy Architecture and Execution

Policies are defined as SQL queries that return one or more rows when a host is compliant and zero rows when it is not. When a policy is created via the Fleet UI, fleetctl CLI, or REST API, a record is stored in the policies table of the MySQL database. This centralized storage ensures that all Fleet server instances behind a load balancer are aware of the policy.

Sources: articles/understanding-the-intricacies-of-fleet-policies.md:25-35, ee/cis/CIS-BENCHMARKS.md:60-65

Data Flow and Update Intervals

The execution of policies on hosts follows a distributed pattern where the host's fleetd agent periodically checks in with the Fleet server.

1. Host Check-in: Hosts access the /api/v1/osquery/distributed/read endpoint every 10 seconds by default.
2. Policy Delivery: The server determines if a policy needs execution based on the FLEET_OSQUERY_POLICY_UPDATE_INTERVAL (default 1 hour).
3. Result Reporting: After the host executes the SQL, it writes the result back to the server, which updates the policy_membership table.
4. Stats Aggregation: A background worker process calculates the total counts of passing and failing hosts once per hour, updating the policy_stats table for performance optimization in the UI.

Sources: articles/understanding-the-intricacies-of-fleet-policies.md:40-75

This diagram illustrates the lifecycle of a policy from creation to its eventual aggregation for UI reporting.
Sources: articles/understanding-the-intricacies-of-fleet-policies.md:30-80

CIS Benchmark Implementation

CIS Benchmarks are categorized into Level 1 (practical, prudent, clear security benefit) and Level 2 (paramount security, defense-in-depth, may inhibit utility). In Fleet, these are authored as YAML documents following a strict schema and stored in platform-specific directories (e.g., ee/cis/macos-26/).

Sources: articles/cis-benchmarks.md:120-140, ee/cis/CIS-BENCHMARKS.md:10-25

Core Policy Schema Fields

Field	Requirement	Description
name	Required	Human-readable title, often appended with qualifiers like (MDM Required).
cis_id	Required	The section number from the CIS benchmark (e.g., 2.3.3.4).
query	Required	Osquery SQL returning 1+ rows for compliance.
resolution	Required	Steps to remediate a failing policy (graphical or terminal).
tags	Required	Categorization labels like compliance, CIS, CIS_Level1.

Sources: ee/cis/CIS-BENCHMARKS.md:38-58

Advanced Query Patterns

For complex security controls, Fleet utilizes specific SQL patterns to ensure accuracy, especially when dealing with MDM-managed settings.

• Managed Policy Check: Verifies that a specific MDM profile is installed. It pairs an EXISTS clause for the correct value with a NOT EXISTS guard for conflicting values to ensure a user-scoped setting isn't overriding a system-level policy.
• Absence-Passes: Used for checks where a host is compliant if a setting is not managed at all (e.g., software update deferment ≤ 30 days).
• Compound Checks: Combines local state (e.g., alf table for firewall) with MDM state.

Sources: ee/cis/CIS-BENCHMARKS.md:70-130

/* Example: Managed Policy Check with Guard */
SELECT 1 WHERE 
  EXISTS (
    SELECT 1 FROM managed_policies WHERE 
      domain='com.apple.SoftwareUpdate' AND 
      name='CriticalUpdateInstall' AND 
      (value = 1 OR value = 'true') AND 
      username = ''
  )
  AND NOT EXISTS (
    SELECT 1 FROM managed_policies WHERE 
      domain='com.apple.SoftwareUpdate' AND 
      name='CriticalUpdateInstall' AND 
      (value != 1 AND value != 'true')
  );

Sources: ee/cis/CIS-BENCHMARKS.md:75-90

Testing and Automation

The integrity of CIS policies is verified using automated test runners and artifacts stored in the test/ subdirectory of each OS version.

Test Artifact Types

The test runner (cis-test-runner.py) classifies policies into priorities based on available artifacts:

1. PASS_FAIL: Uses both _pass.sh and _fail.sh scripts. The runner breaks the setting, verifies failure, applies remediation, and verifies success.
2. PASS_ONLY: Uses a single script to apply remediation and verify success.
3. PROFILE: Specifically for policies reading managed_policies. The runner verifies failure without the .mobileconfig, pushes the profile to Fleet, and verifies success.
4. MANUAL: Policies that cannot be automated due to GUI requirements or subjective judgment.

Sources: ee/cis/CIS-BENCHMARKS.md:200-230, ee/cis/prompt.md:110-125

This diagram demonstrates the validation cycle for a script-based CIS policy.
Sources: ee/cis/CIS-BENCHMARKS.md:210-215

Compliance Monitoring and Limitations

While most CIS benchmarks are automated, certain controls require manual intervention or out-of-band checks. These are documented in the README.md for each OS version under "Limitations."

• GUI-only Remediation: Settings that require physical interaction or have no command-line/profile interface (e.g., Time Machine volume encryption setup).
• Subjective Audits: Controls requiring organizational judgment, such as checking if a computer name contains PII.
• Hardware Dependencies: Controls that require real hardware and cannot be reliably tested in virtual environments (e.g., Apple Silicon power management).

Sources: ee/cis/macos-26/README.md:15-100, ee/cis/CIS-BENCHMARKS.md:310-330

Fleetd Custom Tables

To support CIS queries that cannot be satisfied by standard osquery tables, Fleet includes custom tables via the fleetd agent.

Table Name	Purpose	Example CIS Check
authdb	Inspects the macOS authorization database rules.	Admin password for system-wide preferences.
sudo_info	Parses sudo -V output for timestamp and logging settings.	Sudo timeout period.
pwd_policy	Enumerate local password policies.	Password length and complexity.
software_update	Checks for pending Apple software updates.	System software currency.

Sources: ee/cis/CIS-BENCHMARKS.md:155-185

Conclusion

Policies and CIS Compliance in Fleet provide a robust, SQL-driven framework for continuous monitoring of security standards. By combining real-time osquery telemetry with automated testing for configuration profiles and scripts, Fleet enables organizations to not only detect non-compliance but also automate the verification of remediation efforts across diverse operating systems.

Sources: articles/what-are-fleet-policies.md:105-115, articles/understanding-the-intricacies-of-fleet-policies.md:95-105