SECURE CONFIGURATION BASELINE STANDARD: DISH

Defensive Infrastructure System Hardening · IT and OT Hardening Profile

Table of Contents

1. Purpose and Scope
2. The DISH Profile
3. Baseline Tiers and When Each Applies
4. Baseline Catalog
5. IT Platform Baselines
6. Cloud Baselines
7. Container and Kubernetes Baseline
8. Network and Firewall Baselines
9. SaaS Tier 1 Baselines
10. OT Platform Baselines
11. Regulatory and Framework Alignment Summary
12. Document Control

1. Purpose and Scope

CERG-POL-001 requires approved baselines per asset class. The Operating Model names baselines, IaC, and policy-as-code as core Engineering activities. The IT, OT, and CUI standards each independently call for baselines. Until this standard, those requirements existed without a unified implementation set, which made hardening impossible to delegate or assess.

This standard establishes the DISH profile - Defensive Infrastructure System Hardening - applicable to every in-scope asset class, IT and OT, with a single hardening minimum, an elevated tier for High-Impact and BES systems, and explicit fallbacks where CIS does not apply. The acronym is used throughout the CERG document library to refer to the baselines, scan profiles, and drift-detection signals derived from this standard; it is defined here and in CERG-POL-001 §3.

Hardening Is Not Optional

A baseline that exists “in policy” but cannot be enumerated, scanned, or remediated is not a baseline. CERG treats hardening as a deliverable artifact (the baseline document), a scan profile (DISH), and a continuous control (drift detection). All three are required or the asset is non-compliant.

1.1 Scope

Applies to every in-scope asset class:

• Windows Server, Linux server, workstation/endpoint, mobile (MDM-managed)
• Network device (switch/router), firewall, load balancer
• Cloud landing zone and control plane (AWS, Azure, GCP)
• Container and Kubernetes (cluster + workload)
• Tier 1 SaaS (M365, Salesforce, ServiceNow, etc.)
• SCADA server, HMI, historian, RTU, relay, engineering workstation, OT jump server
• Identity systems (IdP, IGA, PAM), see also CERG-STD-AC-001

2. The DISH Profile

DISH is the CERG-native, IT-and-OT-spanning hardening scan profile. It is implemented in the vulnerability scanning platform as a custom scan template that aggregates the requirements below.

2.1 Composition

Why a Named Profile

DISH gives Engineering, Risk, and the Audit team a single label they all mean the same thing by. “Did this asset pass DISH?” is a yes/no auditable question. “Is this asset hardened?” is not.

2.2 DISH Scan Output

The DISH scan produces, per asset:

1. Pass/fail per check, with CIS/NIST/IEC citation.
2. CERG-X-03 compliance status (Implemented / Partially Implemented).
3. Severity-weighted score for trending (used by CERG-GOV-MTR-001 CM-001).
4. Exception annotation for any check covered by an approved exception in the Exception Register.

3. Baseline Tiers and When Each Applies

Multiple tiers may apply (a BES Cyber System that processes CUI is Tier 2 + Tier 3); the tighter parameter wins per control.

4. Baseline Catalog

The catalog below names each baseline, points at the authoritative source, and identifies CERG overrides where they exist. Each row corresponds to one DISH scan policy in the VM tool.

5. IT Platform Baselines

5.1 Windows Server

The Windows Server baseline is CIS L1 (Tier 0) or L2 (Tier 1 / 3) with the following CERG overrides:

• Local administrator disabled; named administrative accounts only, via PAM JIT per CERG-STD-AC-001.
• SMBv1 disabled without exception (override is a hard fail; exceptions must be reviewed annually).
• LM/NTLMv1 disabled; NTLMv2 only as transitional with documented sunset.
• Audit policy matches the mandatory log source list in CERG-STD-LM-001, specifically Process Creation, Logon, Object Access (privileged file shares), and PowerShell ScriptBlock logging enabled and forwarded to SIEM.
• PowerShell Constrained Language Mode for non-admin sessions; signed script enforcement for admin sessions.
• Time synchronized to authoritative time source; drift > 5 minutes is a finding.
• CMK / disk encryption per CERG-STD-CR-001 for any system holding Restricted or CUI.

5.2 Linux Server

CIS L1 / L2 with CERG overrides:

• Root SSH prohibited; key-based authentication; password authentication disabled.
• sudoers scoped via named groups; no NOPASSWD escalations outside of break-glass accounts.
• auditd enabled with rules covering identity events, sudo, privileged file access, and process execution; forwarded to SIEM.
• Time, hostname, syslog destination, package repository allowlist managed by configuration management.
• Kernel module load restricted via signed-module enforcement where supported.
• Disk encryption for any system holding Restricted or CUI.

5.3 Workstation / Endpoint

CIS L1 with the additional CERG requirements:

• EDR agent installed, healthy, and tamper-protected.
• Full-disk encryption with key escrow.
• Local admin removed for standard users; administrative tasks via just-in-time elevation.
• Conditional access binds device posture to access.
• USB mass storage controlled (allowlist / read-only / blocked per data classification).

6. Cloud Baselines

CERG hardens both landing zone (account / subscription / project provisioning) and control plane (IAM, logging, networking, key management).

6.1 AWS

CIS AWS Foundations Benchmark L1 (Tier 0) / L2 (Tier 1+) with CERG overrides:

• Org-level Service Control Policies (SCPs) enforce: deny root access keys; deny region pinning except approved regions; deny disabling of CloudTrail / GuardDuty / Config / Security Hub; deny public S3 by default.
• CloudTrail multi-region, organization trail, log-file integrity validation enabled, KMS-encrypted, immutable storage.
• GuardDuty / Security Hub / Config / Inspector enabled in every account.
• IAM: no root usage; IAM Identity Center as the only human-access path; permissions boundaries on workload roles; access keys disabled for human users.
• Networking: no default VPC use in production; egress allowlist; VPC flow logs enabled and routed to SIEM.
• KMS: CMK for any data classified Restricted or CUI; rotation per CERG-STD-CR-001.

6.2 Azure

CIS Azure Foundations Benchmark L1 / L2 with CERG overrides:

• Management group hierarchy enforces policy inheritance; Azure Policy initiatives are mandatory.
• Microsoft Defender for Cloud enabled at Standard tier for in-scope subscriptions.
• Activity Logs / Diagnostic Settings routed to immutable Log Analytics workspace and SIEM.
• Entra ID: privileged access via PIM only; Conditional Access for all administrative roles; phishing-resistant MFA for all admins; legacy authentication blocked.
• Storage Accounts: public access disabled by default; CMK for Restricted/CUI workloads.

6.3 GCP

CIS GCP Foundations Benchmark L1 / L2 with CERG overrides:

• Organization Policies enforce: domain-restricted sharing; uniform bucket-level access; require OS Login; disable service-account key creation by default.
• Security Command Center Premium tier in-scope.
• Cloud Audit Logs: admin activity + data access enabled and exported to immutable destination + SIEM.
• CMEK for Restricted/CUI workloads.

7. Container and Kubernetes Baseline

CIS Kubernetes Benchmark for control plane and worker node, plus CERG application-layer requirements:

• Pod Security Standards: restricted for production namespaces.
• Network Policies: default-deny ingress and egress; explicit allowlists per service.
• Admission controllers enforce signed images (cosign / sigstore), no privileged pods, no host network/PID, no :latest tags.
• Image provenance: images built only from approved base images; SBOM produced at build; scan results gate promotion.
• Secrets: Kubernetes secrets disabled or encrypted via external secrets manager per CERG-STD-CR-001.
• Cluster audit log routed to SIEM.

8. Network and Firewall Baselines

8.1 Switches / Routers

CIS Cisco IOS/NX-OS L1 / L2 with CERG overrides:

• Management plane: out-of-band management network; SSH only; TACACS+/RADIUS via central IdP; local accounts only as break-glass per CERG-STD-AC-001.
• Control plane policing enabled with documented thresholds.
• Logging to syslog and SIEM; NTP authenticated.
• Unused services disabled (CDP/LLDP scoped, HTTP server off, etc.).
• Configuration management under version control; out-of-band changes detected and alerted.

8.2 Firewalls

CIS vendor benchmark plus CERG overrides:

• Default deny ingress and egress; explicit allowlists.
• Rule lifecycle: every rule has owner, business justification, and review date; review cadence ≤ 12 months.
• TLS inspection policy aligned with CERG-STD-CR-001 and data classification.
• Log forwarding to SIEM with session-level and threat-event-level detail.

9. SaaS Tier 1 Baselines

9.1 M365 Tenant

CIS M365 Foundations Benchmark L1 / L2 with CERG overrides:

• Phishing-resistant MFA for all admin roles, enforced by Conditional Access.
• External sharing: domain allowlist or full lockdown by default; SharePoint anonymous links disabled.
• Defender for Office 365 Plan 2 features enabled (Safe Links, Safe Attachments, anti-phish).
• Audit log retention ≥ 1 year (advanced audit license); routed to SIEM.
• CUI Enclave (if applicable) uses GCC High or FedRAMP-equivalent tenant per CERG-PLN-CUI-001.

9.2 Salesforce

CIS or vendor baseline plus CERG overrides:

• SSO mandatory for human users; legacy username/password disabled except as documented break-glass.
• MFA phishing-resistant where supported.
• Field-level / record-level access restricted to least privilege; permission set assignments reviewed quarterly.
• Event Monitoring enabled with logs forwarded to SIEM.

9.3 ServiceNow

CERG baseline (no CIS):

• SSO mandatory; admin role assignments reviewed quarterly.
• Inbound integrations scoped via OAuth with rotated client secrets per CERG-STD-CR-001.
• Audit & system logs forwarded to SIEM.
• Domain separation documented when shared with vendors or sub-orgs.

9.4 Pattern for Other Tier 1 SaaS

Where no published baseline exists, the CERG SaaS Baseline Pattern (Section 9 generic) requires: SSO + MFA + admin role review + audit log export + tenancy isolation + CMK or BYOK for Restricted/CUI + documented shared responsibility matrix.

10. OT Platform Baselines

OT baselines lead with NIST 800-82r3 and IEC 62443; CIS is used where the underlying OS supports it (typically engineering workstations and historian servers).

Active Scanning is Forbidden in OT Without Engineering Approval

DISH for OT is delivered via passive monitoring, configuration capture, vendor management interfaces, and engineering-supervised authenticated checks. Active vulnerability scanning of a live SCADA or RTU surface is not permitted under this standard except under an approved scope and time window per CERG-PRC-AV-001.

10.1 SCADA Server

• Underlying OS hardened to CIS L2 with vendor compatibility exceptions documented and risk-accepted per CERG-PRC-RM-001.
• Application allowlisting enforced; only vendor-approved SCADA application binaries permitted.
• Local accounts via PAM; vendor accounts gated by approved workflow per CERG-STD-AC-001.
• Anti-malware where vendor-supported; otherwise compensating controls per IEC 62443-3-3 SR 3.2.
• Logging to one-way SIEM transfer per CERG-STD-LM-001.
• Patch posture per OT VM procedure in CERG-PLN-CIP-001.

10.2 HMI

• Locked-down kiosk-style desktop; standard Windows hardening minus features that interfere with operator workflow (documented).
• USB and removable media controlled, read-only or disabled outside maintenance windows.
• Screen-lock parameters appropriate to operator console operating context (per safety analysis).

10.3 Historian

• Hardened to CIS L2 for Windows/Linux base.
• Database engine hardening (SQL Server / time-series engine) per vendor + CERG.
• Backups per CERG-STD-RES-001, including historian data sets.

10.4 RTU / Relay

• Vendor hardening guidance applied as a minimum; CERG overrides only where they tighten.
• Disable unused protocols; restrict management interfaces; rotate default credentials.
• Firmware version pinned; updates per CERG-PLN-CIP-001 CIP-010 procedure.
• Configuration captured to backup per CERG-STD-RES-001 (configurations, firmware, logic files).

10.5 Engineering Workstation

• CIS Windows L2 baseline.
• Dedicated to OT use only; no general business workload.
• USB / removable media policy stricter than enterprise default; tool-import policy documented.
• Application allowlist of engineering tools and supporting libraries.

10.6 OT Jump Server

• CIS Windows L2 baseline + CERG hardening above general workstation.
• Brokered session recording for all sessions to OT.
• MFA on entry; no clipboard / file transfer beyond named workflow.

11. Regulatory and Framework Alignment Summary

12. Document Control

Source: standards/CERG-STD-CFG-001_Secure_Configuration_Baseline_Standard_DISH.md · Download .md · View on GitHub