What is the Configuration Standards control?
Strike Graph's default control language is: "A baseline security configuration is maintained by the information technology team and is deployed to all systems; the baseline settings are reviewed annually or as business needs change."
This language should be customized to reflect the specific process that your organization has defined. For example, if your baseline security configuration is maintained by another team or is reviewed at a different frequency, then you should update the control language to reflect that. It's important that your stated control description accurately reflects how your organization implements this control.
Who is involved with this control?
Typical control owner: CTO
Typical parties involved: IT Network Administrator
How often should I perform this control?
Typical frequency: Continuous
Which framework is this for?
SOC 2
NIST 800 (series)
Why is this control important?
SOC 2 criteria CC 7.1 - Vulnerability Protection states: To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities.
To meet this objective, the following points of focus are outlined:
Management has defined configuration standards.
The entity monitors infrastructure and software for noncompliance with the standards, which could threaten the achievement of the entity's objectives.
The IT system includes a change-detection mechanism (for example, file integrity monitoring tools) to alert personnel to unauthorized modifications of critical system files, configuration files, or content files.
Procedures are in place to detect the introduction of unknown or unauthorized components.
The entity conducts vulnerability scans designed to identify potential vulnerabilities or misconfigurations on a periodic basis and after any significant change in the environment and takes action to remediate identified deficiencies on a timely basis.
This criteria is not solely applicable to vulnerability scans, but relates to the various tools and practices that protect against vulnerabilities being introduced. Examples covered under this criteria can include:
The baseline configuration of your servers
The pre-configured, hardened image of your virtual machines
The baseline configuration of laptops issued to employees and contractors
The baseline settings for your firewall, intrusion detection system, mobile device management system or other security related tools
Critical file configuration alerting (when something has been altered)
How should I demonstrate this control?
The scope of systems that you set defined baselines for, and how the specific configurations are defined should be based on risk-based decision making. At a minimum, Strike Graph suggests that your production servers are configured a standard security baseline using a hardened image. We suggest the Center for Internet Security’s baselines, and their hardened images are a great resource as well.
To demonstrate this control, consider all security settings and then ensure that they remain unchanged (or updated) during the audit period. This may be a few configurations or many. You can also show the alerting settings that kick off when a baseline has been changed.
The evidence items linked to this control are Security Configuration Standards, Configuration as Code, and Security Configuration review.
The evidence that is acceptable for this control varies widely as the scope and process for configuration standards will be different for each organization. Pick the evidence item most applicable to your process, for example, if you are using hardened machine images for deployments, you can upload evidence of those to the Configuration as Code or Security Configuration Standards items. If you are uploading server hardening documentation, you can upload it to Security Configuration Standards. If you are showing a report from a security configuration monitoring tool, you can upload it to Security Configuration Review
Annual review of these standards is a great practice, but it is not strictly required for SOC 2. If you are not performing formal review of your security baselines then edit the control wording to reflect that, and deactivate the Security Configuration Review evidence item. Also, not all three evidence items are required. If you already uploaded server baselines to the Configuration as Code evidence item, you don't also need to upload something to the Security Configuration Standards item.
Questions?
Reach out through our chat feature for real-time Customer Success support 8 am - 5 pm PT Monday through Friday.