REALTECH AG
REALity for Customers<br />
<br />Consulting

Handlungszwang

Governance und Compliance in IT-Systemen abbilden

Die Uhr tickt: im Jahr 2009 schauen sich Wirtschaftsprüfer die Umsetzung der Euro-SOX-Richtlinien im Unternehmen an. Höchste Zeit, entsprechende Projekte zu starten.  

Spätestens seit den spektakulären Verurteilungen der Enron- und Worldcom-Manager ist der Themenkomplex Governance, Risk-Management, Compliance (GRC) und Security ganz oben auf der Agenda aller an amerikanischen Börsen notierten Unternehmen. Die in Amerika zu Grunde liegenden Gesetze sind im Sarbanes Oxley Act zusammengefasst, dem in Europa seit dem 29. Juni 2006 die 8. EU-Richtlinie gegenübersteht. Diese Gesetze erweitern bereits bestehende Vorgaben aus den Aktien- beziehungsweise Handelsgesetzbüchern. Sie bilden sich innerhalb der Unternehmen in GRC-Prozessen ab und haben entsprechend auch Auswirkung auf die IT-Security.  

 

Zielrichtung

Aus dem Blickwinkel von GRC fokussieren sich die damit verbundenen Maßnahmen im Unternehmen auf die Regelung und Kontrolle der Einhaltung von Zugriffsrechten auf relevante Daten, sowie auf die Verhinderung von unberechtigter Manipulation. Diese Maßnahmen schließen in diesem Zusammenhang auch datenschutzrechtliche Belange mit ein.  

 

Einstieg mit einer Analyse

Am Anfang der Einführung von GRC-Maßnahmen stehen die Identifikation und Bewertung der möglichen Schwachstellen in Prozessen und technischen Systemen. Der Prozess wird zu einem Bestandteil des Risikomanagements. Grundlage für die Analyse ist der Plan der Unternehmensarchitektur, die alle zu betrachtenden Teile (Prozesse, Anwendungen, Komponenten, Systeme, Schnittstellen, etc.) enthält. Diese Teile finden sich im international anerkannten Standard CobiT zur Implementierung einer IT-Governance wieder.  

 

Abb. 1: Blickrichtung des CobiT Standards auf das Thema Governance

 

Oftmals sind den Unternehmen bereits Schwachstellen bekannt. Die Verantwortlichen scheuen jedoch die Investition in ein ausgefeiltes Risiko- und Security-Management.  

 

Festlegung von Standards

Auf die Analyse folgt die Festlegung von Sicherheitsniveaus und wie diese zu erreichen bzw. zu kontrollieren sind. Hierzu zählt auch die Definition von Referenzarchitekturen. An dieser Stelle knüpfen die Governance-Prozesse an Demand- und Portfoliomanagement sowie die Architektur an. Dort unterstützen sie die Einhaltung der Vorgaben durch Prüfpunkte, entsprechend dem Konzept von Quality Gates.  

 

Checklisten

Ein wichtiger Punkt bei der Einführung der Kontrollprozesse ist die Entwicklung von Checklisten, mit denen sich der aktuelle Security-Status der jeweiligen Systeme ermitteln lässt. Die Checklisten werden auch für das spätere Monitoring verwendet. REALTECH bietet hierzu beispielsweise mit den „SAP Security Audit Checklists“ eine zum Teil automatisierte Sammlung von relevanten Statusinformationen zur Vorbereitung von SOX- und FDA-Prüfungen.  

 

Folgemaßnahmen

Nach der Statusermittlung besteht natürlich die Frage, was zu tun ist, wenn ein Vorfall eingetreten ist. Es ist erforderlich im Vorfeld die entsprechenden Folgemaßnahmen festzulegen, zu dokumentieren und zu kommunizieren. Im Bereich Business Continuity Management werden Störungsfälle idealerweise regelmäßig trainiert. Dies erfolgt zum einen, um die Richtigkeit der Vorgehensweise zu überprüfen und zum anderen, um die Beteiligten mit dem Ablauf vertraut zu machen. Verzögerungen und falsche Reaktionen lassen sich so schon im Vorfeld verhindern.  

 

Review

Neben der regelmäßigen Kontrolle der festgelegten Standards ist in größeren Zeitabständen eine Überprüfung der Ausrichtung durch eine erneute Analyse erforderlich. Bei dieser Gelegenheit können Unternehmen die notwendigen Anpassungen an geänderte gesetzliche oder strategische Vorgaben vornehmen.  

 

Wer darf was?

Ein Kernbereich von GRC ist die Definition von Zugriffsrechten für Anwender und Administratoren. Super-User oder Technische User ohne eindeutige Personenzuordnung freuen jeden Auditor und sorgen auf der anderen Seite für Verdruss. Oft heißt es „Dann kann ich ja gar nichts mehr machen!“ Dies zeigt, dass es bereits hier meist an einem grundlegenden Berechtigungs- und Rollenkonzept mangelt. Einher geht dies mit einer Rechtevergabe auf Zuruf („Mir fehlt die Berechtigung für Transaktion XY“), was zwar kurzfristig funktioniert, langfristig aber zu einem undurchschaubaren Urwald an Einzelberechtigungen führt.  

 

Der Aufwand zur Erarbeitung eines Berechtigungs- und Rollenkonzepts übertrifft meist die Vorstellung der Betroffenen. Nur leider gilt hier das Motto: ganz oder gar nicht, da eine schrittweise Einführung nicht wirklich weiterhilft.  

 

In verteilten Applikationslandschaften, wie sie heutzutage eigentlich immer anzutreffen sind, benötigt ein Benutzer meist Zugriff auf eine ganze Reihe von Systemen. Bei der Benutzer- und Rechtepflege schafft ein Identity-Management System deutliche Erleichterung und Vereinfachung. Entsprechend ihrer Rollen werden den Anwendern auf den verschiedenen Systemen die jeweiligen Berechtigungen zentral zugewiesen.

 

Grundprinzipien der Rechtevergabe

In der Umsetzung der Maßnahmen sind drei Grundsätze maßgeblich. Das Prinzip der Least Privilege kann als Goldene Regel betrachtet werden. Konsequent angewandt erhält ein Mitarbeiter nur die Rechte am System, die er für seine Tätigkeit tatsächlich benötigt. Die zweite Regel ist die Funktionstrennung von Business und IT. Diese verbietet, dass ein IT-Mitarbeiter Berechtigungen erhält, mit denen er Geschäftsdaten ändern kann. Gleiches gilt für den Anwender aus dem Fachbereich, der keine IT-spezifischen Daten modifizieren darf.  

 

Als drittes Prinzip gilt die Funktionstrennung zur Vermeidung von Missbrauch, das sogenannte Vier-Augenprinzip. Die Beantragung und Genehmigung eines Vorgangs wird auf zwei Mitarbeiter verteilt und nimmt so Einzelpersonen die Möglichkeit, unkontrolliert kritische Vorgänge auszuführen.  

 

Unterstützung in der Umsetzung erhalten Organisationen durch ein Internes Kontrollsystem (IKS), wie zum Beispiel das GRC Access Control von SAP. Dort werden über Ausschlussregeln die Anforderungen umgesetzt und es wird eine Validierung vorhandener Zugriffsberechtigungen eines Benutzers nach Aufgabenbereichen durchgeführt. Auswertungen schaffen einen sofortigen Überblick über die noch vorhandenen Konflikte und zeigen, an welchen Stellen entsprechende Kontrollpunkte vorhanden sein müssen.  

 

Changemanagement - was wurde wann von wem geändert?

Die Dokumentation inklusive der Nachvollziehbarkeit von Änderungen gehört zu den Kernelementen der Vorgaben für Unternehmen. Innerhalb der Applikationen oder Services wird dies durch das Fortschreiben von Änderungsbelegen typischerweise im Standard abgedeckt. Außerhalb der Applikation ist dies in der IT im Rahmen der ITIL-Prozesse durch das Changemanagement sicherzustellen.  

 

Im Zuge der Einführung einer service-orientierten Architektur (SOA) muss hier der Agilität in der Gestaltung der Prozesse eine entsprechende Effizienz im Dokumentationsprozess zur Seite gestellt werden. Die Herausforderung besteht in der Koppelung von Protokollierungsmethoden für Änderungen einzelner Software-Hersteller. SAP bietet mit dem SAP Solution Manager eine zentrale Management-Lösung für ihre Systemlandschaft, die sich mit einer externen Management-Lösung wie REALTECHs theGuard! Service Management Center verbinden lässt. Das externe Management-System konsolidiert alle Störfälle und Änderungen bei gleichzeitiger Ausnutzung der hohen Integration der SAP-Komponenten in den SAP Solution Manager und den SAP Support.  

 

Ziel ist es, den Release-Stand und die Änderungshistorie aller an einem Prozess beteiligten Komponenten, hinab bis auf einzelne technische Komponenten wie Router und Switches, zu einem beliebigen Zeitpunkt rückverfolgen zu können. Dies wird durch eine weitere Integration von Configuration Management Daten mit dem Change-Management erreicht. Unabhängig von der Dokumentationspflicht schafft dies eine hohe Transparenz und eine Erleichterung für die Fehleranalyse. Wünschenswert ist hier die Darstellung mit Blick auf den oder die entsprechenden Geschäftsprozesse, was z.B. dem REALTECH Business Process Management möglich ist.            

 

Archivierung und Virtualisierung - was muss wie lange aufbewahrt werden?

Neben dem proaktiven Verhindern von Manipulationen ist die Dokumentations- und Nachweispflicht relevant. Die Archivierung und der Zugriff auf historische Daten stellen eine Herausforderung in Zeiten rasch wechselnder Technologien und Anwendungen dar. Hier bieten spezielle Archivierungssysteme oder die Virtualisierung von Systemen entsprechende plattform- und anwendungsunabhängige Lösungen.

In Bezug auf das Thema Security bietet die Virtualisierung von Systemen weitere Verbesserungen. Über eine Kapselung lassen sich Applikationen auf einzelne virtuelle Instanzen verteilen. So kann verhindert werden, dass kompromittierte Applikationen andere Applikationen auf der gleichen Instanz in Mitleidenschaft ziehen.  

 

Fazit

Zusammenfassend lässt sich feststellen, dass akuter Handlungsbedarf für einen Großteil der Unternehmen besteht, den kommenden gesetzlichen Anforderungen entsprechende Maßnahmen entgegen zu stellen. Unternehmen, die sich bereits nach SOX- oder FDA-Vorgaben richten mussten, sind typischerweise ausreichend gut aufgestellt. Für alle anderen ist rasches Handeln angesagt. Spätestens im Jahr 2009 werden Wirtschaftsprüfer die Erfüllung der Vorgaben verifizieren. Bis dahin kommt auch auf die IT-Abteilung einiges an Arbeit zu.  

 

Kontakt: customer-services@realtech.com