Konfigurationen sicher verwalten Risiken bei Konfigurations­drifts und wie man sie beseitigt

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

FTAPI Software GmbH

Outpost24 GmbH

Eskenzi PR Limited

Tripwire

Konfigurationen haben die fatale Neigung, sich zu verändern. Es kommt zu Abweichungen vom sicheren Grundzustand, dem sogenannten Konfigurationsdrift. Gerade schnelle Lösungen, die auf den ersten Blick harmlos erscheinen, erweisen sich im Nachgang nicht selten als riskant. Best Practices geben Orientierungshilfe wie man dieser Art von Risiken entgegenwirken und den Reifegrad des Konfigurationsmanagements kontinuierlich steigern kann.

Die Arbeit von Cybersicherheitsexperten könnte deutlich einfacher sein. Dann nämlich, wenn Konfigurationen sich aus dem einmal erreichten sicheren Grundzustand heraus nicht mehr verändern würden. Im Laufe der Zeit aber weichen Konfigurationen zwangsläufig von diesem sicheren Zustand ab. Dann nämlich, wenn jemand im System Veränderungen vornimmt. Dieses Problem - bekannt als „Configuration Drift“ oder Konfigurationsdrift - bedeutet, je mehr Zeit seit dem letzten Scan vergangen ist, um so größer die Risiken hinsichtlich der potentiellen Angriffsfläche.

Welche Änderungen aber führen zu einem Konfigurationsdrift? Produktoptimierung ist ein kontinuierlicher Prozess. App-Entwickler modifizieren Apps und Infrastruktur in regelmäßigen Abständen zum Beispiel, um sie benutzerfreundlicher zu machen. Solche Änderungen können harmlos sein, können aber auch dazu führen, dass Systeme von der ursprünglich sicheren Grundlinie abweichen. Konfigurationssicherheit ist einer der grundlegenden Bausteine, wenn man eine wirksame Verteidigung gegen Cyberattacken aufbauen will. Aus strategischer Sicht, ist die sichere Konfiguration ein guter Ausgangspunkt (z.B. mit CIS-gehärteten Images). Sie dauerhaft zu pflegen, darin liegt in der Praxis die sehr viel größere Herausforderung.

Drei Beispiele für einen Konfigurationsdrift - und wie man ihn vermeidet

Anhand einiger konkreter Beispiele lässt sich veranschaulichen, wie leicht es zu einem Konfigurationsdrift kommt. Schnelle Lösungen, die auf den ersten Blick harmlos erscheinen, erweisen sich im Nachgang nicht selten als riskant. In anderen Fällen besteht die Schwierigkeit darin, den Prüfern Nachweise zu liefern, dass die vorgenommenen Änderungen annehmbar sind.

1. Einführen neuer Ports

Angenommen, es gibt einen innovativen Ansatz, die Benutzerfreundlichkeit einer App zu verbessern. Als einer der ersten Schritte wird dazu ein neuer Kommunikationsport für die Verwendung proprietärer Protokolle geöffnet. Das betriebliche Team löst ein Änderungsticket aus und stellt fest, dass die Anwendung einwandfrei funktioniert, sobald der neue Port auf Servern und Firewalls geöffnet ist. Sechs Monate später ist es Zeit für eine Sicherheitsüberprüfung. Die Auditoren verweisen auf das Problem des undokumentierten offenen Ports, weil er von der geltenden Sicherheitsrichtlinie abweicht. Die

Sicherheitsabteilung muss jetzt viel Zeit darauf verwenden, die fragliche Änderung zurückzuverfolgen und das damit verbundene Risiko richtig zu beurteilen. Selbst wenn es angesichts des Kontextes akzeptabel ist, dauert es zu lange bis die Prüfer ausreichende Informationen haben, um diese Feststellung überhaupt erst treffen zu können. Wenn Sicherheitsteams den Konfigurationsdrift nachverfolgen und Änderungen an der bekannten gehärteten Grundlinie dokumentieren, ist es um ein Vielfaches leichter, Prüfnachweise zu erbringen, ohne wertvolle Zeit zu vergeuden.

2. Erweiterung von Privilegien

Auch erweiterte Privilegien und Zugriffsberechtigungen sind ein Weg, wie IT-Experten unwissentlich jede Menge Risiken in ihre Systeme einschleusen. Wenn ein App-Entwickler sich wiederholt in einen einzelnen Server einloggt, will er vielleicht eine Abkürzung nehmen, indem er die Gruppe "Benutzer" zu den Benutzerrechte-Kategorien hinzufügt, was für mehr Komfort bei der Entwicklung sorgt. Auf diese Weise lassen sich die speziellen Admin-Zugangsdaten umgehen, die für eine Produktionsänderung erforderlich sind. Das „Ausleihen“ von Admin-Zugangsdaten aus einem Passwort-Tresor ist potenziell zeitaufwändig. Aus Sicht von Entwicklern ist die Aktion nicht einmal besonders riskant, weil es sich um einen einzelnen Server, und nicht um eine komplette Domain handelt. Trotzdem kann sich eine Erweiterung der Privilegien selbst für einen einzelnen Server in Bezug auf den Konfigurationsdrift als riskant erweisen. Unter Umständen ist das Risiko sogar deutlich höher als die möglichen Vorteile beim Benutzen der App. Die Sicherheitsverantwortlichen erfahren aber erst bei der nächsten manuellen Prüfung des Servers, was überhaupt passiert ist.

3. Cloud-Speicher

Die Verwendung eines Public Cloud-Anbieters setzt voraus, dass Sie sich voll und ganz darüber im Klaren sind, welche Sicherheitsverantwortlichkeiten bei Ihnen und welche im Zuständigkeitsbereich des Anbieters liegen. Amazon Web Services (AWS) blockiert standardmäßig den gesamten öffentlichen Zugriff, wenn ein Benutzer einen neuen Bucket erstellt. Das ist aus Sicherheitsgründen vorteilhaft. IT-Teams sehen darin aber auch ein Effizienzhindernis. Um bestimmte IT-Vorgänge zu optimieren, kann es verlockend sein, diese automatische Einstellung zu deaktivieren. Das kann die IT zum Zeitpunkt der Einrichtung tun oder bei einem temporären Anwendungsfall. Dann allerdings gerät die Aktion leicht in Vergessenheit, und die IT versäumt, wieder auf die AWS-Standardeinstellung zurückzusetzen. Das kann übrigens auch das Ergebnis eines Fehlers in einem automatisierten Skript sein.

Was auch immer der konkrete Grund ist, eine Änderung der Bucket-Zugriffseinstellungen kann genau die Art von Konfigurationsdrift hervorrufen, die Unternehmen besonders anfällig für Sicherheitsverletzungen macht. Sich beim Sicherheitskonfigurationsmanagement (SCM) an Best Practices zu orientieren, wirkt dieser Art von Risiken entgegen. Noch wichtiger als die Festlegung dieser Prozesse ist die kontinuierliche Überwachung auf Abweichungen von einem vorab genehmigten Konfigurationsstatus.

Reifegrade beim Konfigurationsmanagement

Es gibt eine Vielzahl von Anleitungen für sicheres Konfigurationsmanagement. Hier betrachten wir das Konfigurationsmanagement aus der Perspektive eines Reifegradmodells. Je nachdem, wo ein Sicherheitsprogramm steht, befindet sich das Unternehmen in punkto Konfigurationsmanagement im manuellen, Scan- oder Nahe-Echtzeit-Status.

1. Manuelle Konfigurationsüberwachung

Die manuelle Konfigurationsüberwachung ist extrem zeitaufwändig und führt tendenziell dazu, von einem regelmäßigen Scan-Rhythmus abzuweichen. Vor allem, wenn andere Prioritäten dringlicher zu sein scheinen. Systeme bleiben dann so lange unbeaufsichtigt, bis eine Kompromittierung erkannt wird oder es Zeit für eine routinemäßige Überprüfung wird. Compliance-Vorgaben bedeuten, oft nur eine Teilmenge dieser Systeme in eine Prüfung einzubeziehen. Ist das der Fall, versuchen Sicherheitsteams, die Anzahl der in die Prüfung einzubeziehenden Systeme zu begrenzen. Man erkennt folglich nur, dass bestimmte Systeme nicht regelkonform sind und reagiert entsprechend. Andere Systeme bleiben möglicherweise exponiert.

2. Lösungen, die auf Compliance hin scannen

Bei der nächsten Reifegradstufe des Konfigurationsmanagements verwendet man Lösungen, die in geplanten Intervallen automatisch auf Compliance scannen. Das ist nicht annähernd so mühsam wie das manuelle Scannen, erfordert aber immer noch ein hohes Maß an Interaktion. Man muss administrative Anmeldedaten für das Tool erstellen, mit dem gescannt werden soll, und man braucht jemanden, der die Scans bei Bedarf plant, ausführt und die Ergebnisse korrigiert. Dies geschieht in der Regel einmal im Monat oder einmal im Quartal, um dem Auditprozess zuvorzukommen.

Ähnlich wie bei der vorherigen Stufe kann man auch hier die Zahl der Systeme beschränken, die bei einem Prozess-Scan erfasst werden – nämlich innerhalb einer Compliance-Zone. Systeme außerhalb dieser Zone bleiben dann leicht auf der Strecke und werden eventuell nur dann überprüft, wenn sie kompromittiert werden oder eine Überprüfung erforderlich ist. Das Center for Internet Security (CIS) rät in seiner Critical Security Control #5, alle Systeme mit sicheren Konfigurationen auszustatten und diese laufend zu warten, wenn sich im Laufe der Zeit Änderungen ergeben.

3. Systemüberwachung in Nahe-Echtzeit

Auf der nächsten Stufe erfolgt der Scanvorgang nahezu in Echtzeit und nicht mehr nur in intermittierenden geplanten Scans. Dazu stellt man einen einfachen Agenten für die Systemüberwachung bereit, ohne dass Anmeldeinformationen oder Betriebssystem-Audits nötig werden. Der Agent muss auf allen Systemen eingesetzt werden. Dazu bettet man ihn in Images ein oder bindet ihn in Prozesse von automatisierten Tools wie Puppet oder Chef ein.

Wenn neuerliche Änderungen auftreten, die zu einem Konfigurationsdrift führen, leitet man einen entsprechenden Anpassungs- und Korrekturprozess ein. Ein Beispiel hierfür ist das automatische Erstellen von Event-Tickets oder Warnungen, die über das Security Incident and Event Management (SIEM) Tool an das Security Operations Center (SOC) gesendet werden. Organisationen wie die CIS bieten bewährte Richtlinien für Systemkonfigurationen, die eine Angriffsfläche aktiv reduzieren helfen, sogenannte „Benchmarks“.

CIS empfiehlt die folgenden Metriken zur genauen Messung der folgenden Daten zu benutzen:

• 1. Wie hoch ist der Prozentsatz an Unternehmenssystemen, die derzeit nicht mit der Sicherheitskonfiguration ausgestattet sind, die dem genehmigten Konfigurationsstandard des Unternehmens entspricht?

• 2. Wie hoch ist der Prozentsatz an Unternehmenssystemen, deren Sicherheitskonfiguration nicht mittels Applikationen zum technischen Konfigurationsmanagement durchgesetzt wird (nach Geschäftsbereichen)?

• 3. Wie hoch ist der Prozentsatz an Unternehmenssystemen, die nicht mit den neuesten verfügbaren Sicherheits-Patches für Betriebssystemsoftware aktualisiert wurden?

• 4. Wie hoch ist der Prozentsatz der Unternehmenssysteme, die nicht mit den neuesten verfügbaren Patches für die Anwendungssicherheit von Unternehmenssoftware aktualisiert wurden?

• 5. Wie hoch ist der Prozentsatz der Unternehmenssysteme, die nicht durch Software-Anwendungen geschützt sind, die die Dateiintegrität überprüfen?

• 6. Wie hoch ist der Prozentsatz an nicht autorisierten oder nicht dokumentierten Änderungen mit möglichen Auswirkungen auf den Sicherheitsstatus?

Einem Konfigurationsdrift zu verhindern ist ein fortwährender Prozess. Innerhalb dieses Prozesses geht es nicht zuletzt darum, den Reifegrad des Konfigurationsmanagements im Laufe der Zeit kontinuierlich zu erhöhen. Das trägt zu mehr Effektivität und Effizienz bei. Benchmarks von Organisationen wie der CIS bilden einen wichtigen Schwerpunkt bei der Zusammenarbeit von Sicherheitsfachleuten und betrieblichen Teams. Die hilft, einen Konfigurationsdrift zu vermeiden oder doch wenigstens schnellstmöglich zu beheben.

Über den Autor: Tim Erlin ist VP Produktmanagement & Strategie bei Tripwire.

(ID:47056953)