IT-Security und Compliance

Fünf einfache Taktiken, um die Compliance-Prüfung zu überstehen
So bekommen Sie den Compliance-Prüfer so schnell wie möglich aus dem Büro

Von Max Waldherr, Pre-Sales Manager und IAM-Experte bei Dell Software

(05.09.14) - Compliance-Anforderungen bestehen überall und ohne Ausnahme, und werden immer anspruchsvoller. Zuvor mussten sich nur Banken, Aktiengesellschaften und die Medizinunternehmen Gedanken über Compliance machen. Heute jedoch müssen praktisch alle Organisationen – öffentliche und private, große und kleine, profitorientiert oder non-profit – in der ein oder anderen Art mit dem Druck der Gesetzgebung klarkommen. Egal, ob staatliche Compliance-Vorgaben wie Sarbanes-Oxley Act (SOX) bzw. HIPAA, von der Industrie gestellte Vorgaben wie PCI DSS oder selbst auferlegte Kontrollen wie die ISO 27002: die Buchstabensuppe an gültigen Vorgaben wächst, und die Erfüllung all dieser Vorgaben wird immer schwieriger.

Die logische Reaktion hierauf wäre, die Compliance oder Mangel an Compliance im Detail zu bewerten, oftmals mit Hilfe eines Prüfers, der alles prüft und dann etwas vielleicht Unerwartetes findet. Dem folgt oft eine kopflose und hektische Suche nach einer Lösung für den entsprechenden Verstoß, wobei die einzelnen Befunde teilweise nichts miteinander zu tun haben und verschiedene Insellösungen eingesetzt werden. Doch Compliance muss nicht kompliziert sein, und vor allem nicht reaktiv.

Hierzu gibt es fünf Taktiken, welche die Chancen, die nächste Prüfung erfolgreich zu bestehen, deutlich verbessern.

1. Nutzung eines einzelnen, starken Passworts
Inkonsistenz bei der Passwortstärke, die Tatsache, dass einzelne Nutzer mehrere (wenn nicht gar Dutzende) unterschiedliche Passwörter besitzen, und das vergebliche Bemühen, der IT den Aufwand zu ersparen, den Benutzern wieder Zugang zu verschaffen: all das trägt zu der schwierigen Situation mit den Passwörtern bei. Wie viele Passwörter haben Ihre Benutzer im Schnitt? Sind diese Passwörter alle gleich sicher? Können Sie ruhigen Gewissens sagen, dass keiner ihrer Benutzer Vorgehensweisen verwendet, die nicht der Compliance entsprechen, wie z.B. das Aufschreiben von Passwörtern, oder die Anwendung unzureichender Komplexitätsregeln, um die Passwörter nicht zu vergessen?

PCI DSS 8, ISO 27002 A.11, und HIPAA Title II erfordern starke Passwörter mit festgelegten Regeln für Komplexität, Änderungshäufigkeit, Wiederverwendung und Übertragung. Die meisten anderen Vorgaben erfordern ähnliche Vorgehensweisen. Jeder Aufwand, den man in die Vereinheitlichung der Passwortvorgaben, in die Eliminierung unsicherer Vorgehensweisen und in die Automatisierung des Passwortmanagements investiert, eliminiert wieder einen der Schlüsselbereiche, nach denen die Prüfer suchen.

Empfehlungen:
• >> Eliminierung so vieler Passwörter wie möglich durch Identitätsvereinheitlichung, Single Sign On und Synchronisierung.
• >> Alle Passwortvorgaben (systemunabhängig) basieren auf einem bewährten und compliance-konformen System
• >> Möglichkeit für die Benutzer zur sicheren Selbstverwaltung ihrer eigenen Passwörter, um diese nicht mehr aufschreiben zu müssen.

2. Starke Authentifizierung
Die schwache Authentifizierung – ob aufgrund der technischen Beschränkungen mancher Systeme oder aufgrund der höheren Anforderungen hochempfindlicher Systeme - ist eng mit den schwachen Passwortverfahren verwandt, und wird in Prüfungen häufig beanstandet. Dies lässt sich jedoch leicht beseitigen.

PCI DSS 8 und ISO 27002 A.11 erfordern eine Authentifizierung, bei der die Übertragung von Passwörtern so abgesichert werden muss, dass unberechtigte Dritte keinen Zugriff darauf erhalten (z.B. durch Ausspähen und Benutzen unverschlüsselter Passwörter). Darüber hinaus empfehlen praktisch alle Vorgaben den Einsatz zusätzlicher Sicherungsebenen für die Authentifizierung, bzw. "angemessene Authentifizierungsmethoden" für sensible Systeme, z.B. solche, die Kreditkartendaten (PCI) oder personenbezogene Daten enthalten (HIPAA und praktisch alle anderen auch).

Empfehlungen:
• >> Keine unverschlüsselte Übertragung von Passwörtern (wie z.B. bei früheren Unix-Systemen mit NIS) durch vereinheitlichte Authentifizierung mit besseren und bereits Compliance-konformen Quellen (z.B. Active Directory).
• >> Implementierung einer Mehr-Faktor-Authentifizierung, z.B. zusätzliche Einmalpasswörter (OTP) bei Systemen bzw. für Situationen, die eine stärkere Authentifizierung erfordern.

3. Deprovisioning ist wichtiger als Provisioning
Auch wenn die rechtzeitige und effiziente Einrichtung von Benutzerkonten (Provisioning) unerlässlich für Betrieb und Produktivität ist: den gesetzlichen Vorgaben ist das egal. PCI 8.5 und ISO 2002 A.8.3 (ebenso wie die entsprechenden Abschnitte in nahezu allen anderen Vorgaben) erfordern den unmittelbaren und vollständigen Widerruf des Zugangs für ausscheidende Mitarbeiter. Dieser Vorgang, der wahrscheinlich am häufigsten unzureichend durchgeführt wird, heißt Deprovisioning, und ist einer der Schwerpunkte der Compliance.

Wie lange dauert es, bis die gesamten Zugriffsrechte für einen ausscheidenden Mitarbeiter komplett entfernt und nicht nur deaktiviert sind? Wie viele ehemalige Mitarbeiter haben immer noch Benutzerkonten für Ihre Systeme? Wie viele "verwaiste" Benutzerkonten gibt es? Woher erhält man überhaupt diese Informationen?

Empfehlungen:
• >> Automatisiertes Provisioning und Deprovisioning, um den Zugang für Mitarbeiter, deren Status sich in einer Hauptdatenquelle ändert (z.B. im HR-System), sofort und vollständig zu löschen.
• >> Vereinheitlichung der Identitäten (ähnlich wie oben für die Passwörter beschrieben). So kann das Deprovisioning an weniger Orten stattfinden, und das Risiko verwaister Benutzerkonten sinkt.

4. Privilegierte Benutzerkonten nicht vergessen
Privilegierte Benutzerkonten – diejenigen mit Zugriff auf Systemebene – sind eine der Hauptquellen von Sicherheitslücken und auch einer der ersten Punkte, welche die Prüfer bei einer Compliance-Prüfung auf Schwachstellen abklopfen. Aufgrund der Tatsache, dass diese Benutzerkonten über sämtliche Berechtigungen verfügen, unabdingbar für Betrieb und Management des Systems sind, und nicht an eine individuelle Person gebunden sind (d.h. sie werden meist von allen Administratoren, die diese Rechte benötigen, gemeinsam genutzt), stellen diese privilegierten Benutzerkonten (sogenannte Super-User) das Hauptziel für schädliche Aktivitäten dar, welche die Vorgaben zu bekämpfen versuchen.

Sowohl PCI DSS 2, 6, 7, 8, 10 als auch die ISO 27002 A 10 und 11 beinhalten spezielle Anforderungen an den Umgang mit privilegierten Zugängen. Auch alle anderen Vorgaben richten sich an ähnliche Risiken mit nahezu identischen Anforderungen.

Empfehlungen:
• >> Keine gemeinsame Nutzung von Administratorpasswörtern und Login-Daten bzw. gemeinsame Nutzung mit Hilfe von Technologien, die Richtlinien für die Anforderung, Freigabe, Ausstellung, Rücknahme und das Zurücksetzen von Administratorpasswörtern erfordern.
• >> Delegation des administrativen Tagesgeschäfts zur Umsetzung eines MoProzents mit minimalen Berechtigungen. So erhalten die Administratoren nur die Rechte, die sie zur Ausübung ihrer Tätigkeit auch wirklich benötigen – nicht mehr und nicht weniger.
• >>Überwachung, was die Administratoren entweder mit ihrem eigenen Vollzugang oder denihnen übertragenen Rechten machen, um persönliche Verantwortung für zuvor anonyme Tätigkeiten herzustellen.
• >> Eventuell Einführung der Zwei-Faktor-Authentifizierung in die Managementstrategie für privilegierte Zugänge.

5. Keine personalisierten Zugriffsrechte
Eines der Hauptthemen bei allen Vorgaben ist das Konzept der Aufgabentrennung (Separation ofDuties, SoD). Bei SOX bedeutet dies, dass derjenige, der z.B. eine Ausgabe genehmigt, nicht dieselbe Person sein darf, die den Scheck ausstellt. Bei HIPAA bedeutet dies, dass die Person in der Rechnungsabteilung keinen Zugriff auf sensible Patientendaten haben darf, und dass der medizinische Betreuer nicht auf die Zahlungshistorie des Patienten zugreifen darf.

Die manuelle Umsetzung von SoD durch Bewertung der Bedürfnisse und Verantwortlichkeiten der einzelnen Benutzer und die Sicherstellung, dass es keine Konflikte bei den Zugriffsrechten der einzelnen Personen gibt, ist extrem aufwändig und fehleranfällig, insbesondere bei einem Jobwechsel oder wenn zeitweiser Zugriff benötigt wird. Wird der Zugriff jedoch freigegeben, und SoD auf Basis der Rolle eines Benutzers oder einer anderen Eigenschaft umgesetzt, z.B. Abteilung oder Standort, Mitgliedschaft in einer bestimmten Gruppe, eines bestimmten Attributs oder einer speziellen Rolle, so ist die effiziente Umsetzung von SoS durchaus möglich.

Empfehlungen:
• >> Vereinheitlichung der Rollen in der gesamten Organisation, so dass eine Rolle in einem System exakt derselben Rolle in allen anderen Systemen entspricht.
• >> Umfängliche und einheitliche Verknüpfung der Zugriffsrechte mit dem Provisioning, so dass eine einzige Maßnahme entsprechend den Zugang über alle Systeme hinweg gewährleistet.
• >> Gestaltung der Attestierung (bzw. der regelmäßigen Rezertifizierung der Zugriffsrechte) als intuitiven Prozess, bei dem diejenigen das Sagen haben, die wissen, wer worauf Zugriff haben sollte (Fachbereich), nicht nur diejenigen, die wissen, wie man Zugänge einrichtet und an die Daten kommt (IT).

Werden diese fünf simplen Bereiche beachtet, kann die Compliance viel einfacher und nachhaltiger hergestellt werden. Meine Empfehlung lautet: suchen Sie sich zunächst den Bereich aus, der in der nächsten Prüfung am wahrscheinlichsten zu Beanstandungen führt, und lösen Sie dieses Problem zuerst. Arbeiten Sie dann das nächste Problem ab, und so weiter. Durch das Lösen der grundlegenden Probleme wird das zeilenweise Suchen von Einzelproblemen vermieden, mit dem viele Organisationen zu kämpfen haben, wenn sich der Prüfer erst einmal angekündigt hat.

Mit diesen vier Schritten zur erfolgreichen Compliance-Prüfung

1. Weniger Komplexität durch Datenkonsolidierung
Wenn Ihre IT-Infrastruktur in Silos aufgebaut ist, und es für jede Plattform einen anderen Administrator gibt, muss man, wenn der Prüfer fragt, worauf ein bestimmter Mitarbeiter Zugriff hat, und wie er diesen Zugriff erhalten hat, jeden einzelnen Administrator bitten, eine entsprechende Abfrage durchzuführen. Auf wie viele Systeme bzw. Applikationen haben Sie aktuell Zugriff? Mir selbst fallen spontan 9 ein. Das würde bedeuten, dass 9 Administratoren ihre Arbeit stehen und liegen lassen und eine Suche durchführen müssen, um zu sehen, ob ich Zugriff habe, und dann ihre Ereignisprotokolle durchsuchen müssen, um festzustellen, wie ich diesen Zugriff erhalten habe. Ich weiß außerdem, dass es in meiner Organisation mehr als neun verschiedene Applikationen gibt, die die Administratoren dann ebenfalls durchsuchen müssten, um nachzuweisen, dass ich darauf eben keinen Zugriff habe. Das alles wäre viel einfacher, wenn diese Daten in einer durchsuchbaren Datenbank hinterlegt wären, weil dann nicht mehr 9 Leute oder mehr eine einzige Frage beantworten müssten.

2. So bekommen Sie den Prüfer so schnell wie möglich aus dem Büro
Ich spreche nicht vom Vortäuschen einer ansteckenden Krankheit und aus dem Gebäude stürmen – ich spreche davon, alle Daten leicht zugänglich und durchsuchbar zur Hand zu haben, so dass der Prüfer nicht warten muss, während Sie nach der buchstäblichen Nadel im Heuhaufen suchen. Wenn Ihre Identitätsdaten zentral und durchsuchbar konsolidiert sind, so dass der Prüfer die gewünschten Informationen mit Hilfe eines Reports schnell bekommt, ist die Prüfung auch schneller vorbei.

3. Eigener Zugang für den Prüfer zur Erzeugung eigener Reports
Angenommen, die ersten beiden Punkte wurden umgesetzt, die Identitäts- und Zugangsdaten sind zentral hinterlegt, und es besteht die Möglichkeit zur schnellen Suche nach der gewünschten Information. Warum nicht den Mittelsmann aus dem Spiel nehmen und dem Prüfer ein sicheres Portal zur Verfügung stellen, so dass er sich die gewünschten Informationen selbst besorgen kann? Wenn man die Möglichkeit schafft, dem Prüfer in einer Rolle Zugang zu gewähren, in der er lediglich Abfragen durchführen und Reports erzeugen kann, kann nichts passieren, und gleichzeitig zeigen Sie, dass Sie nichts zu verbergen haben.

4. Schlüpfen Sie in die Rolle des Prüfers und finden Sie Fehler, bevor der Prüfer sie findet
Herauszufinden, dass ein Compliance-Verstoß vorliegt, ist nie erfreulich. Kommt der Verstoß allerdings bei einer Prüfung ans Licht, ist das noch schlimmer, da man sich hierbei vor den Augen des Prüfers abmüht, eine Lösung für ein Versäumnis zu suchen. Warum erzeugen Sie nicht einfach mal einige Reports im Vorfeld? Wenn man zum Beispiel weiß, dass der Prüfer bald kommt, um die Einhaltung der PCI-Anforderungen durch die Organisation zu überprüfen, könnte man einige spezielle Reports zu den PCI-Anforderungen erzeugen und sehen, wo man steht. So ist man, wenn ein Fehler oder ein Verstoß festgestellt wird, in einer besseren Position und kann Maßnahmen ergreifen, bevor die Prüfung erfolgt. Sehen Sie es so: wenn etwas in der eigenen Abteilung schiefgelaufen ist – möchten Sie dann derjenige sein, der das Problem entdeckt und die Integrität besitzt, zu sagen "Ich habe das Problem entdeckt, und bereits Maßnahmen zur Behebung ergriffen", oder möchten Sie lieber in der Defensive sein und den Prüfer das Problem vor Ihnen, Ihrem Vorgesetzten und der Unternehmensführung ausbreiten lassen? Der Nachweis der Compliance macht keinen Spaß, und ich kenne auch keine Kinder, deren sehnlichster Berufswunsch es ist, Compliance-Prüfer zu werden – allerdings ist auch nicht alles so schlimm wie beispielsweise ein Zahnarztbesuch. Wenn Sie diese vier Schritte beachten, wird ihre nächste Prüfung zur schnellen, effizienten und befriedigenden Angelegenheit – sowohl für Sie als auch für den Prüfer.
(Dell Software: ra)

Dell: Kontakt und Steckbrief

Der Informationsanbieter hat seinen Kontakt leider noch nicht freigeschaltet.

Meldungen: Administration