Configuration, change and patch management for security

Many serious breaches begin not with a clever new technique but with something ordinary: a server deployed with a default password, a storage bucket left open after a test, a firewall rule added for a weekend and never removed, or a patch for a known vulnerability that sat unapplied for months. These are failures of configuration, change and patch management. They are unglamorous disciplines, but they decide whether an organization's systems stay in the secure state its architects designed.

The CISSP outline covers these topics in several sub-domains of Domain 7: perform configuration management (7.3), implement and support patch and vulnerability management (7.8) and understand and participate in change management processes (7.9). CISSP-115 covered vulnerability scanning and scoring as assessment activities, and ITIL-140 covered change enablement as an IT service management practice. This lesson connects them from the security operations point of view: how to define and hold a secure baseline, how to make sure changes do not weaken it, and how to run patching as a reliable process with measurable service levels.

Configuration management and secure baselines

Configuration management is the discipline of establishing, documenting and maintaining the configuration of systems throughout their life. For security, the central idea is the baseline: an approved, documented configuration that a class of systems must meet, covering things such as which services run, which accounts exist, password and lock-out settings, logging, encryption and remote access. New systems are built from hardened images or templates that already meet the baseline, and existing systems are checked regularly for drift.

Organizations rarely write baselines from scratch. Widely used sources include the Center for Internet Security (CIS) Benchmarks, consensus-developed configuration guides for operating systems, cloud platforms and applications, and US government Security Technical Implementation Guides (STIGs). These are starting points; each organization tailors them to its risk and documents justified deviations. Baselines must be versioned and reviewed when platforms change, and when a setting must differ for business reasons, the exception should be approved, time-limited and recorded.

Automation has changed configuration management. Infrastructure as code describes servers, networks and cloud resources in version-controlled templates, so that the same reviewed template produces the same result every time. Policy-as-code tools check templates for insecure settings before deployment, and cloud security posture management tools continuously compare live cloud configurations against policy. These approaches make the baseline enforceable rather than aspirational, but they also move risk into the pipeline: whoever can change the templates or the pipeline can change production, so the pipeline itself needs strong access control, review and logging.

# Compare actual server settings with the approved baseline and report drift
baseline = {
    'ssh_root_login': 'no', 'password_min_length': 14, 'audit_logging': 'on',
    'tls_min_version': '1.2', 'smb_v1': 'off', 'auto_updates': 'on',
}
servers = {
    'web01': {'ssh_root_login': 'no', 'password_min_length': 14, 'audit_logging': 'on', 'tls_min_version': '1.2', 'smb_v1': 'off', 'auto_updates': 'on'},
    'web02': {'ssh_root_login': 'yes', 'password_min_length': 14, 'audit_logging': 'on', 'tls_min_version': '1.0', 'smb_v1': 'off', 'auto_updates': 'on'},
    'file01': {'ssh_root_login': 'no', 'password_min_length': 8, 'audit_logging': 'off', 'tls_min_version': '1.2', 'smb_v1': 'on', 'auto_updates': 'off'},
}
exceptions = {('file01', 'smb_v1'): 'EXC-114 legacy scanner, expires 2026-12-31'}
for host, cfg in servers.items():
    drift = [k for k, v in baseline.items() if cfg.get(k) != v]
    approved = [k for k in drift if (host, k) in exceptions]
    open_items = [k for k in drift if k not in approved]
    score = 1 - len(open_items) / len(baseline)
    print(f'{host:7s} compliance {score:5.0%}  drift: {open_items or "none"}')
    for k in approved:
        print(f'        approved exception for {k}: {exceptions[(host, k)]}')

web01   compliance  100%  drift: none
web02   compliance   67%  drift: ['ssh_root_login', 'tls_min_version']
file01  compliance   50%  drift: ['password_min_length', 'audit_logging', 'auto_updates']
        approved exception for smb_v1: EXC-114 legacy scanner, expires 2026-12-31

The report is the kind of output a configuration compliance tool produces. The important management behaviours are what happens next: unapproved drift is assigned to an owner and fixed within a defined time, approved exceptions carry an expiry date and a compensating control, and repeated drift on the same setting prompts a look at the underlying cause, such as a build process that does not apply the baseline.

Change management from a security perspective

Change management makes sure that changes to systems are requested, assessed, approved, tested, implemented and reviewed in a controlled way. ITIL-140 described the practice in detail: change types (standard, normal and emergency), change authorities and change schedules. The security function's role is to make sure that every change is assessed for security impact, that changes that alter the attack surface receive appropriate review, and that unauthorized changes are detected.

Security impact assessment does not need to be heavy for every change. A risk-based approach classifies changes so that low-risk, pre-approved standard changes, such as adding a user to a predefined group, flow quickly, while changes to internet-facing systems, authentication, encryption, logging, firewall rules or privileged access get explicit security review. Emergency changes, made to restore service or respond to an incident, are allowed to bypass normal approval but must be documented and reviewed afterwards; an organization where most changes are emergencies has a process problem, not a run of bad luck.

# Risk scoring for proposed changes to decide the level of security review
factors = {'internet_facing': 3, 'touches_auth_or_crypto': 3, 'changes_firewall': 2,
           'privileged_access': 2, 'no_rollback_plan': 2, 'untested': 2, 'out_of_hours_only': 1}
changes = {
    'CHG-2201 add user to finance-readers group': [],
    'CHG-2202 open port 8443 on edge firewall to new vendor': ['internet_facing', 'changes_firewall'],
    'CHG-2203 replace SSO certificate on identity provider': ['internet_facing', 'touches_auth_or_crypto', 'out_of_hours_only'],
    'CHG-2204 emergency patch of VPN appliance, not yet tested': ['internet_facing', 'privileged_access', 'untested', 'no_rollback_plan'],
}
def route(score):
    if score == 0: return 'standard change, pre-approved'
    if score <= 4: return 'normal change, security peer review'
    return 'normal or emergency change, security sign-off and post-implementation review'
for chg, f in changes.items():
    score = sum(factors[x] for x in f)
    print(f'{chg}\n    score {score:2d} -> {route(score)}')

CHG-2201 add user to finance-readers group
    score  0 -> standard change, pre-approved
CHG-2202 open port 8443 on edge firewall to new vendor
    score  5 -> normal or emergency change, security sign-off and post-implementation review
CHG-2203 replace SSO certificate on identity provider
    score  7 -> normal or emergency change, security sign-off and post-implementation review
CHG-2204 emergency patch of VPN appliance, not yet tested
    score  9 -> normal or emergency change, security sign-off and post-implementation review

Detecting unauthorized change is the complement to controlling authorized change. File integrity monitoring watches critical files and configuration settings and alerts when they change; configuration drift tools compare systems to the baseline; and change records are reconciled against what monitoring actually observed. A change that appears in monitoring but has no matching approved ticket is either a process failure or a possible intrusion, and should be investigated as such.

Patch and vulnerability management as an operational process

Patch management keeps software up to date with fixes released by vendors; vulnerability management is the broader process of identifying, prioritizing and remediating weaknesses, of which patching is the most common remedy. CISSP-115 covered scanning and prioritization using CVSS, EPSS and known exploited vulnerability catalogues. In operations, the challenge is execution: getting fixes deployed across thousands of systems, quickly enough to matter, without breaking the business.

A mature patch process has these stages: maintain an accurate inventory of assets and software (you cannot patch what you do not know about); monitor vendor and government advisories; assess and prioritize each fix by severity, exploitation status and asset criticality; test on representative systems; deploy in waves, starting with a pilot group; verify through scanning that the fix is in place; and report compliance against service levels. When a patch cannot be applied, for example because a vendor no longer supports a product or a medical device cannot be changed, the risk is mitigated by compensating controls such as network isolation and monitoring, and accepted formally by the system owner.

Service levels turn the process into something measurable. A typical policy sets remediation targets by severity, with shorter targets for vulnerabilities that are known to be exploited in the wild and for internet-facing systems. US federal agencies, for example, must remediate entries in CISA's Known Exploited Vulnerabilities catalogue within deadlines set by Binding Operational Directive 22-01; many private organizations borrow the same idea. In Canada, CCCS's baseline cyber security controls for small and medium organizations likewise stress prompt patching of internet-facing and actively exploited flaws.

from datetime import date
# Patch SLA compliance from a sample of closed findings (synthetic)
sla_days = {'critical-kev': 14, 'critical': 30, 'high': 60, 'medium': 90}
findings = [
    ('critical-kev', date(2026, 8, 1), date(2026, 8, 9)),
    ('critical-kev', date(2026, 8, 3), date(2026, 8, 25)),
    ('critical', date(2026, 7, 10), date(2026, 8, 2)),
    ('critical', date(2026, 7, 12), date(2026, 8, 30)),
    ('high', date(2026, 6, 1), date(2026, 7, 20)),
    ('high', date(2026, 6, 5), date(2026, 8, 15)),
    ('medium', date(2026, 5, 1), date(2026, 7, 2)),
    ('medium', date(2026, 5, 2), date(2026, 9, 1)),
]
from collections import defaultdict
stats = defaultdict(lambda: [0, 0])
for sev, found, fixed in findings:
    days = (fixed - found).days
    stats[sev][0] += 1
    stats[sev][1] += days <= sla_days[sev]
    print(f'{sev:13s} {days:3d} days  target {sla_days[sev]:2d}  {"met" if days <= sla_days[sev] else "MISSED"}')
for sev, (n, ok) in stats.items():
    print(f'{sev:13s} on time {ok}/{n}')

critical-kev    8 days  target 14  met
critical-kev   22 days  target 14  MISSED
critical       23 days  target 30  met
critical       49 days  target 30  MISSED
high           49 days  target 60  met
high           71 days  target 60  MISSED
medium         62 days  target 90  met
medium        122 days  target 90  MISSED
critical-kev  on time 1/2
critical      on time 1/2
high          on time 1/2
medium        on time 1/2

Reporting should show not just the percentage met but the age of what remains open, broken down by owner and asset criticality. A single critical, actively exploited flaw on an internet-facing system that is three weeks overdue matters more than dozens of low-severity items, and management reports should make that visible.