FC-02 · Secure Configuration — IT Staff Technical Procedures

This content is visible to isms-it-staff and isms-security via Scroll Content Manager. The all-staff behavioural guidance appears above this section for all users. What follows is the operational implementation detail for IT Operations staff.

---

Technical implementation overview

Secure configuration is implemented through a layered enforcement model. Documentation alone does not satisfy NIST 800-171 3.4.2 — every setting in the baseline must be technically enforced, not merely described. The enforcement mechanisms are:

Group Policy Objects (GPO) enforce Windows endpoint and server baselines via Active Directory. GPOs are the authoritative enforcement mechanism for Windows CUI-scope systems. Settings applied via GPO take precedence over local configuration and are reapplied at policy refresh intervals (default 90 minutes for computers, 90 minutes plus random offset for users).

Mobile Device Management (MDM — Microsoft Intune / Jamf) enforces macOS and mobile device baselines via configuration profiles. MDM profiles are pushed to enrolled devices and cannot be removed by the end user. Device compliance is continuously evaluated against the profile and reported to the MDM compliance dashboard.

Ansible playbooks (or equivalent IaC tooling — Chef / Puppet / SaltStack) enforce Linux server baselines. Playbooks are version-controlled in the source code repository, applied at initial deployment, and run on a scheduled basis to prevent and detect configuration drift. The scheduled run is the drift remediation mechanism for Linux systems.

Infrastructure as Code (Terraform / CloudFormation / Bicep) enforces cloud resource configuration. No manual change to CUI-scope cloud resources is permitted — all changes go through the IaC pipeline, which includes a policy-as-code security gate before deployment.

Cloud Security Posture Management (CSPM — Microsoft Defender for Cloud / AWS Security Hub / GCP Security Command Centre) provides continuous compliance checking of cloud resources against the approved baseline and generates findings that flow into the vulnerability management process.

The interaction between these mechanisms is deliberate: a CUI-scope system with GPO enforcement, MDM compliance monitoring, and quarterly configuration audit creates three independent opportunities to detect and correct drift before it is found by an external assessor.

---

Baseline document governance

Before documenting any specific baseline settings, the governance structure for baseline documents must be clear. This section defines how baselines are created, updated, versioned, and referenced.

Baseline naming and location

Each platform baseline is maintained as a child page of AT-CM in the Confluence ISMS space, named according to the convention: BL-[PLATFORM] · [Platform name] Baseline. The six baselines are:

BL-WIN11    · Windows 11 Workstation Baseline
BL-WINSRV   · Windows Server 2022 Baseline
BL-MAC      · macOS Ventura / Sonoma Workstation Baseline
BL-UBUNTU   · Ubuntu 22.04 LTS Server Baseline
BL-NET      · Network Device Baseline (firewalls and managed switches)
BL-CLOUD    · Cloud Resource Baseline (AWS / Azure / GCP)

Each baseline page contains: the CIS Benchmark version it references; the enforcement mechanism; the specific setting, required value, and CIS control reference for each item; deviations from the CIS Benchmark with documented justification; and the last-reviewed date with reviewer name.

Baseline update triggers

Baselines must be reviewed and updated in the following circumstances:

Mandatory triggers (review and update within 30 days):
  - A new major OS version is deployed to CUI-scope devices
  - CIS releases a new major Benchmark version for a covered platform
  - A security incident reveals a configuration gap not covered by the baseline
  - A CISA KEV or NCSC advisory identifies a configuration-based vulnerability
    in a covered technology
  - A post-assessment finding identifies a baseline deficiency

Scheduled review (annually):
  - Full review of all six baselines as part of Q4 management review preparation
  - CIS Benchmark version check — confirm we are not more than one minor 
    version behind the current release

All baseline updates go through the change management process (AT-CM 3.4.3). A baseline update is classified as a Normal change — it requires a CAB review, a security impact assessment, and a test in a staging environment before production deployment. The RFC must reference the specific baseline document version being replaced.

---

BL-WIN11 · Windows 11 Workstation Baseline

Reference and enforcement

CIS reference: CIS Microsoft Windows 11 Benchmark v3.0.0
Level applied: Level 1 for all CUI-scope workstations
               Level 2 for workstations with privileged account access or CUI file store access
Enforcement: Group Policy Object — linked to OU=Workstations in AD
Verification: Microsoft Defender for Endpoint (MDE) configuration assessment
              quarterly via CIS-CAT Pro on a sample of 10% of CUI-scope workstations

GPO structure

GPO architecture for Windows 11 workstations:
  GPO-BASE-Security        → applied to all domain-joined workstations
    └─ GPO-CUI-Workstation → applied to CUI-scope workstations OU (more restrictive)
       └─ GPO-Privileged   → applied to workstations used by privileged users (most restrictive)

Do not layer conflicting settings across GPOs — use a single authoritative GPO 
per setting. Where settings overlap between GPOs, document the precedence 
explicitly and test with RSOP (Resultant Set of Policy).

Account policies (Account Policies → Password Policy)

Setting                                    Required value        CIS ref    Enforcement
──────────────────────────────────────────────────────────────────────────────────────
Enforce password history                   24 passwords          1.1.1      GPO
Maximum password age                       Not applicable*       1.1.2      GPO
Minimum password age                       1 day                 1.1.4      GPO
Minimum password length                    16 characters         1.1.6      GPO + Entra PP
Password complexity requirements           Enabled               1.1.5      GPO
Store passwords using reversible           Disabled              1.1.7      GPO
  encryption

*Maximum password age: set to 0 (never expire) where MFA is enforced.
 Where MFA is unavailable for an account, set to 90 days.
 Document any account with 90-day expiry in the exception register (EV-D08).

Account lockout policies (Account Policies → Account Lockout Policy)

Setting                                    Required value        CIS ref    Enforcement
──────────────────────────────────────────────────────────────────────────────────────
Account lockout duration                   15 minutes            1.2.1      GPO (FGPP overrides
                                                                            for admin: 30 min)
Account lockout threshold                  5 invalid attempts    1.2.2      GPO
Reset account lockout counter after        15 minutes            1.2.3      GPO

Local policies — audit policy

All audit policy settings configured via Advanced Audit Policy Configuration,
not via the legacy Audit Policy (the legacy settings have less granularity
and are overridden by Advanced Audit Policy when both are configured).

GPO path: Computer Configuration → Windows Settings → Security Settings →
          Advanced Audit Policy Configuration → Audit Policies

Category                        Subcategory                    Setting
──────────────────────────────────────────────────────────────────────────────────
Account Logon                   Credential Validation          Success, Failure
                                Kerberos Authentication        Success, Failure
                                Kerberos Service Ticket Ops    Success, Failure

Account Management              Computer Account Mgmt          Success
                                Other Account Mgmt Events      Success
                                Security Group Mgmt            Success
                                User Account Mgmt              Success, Failure

Detailed Tracking               Plug and Play Events           Success
                                Process Creation               Success
                                Token Right Adjusted           Success

Logon/Logoff                    Account Lockout                Failure
                                Logon                          Success, Failure
                                Logoff                         Success
                                Other Logon/Logoff Events      Success, Failure
                                Special Logon                  Success

Object Access                   File System (CUI paths only)   Success, Failure
                                Removable Storage              Success, Failure
                                SAM                            Failure

Policy Change                   Audit Policy Change            Success
                                Authentication Policy Change   Success
                                Authorisation Policy Change    Success

Privilege Use                   Sensitive Privilege Use        Success, Failure

System                          IPsec Driver                   Success, Failure
                                Security State Change          Success, Failure
                                Security System Extension      Success, Failure
                                System Integrity               Success, Failure

Security options — selected critical settings

GPO path: Computer Configuration → Policies → Windows Settings →
          Security Settings → Local Policies → Security Options

Setting                                               Required value      CIS ref
──────────────────────────────────────────────────────────────────────────────────
Accounts: Block Microsoft accounts                    Users can't add     2.3.1.1
Accounts: Guest account status                        Disabled            2.3.1.2
Accounts: Limit local account use of blank passwords  Enabled             2.3.1.4
Interactive logon: Machine inactivity limit           900 seconds         2.3.7.3
                                                      (15 minutes)
Interactive logon: Smart card removal behavior        Lock workstation    2.3.7.7
                                                      (or Disconnect if
                                                       remote desktop)
Microsoft network client: Digitally sign              Always              2.3.8.1
  communications (always)
Microsoft network server: Digitally sign              Always              2.3.9.1
  communications (always)
Network access: Do not allow anonymous                Enabled             2.3.10.2
  enumeration of SAM accounts
Network security: LAN Manager auth level              NTLMv2 only;       2.3.11.7
                                                      refuse LM & NTLM
Network security: Minimum session security for        Require 128-bit    2.3.11.9
  NTLM SSP                                            encryption
System cryptography: Use FIPS-compliant algorithms    Enabled             2.3.17.1
  for encryption, hashing, and signing
User Account Control: Admin Approval Mode for         Enabled             2.3.15.1
  the built-in administrator account
User Account Control: Behavior of elevation prompt    Prompt for          2.3.15.5
  for administrators in Admin Approval Mode           credentials
User Account Control: Run all administrators in       Enabled             2.3.15.10
  Admin Approval Mode

Windows Defender settings (via GPO and MDE policy)

GPO path: Computer Configuration → Administrative Templates →
          Windows Components → Microsoft Defender Antivirus

Setting                                               Required value
──────────────────────────────────────────────────────────────────────────────────
Turn off Microsoft Defender Antivirus                 Disabled (Defender ON)
Turn off real-time protection                         Disabled (real-time ON)
Configure detection for PUAs                          Enabled: Block

MDE policy (Intune → Endpoint Security → Antivirus):
  Cloud-delivered protection: Enabled
  Cloud protection level: High
  Automatic sample submission: Enabled
  Tamper protection: Enabled
  Network protection: Block mode

Verify tamper protection is active:
  Get-MpComputerStatus | Select-Object AMTamperProtectionEnabled
  Expected: True
  If False: MDE onboarding issue — re-onboard device

Additional critical settings

Setting                                 GPO path / Registry                   Required value
──────────────────────────────────────────────────────────────────────────────────────────────
SMBv1 (client)                         GPO: Admin Templates → Network →       Disabled
                                       Lanman Workstation → Enable insecure
                                       guest logons: Disabled
                                       AND: Network → Lanman Workstation →
                                       Enable insecure guest: Disabled

SMBv1 (server)                         PowerShell at deployment:              Disabled
                                       Set-SmbServerConfiguration 
                                       -EnableSMB1Protocol $false

AutoRun / AutoPlay                     GPO: Admin Templates → Windows         Disabled for all
                                       Components → AutoPlay Policies →       drives
                                       Turn off Autoplay: Enabled

PowerShell Script Block Logging        GPO: Admin Templates → Windows         Enabled
                                       Components → Windows PowerShell →
                                       Turn on PowerShell Script Block Logging

PowerShell Transcription               GPO: Admin Templates → Windows         Enabled
                                       Components → Windows PowerShell →      Output to
                                       Turn on PowerShell Transcription        \\[path]

NTLM restriction (outbound)            GPO: Security Options →                Deny all
                                       Network Security: Restrict NTLM:
                                       Outbound NTLM traffic to remote servers

LAPS v2 (local admin randomisation)    Intune LAPS policy:                    Enabled
                                       Backup directory: Azure AD             90-day rotation
                                       Password age (days): 90
                                       Password complexity: Large letters +
                                       small letters + numbers + symbols
                                       Password length: 32

BitLocker (full-disk encryption)       Intune: Endpoint Security →            AES-256-XTS
                                       Disk Encryption → BitLocker            TPM 2.0 required
                                       OS drive: Require startup PIN +        Recovery key to
                                       BitLocker recovery key backup to AAD   Entra ID

Event log sizes                        GPO: Windows Settings → Security       Security: 196608 KB
                                       Settings → Event Log                   Application: 32768 KB
                                       "Do not overwrite events" → set        System: 32768 KB
                                       retention method to Overwrite events   Overwrite events
                                       as needed                              as needed

---

BL-WINSRV · Windows Server 2022 Baseline

Reference and enforcement

CIS reference: CIS Microsoft Windows Server 2022 Benchmark v2.0.0
Level applied: Level 1 minimum for all CUI-scope servers
               Level 2 for servers storing or processing CUI directly
Enforcement: Dedicated server GPO — GPO-SERVER-CUI-Security (separate from workstation GPO)
             Applied to OU=Servers,OU=CUI-Scope
Verification: CIS-CAT Pro (server scan profile) quarterly on all CUI-scope servers

Server-specific additions to workstation baseline

All BL-WIN11 settings apply to servers where applicable. The following are additional or modified settings for servers.

Setting                                 Configuration                          Rationale
──────────────────────────────────────────────────────────────────────────────────────────────
Windows Remote Management (WinRM)       Enabled on 5986 (HTTPS) only           Admin access
                                        Firewall: restrict to management VLAN  requires TLS
                                        Basic authentication: Disabled          no plaintext
                                        AllowUnencrypted: False

Remote Desktop (RDP)                    Disabled by default                    Jump host / PAM
                                        Enable only if documented as required   mediated access
                                        NLA required (NetworkLevel Auth)        preferred
                                        Restrict via firewall to mgmt VLAN
                                        Idle session timeout: 30 minutes

Server roles and features               Only explicitly required roles          Least functionality
                                        Verify post-deployment:                 (3.4.6)
                                        Get-WindowsFeature | 
                                        Where-Object {$_.Installed -eq $true}
                                        Compare against approved role list
                                        for each server type in EV-D19

Windows Defender Credential Guard       Enabled via GPO:                       Prevents credential
                                        Admin Templates → System →              theft from memory
                                        Device Guard → Turn on VBS:
                                        Enabled with UEFI lock

Protected Users security group          All interactive CUI-scope user          Prevents NTLM,
                                        accounts added to Protected Users        Kerberos RC4,
                                        Built-in admin not eligible —           unconstrained
                                        use LAPS instead                        delegation

LLMNR                                   GPO: Admin Templates → Network →       Prevents LLMNR
                                        DNS Client → Turn off multicast        poisoning attacks
                                        name resolution: Enabled

mDNS                                    Registry: HKLM\SYSTEM\                 Prevents mDNS
                                        CurrentControlSet\Services\            poisoning
                                        Dnscache\Parameters\
                                        EnableMDNS: 0

Unnecessary services (disabled):
  Print Spooler (non-print servers):    sc config spooler start=disabled
  WLAN AutoConfig:                      sc config wlansvc start=disabled
  Xbox services:                        Disable all Xbox-related services
  Fax:                                  sc config fax start=disabled
  Bluetooth Support:                    sc config bthserv start=disabled

Audit: Object access for CUI shares     Advanced Audit Policy →                File access
                                        Object Access → File System:           accountability
                                        Success, Failure                       (AT-AC 3.1.1)
                                        Apply to: CUI-classified share paths
                                        only (not all file system paths —
                                        volume would be unmanageable)

IIS hardening (if installed on CUI-scope server)

IIS is not installed by default on CUI servers. If required for a specific application:

Setting                                 Required value
──────────────────────────────────────────────────────────────────────────────────────────────
Default documents                       Remove all default documents or 
                                        restrict to application-specific
Directory browsing                      Disabled
HTTP response headers: X-Powered-By     Remove (reveals technology stack)
HTTP response headers: Server           Remove or set to empty string
Request filtering: Unlisted extensions  Deny unlisted file extensions
Request filtering: Allowed verbs        GET, POST only (remove TRACE, PUT, DELETE
                                        unless specifically required)
TLS minimum version                     TLS 1.2 minimum (configure via IIS 
                                        Crypto or registry)
TLS cipher suites                       Remove RC4, 3DES, MD5, SHA-1
                                        Preferred: AES-256-GCM, CHACHA20-POLY1305

---

BL-MAC · macOS Ventura / Sonoma Workstation Baseline

Reference and enforcement

CIS reference: CIS Apple macOS 14.0 Sonoma Benchmark v1.1.0
               (apply to Ventura systems until upgrade: CIS macOS 13.0 v2.0.0)
Level applied: Level 1 minimum for all CUI-scope macOS workstations
Enforcement: Jamf Pro configuration profiles (or Microsoft Intune if Jamf not deployed)
Verification: Jamf compliance reporting (Dashboard → Computers → Smart Group: 
              CUI-Scope-NonCompliant) reviewed monthly; 
              CIS-CAT Pro quarterly on a sample of macOS devices

Configuration profile settings

Each setting below is delivered as an MDM configuration profile payload. Group related settings into logical profiles (one profile per major category) to simplify troubleshooting.

Profile: Security and Privacy
──────────────────────────────────────────────────────────────────────────────────────────────
FileVault 2:
  Payload type: com.apple.MCX.FileVault2
  Enable: true
  Defer: true (enables at next logout if not already enabled)
  DeferForceAtUserLoginMaxBypassAttempts: 3
  ForceEnableInSetupAssistant: true
  Recovery key escrowed to MDM: true (Jamf: FileVault PRK escrowed)
  Algorithm: AES-128-XTS (hardware encryption on Apple Silicon)

Screen lock timeout:
  Payload: com.apple.screensaver
  loginWindowIdleTime: 900 (15 minutes)
  askForPasswordDelay: 0 (require password immediately on lock)

Gatekeeper:
  Payload: com.apple.systempolicy.control
  EnableAssessment: true
  AllowIdentifiedDevelopers: true
  (For highest-security CUI workstations: set to Mac App Store only)

System Integrity Protection (SIP):
  SIP cannot be disabled via MDM — it requires booting to Recovery Mode
  Verify via compliance rule:
    csrutil status | grep "enabled"
  If disabled: re-enable via Recovery Mode; investigate why it was disabled

Firewall:
  Payload: com.apple.security.firewall
  EnableFirewall: true
  BlockAllIncoming: true (with exceptions for required services)
  EnableStealthMode: true

Automatic login:
  Payload: com.apple.loginwindow
  com.apple.login.mcx.DisableAutoLoginClient: true
  SHOWFULLNAME: true (show username field, not user list)

Diagnostic data sharing:
  Payload: com.apple.MCX
  DisableDiagnosticSubmission: true
  submissionMode: none

iCloud restrictions (for CUI workstations):
  Payload: com.apple.applicationaccess
  allowCloudDocumentSync: false (disable iCloud Drive sync of work documents)
  allowCloudKeychainSync: false

Profile: Network Security
──────────────────────────────────────────────────────────────────────────────────────────────
Remote Login (SSH):
  Payload: com.apple.MCX
  com.apple.Remote-Apple-Events: {state: off}
  If SSH required for specific admin function:
    Restrict via /etc/ssh/sshd_config (deployed via script):
      PermitRootLogin no
      PasswordAuthentication no
      AllowUsers [specific admin usernames only]

Bluetooth:
  Payload: com.apple.MCX.Bluetooth
  DisableBluetooth: false (cannot fully disable via MDM)
  Inform users via policy — disable when not in use

Sharing services (disable all):
  Payload: com.apple.MCX
  Disable: Screen Sharing, Remote Management, Remote Login (SSH, unless required),
           File Sharing, Remote Apple Events, AirDrop, AirPlay Receiver

Profile: Password Policy
──────────────────────────────────────────────────────────────────────────────────────────────
Payload: com.apple.mobiledevice.passwordpolicy
  minLength: 16
  requireAlphanumeric: true
  minComplexChars: 1
  maxPINAgeInDays: 0 (no expiry where MFA enforced)
  pinHistory: 24
  maxFailedAttempts: 5
  lockout: lockDevice
  lockoutDuration: 900 (15 minutes)

macOS-specific compliance rules in MDM

Create the following Smart Groups in Jamf (or compliance policies in Intune):

  "CUI-Scope-MacOS-NonCompliant" — criteria:
    FileVault 2 Enabled: is not: true
    OR Gatekeeper Enabled: is not: true
    OR SIP Status: is not: System Integrity Protection status: enabled
    OR OS Build Version: is not up to date (within 2 minor versions)
    OR Last Check-in: more than 24 hours ago (agent health)

  Any device in this Smart Group generates a MDM alert → IT Operations reviews
  within 24 hours → remediation or exception documented

---

BL-UBUNTU · Ubuntu 22.04 LTS Server Baseline

Reference and enforcement

CIS reference: CIS Ubuntu Linux 22.04 LTS Benchmark v2.0.0
Level applied: Level 1 minimum; selected Level 2 settings for CUI servers
Enforcement: Ansible playbook — baseline.yml — stored in the configuration 
             management repository (GitLab/GitHub/ADO) under version control
Schedule: Applied at deployment (via cloud-init or kickstart integration) 
          AND on a weekly cron job (Ansible pull or push-based schedule)
Verification: CIS-CAT Pro (Linux profile) on all CUI-scope Ubuntu servers quarterly;
              Ansible check mode (--check flag) run weekly — generates drift report

Ansible playbook structure

# baseline.yml — top-level structure
# This file orchestrates the role-based approach

---
- name: Apply CUI-scope Ubuntu 22.04 security baseline
  hosts: cui_scope_servers
  become: yes
  become_method: sudo
  roles:
    - role: filesystem_hardening      # Section 1.1
    - role: software_management       # Section 1.3
    - role: kernel_parameters         # Section 1.5
    - role: filesystem_permissions    # Section 1.7
    - role: apparmor                  # Section 1.6
    - role: ssh_hardening             # Section 5.2
    - role: pam_configuration         # Section 5.3/5.4
    - role: audit_configuration       # Section 4.1
    - role: network_configuration     # Section 3.x
    - role: logging_configuration     # Section 4.2
    - role: cron_access_control       # Section 5.1
    - role: account_settings          # Section 5.4/5.6
    - role: warning_banners           # Section 1.8
    - role: service_management        # Section 2.x

Key configuration settings by section

FILESYSTEM HARDENING (role: filesystem_hardening)
──────────────────────────────────────────────────────────────────────────────────────────────
Partition layout (configure at deployment — cannot be changed post-install):
  /tmp        → separate partition, nodev,nosuid,noexec mount options
  /var        → separate partition
  /var/log    → separate partition
  /var/log/audit → separate partition
  /home       → separate partition, nodev mount option

Disable unused filesystems (/etc/modprobe.d/cis-filesystems.conf):
  install cramfs /bin/false
  blacklist cramfs
  install freevxfs /bin/false
  blacklist freevxfs
  install jffs2 /bin/false
  blacklist jffs2
  install hfs /bin/false
  blacklist hfs
  install hfsplus /bin/false
  blacklist hfsplus
  install udf /bin/false
  blacklist udf
  install usb-storage /bin/false   # Critical — prevents USB mass storage
  blacklist usb-storage

SSH HARDENING (role: ssh_hardening)
──────────────────────────────────────────────────────────────────────────────────────────────
# /etc/ssh/sshd_config managed via Ansible template:

Protocol 2
Port 22                            # Change from default if threat model warrants
AddressFamily inet                 # IPv4 only (or any if IPv6 required)
ListenAddress 0.0.0.0

# Authentication
PermitRootLogin no                 # CIS 5.2.10 — never permit root SSH
PasswordAuthentication no          # Certificate or key-based auth only
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes
KerberosAuthentication no
GSSAPIAuthentication no

# Session settings
X11Forwarding no                   # CIS 5.2.6
AllowTcpForwarding no             # Unless documented requirement exists
ClientAliveInterval 300           # 5-minute keepalive
ClientAliveCountMax 2             # Disconnect after 10 minutes idle
MaxAuthTries 4                    # CIS 5.2.7
MaxSessions 10
LoginGraceTime 60                 # 60 seconds to authenticate

# Algorithm restrictions (require strong algorithms)
Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr
MACs hmac-sha2-512,hmac-sha2-256
KexAlgorithms curve25519-sha256,diffie-hellman-group14-sha256

# Restrict access to named accounts only
AllowUsers [list explicit allowed usernames — no wildcards for CUI servers]
AllowGroups ssh-allowed           # Create this group and add only required users

KERNEL PARAMETERS (role: kernel_parameters)
──────────────────────────────────────────────────────────────────────────────────────────────
# /etc/sysctl.d/60-cis-baseline.conf managed via Ansible:

# Kernel hardening
kernel.randomize_va_space = 2          # ASLR — full randomisation
kernel.kptr_restrict = 2              # Hide kernel pointers
kernel.dmesg_restrict = 1             # Restrict dmesg access
kernel.perf_event_paranoid = 3        # Restrict perf subsystem

# Core dumps
kernel.core_pattern = |/bin/false     # Disable core dumps
fs.suid_dumpable = 0                  # Don't dump SUID binaries

# Network hardening
net.ipv4.ip_forward = 0               # Not a router
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.all.log_martians = 1    # Log impossible addresses
net.ipv4.conf.default.log_martians = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.conf.all.rp_filter = 1      # Reverse path filtering
net.ipv4.tcp_syncookies = 1          # SYN flood protection

AUDITD CONFIGURATION (role: audit_configuration)
──────────────────────────────────────────────────────────────────────────────────────────────
# /etc/audit/rules.d/cis-audit.rules managed via Ansible:

# Delete all existing rules first
-D

# Set buffer size (adjust for log volume)
-b 8192

# Failure mode: 1=print, 2=panic (use 2 for CUI systems)
-f 2

# Identity changes
-w /etc/group -p wa -k identity
-w /etc/passwd -p wa -k identity
-w /etc/gshadow -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/security/opasswd -p wa -k identity

# Network configuration changes
-w /etc/issue -p wa -k system-locale
-w /etc/issue.net -p wa -k system-locale
-w /etc/hosts -p wa -k system-locale
-w /etc/network -p wa -k system-locale

# Login/logout
-w /var/log/faillog -p wa -k logins
-w /var/log/lastlog -p wa -k logins
-w /var/run/faillock/ -p wa -k logins

# Session initiation
-w /var/run/utmp -p wa -k session
-w /var/log/wtmp -p wa -k logins
-w /var/log/btmp -p wa -k logins

# Privileged command execution (all setuid/setgid binaries)
-a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged
-a always,exit -F path=/usr/bin/su -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged
# Generate full list with: find / -xdev -perm -4000 -o -perm -2000 2>/dev/null

# File deletion
-a always,exit -F arch=b64 -S unlinkat,rename,renameat,rmdir -F auid>=1000 -F auid!=4294967295 -k delete
-a always,exit -F arch=b32 -S unlinkat,rename,renameat,rmdir -F auid>=1000 -F auid!=4294967295 -k delete

# Kernel module loading
-w /sbin/insmod -p x -k modules
-w /sbin/rmmod -p x -k modules
-w /sbin/modprobe -p x -k modules
-a always,exit -F arch=b64 -S init_module,finit_module,delete_module -k modules

# Audit configuration changes
-w /etc/audit/ -p wa -k auditconfig
-w /etc/libaudit.conf -p wa -k auditconfig
-w /etc/audisp/ -p wa -k auditconfig

# Make rules immutable (must reboot to change audit config)
-e 2

PAM CONFIGURATION (role: pam_configuration)
──────────────────────────────────────────────────────────────────────────────────────────────
# /etc/security/pwquality.conf:
minlen = 16
dcredit = -1        # At least 1 digit
ucredit = -1        # At least 1 uppercase
ocredit = -1        # At least 1 special character
lcredit = -1        # At least 1 lowercase
retry = 3
maxrepeat = 3       # No more than 3 consecutive identical characters

# /etc/pam.d/common-password — add pam_pwhistory:
password required pam_pwhistory.so remember=24 use_authtok

# /etc/login.defs — password hashing:
ENCRYPT_METHOD SHA512
SHA_CRYPT_MIN_ROUNDS 5000

# pam_faillock configuration (/etc/security/faillock.conf):
deny = 5            # Lock after 5 failed attempts
unlock_time = 900   # Unlock after 15 minutes
fail_interval = 900

AppArmor (role: apparmor)
──────────────────────────────────────────────────────────────────────────────────────────────
# Verify AppArmor is enabled and all profiles in enforce mode:
  apparmor_status | grep "profiles are in enforce mode"

# Ensure all installed service profiles are in enforce mode (not complain):
  aa-enforce /etc/apparmor.d/*

# If a specific service has no AppArmor profile, create one:
  aa-genprof [service-binary]    # Interactive profile generation
  # Then move to enforce mode: aa-enforce [profile]

# Verify in Ansible via command module:
  command: apparmor_status --json
  register: apparmor_status
  failed_when: apparmor_status.stdout | from_json | 
               json_query('processes.unconfined') != []

Ansible drift detection (weekly)

# Run in check mode (--check) — reports what WOULD change without changing it
# Schedule via cron or Ansible Tower / AWX job:

ansible-playbook baseline.yml \
  --check \
  --diff \
  --limit cui_scope_servers \
  -o /var/log/ansible-drift/drift-$(date +%Y%m%d).log

# Parse output for changes:
grep -E "^(TASK|changed:|failed:|ok:)" /var/log/ansible-drift/drift-$(date +%Y%m%d).log

# A "changed" result in check mode means a drift exists — the setting 
# on the system does not match the playbook.
# A "failed" result means the check itself failed — investigate immediately.

# Send drift report to IT Operations:
if grep -q "changed:" /var/log/ansible-drift/drift-$(date +%Y%m%d).log; then
  mail -s "Configuration drift detected on $(date +%Y-%m-%d)" \
       itops@organisation.com \
       < /var/log/ansible-drift/drift-$(date +%Y%m%d).log
fi

---

BL-CLOUD · Cloud Resource Baseline (AWS / Azure / GCP)

Reference and enforcement

CIS references:
  AWS:   CIS Amazon Web Services Foundations Benchmark v2.0.0
  Azure: CIS Microsoft Azure Foundations Benchmark v2.1.0
  GCP:   CIS Google Cloud Platform Foundation Benchmark v3.0.0

Enforcement: 
  Infrastructure as Code (Terraform / CloudFormation / Bicep / Deployment Manager)
  Policy-as-code: AWS SCPs, Azure Policy, GCP Org Policy
  Continuous verification: AWS Security Hub, Microsoft Defender for Cloud, GCP SCC

Key principle: no manual changes to CUI-scope cloud resources.
All changes via IaC pipeline with security policy gate.

AWS — critical baseline settings

IAM:
  Root account:
    MFA: hardware MFA device required (not virtual)
    Access keys: none (delete any existing root access keys)
    Usage: zero — document any root access event as an incident

  IAM password policy (enforce via Terraform aws_iam_account_password_policy):
    minimum_password_length     = 16
    require_symbols             = true
    require_numbers             = true  
    require_uppercase_chars     = true
    require_lowercase_chars     = true
    allow_users_to_change       = true
    max_password_age            = 90  (or 0 if IdP-federated)
    password_reuse_prevention   = 24
    hard_expiry                 = false

  Access keys:
    Rotate: every 90 days (AWS Config rule: access-keys-rotated)
    Unused keys (>90 days): disable and rotate
    No access keys for root: enforce via AWS Config

Logging:
  CloudTrail:
    Enable in all regions (including regions not actively used)
    Log validation: enabled
    S3 bucket: separate security-dedicated account
    S3 MFA delete: enabled
    CloudWatch Logs integration: enabled

  Config:
    Enable in all regions
    Recording: all resources
    Delivery: to S3 + SNS → SIEM

  S3 access logs: enabled on all CUI-scope buckets
  VPC Flow Logs: enabled on all CUI-scope VPCs

Network:
  Default VPC:
    Delete in all regions (use purpose-built VPCs only)
    Terraform: aws_default_vpc → mark for deletion

  Security groups:
    No 0.0.0.0/0 inbound on port 22 (SSH)
    No 0.0.0.0/0 inbound on port 3389 (RDP)
    AWS Config rule: restricted-ssh, restricted-common-ports

  EBS encryption:
    Default encryption: enabled in all regions
    Terraform: aws_ebs_encryption_by_default → true

Monitoring (CloudWatch alarms + SNS → SIEM):
  Root account usage:
    metric filter: { $.userIdentity.type = "Root" && 
                     $.userIdentity.invokedBy NOT EXISTS && 
                     $.eventType != "AwsServiceEvent" }

  Console sign-in without MFA:
    metric filter: { $.eventName = "ConsoleLogin" && 
                     $.additionalEventData.MFAUsed != "Yes" }

  IAM policy changes:
    metric filter: { $.eventName = "CreatePolicy" || $.eventName = "DeletePolicy" || 
                     $.eventName = "PutUserPolicy" || ... }

  CloudTrail configuration changes:
    metric filter: { $.eventName = "StopLogging" || $.eventName = "DeleteTrail" || 
                     $.eventName = "UpdateTrail" }

  Security group changes:
    metric filter: { $.eventName = "AuthorizeSecurityGroupIngress" || 
                     $.eventName = "RevokeSecurityGroupIngress" }

  Unauthorised API calls:
    metric filter: { $.errorCode = "*UnauthorizedAccess*" || 
                     $.errorCode = "AccessDenied" }

Azure — critical baseline settings

Identity:
  MFA for all users: enforced via Conditional Access (not legacy per-user MFA)
  Global admins: maximum 5 (align with CISO + IT Manager + 3 emergency)
  Guest users: review quarterly — disable unused guest accounts
  Password expiry: disabled (use CA sign-in frequency instead)

Logging:
  Azure Activity Log: diagnostic settings → Log Analytics workspace → SIEM
  Microsoft Entra ID audit logs: → Log Analytics → SIEM
  Microsoft Entra ID sign-in logs: → Log Analytics → SIEM
  Resource diagnostic logs: enable for all CUI-scope resources
  Storage account logging: read/write/delete for Blob, Queue, Table

Security:
  Microsoft Defender for Cloud:
    Enable for all subscription types:
      Servers: Standard tier
      App Services: Standard tier
      Databases: Standard tier
      Storage: Standard tier
      Containers: Standard tier
    Auto-provisioning: enabled (Log Analytics agent, Qualys)
    Security contacts: CISO email + phone
    Send alerts to: security contact AND subscription owners

  Key Vault:
    Soft delete: enabled (minimum 90 days)
    Purge protection: enabled
    Diagnostic logging: enabled
    Access: RBAC only (not legacy access policies)

  Storage accounts:
    Require secure transfer (HTTPS): enabled
    Public blob access: disabled (explicit, per-container exceptions need review)
    Minimum TLS version: TLS 1.2
    Infrastructure encryption: enabled (double encryption)
    Blob versioning: enabled for CUI-scope accounts

Networking:
  Network Watcher: enabled in all regions in use
  NSG flow logs: version 2, traffic analytics enabled
  No unrestricted inbound on ports 22, 3389 (check via Security Center)

---

Approved software list management

List structure and governance

The approved software list is maintained as a Confluence child page of AT-CM titled Approved Software List with a version history. The list has five categories and a denied software register. Every installation on a CUI-scope device must correspond to a list entry or an approved exception.

Category 1: Productivity
  Description: Standard office and collaboration tools for all staff
  Approval authority: IT Manager
  Deployment method: MDM / SCCM / Jamf
  Example entries:
    Microsoft 365 Apps for Enterprise (current channel)
    Microsoft Teams
    Microsoft Edge (stable channel)
    Adobe Acrobat Reader DC
    [VPN client — specify product and version range]

Category 2: Developer tools
  Description: IDEs, compilers, source control clients, build tools
  Approved users: Developer role only
  Approval authority: IT Manager + relevant team lead confirmation
  Example entries:
    Visual Studio Code (current stable)
    Git for Windows (current stable)
    Python 3.11.x or later (from python.org)
    Docker Desktop (for approved dev environments only)

Category 3: Security tools
  Description: AV/EDR platform, SIEM agents, vulnerability scanner, monitoring agents
  Approved users: IT Operations and Security team only
  Approval authority: IT Manager
  Example entries:
    [EDR product] agent (current version — auto-updated by platform)
    [SIEM] forwarder agent (current version)
    Tenable Nessus / Qualys agent (current version)
    CIS-CAT Pro scanner (current version)

Category 4: Privileged utilities (install on-demand, remove after use)
  Description: Network scanners, packet capture, forensic tools, password managers
  Approved users: Security team only
  Approval authority: CISO
  Deployment: On-demand via MDM → remove within 24 hours of task completion
  Usage: Logged to SIEM — session recording active during use
  Example entries:
    Wireshark (approved version)
    Nmap (approved version)
    FTK Imager (approved version)
    Volatility (approved version) 

Category 5: Approved browser extensions
  Description: Extensions permitted on CUI-scope workstations
  Approval authority: IT Manager
  Enforcement: Chrome managed extensions list via GPO; 
               Safari via MDM; Firefox via enterprise policy
  Example entries:
    uBlock Origin (approved — privacy and malware protection)
    [Password manager browser extension — if approved password manager deployed]
    Microsoft Defender Browser Protection

  All other extensions: blocked by default via GPO/MDM managed extension policy
  Extension whitelist enforcement (Chrome GPO):
    ExtensionSettings policy with:
      "*": {"installation_mode": "blocked"}
      "[extension-id]": {"installation_mode": "allowed"} (per approved extension)

Software approval request process

Request submission:
  User submits helpdesk ticket with:
    Software name and version
    Vendor/source URL
    Business justification (what task requires it)
    Information it will handle (will it access CUI? personal data? both?)
    Frequency of use (occasional / daily)

IT Manager assessment (3 business days SLA):
  Vendor reputation check: security vulnerability history, CVE count
  Data access scope: what data does it access/transmit?
  Licence compliance: is the licence appropriate?
  Conflict check: does it conflict with existing AV/EDR or security tools?
  Network exposure: does it make outbound connections? to where?

CISO assessment (additional 2 days for items accessing CUI or internet):
  Same as IT Manager plus:
  GDPR implications: does it process personal data?
  Contract compliance: does use of this tool violate any customer contract?
  CUI handling: can it be configured to not transmit CUI to the vendor?

Decision:
  Approved: add to approved software list, create MDM deployment package
  Approved with conditions: approve with specific configuration requirements documented
  Denied: add to denied software register with reason; 
          notify requester with explanation

Denied software register:
  Maintain a register of denied software with the reason for denial.
  Re-submission of denied software within 6 months is not accepted unless
  circumstances have materially changed.
  Purpose: prevents repeat requests and creates an audit trail of governance decisions.

Technical enforcement of the approved software list

Windows (application allow-listing — CUI servers):
  Windows Defender Application Control (WDAC) — preferred over AppLocker
  for Windows 11 / Server 2022:

  Create base policy from approved software list:
    New-CIPolicy -Level Publisher -ScanPath "C:\Program Files" `
                 -UserPEs -FilePath ".\BasePolicy.xml"

  Supplement with specific signed publisher rules for approved software:
    # Allow Microsoft-signed binaries
    # Allow [org code signing cert]-signed binaries
    # Block all unsigned executables

  Deploy via MDM / GPO:
    ConvertFrom-CIPolicy -XmlFilePath ".\BasePolicy.xml" `
                         -BinaryFilePath "C:\Windows\System32\CodeIntegrity\SiPolicy.p7b"

  For endpoints (allow-list approach requires significant maintenance):
    Alternative: deny-by-exception via MDM software restriction
    + admin rights removal (users cannot install without elevation)
    + MDM software inventory report flagging unapproved software

Windows (standard endpoints — deny-by-exception with inventory monitoring):
  Remove local admin rights from all standard user accounts (via GPO)
  Configure MDM (Intune) to generate compliance report on detected applications
  Create compliance policy: flag any application not in the approved list
  Weekly review of MDM non-compliance report by IT Operations

macOS (via Jamf or Intune):
  Restrict App Store to organisation account only:
    Configuration Profile → Restrictions → Allow App Store: Managed (not Open)
  Block sideloading (Gatekeeper Level 2: App Store only):
    For CUI workstations — configure Gatekeeper via MDM to App Store only
  Software restriction via Jamf policy:
    Create "Software Restriction" policy: block specific application bundles
    Example: block personal cloud storage (Dropbox, personal OneDrive, Google Drive)

Linux (application allow-listing via AppArmor):
  Ansible deploys AppArmor profiles for all services in enforce mode
  All unconfined processes generate a SIEM alert
  Verify weekly via: apparmor_status | grep "unconfined"

---

Configuration drift detection

Detection mechanisms — layered approach

Drift detection uses four independent mechanisms that provide different detection windows. A control whose drift is not caught by one mechanism should be caught by another.

Layer 1: MDM continuous compliance reporting (Windows and macOS)
  Detection window: near-real-time (15-minute MDM check-in cycle)
  Scope: MDM-enrolled endpoints (all CUI-scope workstations)
  Mechanism: Intune compliance policy evaluates device against policy settings
             Non-compliant: device marked non-compliant → CA policy denies access
             Alert: SIEM receives compliance state change event
  Evidence: MDM compliance dashboard exported monthly as part of EV-D20

Layer 2: SIEM alert on security configuration change events (Windows)
  Detection window: within 60 seconds
  Scope: all CUI-scope Windows systems forwarding to SIEM
  Mechanism: GPO/audit policy captures security config changes as Windows events
             SIEM correlation rule fires on:
               Event 4719 (Audit policy changed)
               Event 4902 (Per-user audit policy table created)
               Event 4904/4905 (Attempt to register/unregister security event source)
  Alert severity: High — unexpected audit policy changes are an attacker indicator

Layer 3: Ansible check mode weekly (Linux servers)
  Detection window: weekly
  Scope: all CUI-scope Ubuntu servers
  Mechanism: Ansible check mode compares live state against playbook definition
             Any "changed" result in check mode = drift detected
  Output: drift report emailed to IT Operations

Layer 4: Quarterly configuration audit (all platforms)
  Detection window: quarterly (EV-D20)
  Scope: all CUI-scope systems — sample-based for workstations, full for servers
  Mechanism: CIS-CAT Pro scan comparing live settings against approved baseline
  Output: per-system compliance score and failed control list filed in EV-D20

CIS-CAT Pro quarterly scan procedure (generates EV-D20)

CIS-CAT Pro is the automated configuration assessment tool that produces the quarterly configuration audit evidence. It requires a licence — confirm the organisation holds a current CIS SecureSuite licence that includes CIS-CAT Pro.

Scan preparation:
  Confirm CIS-CAT Pro is updated to the latest version
  Confirm benchmark profiles match the currently approved baselines:
    Windows 11 → CIS_Microsoft_Windows_11_Benchmark_v3.0.0-L1
    Windows Server 2022 → CIS_Microsoft_Windows_Server_2022_Benchmark_v2.0.0-L1
    macOS → CIS_Apple_macOS_14.0_Sonoma_Benchmark_v1.1.0-L1
    Ubuntu 22.04 → CIS_Ubuntu_Linux_22.04_LTS_Benchmark_v2.0.0-L1

Scope selection:
  Servers: scan all CUI-scope servers (full population)
  Workstations: scan 10% minimum (random sample from each OS type)
  Total minimum sample:
    If 50 CUI-scope Windows workstations: scan minimum 5
    If 20 CUI-scope macOS: scan minimum 2
    All 8 CUI-scope servers: scan all

Scan execution:
  Windows (remote scan from scan host in management VLAN):
    cis-cat-full.bat -b benchmarks/CIS_Win11_v3.0.0.xml \
                     -t [target IP] \
                     -u [domain]\[scan account] \
                     -p [password from PAM] \
                     -o reports/ \
                     -nrr  (no right-click report, output HTML+CSV)

  Linux (SSH-based scan):
    ./cis-cat-full.sh -b benchmarks/CIS_Ubuntu22_v2.0.0.xml \
                      -t [target IP] \
                      --ssh-port 22 \
                      --ssh-user [scan user] \
                      --private-key [scan key path] \
                      -o reports/

  macOS (via Jamf script or direct SSH):
    As above using macOS benchmark profile

Report analysis:
  For each scanned system:
    Record: hostname, scan date, benchmark version, overall score (%)
    Flag: any control scoring below pass threshold
    Categorise each failing control by severity:
      Critical (CVSS 9+): remediate within 7 days
      High (CVSS 7-8.9): remediate within 14 days  
      Medium (CVSS 4-6.9): remediate within 30 days
      Low: remediate within 90 days or document accepted risk

Remediation tracking:
  Each failing control creates an entry in EV-D07 (patch/configuration tracking register)
    Not just patches — configuration deviations are tracked here alongside patches
  Owner assigned (IT Operations engineer)
  Due date calculated from severity
  Evidence of remediation: re-scan of affected system after fix applied

EV-D20 filing:
  File in: EV-D · Config Management → Config Audits → [YYYY-QQ]
  Contents:
    Summary table: system name, OS, scan date, benchmark version, score %, findings count
    Individual scan reports (HTML output from CIS-CAT Pro)
    Deviation analysis: what failed, what is being remediated, what is accepted
    IT Manager sign-off confirming review and remediation tracking initiated

Configuration deviation handling and the exception register

When a deviation is found that cannot be remediated within the standard SLA:

Step 1 — Create an exception record in EV-D08:
  CVE or control reference: [CIS control ID]
  Affected system(s): [hostname(s)]
  Description of deviation: [specific setting and its actual vs required value]
  Reason remediation is delayed:
    Operational dependency (patching this breaks a required service)
    Vendor issue (fix requires vendor-provided patch/update not yet available)
    Testing required (significant change requires staging environment test first)
    Resource constraint (approved but awaiting scheduled maintenance window)

Step 2 — Document compensating controls:
  What is in place to reduce the risk during the exception period?
  Examples:
    Network isolation of the affected system from high-risk segments
    Enhanced SIEM monitoring for exploitation of the specific configuration
    Additional access controls limiting who can reach the affected system

Step 3 — Set expiry:
  Critical/High exceptions: maximum 30 days (escalate to CISO at 30 days)
  Medium exceptions: maximum 90 days
  Low exceptions: maximum 12 months (annual risk acceptance decision)

Step 4 — CISO approval:
  Critical and High exceptions require CISO signature before filing
  Medium and Low exceptions require IT Manager signature

Step 5 — Monthly review:
  All open exceptions reviewed monthly by CISO
  Progress notes updated for each exception
  Any exception past its expiry without resolution escalates to management

---

Change management integration

How secure configuration changes flow through change management

A configuration baseline update — whether it is a new CIS Benchmark setting, a deviation correction, or a new platform added to scope — is not simply deployed. It goes through the change management process defined in AT-CM 3.4.3.

Change category determination for configuration changes:

  Standard (pre-approved):
    Routine patch deployment via MDM/WSUS within SLA
    LAPS password rotation (automated — no manual RFC required)
    Antivirus signature update (automated)
    Certificate renewal via ACME automation

  Normal (individual CAB review required):
    New GPO setting or modification to existing GPO
    New Ansible playbook task or role modification
    New MDM configuration profile or modification
    Addition of a new system to the CUI-scope OU or scan scope
    New software added to the approved software list (if involving deployment change)
    Baseline update following new CIS Benchmark release

  Major (CAB + CISO + senior management notification):
    New platform added to the baseline programme (new OS type in scope)
    Significant architectural change (e.g. moving from GPO to MDM for Windows)
    Change that affects the system boundary described in the SSP

  Emergency:
    Immediate configuration fix required to contain an active incident
    CISA KEV exploitation confirmed — emergency patching or configuration change

Security Impact Assessment (SIA) for configuration changes

Every Normal and Major configuration change RFC requires a SIA completed before CAB submission. For configuration changes, the SIA template in the ITSM system should include specific questions that are configuration-relevant:

Configuration-specific SIA questions:

1. Which baseline document(s) does this change affect?
   [Reference specific BL-[PLATFORM] document and section]

2. Which NIST 800-171 controls does this configuration setting satisfy?
   [Reference AT-CM, AT-IA, AT-AU, AT-SC, etc. as applicable]

3. Has the setting been tested in a staging environment?
   If Yes: describe the test environment and outcomes
   If No: justify why staging test is not feasible for this change

4. Will this change require a device restart or service interruption?
   If Yes: define the maintenance window and user communication plan

5. What is the rollback procedure if this change creates an adverse condition?
   [Specific GPO revert / Ansible rollback / MDM profile removal procedure]

6. Will this change affect CIS-CAT Pro compliance scores?
   If Yes: describe the expected change in compliance score and direction

7. Does this change affect any currently open EV-D08 exception records?
   If Yes: list exception record references — the change may close or modify exceptions

Post-change verification

After any configuration change is implemented, a verification step confirms the change was applied as intended and did not introduce unintended effects.

Standard verification after GPO change:
  1. On a sample test workstation in the target OU:
     gpupdate /force
  2. Run RSOP (Resultant Set of Policy) to verify the setting:
     rsop.msc → navigate to the changed setting → confirm expected value
  3. Run CIS-CAT Pro targeted scan on the test workstation:
     Verify the specific control that was changed now shows Pass
  4. Confirm no new failures introduced in adjacent controls

Standard verification after Ansible change:
  1. Run in check mode on one server first:
     ansible-playbook baseline.yml --check --diff --limit [test-server]
     Confirm only expected changes are shown
  2. Apply to one server:
     ansible-playbook baseline.yml --limit [test-server]
  3. Run in check mode again on the same server:
     ansible-playbook baseline.yml --check --limit [test-server]
     Expected: zero "changed" results (idempotent)
  4. Confirm service is still operational post-change
  5. Roll out to remaining servers

Post-change SIEM monitoring:
  For changes to security-relevant settings, set a 24-hour monitoring 
  window in the SIEM after deployment:
    Alert: any authentication failure spike following change
    Alert: any new service failing to start on affected systems
    Alert: any security event category going silent (indicates audit policy 
           change may have unintentionally suppressed logging)

Document in RFC:
  Post-change verification completed: [date and engineer]
  Verification method: [RSOP / CIS-CAT / Ansible check / SIEM review]
  Result: [Pass / Issues found — describe and link to follow-up ITSM ticket]

---

Evidence items — what to generate and when

Evidence ID	What it is	Trigger	Owner	Filed at
EV-D19	Baseline configuration specifications — one per platform, version-controlled	Annual review + on major OS/CIS release	IT Manager	AT-CM → BL-[PLATFORM] child pages
EV-D20	Quarterly configuration audit — CIS-CAT Pro output, deviation analysis, IT Manager sign-off	Quarterly — Q1/Q2/Q3/Q4	IT Manager	EV-D → Config Management → Config Audits → [YYYY-QQ]
EV-D21	Change management records — RFC per configuration change, including SIA and post-change verification	Per configuration change event	IT Manager (CAB chair)	EV-D → Config Management → Change Log
EV-D22	Asset register — system component inventory reconciled against network discovery	Quarterly reconciliation	IT Operations	EV-D → Config Management → Asset Register
EV-D08	Configuration exception register — per deviation, compensating control, CISO approval	Per exception raised	CISO / IT Manager	EV-D → Vulnerability Management → Patch Exceptions
Approved software list	Version-controlled list of permitted software	Annual review + per approval decision	IT Manager	AT-CM → Approved Software List
Ansible drift report	Weekly check-mode output showing configuration drift on Linux servers	Weekly (automated)	IT Operations	EV-D → Config Management → Ansible Drift Reports → [YYYY-MM]
MDM compliance export	Monthly MDM compliance dashboard export showing all enrolled devices and compliance state	Monthly	IT Operations	Filed within EV-D20 for that quarter

Evidence production calendar

Weekly (automated):
  [ ] Ansible check-mode drift report — Linux CUI servers
  [ ] MDM non-compliance report review — Windows and macOS

Monthly:
  [ ] MDM compliance export — file for quarterly EV-D20 preparation
  [ ] Review Ansible drift reports — any unresolved drift becomes EV-D08 entry

Quarterly:
  [ ] EV-D20 — CIS-CAT Pro scan on all CUI-scope servers + 10% workstation sample
  [ ] EV-D22 — Asset register reconciliation against network discovery scan
  [ ] Approved software list review — verify list matches MDM inventory

Annually:
  [ ] EV-D19 — Full baseline review for all six BL-[PLATFORM] documents
  [ ] CIS Benchmark version check — are we within one minor version?
  [ ] Approved software list comprehensive review — retire EOL entries

Per event:
  [ ] EV-D21 — RFC created and closed for every Normal+ configuration change
  [ ] EV-D08 — Exception record created within 5 business days of finding

---

FC-02 IT Staff Technical Procedures — Owner: IT Manager. Related AT-[family] pages: AT-CM · Configuration Management, AT-SI · System and Info Integrity. Evidence register: EV-D19, EV-D20, EV-D21, EV-D22, EV-D08.