IT Audit von digatus
02.05.2019 | Carl-Friedrich Heintz | 6 min Lesezeit
merken
Stern Icon
Stern Icon
Briefumschlag Iconper E-Mail erinnern X Icon
Ladekreisel
Bitte geben Sie eine E-Mail Adresse ein!
Das Datum darf nicht in der Vergangenheit liegen!
Stern Icondiesen Artikel merken
Stern Icondieser Artikel ist auf der Merkliste

IT Audits: Auslöser, Vorgehen und Ergebnisse

grüne Trennlinie

Nun ist der Tag gekommen, das IT Audit steht an. Was erwartet uns, mit welchen Themenkomplexen werden wir konfrontiert, ist unsere Dokumentation ausreichend? Diese und viele ähnliche Fragestellungen sind uns von auditierten Einheiten berichtet worden, nachdem sie mit dem Thema Audit das erste Mal konfrontiert wurden. Nicht selten schwingt hier zu Beginn des Projekts auch ein gewisser Argwohn dem - meist externen - Audit-Team gegenüber mit, da gerade bei „Erst-Audits“ die Erfahrungen im Umgang mit dem Thema sehr variieren und dementsprechend auch die Reaktionen der betroffenen Personen. Und wer kann es ihnen verdenken? Schließlich wird ein Audit häufig dadurch ausgelöst, dass jemand den Status-Quo hinterfragt oder überprüfen lassen möchte. Doch ist dieser Argwohn gerechtfertigt?

In diesem Artikel beschäftigen wir uns mit den Auslösern für ein IT Audit, welche Vorgehensmöglichkeiten es gibt, welche Ergebnisse sich der Auftraggeber davon erwarten kann und wie die Zusammenarbeit der einzelnen Parteien möglichst ergebnisorientiert erfolgen kann.

Auslöser eines IT Audits

grüne Trennlinie

Audits haben manchmal etwas sehr Stringentes und werden damit für ungeübte Teilnehmer vielleicht als bedrohlich oder unfreundlich wahrgenommen. Unterfüttert wird diese Wahrnehmung auch gerne mit Szenen aus dem Fernsehen, in denen Heerscharen von Anwälten in eine Firma „einmarschieren“, um diese auf den Kopf zu stellen. Aber ist das wirklich immer so? Tatsächlich gibt es auch diese Art von Audit, üblicherweise in Zusammenhang mit Rechtsverstößen oder ähnlichen Vorwürfen, in denen der Wind durchaus etwas „rauer“ weht. Begriffe wie „Compliance Audit“ oder „Litigation Audit“ sind hier gerne genutzte Stichworte. Allerdings gilt auch in diesem Fall im ersten Schritt die Unschuldsvermutung, und gerade die Vorgehensweise in unseren Breitengraden hat nicht unbedingt etwas mit dem Vorgehen, welches Hollywood suggeriert, gemeinsam.

In vielen Fällen sind die Gründe für eine Auditierung jedoch wesentlich freundlicher, deswegen aber nicht weniger strukturiert und mit einem professionellen Vorgehen verbunden. Ein Unternehmen möchte wachsen und widmet sich der Fragestellung, ob die heutige IT Landschaft für dieses Wachstum überhaupt geeignet ist. Exemplarische Fragestellungen können dabei sein: Reichen die Kapazitäten im Rechenzentrum, ist die Infrastruktur ausreichend redundant ausgelegt, kann das Team die erweiterten Servicezeiten abdecken? Ein anderes Beispiel ist der Fall von besonderen Zertifizierungen, bei denen sich das Unternehmen der Befolgung bestimmter Prozessframeworks verpflichtet hat (z.B. ISO 27001 oder ISO 9001), und deren Einhaltung stichprobenartig im Rahmen der Rezertifizierung überprüft werden muss. Gerade in der Finanzbranche ist im Rahmen der sogenannten Baselrichtlinien das notwendige Risikomanagement[1] in großen Teilen an entsprechende IT Prozesse geknüpft, welche es regelmäßig zu überprüfen gilt. Manchmal geht es auch weniger um Art und Weise wie ein IT Betrieb erbracht wird, sondern eher um die Kostenstrukturen dahinter. Ein regelmäßiges „durchlüften“ älterer Verträge und Abgleich mit aktuellen Marktpreisen kann  deutliche Potentiale im Bereich der Kostenoptimierung aufdecken.

Vorgehen

grüne Trennlinie

Was auch immer der Auslöser für das (angeordnete) Audit sein mag, in fast jedem Fall ist das durchführende Audit-Team auf ein gutes Miteinander mit den Betroffenen aus, denn in einer kooperativen Zusammenarbeit erledigen sich die Aufgaben wesentlich schneller und effizienter. Bei digatus wenden wir zu diesem Zweck einen transparenten, auf aktuellen Branchenstandards[2] basierenden Ansatz an, der sich in bisherigen Projekten bewährt hat.

Kernelement ist eine klare Projektkommunikation zu Beginn des Audits, um die Erwartungshaltung des Auftraggebers sowie die Mitwirkungsaufgaben des zu auditierenden Bereichs allen beteiligten Personen klar zu vermitteln. Gerade in unserem ersten Fall „Compliance Audit“, mit dem Ziel vermutete Verstöße oder Fehlverhalten einzelner Personen oder Bereiche zu identifizieren, ist eine hohe Kooperation der betroffenen Personen erforderlich, damit die jeweiligen Nachweise in konstruktiver Zusammenarbeit identifiziert und gefunden werden. Kniffeliger wird es, wenn die Kooperation ausbleibt, die notwendigen Daten gelöscht oder gar durch physische Beschädigung versucht wurde diese zu vernichten. In einer solchen Situation kommen Spezialisten zum Einsatz, die in der Lage sind von beliebigen Datenträgern in mühevoller Kleinstarbeit einzelne Rohdaten Stück für Stück zu extrahieren und aus diesen Puzzleteilchen das „große Ganze“ zu rekonstruieren. Beobachtet man die entsprechenden Kollegen bei ihrer Arbeit, vermittelt dies oft mehr den Eindruck eines Forschungslabors als den eines IT Unternehmens und allerlei spezieller Werkzeuge und Tools kommt zum Einsatz. Interessierten Lesern sei an dieser Stelle der „Leitfaden IT-Forensik“[3] des Bundesamts für Sicherheit in der Informationstechnik (BSI) empfohlen, welcher einen guten Überblick gibt und mögliche Szenarien und Vorgehensmodelle beschreibt.

Anders sieht es aus, wenn es um den genannten Anlass Unternehmenswachstum oder die Überprüfung der Einhaltung von Prozessmodellen geht. Hierbei sind den Möglichkeiten grundsätzlich keine Grenzen gesetzt und die Art und der Umfang des Audits ist jeweils mit dem Auftraggeber und dessen Erwartungshaltung abzustimmen. Im einfachsten Fall werden die vorhandenen IT Kapazitäten überprüft, gemeinsam mit dem IT Team eine Planung über die erwarteten Zuwächse erstellt und diese mit den vorgefundenen Möglichkeiten verglichen. In einer tiefergehenden Variante kann dabei auch der Wartungszustand einer IT Landschaft überprüft werden, indem man die Versionsstände der eingesetzten Komponenten hinsichtlich ihrer Soft- und Firmware erhebt und etwaige Herstellerempfehlungen dagegenstellt. Bei erweiterter Vorgehensweise können zusätzlich vorhandene Support- und Wartungsverträge überprüft werden, als auch inwiefern die eingesetzten Produkte überhaupt noch durch den Hersteller supportet sind und z.B. eine Ersatzteilversorgung im Fehlerfall sichergestellt ist. Möchte man noch einen Schritt weiter gehen, können die im Fokus befindlichen Systeme und Prozesse durch „Real-World“ Tests einer echten Belastung ausgesetzt und ihr jeweiliges Verhalten dabei bewertet werden. Im Bereich Sicherheit (Firewalls, öffentliche Webservices etc.) kommen dabei sogenannte „Penetration-Tests“ (auch „Pen-Test“ genannt) zum Einsatz. Diese versuchen mit spezieller Software Sicherheitslücken oder unerwünschtes Verhalten durch Aus- oder Überlastung auf den betroffenen Systemen zu identifizieren. Ein Beispiel im Sicherheitsumfeld ist das „OWASP“ Projekt[4] zur Überprüfung von Applikationen, welches über eine Sammlung von Best-Practice Ansätzen und Tools verfügt. Nicht selten kommen bei diesem Vorgehen viele selbstentwickelte Tools des Auditors zum Einsatz, welche das jeweilige Spezial-Know-how darstellen.

Leicht anders gelagert verhält es sich im Bereich der Last-Tests von zum Beispiel Onlineshops oder ERP Systemen, bei denen durch das künstliche Erzeugen von Auslastung (Bestellungen, gleichzeitigen Besuchern, Produktionsvorgängen etc.) die jeweiligen Lastgrenzen ausgelotet werden sollen. Gerade im Bereich von Handelssystemen und Webshops kann zum Beispiel eine Ladezeit von mehr als drei Sekunden auf einer Bestellseite einen deutlichen zweistelligen Prozentsatz an Kunden, welche abspringen und ihren Kauf nicht abschließen, zur Folge haben und damit direkten Einfluss auf den Geschäftserfolg des Unternehmens[5]. Last but not least können im Rahmen solcher Auditierungsprojekte auch Fail-Over Szenarien oder die Reaktionsfähigkeit von Serviceprozessen etc. getestet werden, indem das Audit-Team in enger Abstimmung mit dem Auftraggeber unangekündigte aber gezielte Abschaltungen oder Entkopplung einzelner Komponenten vornimmt, vom einfachen Edge-Switch über den zentralen Core-Switch bis hin zum ERP System oder Domaincontroller. Hierbei können die jeweiligen IT Lösungen nun ihre Redundanz beweisen, oder im Falle von Serviceteams diese ihre Fähigkeit zur schnellen und zielgerichteten Identifizierung der richtigen Fehlerquelle, sowie deren Behebung.

Wesentlich theoretischer geht es bei der Überprüfung von Verträgen mit Dienstleistern zu, in denen das primäre Ziel ist, den heutigen Serviceumfang der Verträge mit dem tatsächlich geleisteten zu vergleichen, sowie mögliche Einsparungspotentiale durch den Vergleich mit aktuellen Marktpreisen zu erzielen.

Ergebnisse

grüne Trennlinie

Die Darstellung der Vorgehensweisen lässt es erahnen – so vielfältig wie die Vorgehensmodelle, können auch die Ergebnisse eines IT Audits sein. Um sich im Erwartungshorizont des Auftraggebers zu bewegen, ist es wichtig, zu Beginn die Anforderungen klar abzustimmen, um sicherzustellen, dass in der Vorgehensweise ein Modell gewählt wird, welches die notwendigen Daten für den gewünschten Ergebnisumfang ermöglicht. Üblicherweise werden die im Rahmen der Audits generierten Erkenntnisse bei einer Abschlusspräsentation vorgestellt, sowie für den Kunden ein Ergebnisdokument erstellt, welches die Anforderungen, die behandelten Komponenten, Systeme oder Prozesse als auch deren Ergebnisse beinhaltet. Da wir als digatus daran glauben, dass nur auf Probleme oder Handlungsbedürfnisse hinweisen nicht ausreichend ist und leider viel zu viele gute Auditergebnisse ohne Verbesserung wieder in Schubladen verschwinden, geben wir in diesem Kontext auch immer konkrete Handlungsempfehlungen zur Behebung der jeweils identifizierten Themen – auf Wunsch auch gerne unterstützt durch unser Team.

Autor Profilbild

Carl-Friedrich Heintz

grüne Trennlinie