Enterprise Patch Management: Systematische Schwachstellenbehebung

Patch management is one of the most effective yet underrated security measures. Most successful attacks exploit known, patched vulnerabilities—because patching is poorly organized. A structured patch management program closes this window.

The Patch Management Process

Patch Management Cycle (continuous):

Phase 1: Asset Inventory (Foundation)
  → Without a complete inventory: blind spots!
  → Servers: IP, OS, patch status, criticality
  → Clients: device, OS, software, user
  → Network devices: manufacturer, firmware, management access
  → Cloud: EC2/VMs, containers, managed services
  → IoT/OT: separate handling (different cycles, offline phases)
  → Tools: CMDB, Active Directory (clients), AWS Config, Azure Inventory

Phase 2: Monitor patch sources
  → Microsoft MSRC:     msrc.microsoft.com (Patch Tuesday: 2nd Tuesday of the month)
  → CISA KEV:           cisa.gov/known-exploited-vulnerabilities (ALWAYS immediately!)
  → BSI Alerts:  bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen
  → NVD/CVE:           nvd.nist.gov (RSS feed recommended)
  → Vendor Portals:  Cisco PSIRT, VMware Security Advisories, etc.
  → Threat Intel Feeds: MISP, OTX, commercial

Phase 3: Risk Assessment
  → CVSS Score: technical severity (0–10)
  → EPSS Score: probability of exploitation (0–100%)
  → CISA KEV:   actively exploited in the wild → ALWAYS Priority 1!
  → Specific context:
    - Is the system accessible via the Internet? → multiplies risk
    - Does the system contain sensitive data?
    - Is there a workaround/mitigation?

Phase 4: Patch SLA (binding deadlines)
  Critical (CVSS 9-10) + External:  24 hours
  Critical (CVSS 9-10) + Internal:  72 hours
  CISA KEV (any score):     IMMEDIATELY, regardless of CVSS
  High (7-8) + External:            7 days
  High (7-8) + Internal:            14 days
  Medium (4-6):                   30 days
  Low (0-3):                      90 days or documented acceptance

Phase 5: Patch Testing
  → Never directly to production! (except for emergency patches after assessment)
  → Test environment: representative subset of the production environment
  → Automated tests: CI/CD pipeline verifies functionality after patch
  → Rollback plan: ALWAYS create before patch deployment!

Phase 6: Deployment
  → Patch window: scheduled maintenance windows (production: nights/weekends)
  → Staging → Canary (5% of systems) → Full rollout
  → Monitoring: increased attention after patch deployment

Phase 7: Verification
  → Rescan after patch: Is the CVE actually fixed?
  → Vulnerability scanner: Does the finding disappear?
  → Compliance check: Patch SLA met?

Patching Windows environments

Microsoft WSUS (Windows Server Update Services):

Free, on-premises, for pure Windows environments:

Setup (PowerShell):
  Install-WindowsFeature -Name UpdateServices -IncludeManagementTools
  & 'C:\Program Files\Update Services\Tools\wsusutil.exe' postinstall `
    CONTENT_DIR=D:\WSUS

  Recommended WSUS groups:
  → "Pilot PCs" (10–20 devices)
  → "Production Servers"
  → "Domain Controllers" (extra caution!)
  → "Workstations"

WSUS Policy (GPO):
  Computer Configuration → Administrative Templates →
  Windows Components → Windows Update
  → Configure Automatic Updates: 4 (Download and schedule install)
  → Specify intranet MS update service: http://wsus-server:8530
  → Automatic update schedule: 0200 UTC Sunday

Deployment Strategy:
  Week 1: Pilot group (test critical patches)
  Week 2: Broader test (10% of workstations)
  Week 3: All workstations
  Week 4: Servers (during maintenance window!)
  Exception: CISA KEV → directly into the Server phase!

---

Microsoft Endpoint Configuration Manager (MECM/SCCM):
  → Complete enterprise solution (WSUS + Deployment + Reporting)
  → Configure Software Update Point
  → Automatic Deployment Rules (ADR) for monthly patches
  → Maintenance windows per collection

Microsoft Intune (Cloud-native, Hybrid):
  → Managed via Azure Portal
  → Update rings:
    - Ring 0: IT admins (immediately)
    - Ring 1: Pilot users (7 days after release)
    - Ring 2: Broad deployment (21 days)
    - Ring 3: Latecomers (35 days, not yet rolled out)
  → Feature updates: Separate update policy for OS versions

Monitoring Windows patch status:
  PowerShell (local check):
  Get-HotFix | Sort-Object InstalledOn -Descending | Select -First 10

  System-wide compliance:
  Get-WmiObject -Class Win32_QuickFixEngineering |
    Where-Object {$_.InstalledOn -lt (Get-Date).AddDays(-30)} |
    Measure-Object

Patching Linux environments

Linux Patch Management:

Debian/Ubuntu (apt):
  # Security updates without user interaction:
  apt-get update && apt-get upgrade -y --security-only

  Unattended Upgrades (automatic):
  apt install unattended-upgrades
  # /etc/apt/apt.conf.d/50unattended-upgrades:
  Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
  };
  Unattended-Upgrade::Automatic-Reboot "false";  # Schedule reboot manually!
  Unattended-Upgrade::Mail "sicherheit@firma.de";

RHEL/CentOS/Rocky (dnf/yum):
  # Security patches only:
  dnf update --security -y

  # What would be updated?
  dnf updateinfo list security

  # Automatic (dnf-automatic):
  dnf install dnf-automatic
  # /etc/dnf/automatic.conf:
  [commands]
  apply_updates = yes
  upgrade_type = security

---

Ansible for scalable Linux patching:

# patch-servers.yml
---
- name: Patch Linux Servers
  hosts: all
  become: yes
  tasks:
    - name: Update apt cache (Debian/Ubuntu)
      apt:
        update_cache: yes
        cache_valid_time: 3600
      when: ansible_os_family == 'Debian'

    - name: Install security updates (Debian/Ubuntu)
      apt:
        upgrade: dist
        update_cache: yes
      when: ansible_os_family == 'Debian'
      notify: Check if reboot required

    - name: Update packages (RHEL)
      dnf:
        name: '*'
        security: yes
        state: latest
      when: ansible_os_family == 'RedHat'
      notify: Check if reboot required

    - name: Check if reboot required (Ubuntu)
      stat:
        path: /var/run/reboot-required
      register: reboot_required
      when: ansible_os_family == 'Debian'

  handlers:
    - name: Check if reboot required
      debug:
        msg: "REBOOT REQUIRED on {{ inventory_hostname }}"

# Run:
# ansible-playbook -i inventory.ini patch-servers.yml --limit staging
# ansible-playbook -i inventory.ini patch-servers.yml --limit production

Patching Cloud Environments

AWS Patch Management (AWS Systems Manager):

SSM Patch Manager:
  1. Create a patch baseline (which patches automatically?):
     aws ssm create-patch-baseline \
       --name "AWARE7-Linux-Security-Baseline" \
       --operating-system "AMAZON_LINUX_2" \
       --approval-rules \
         'PatchRules=[{PatchFilterGroup:{PatchFilters:[
           {Key=SEVERITY,Values=[Critical,High]},
           {Key=CLASSIFICATION,Values=[Security]}]},
           AutoApproveAfterDays=7}]'

  2. Patch Group: Assign EC2 instances via tag
     Tag: "Patch Group" = "production-servers"

  3. Maintenance Window:
     aws ssm create-maintenance-window \
       --name "Sunday-Night-Patching" \
       --schedule "cron(0 2 ? * SUN *)" \
       --duration 4 \
       --cutoff 1

  4. Check compliance:
     aws ssm describe-instance-patch-states-for-patch-group \
       --patch-group production-servers

Azure Update Manager:
  → Azure Portal: Update Manager → Patch Management
  → Assessment: Immediate patch status check
  → Maintenance Schedule: Configure patch window
  → Compliance Dashboard: Which VMs are unpatched?

Container patching (Docker):
  → Keep base images up to date: FROM ubuntu:22.04 (never :latest!)
  → Trivy scan in CI: prevents vulnerable images from entering production
  → Rebuild strategy: Rebuild images weekly (not just code changes)
  → Registry scan: AWS ECR Inspector, Google Artifact Analysis

Emergency Patching (Emergency Patch Process)

If CISA KEV or CVSS 9-10+ is actively exploited:

Trigger: BSI warning OR CISA KEV addition OR active attack

Step 1: Exposure Assessment (0–2 hours)
  → Do we have the affected software? (SBOM, asset inventory)
  → Where is it deployed? (Exposed to the internet?)
  → Are there workarounds? (WAF rule, feature disable, firewall block)
  → Is an active exploit in use? (Threat Intel, BSI)

Step 2: Decision (2–4 hours)
  Option A: Immediate patch (testing reduced to < 2 hours)
  Option B: Workaround + scheduled patch (if patch is not available)
  Option C: Take system offline (if risk is unacceptable)
  Approval: CISO (or representative) must sign off on the decision

Step 3: Accelerated rollout
  → Testing: minimal functional test (not a complete test suite)
  → Patch in parallel instead of sequentially
  → Increase monitoring during deployment

Step 4: Documentation (always!)
  → What was the vulnerability (CVE)?
  → When detected, when patched?
  → Was the exploit active before the patch?
  → Final confirmation: Vulnerability no longer visible in rescan

Communication for emergency patches:
  → IT team: Immediate Slack/Teams message
  → Affected departments: Announce planned downtime
  → Management: Brief summary (risk, action, status)
  → CISO: Approval and notification

Compliance requirements

Regulatory Patch Requirements:

ISO 27001:
  A.8.8: Management of technical vulnerabilities
  → Written patch management policy
  → Verifiable SLAs and compliance tracking
  → Regular auditing

NIS2 (Art. 21):
  → "Appropriate technical and organizational measures"
  → Patch management explicitly addressed
  → 72-hour reporting requirement for incidents caused by unpatched vulnerabilities

BSI IT-Grundschutz:
  OPS.1.1.3: Patch and Change Management
  → Apply patches immediately
  → Documented testing procedures
  → Verifiable rollback capability

KRITIS (§8a BSIG):
  → State-of-the-art for critical systems
  → Audit every 2 years (by accredited bodies)
  → Patch process part of ISMS documentation

PCI DSS v4 (Requirement 6.3):
  → Critical patches: within 1 month of release
  → All other patches: within 3 months
  → Formal change management process

Documentation for audits:
  □ Patch policy document (SLAs, process, roles)
  □ Asset inventory with patch status
  □ Monthly patch compliance reports
  □ Exception approvals with justification
  □ Evidence: Vulnerability scanner reports before/after patch
  □ Emergency patch logs