Unternehmen stehen vor der Herausforderung, IT-Prozesse an Compliance-Anforderungen auszurichten: Sie müssen gewährleisten, dass gesetzliche Vorschriften und Dokumentationspflichten eingehalten werden, die Integrität von Finanzberichten oder anderen kritischen Informationen sichergestellt ist und der Verlust sensibler Daten verhindert wird. Aus diesem Grund haben sich viele IT-Abteilungen und Sicherheitsverantwortliche zum Ziel gesetzt, Applikationen zu implementieren, mit denen sie die Einhaltung von Richtlinien sicherstellen können. Die entsprechenden Lösungen spielen daher im heutigen Wirtschaftsleben eine entscheidende Rolle.
Enttäuschende Resultate
Allerdings schlagen viele Lösungsansätze fehl, oder die Ergebnisse sind unbefriedigend. Oft stehen die Investitionen in Compliance-Maßnahmen in keinem Verhältnis zum erhofften Risiko-Management oder messbaren Kostenreduzierungen. Eine häufige Ursache: Compliance-Aufgaben sowie die damit verbundenen Maßnahmen werden als Projekte und nicht als nachhaltige Programme umgesetzt. Arbeitsintensive Vorgehensweisen belasten die ohnehin schon unter Druck stehende IT-Abteilung noch zusätzlich.
Beim Aufbau eines IT-Compliance-Programms messen viele Unternehmen zunächst die Richtlinienkonformität, indem sie schlicht überprüfen, ob die Kontrollmechanismen ordnungsgemäß implementiert sind und gepflegt werden. So werden etwa Kontrollmaßnahmen für die Identifizierung und die Authentifizierung (etwa Passwort-Anforderungen) bewertet. Leider gibt es bei diesem Ansatz mehrere Beschränkungen: Nicht alle Kontrollmaßnahmen sind gleich zu behandeln oder zu gewichten. Einige Kontrolldefizite bergen ein höheres Risiko als andere. So stellt ein Administrator-Account ohne Passwort auf einem Rechner eine größere Gefahr dar als ein ebenfalls nicht Passwort-geschütztes Konto mit eingeschränkten Benutzerrechten. Der "binäre” Ansatz (Ja oder Nein) führt bei der Bewertung von Kontrollmaßnahmen zu einer Verzerrung und zwingt das Management (oder die Administratoren) oft zu kostspieligen Kontrollmaßnahmen, die das Risiko jedoch nicht nennenswert reduzieren.
Nach der Systembedeutung bewerten
Auch sind nicht alle Systeme gleich zu behandeln oder zu gewichten. Unterschiedliche Systeme haben für das Unternehmen einen unterschiedlichen Wert. So ist der primäre Server, mit dem etwa das ERP-System unterstützt wird, wesentlich wichtiger als ein E-Mail-Backup-Server. Bei der Bewertung gilt es demnach, die jeweilige Bedeutung der Systeme für die Organisation zu berücksichtigen, damit das Management gezielt Ressourcen einsetzen kann, um die wichtigsten Elemente zu schützen.
Einige Kontrollmaßnahmen können für bestimmte Systeme ungeeignet sein. Oft werden in Richtlinien Kontrollmaßnahmen vorgegeben, die sich nicht ohne negative Folgen implementieren lassen. So sind etwa bei Service-Accounts, die zum Starten von Applikationen oder anderen Diensten auf einem Rechner benötigt werden, häufig gleich bleibende Passwörter erforderlich. In vielen Unternehmen gibt es jedoch eine Richtlinie, die - sinnvollerweise - vorschreibt, dass Passwörter von Benutzerkonten in regelmäßigen Abständen zu ändern sind. Weil eine solche Policy bei wichtigen Service-Accounts aus offensichtlichen Gründen ungeeignet ist, gilt es, Ausnahmeregelungen zu treffen.
Mit einem korrekt umgesetzten Risiko-Management lassen sich derartige Beschränkungen überwinden.
Compliance in drei Stufen
Für das kombinierte Compliance- und Risiko-Management empfiehlt sich eine dreistufige Vorgehensweise mit den Phasen "Assess” (Bewerten), "Operate” (Durchführen) und "Control” (Steuern). Dieser Ansatz basiert in großen Teilen auf den Prinzipien führender Frameworks. Dazu zählen das Enterprise Risk Management Integrated Framework von COSO, die Control Objectives for Information and Related Technology (Cobit) von Isaca und das Risk-Management-Framework des National Institute of Standards and Technology (NIST). Im Gegensatz zu diesen Rahmenwerken eignet sich das im Folgenden beschriebene Verfahren jedoch für nahezu jeden zu implementierenden Prozess.
Beim Assessment gilt es genau zu beachten, was geschützt werden muss und wie hoch die Investitionen in den Schutz sein sollen. Ebenso ist sicherzustellen, dass der Schutz und das Risiko-Management auf Richtlinien (Geschäftsregeln) basieren und nicht auf der Ad-hoc-Beurteilung durch IT-Administratoren und -Architekten. Auf Grundlage korrekter Bewertungen und fachlicher Prioritäten lassen sich anschließend gezielt Sicherheitsmaßnahmen treffen.
1. Assess
Bestandsaufnahme und Priorisierung der Systeme. Um die Systemumgebung evaluieren und die Einhaltung von Sicherheitsrichtlinien gewährleisten zu können, müssen Firmen zunächst eruieren, welche Systeme vorhanden und wie wichtig sie für die eigene Organisation sind. Einige Unternehmen nutzen Praktiken wie das Itil-Konfigurations-Management und die dazugehörige Configuration Management Database (CMDB), um ihre IT effektiv zu verwalten. Andere hingegen tun sich mit der Bestandsaufnahme ihrer Systeme und der Festlegung ihrer Bedeutung nach wie vor schwer.
Von der Compliance-Bewertung bis zu Basiskonfigurations-Standards. Ein wichtiges Element in der Assess-Phase von Compliance-Programmen ist die Beurteilung der Systeme auf Grundlage definierter Sicherheitsstandards. Aus diesem Grund nutzen viele Firmen Benchmarks, die auf allgemein akzeptierten Praktiken wie etwa der des Center for Internet Security basieren, die die Mindestanforderungen an die Sicherheitskonfiguration eines Systems definieren. Andere ergänzen ihre Security-Benchmarks durch operative Anforderungen - zum Beispiel Services, die zur Unterstützung einer Applikation laufen müssen, erforderliche Service-Accounts sowie Mindestvorgaben hinsichtlich der freien Speicherkapazität.
Schwachstellen oder manipulierte Systeme aufspüren. Ein weiterer wichtiger Aspekt ist die Identifizierung von Schwachstellen sowie Systemen, die bereits kompromittiert, beeinträchtigt oder infiziert sind. Im Allgemeinen schreiben Richtlinien den Schutz der Systeme vor bekannten Bugs und Bedrohungen vor. In der Regel sind Schwachstellen auf Konfigurationsfehler, fehlende Patches, den Betrieb gefährlicher oder unnötiger Dienste sowie schlecht geschützte Benutzer-Accounts zurückzuführen. Entsprechend muss eine Lösung, die gefährdete Systeme identifizieren soll, all diese Ursachen berücksichtigen.
2. Operate
Diese Phase umfasst die täglichen Überwachungs- und Administrationsaufgaben, die zur Einhaltung der Richtlinien erforderlich sind. Hierzu gehört, Serviceprobleme und Sicherheitsverstöße sowie unberechtigte oder potenziell schädigende Modifikationen zu erkennen und zu beheben. Ferner umfasst sie das Incident-Management. Bei effektiver Implementierung sind Sicherheitsaufgaben wie Incident-, Problem- und Change-Management gewöhnlich in die bestehenden Arbeitsabläufe und IT-Prozesse des Unternehmens integriert. Hierbei gilt es jedoch zu beachten, dass spezielle Vorkehrungen für sicherheitsbezogene Incidents getroffen werden, für die häufig Security-Fachkenntnisse (etwa Computerforensik) sowie eine ordnungsgemäße Beweissicherung erforderlich sind. Die "Operate"-Phase besteht aus drei Schritten:
Effiziente Analyse von Security-Logs und -Events. Viele IT-Sicherheitsvorschriften (etwa HIPAA Security Rule) und -standards (zum Beispiel Cobit) erfordern eine Überprüfung der System- oder Sicherheitsaktivitäten. Das bedeutet, dass Logs in regelmäßigen Abständen zu überprüfen sind, was nicht nur zeitaufwändig und mühsam sein kann. Erschwerend kommt hinzu, dass in vielen Organisationen die Konsolidierung und Archivierung der Logfiles vorgeschrieben sind, damit sie für spätere Nachprüfungen oder Ermittlungen zur Verfügung stehen. Daher kommt der effizienten Analyse von Security-Logs und -Events eine hohe Bedeutung zu.
Bedrohungen, Änderungen und Richtlinienverstöße erkennen. Ebenso bedeutend ist es, Bedrohungen, Änderungen und Richtlinienverstöße zu identifizieren. Das Spektrum reicht von automatisch ablaufenden Schadprogrammen wie Würmern und Viren über verärgerte Mitarbeiter bis hin zu Hackern und Kriminellen - und kann unerwartet auftreten. Vor allem unberechtigte Änderungen sowie Richtlinienverstöße gefährden die Sicherheit von Systemen und können sich direkt auf die Performance auswirken.
Security-Incidents managen. Neben versuchten und vollendeten Angriffen umfasst der Begriff "Security Incident" Verstöße gegen Richtlinien - etwa einen unberechtigten Zugriff auf Ressourcen sowie berechtigte beziehungsweise unberechtigte Änderungen an Sicherheits- und Kontrollmechanismen. Die Art des Incident bestimmt, auf welche Weise, wie schnell und mit welchem IT-Personal das Problem zu beheben ist. Darüber hinaus gibt es Sicherheitsvorfälle, die keine weiteren Maßnahmen erfordern, jedoch zu statistischen Zwecken oder für mögliche spätere Ermittlungen aufzuzeichnen sind.
3. Control
In dieser Phase stehen präventive oder korrektive Überwachungsmaßnahmen im Vordergrund, die das Risiko von Compliance- oder Datenschutzverletzungen sowie Beeinträchtigungen der Datenintegrität und -verfügbarkeit reduzieren sollen. Ziel eines Policy-Frameworks ist es, Kontrollmechanismen zu implementieren, die die Erfüllung von Pflichten und Vorschriften sowie das Management von Risiken beziehungsweise deren Management gewährleisten. Die Control-Phase ist die logische Fortsetzung der Assess-Phase, in der Schwachstellen in den Steuerungsmechanismen identifiziert, und der Operate-Phase, in der Änderungen und Umgehungen von Steuerungsmechanismen ermittelt werden.
Die Control-Aktivitäten müssen flexibel sein. Zwar wäre es wünschenswert, Steuerungsmechanismen stets auf der Grundlage von Richtlinien und Standards zu implementieren. Allerdings ist dies oft nicht möglich - wie sich an dem Beispiel von Service-Accounts, bei denen sich Passwörter häufig nicht ändern lassen, zeigt. Wo sich die von Richtlinien vorgesehenen Kontrollmechanismen nicht implementieren lassen, sind risikomindernde oder ausgleichende Steuerungsmechanismen erforderlich.
Durch eine sachgemäße und methodische Handhabung von Steuerungsmechanismen können Unternehmen ein Sicherheitsverhalten etablieren, das dem jeweiligen Grad ihrer Risikobereitschaft entspricht und gegenüber Auditoren auch dann verteidigt werden kann, wenn es von Richtlinien abweicht. Darüber hinaus wird die erste Verteidigungslinie - die Mitarbeiter des Unternehmens - gestärkt, während gleichzeitig die Kosten des Sicherheits-Managements durch weitgehende Standardisierung gesenkt werden. Ferner lassen sich Risiken oft ohne nennenswerte Änderungen oder Störungen der produktiven Systeme reduzieren. Die Control-Phase besteht aus drei Schritten:
Mitarbeiter einbeziehen und das Sicherheitsbewusstsein erhöhen. Interne und externe Mitarbeiter können eine wesentliche Ursache von Sicherheitsvorfällen sein. Letztere werden oft jedoch nicht böswillig, sondern durch Unwissenheit verursacht. Ein wesentlich größeres Problem stellen uninformierte IT-Administratoren und -Architekten sowie andere technische Mitarbeiter dar, die unmittelbar für die Gestaltung und Implementierung von Sicherheitskontrollen verantwortlich sind. Häufig gelingt es nicht, zu gewährleisten, dass diese wichtigen Mitarbeiter mit den eingeführten Sicherheitsstandards vertraut sind. So wissen viele Windows-Administratoren nicht, wie ein Windows-Server richtig abgesichert wird.
Konfigurationsstandards durchsetzen. Sicherheitskonfigurationsstandards helfen, das Risiko- und Sicherheitsverhalten einer Ressource zu definieren. Bei der Ermittlung, inwieweit die Systeme die Basissicherheitsstandards erfüllen (Assess-Phase), zeigen sich mitunter Abweichungen von Konfigurationsstandards. Auch in der Operate-Phase werden häufig Änderungen der Systemkonfiguration entdeckt, die dazu führen, dass das System nicht mehr den Richtlinien entspricht. Die Durchsetzung dieser Standards kann daher ein probates Mittel sein, um solchen Problemen vorzubauen.
Ausgleichende Steuerungsmechanismen implementieren. Häufig ist es nicht möglich, Systeme vollständig richtlinienkonform zu konfigurieren. Daher sollten sich ausgleichende Steuerungsmechanismen implementieren lassen, mit denen die Risiken zu kontrollieren sind. Die zuvor genannten Service-Accounts werden von Applikationen genutzt. Obwohl diese mitunter mit erheblichen Privilegien (insbesondere im Hinblick auf den Datenzugriff) ausgestattet sind, lassen sie sich nicht durch regelmäßiges Ändern der Passwörter schützen, da dies zu Störungen oder zum Absturz der Applikation führen würde. In solchen Fällen gilt es, einen ausgleichenden Steuerungsmechanismus zu implementieren, um die Risiken zu verringern.
Messung und Dokumentation
Eine kontinuierliche Verbesserung - das Ziel der meisten Compliance- und Risiko-Management-Programme - ist nur zu erzielen, wenn sich der Fortschritt messen lässt. Dazu gibt es unterschiedliche Möglichkeiten, wobei es stets darum geht, anschaulich darzustellen, dass gesetzliche Anforderungen und andere fachliche Vorgaben eingehalten werden, und den kontrollierten Umgang mit Risiken nachzuweisen.
Die Automatisierung von IT-Prozessen kann nicht nur helfen, die Kosten drastisch zu senken, sondern ermöglicht auch eine zuverlässige Erfüllung von Aufgaben, die beim Bereitstellen fachlicher Services immer wieder anfallen. Mit der Erweiterung der Prozessautomatisierung in den Security-Bereich werden IT- und Sicherheitsverantwortliche effizienter. So lassen sich die konsistente Einhaltung von Regeln und Richtlinien, umfassender Datenschutz sowie ein effizienteres Incident- und Event-Management sicherstellen, ohne die Mitarbeiterproduktivität zu beinträchtigen.
Darüber hinaus empfiehlt es sich, Security-Events eng in firmenweite Event- und Incident-Management-Prozesse zu integrieren, um auf Security-Aspekte zurückzuführende Probleme rascher beheben zu können. Auf dieser Basis können Sicherheitsteams Risiko- und Compliance-Abläufe definieren und sicherstellen, dass diese nicht nur von ihnen selbst, sondern auch von anderen Mitarbeitern befolgt werden. Dabei lassen sich Zuständigkeiten auf Grundlage definierter Rollen klar zuteilen. (kf)