Security Baselines — Flashcards

A documented set of approved security configuration settings, patch levels, and requirements that every instance of an application environment must meet. Defines the minimum acceptable security state — covering firewall rules, OS settings, patch levels, file versions, authentication policies, and access controls. All deployed instances must conform; inconsistent application defeats the purpose.

1. Establish: Define approved settings, drawing from manufacturer recommendations and organizational policy.

2. Deploy: Push baseline to all applicable systems via automated tooling.

3. Maintain: Monitor for drift; update baseline when vulnerabilities, app updates, or OS changes require it.

4. Audit: Periodic formal compliance review producing documented evidence.

The process of comparing a system's current configuration state against its approved baseline to identify deviations. Should be performed frequently — ideally continuously — to minimize detection time. Any deviation triggers immediate investigation and remediation. Both unauthorized changes by admins and attacker modifications appear as baseline deviations, making integrity checks a security detection tool as well as a compliance tool.

The gradual divergence of a system's actual configuration from its approved baseline over time. Caused by manual administrative changes, software updates, unauthorized changes, and emergency modifications that are never reversed. Drift is invisible without active monitoring and compounds over time — a system with 20 small deviations is significantly more vulnerable than one with none. Detected through continuous integrity measurement.

A set of tools and pre-configured baseline packages published by Microsoft for Windows operating systems and Windows Server. Allows organizations to apply Microsoft's recommended security settings without building baselines from scratch. Includes downloadable GPO backup files that can be imported into Active Directory, comparison tools for assessing compliance, and documentation explaining each setting's purpose and recommended value.

1. Application developer: Configuration settings and file permissions specific to their application; they know their own attack surface.

2. Operating system manufacturer: Security settings for the OS layer — e.g., Microsoft's SCT for Windows; hundreds of policy settings.

3. Appliance manufacturer: Hardening guides for purpose-built hardware; default credential changes, service disabling, administrative access controls.

Organizations start from these recommendations and adapt them to their specific operational context.

In any environment with dozens to thousands of devices, manual configuration is impractical and inconsistent. Manual processes introduce human error: settings missed, settings applied incorrectly, systems skipped. One unconfigured system is a potential breach point.

Automated deployment (Group Policy, MDM, Ansible, etc.) applies configurations consistently to all devices, eliminates per-device labor, and provides continuous enforcement — reapplying settings if they drift. A baseline that exists only as a document without automated enforcement is not an actual security control.

A situation where security recommendations from different manufacturers contradict each other for the same system setting. Requires the organization to assess both positions, evaluate the risk on each side, make a deliberate documented decision, and test the chosen configuration before deployment. Neither source is automatically correct — judgment is required. The decision and its rationale must be documented in the baseline deviation record.

New vulnerability discovered: A CVE may require a configuration change (not just a patch) — disable a feature, restrict an access path, enable a mitigation.

Application updated: New version may add new settings to secure or remove settings the baseline referenced.

New OS installed: Different OS version has different policy structure; existing baseline may not apply; full review required.

Many settings are stable best practices and rarely change; others require active maintenance as the environment evolves.

Continuous monitoring detects drift in near-real-time and triggers remediation — it is a security operations tool.

Compliance auditing produces formal documented evidence of compliance at defined points in time — it is a governance and legal tool. Frameworks like ISO 27001, NIST CSF, PCI DSS, and HIPAA require documented proof that controls are in place, not just that monitoring is running. Audit records demonstrate to regulators, auditors, and stakeholders that the organization maintains and enforces its security baselines systematically.