Schlagwortarchiv: Patch-Management

Schwachstellen- und Patchmanagement im Jahre 2026

4 Antworten

In diesem Artikel thematisiere ich, wie sich die Anzahl der entdeckten Schwachstellen in den letzten Jahren entwickelt hat und ob wir noch von Zero-Day sprechen, oder eher von Zero-Hour oder Zero-Minute.

Ich werde darstellen, warum es in meinen Augen bis auf wenige Ausnahmen nicht mehr angemessen ist, nur noch einmal im Jahr oder quartalsweise zu patchen und unter Schmerzen eingeübte Prozesse heute nicht mehr zeitgemäß erscheinen.

Anschließend werde ich euch bitten, eure Erfahrungen anonym mit mir zu teilen. Ich erhoffe mir, so einen besseren Überblick über die Situation da draußen in den Rechenzentren, Serverräumen und IT-Betriebseinheiten zu gewinnen. Mehr dazu unten im Text.

Entwicklung der Bedrohungslage

Die Anzahl der pro Jahr gemeldeten Schwachstellen (CVE) steigt rasant, wie folgendes Diagramm in Abbildung 1 verdeutlicht.

Diagramm welches die Entwicklung der Schwachstellenanzahl pro Jahr für die Jahre 2003 bis 2025 darstellt. Erläuterungen dazu finden sich im Fließtext.
Abbildung 1: Grafische Darstellung der CVE-Metriken für die Jahre 2003 bis 2025 von: https://www.cve.org/About/Metrics

Während sich die Anzahl der CVE pro Jahr erstmalig im Zeitraum von 2016 bis 2017 von ca. 6.500 auf ca. 14.500 mehr als verdoppelt hat, kam es zuletzt in den Jahren 2021 bis 2024 zu einer Verdopplung. Diesmal hat sich die Anzahl jedoch von ca. 20.000 auf knapp über 40.000 gesteigert. Und diese Zahl steigt weiter. So wurden für das erste Quartal 2026 bereits 15.176 CVE gezählt.

Wenn sich dieser Trend fortsetzt, werden wir das Jahr 2026 mit deutlich mehr als 60.000 registrierten CVE abschließen. Das wären 5.000 CVE/Monat oder 164 CVE/Tag.

Gleichzeitig sinkt die mittlere Zeit von der Veröffentlichung eines CVE bis zu einem Exploit, wie Abbildung 2 zeigt.

Abbildung 2: Die mittlere Zeit zwischen der Veröffentlichung einer Schwachstelle und des Exploits sinkt stetig (schwarze Linie). Quelle: https://zerodayclock.com/ (letzter Abruf: 2026-06-28)

Lag die mittlere Zeit zwischen der Veröffentlichung eines CVE und des Exploits 2023 noch bei über 4 Monaten, ist diese auf 21,5 Tage im Jahr 2025 gesunken. Für 2026 wird diese sogar mit nur noch 3 Stunden angegeben.

Noch bedrohlicher wirkt die Lage, wenn man sich ansieht, für wie viele CVE noch am gleichen Tag oder sogar vor deren Veröffentlichung ein Exploit bekannt wird (siehe Abbildung 3). Man spricht hier auch von Zero-Day-Exploits.

Abbildung 3: Rate der Zero-Day-Exploits, gemessen in Prozent an der Anzahl CVE pro Jahr (rote Linie). Quelle: https://zerodayclock.com/ (letzter Abruf: 2026-06-28)

Im Jahr 2024 gab es für 47,9% der CVE einen Zero-Day-Exploit. Im Jahr 2025 war das bereits für mehr als die Hälfte der Fall, nämlich 53,6 %. Das Jahr 2026 ist noch in vollem Gange. Die Rate der Zero-Day-Exploits liegt mit bisher 76,9% nochmals deutlich höher.

Es wird für die Paketbetreuenden, Upstream-Entwickelnden und Software-Herstellenden Menschen immer herausfordernder, einen Patch bereitzustellen, bevor ein Exploit existiert und aktiv gegen verwundbare Systeme eingesetzt wird.

Klassische Ansätze funktionieren nicht mehr

Aus meiner beruflichen Tätigkeit als Red Hat TAM und als Sysadministator bei verschiedenen Unternehmen ist mir bekannt, dass unterschiedliche Unternehmen und Organisationen sehr verschieden mit Schwachstellen und deren Behandlung umgehen.

Allen ist gemein, dass sie für ihre Anwendungen Wartungsfenster vereinbaren, in denen z.B. Sicherheitsaktualisierungen installiert werden, um vorhandene Schwachstellen zu schließen. Einige haben einen Patchday pro Jahr, manche patchen einmal im Quartal und wieder andere monatlich. Einzelne Unternehmen können dies sogar noch schneller.

Die einen haben regelmäßig wiederkehrende Wartungsfenster, die anderen müssen diese bei Bedarf anmelden. Einige haben schlanke Prozesse, einige nutzen Change-Management nach ITIL.

Um die Integrität, Verfügbarkeit und Vertraulichkeit der eigenen Informationssysteme und deren umgebener Infrastruktur zu schützen, sind zwei Grundsätze seit vielen Jahren allgemein bekannt:

  1. Installiere verfügbare Sicherheitsaktualisierungen so schnell wie möglich.
  2. Nutze und implementiere Verteidigung in der Tiefe.

Die beiden Grundsätze stehen nicht in einer Entweder-Oder-Beziehung. Sie sollten beide berücksichtigt werden.

In meinen Augen ist es längst nicht mehr zeitgemäß, Sicherheitsaktualisierungen jährlich oder quartalsweise zu installieren. Eine kleine Ausnahme mögen hier Systeme bilden, deren Nutzerkreis stark eingeschränkt ist und auf die ausschließlich über wenige sehr gut gesicherte Kanäle zugegriffen werden kann.

Um es deutlich zu sagen: „Für wochen- oder tagelange Change-Management-Prozesse bleibt keine Zeit. Wer weiterhin so arbeitet, riskiert die Informationssicherheit seiner Umgebung.“

Wer alle seine Systeme einmal im Monat wartet und neustartet, bewegt sich in meiner Wahrnehmung aktuell im Mittelfeld dessen, was man im Feld findet. Doch auch hierauf darf sich niemand ausruhen. Existiert zu einem CVE ein Exploit und ein Patch, erscheint es fahrlässig, bis zu einem Monat mit dessen Installation zu warten.

Leider fehlt etlichen Unternehmen bzw. Organisationen noch immer die Fähigkeit schnell festzustellen, ob ihre IT-Dienste korrekt ausgeführt werden. Patch-Management-Zyklen sehen hier meist vor, dass zuerst einige Systeme aktualisiert werden, dann wartet man 1-2 Wochen, ob jemand meckert und dann aktualisiert man die restlichen Systeme. Das ist nicht mehr zeitgemäß.

Aus der eingangs beschriebenen Bedrohungslage folgend muss das neue Ziel lauten, jedes individuelle System an jedem Tag aktualisieren und neustarten zu können. Die Funktion von IT-Diensten ist durch automatisierte Mechanismen wie z.B. Monitoring oder automatisierte Tests zu verifizieren, um schnell mit der nächsten Stage fortfahren zu können. Wer dieses Ziel noch nicht erreicht hat, sollte sich schnellstens auf den Weg machen. Selbst wenn die 100% unerreichbar scheinen, ist jedes System, das man schnell absichern kann, ein deutlich geringeres Risiko für die eigene Informationssicherheit.

Wo Sicherheitsaktualisierungen nicht zeitnah eingespielt werden können, lässt sich das Risiko durch Verteidigung in der Tiefe minimieren. Kommunikationsverbindungen von und zu betrachteten Systemen sind zu überwachen und ggf. zu limitieren. Doch auch diese Maßnahmen müssen schnell verfügbar und umsetzbar sein. Wer erst zwei Wochen diskutieren muss, ob man den Zugriff auf einen Dienst einschränken könne, müsse, sollte, handelt nicht angemessen.

Zusammenfassend sehe ich unklare Verantwortlichkeiten, langwierige Abstimmungsprozesse und manuelle Tätigkeiten als Gift und Risiko für die Informationssicherheit. Klare Strukturen, geklärte Verantwortlichkeiten und Automation sind kein nice-to-have, sondern ein MUSS.

Wie geht ihr damit um?

Nun möchte ich von euch wissen: „Patcht ihr schon oder prozessiert ihr noch?“

Ich bin sehr daran interessiert zu erfahren, wie es in den Umgebungen meiner Lesenden und derer Bekannten zugeht. Daher freue ich mich sehr, wenn ihr (gern anonym) euer Patch-Management-Konzept, die Branche eures Unternehmens und die ungefähre Größe eurer Umgebung mit der Gemeinschaft bzw. mir teilt.

  • Ihr habt euer Patch-Management im eigenen (Firmen-)Blog beschrieben? Teilt bitte den Link in den Kommentaren.
  • Sendet mir gerne eine E-Mail an patchmanagement@my-it-brain.de.
  • Beschreibt euer Patch-Management in den Kommentaren unter diesem Beitrag.

Evtl. werde ich eure Beispiele anonymisiert unter ausschließlicher Nennung der Branche (falls bekannt) in Vorträgen, Diskussion und weiteren Arbeiten zu diesem Thema verwenden. Bitte schreibt ausdrücklich dazu, wenn ihr dies nicht wünscht.

Ich freue mich auf eure Beiträge, Zusendungen und wenn ihr diesen Artikel in euren Netzwerken teilt.

Ansible: Patch-Management für Red Hat Systeme

6 Antworten

Als Linux-Distribution für den Betrieb im Rechenzentrum fiel unsere Wahl vor einiger Zeit auf Red Hat Enterprise Linux. Zu meinen Aufgaben gehört es, ein Patch-Management für diese Systeme zu entwickeln, welches die folgenden Anforderungen erfüllt:

  1. Die zu aktualisierenden Hosts werden in Gruppen im Ansible Inventory verwaltet. Eine Gruppe entspricht dabei einer Stage/Phase für das Patch-Management.
  2. An definierten Stichtagen sollen automatisiert fehlende Sicherheitsaktualisierungen auf den Systemen in den verschiedenen Stages/Phasen eingespielt werden können.
  3. Dabei sollen ausschließlich Pakete aktualisiert werden, für die Red Hat Security Advisory veröffentlicht wurden.
  4. Wenn Pakete aktualisiert wurden, soll der Host anschließend neugestartet werden.

Ich habe mich entschieden, diese Anforderungen durch die Verwendung von Ansible zu erfüllen. Wem Ansible noch kein Begriff ist, möge einen Blick in die Quellen am Ende des Artikels werfen.[1. Ansible – IT-Automation für Jedermann] [2. Ansible Documentation {en}] [3. Linux-Benutzerkonten mit Ansible verwalten] [4. Das Modul yum_repository] [5. Die Module copy und cron]

Mit den Anregungen meines Arbeitskollegen habe ich dazu das folgende Playbook erstellt, welches die Rolle rhel-patchmanagement auf allen Hosts mit einem Red Hat Betriebssystem ausführt:

---
- hosts: all

  tasks:
    - name: Group by OS
      group_by: key=os_{{ ansible_distribution }}
      changed_when: False

- hosts: os_RedHat
  roles:
    - rhel-patchmanagement

Die Rolle rhel-patchmanagement besteht aus den beiden folgenden Dateien:

  • roles/patch_rhel/tasks/main.yml
  • roles/patch_rhel/vars/main.yml

roles/patch_rhel/vars/main.yml:

---
rhsa_to_install: RHSA-2016:1626,RHSA-2016:1628,RHSA-2016:1633

Obiges Listing gibt ein kurzes Beispiel, wie die Red Hat Security Advisory (RHSA) Nummern einer Variablen zugewiesen werden können. Die Variable rhsa_to_install wird dann in der Task-Datei verwendet.

roles/patch_rhel/tasks/main.yml:

---
  - name: Install Red Hat Security Advisory (RHSA)
    command: yum -y update-minimal --advisory {{ rhsa_to_install }}
    register: yum_output
  - debug: var=yum_output

  - name: Reboot Host if packages were updated
    shell: sleep 2 && shutdown -r now "Ansible updates triggered"
    async: 1
    poll: 0
    ignore_errors: true
    when: ('"Complete!" in "{{ yum_output.stdout_lines[-1] }}"') or
          ('"Komplett!" in "{{ yum_output.stdout_lines[-1] }}"')

  - name: waiting for access server
    local_action: wait_for
      host={{ inventory_hostname }}
      state=started
      port=22
      delay=30
      timeout=300
      connect_timeout=15

Zuerst wird das Kommando zur Aktualisierung der zu den angegebenen RHSA gehörenden Pakete auf den Hosts ausgeführt. Dabei wird die Ausgabe des Kommandos yum auf den Hosts der Variable yum_output zugewiesen.[6. Registered Variables] Diese Variable wird im nächsten Schritt ausgewertet, um zu ermitteln, ob Pakete aktualisiert wurden. Ist dies der Fall, wird der Host neugestartet.

Erklärung: Wurden Pakete aktualisiert, steht in der letzten Zeile der YUM-Ausgabe der Ausdruck „Complete!“. "{{ yum_output.stdout_lines[-1] }}" dereferenziert die Variable und liefert die Ausgabe des YUM-Kommandos als Liste zurück. Dabei wird in diesem Fall auf das letzte Element der Liste zugegriffen. Enthält diese Zeile den genannten Ausdruck, wird der Host neugestartet. Hinweis: Die zweite Zeile der when-Bedingung aus dem oberen Listing dient der Behandlung einer deutschsprachigen Ausgabe. In diesem Fall wird das Schlüsselwort „Komplett!“ ausgegeben und in der Variable gespeichert.

Der letzte Task wartet 30 Sekunden ab, um dem Host Zeit für den Neustart zu geben und prüft, ob eine Verbindung hergestellt werden kann. Damit soll sichergestellt werden, dass der Host nach dem Neustart wieder korrekt hochfährt.

Damit sind die Anforderungen aus Punkt 2 und 3 erfüllt. Um auch noch die Anforderung aus Punkt 1 zu erfüllen, setze ich folgendes Wrapper-Skript ein, welches das Playbook zu den definierten Stichtagen ausführen soll:

#!/bin/sh

DOM=`date +%d`
DOW=`date +%w`
LOG="/var/log/ansible/patch_run_`date +%Y-%m-%d`.log"
SETUP_LOG="/var/log/ansible/setup_patch_run_`date +%Y-%m-%d`.log"
SSH_KEY="/pfad/zum/ssh-key"
PLAYBOOK="/data/ansible/patch_rhel.yml"
CREATEVARS="/pfad/zu/roles/rhel-patchmanagement/create_vars.sh"

# Run Patch-Management ad-hoc in the specified phase.
# Example: './run_rhel_patch_mgmt.sh NOW rhel-patch-phase1'
if [ "${1}" = "NOW" ] && [ -n "${2}" ]
then
  ansible-playbook $PLAYBOOK --private-key=$SSH_KEY --limit="${2}" >>$LOG 2>&1
  exit
fi

if [ "${1}" = "NOW" ] && [ -z "${2}" ]
then
  echo "ERROR: Second argument is missing."
  echo "Example: './run_rhel_patch_mgmt.sh NOW rhel-patch-phase1'"
  exit
fi

# Setup the next patchcycle
if [ "$DOW" = "2" ] && [ "$DOM" -gt 0 ] && [ "$DOM" -lt 8 ]
then
    $CREATEVARS > $SETUP_LOG 2>&1
fi

# Patchcycle of the rhel-patch-phase1 on the second Tuesday of a month
if [ "$DOW" = "2" ] && [ "$DOM" -gt 7 ] && [ "$DOM" -lt 15 ]
then
    ansible-playbook $PLAYBOOK --private-key=$SSH_KEY --limit=rhel-patch-phase1 > $LOG 2>&1
fi

# Patchcycle of the rhel-patch-phase2 on the third Tuesday of a month
if [ "$DOW" = "2" ] && [ "$DOM" -gt 14 ] && [ "$DOM" -lt 22 ]
then
    ansible-playbook $PLAYBOOK --private-key=$SSH_KEY --limit=rhel-patch-phase2 > $LOG 2>&1
fi

# Patchcycle of the rhel-patch-phase3 on the fourth Tuesday of a month
if [ "$DOW" = "2" ] && [ "$DOM" -gt 21 ] && [ "$DOM" -lt 29 ]
then
    ansible-playbook $PLAYBOOK --private-key=$SSH_KEY --limit=rhel-patch-phase3 > $LOG 2>&1
fi

# Patchcycle of the rhel-patch-phase4 on the fourth Wednesday of a month
if [ "$DOW" = "3" ] && [ "$DOM" -gt 21 ] && [ "$DOM" -lt 30 ]
then
    ansible-playbook $PLAYBOOK --private-key=$SSH_KEY --limit=rhel-patch-phase4 > $LOG 2>&1
fi

Mit diesem Wrapper-Skript möchte ich dafür sorgen, dass an jedem 2. Dienstag im Monat die RSHA-Aktualisierungen auf den Hosts in der rhel-patch-phase1, jeden 3. Dienstag in der rhel-patch-phase2, jeden 4. Dienstag in der rhel-patch-phase3 und jeden 4. Mittwoch in rhel-patch-phase4 installiert werden.

So kann sichergestellt werden, dass die Informationen aus den RHSA alle Hosts erreichen. Gleichzeitig wird den Betreibern der Hosts die Gelegegnheit gegeben, die Aktualisierungen bis zu den genannten Stichtagen selbst einzuspielen. Damit sollte ich auch an Punkt 1 einen Haken dran machen können.

Die Ansible-Rolle und dazugehörende Skripte und Beispiel-Dateien findet ihr auf:

Fragen zur Anwendung, Konfiguration und Nutzung des RHEL-Patchmanagements könnt ihr gerne auf GitHub oder hier in den Kommentaren stellen.

Aktualisiert am: 07.09.2018