Security baseline

NIST describes a baseline configuration as a set of specifications for a system that has been formally reviewed and agreed on at a given point in time, can be changed only through change control, and serves as the basis for future builds and changes. In practice it is a list: setting, expected value, and the reason.

Where baselines come from

• Vendor baselines: Microsoft publishes security baselines, and Intune can deploy them to Windows devices. Each is a group of preconfigured settings that you can customise before you deploy it. Microsoft notes that they are not strictly CIS or NIST compliant, because there is no one-to-one mapping.
• CIS Benchmarks: consensus-based configuration recommendations from CIS, written per product, for example for Microsoft 365, Azure, Google Cloud and AWS.
• Your own: most organisations start from one of the above and adjust it for their environment, recording each deviation.

Examples

• Microsoft 365: administrators protected by MFA, audit log search switched on, external sharing limited.
• Azure: storage accounts that refuse public network access and require a minimum TLS version.
• Google Cloud: virtual machines that do not use the default service account.
• AWS: S3 buckets with Block Public Access, and a root user protected by MFA.

Without a baseline each administrator decides settings from memory, and the result differs between teams, subscriptions and years. The joint NSA and CISA advisory AA23-278a lists default configurations of software and applications among the most common weaknesses its teams find, which is the situation a baseline is meant to prevent.

A baseline is also the reference that makes change visible. If you know what the agreed value was, a change away from it is a finding, and you can ask whether it was intended. That is the basis of detecting configuration drift.

The strictest setting is not automatically the right one. The Intune documentation advises reviewing baseline defaults against your other policies before assigning them, because a restrictive default can conflict with something your environment relies on. A good baseline is one you have tested and can explain.

1. Pick one scope, such as the Microsoft 365 tenant or one Azure subscription, so the first baseline stays manageable.
2. Choose a starting point: the relevant CIS Benchmark at Level 1 is a sensible choice for most organisations, because it aims at minimal impact.
3. Go through the settings and mark each as adopted, adopted with a changed value, or deferred, with a short reason. The record of exceptions is part of the baseline.
4. Test changes on a pilot group before you roll them out widely.
5. Choose an owner and a review rhythm, and update the baseline when the vendor or the benchmark releases a new version.
6. Check the live environment against the baseline regularly, rather than assuming it still matches.

ConfigCobra checks your cloud settings against CIS benchmarks and reports where they fall short. It covers the CIS Microsoft 365 Foundations Benchmark v7.0.0 with 160 controls, of which 143 are automated and 17 require manual verification. For Azure it covers four CIS benchmarks with 339 controls in total, for Google Cloud the CIS Google Cloud Platform Foundation Benchmark v5.0.0 with 93 controls, and for AWS four CIS benchmarks with 306 controls in total.

Every connected cloud is scanned automatically every day, and you can start an ad hoc scan at any time. ConfigCobra raises an alert when a control regresses. Each control carries a severity estimate, which is ConfigCobra's own prioritisation and not something CIS publishes. Access is read-only, and ConfigCobra never changes your tenant: for a failing control it gives you a script or portal steps to apply yourself.