Projekt Phoenix. Kevin Behr

Читать онлайн.
Название Projekt Phoenix
Автор произведения Kevin Behr
Жанр Зарубежная деловая литература
Серия
Издательство Зарубежная деловая литература
Год выпуска 0
isbn 9783958751774



Скачать книгу

des Ernstes der Situation habe ich das Audit-Komitee schon mündlich darüber informiert.«

      Ich werde bleich. Ich verstehe zwar nicht den ganzen Audit-Jargon, weiß aber genug, um zu erkennen, dass Dicks Tag damit gelaufen ist und es möglicherweise weitere schlechte Nachrichten über uns in den Zeitungen geben wird.

      Zufrieden, dass ich den Ernst der Lage verstehe, nickt Nancy. »Tim, bitte stellen Sie uns Ihre Ergebnisse vor.«

      Er holt einen dicken Stapel getackerte Papiere hervor und gibt jedem von uns ein Exemplar. »Wir sind gerade mit unserem Audit der IT General Controls bei Parts Unlimited für die ganzen kritischen Finanzsysteme fertig geworden. Vier Leute haben acht Wochen gebraucht, um diese Zusammenfassung zu erstellen.«

      Meine Fresse. Ich hebe den dicken Stapel Papier hoch. Wo haben die einen Tacker gefunden, der das zusammenfasst?

      Es handelt sich um ein ausgedrucktes Excel-Sheet, jeweils mit 20 Zeilen pro Seite in winziger Acht-Punkt-Schrift. Die letzte Seite trägt die Nummer 189. Ungläubig sage ich: »Das müssen über 1000 Punkte sein!«

      »Leider ja«, antwortet Tim und kann dabei seine selbstgefällige Genugtuung nicht ganz verbergen. »Wir haben 952 IT-General-Control-Mängel gefunden, von denen 16 signifikante und 2 potenzielle wesentliche Schwachstellen sind. Das hat uns ganz offensichtlich alarmiert. Angesichts der Kürze der Zeit, die bis zum Beginn des externen Audits bleibt, brauchen wir Ihren Plan zur Nachbesserung so schnell wie möglich.«

      Wes hängt gebeugt über dem Tisch, eine Hand an seiner Stirn, mit der anderen blättert er die Seiten durch. »Was für ein verdammter Mist ist das denn?«

      Er hält auf einer Seite inne. »›Punkt 127. Unsichere Windows-Einstellung MAX_SYN_COOKIE‹? Soll das ein Witz sein? Falls Sie es noch nicht mitbekommen haben – wir müssen eine echte Firma am Laufen halten. Es tut mir leid, wenn das diesem Vollzeit-Audit-Geraffel in die Quere kommt.«

      Auf Wes kann man sich verlassen. Er sagt die Dinge, die die Leute denken, die aber schlau genug sind, sie nicht zu sagen.

      Nancy antwortet ernst: »Leider ist jetzt die Phase der Control Reviews und Tests vorbei. Wir brauchen von Ihnen den ›Management Response Letter‹. Sie müssen jeden dieser Punkte untersuchen, bestätigen und dann einen Plan zur Nachbesserung erstellen. Wir werden den dann begutachten und dem Audit-Komitee sowie dem Aufsichtsrat vorstellen. Normalerweise hätten Sie ein paar Monate Zeit dafür, Ihren Response Letter vorzubereiten und den Nachbesserungsplan umzusetzen«, fährt sie fort und hat dabei einen entschuldigenden Gesichtsausdruck. »Leider haben wir angesichts des Audit-Testplans dieses Mal nur drei Wochen, bevor die externen Auditoren eintreffen. Das ist bedauerlich. Wir werden darauf achten, IT in der nächsten Audit-Runde mehr Zeit einzuräumen. Aber dieses Mal brauchen wir Ihre Antwort bis ...«

      Sie schaut in ihren Kalender. »... Montag in einer Woche – spätestens. Meinen Sie, das ist möglich?«

      Oh nein.

      Das sind gerade einmal sechs Arbeitstage. Wir brauchen schon drei Tage, um das ganze Dokument überhaupt zu lesen.

      Unsere Auditoren, von denen ich bisher immer dachte, sie stünden für Gerechtigkeit und Objektivität, hauen uns jetzt in die Pfanne?

      Ich schnappe mir auch den dicken Stapel Papier und schaue mir ein paar Seiten an. Es gibt viele Einträge wie den, den Wes vorgelesen hat, aber andere verweisen auf unpassende Sicherheitseinstellungen, das Vorhandensein von Ghost-Accounts und Probleme mit dem Change-Management oder der Funktionstrennung.

      John blättert in seiner Mappe und sagt diensteifrig: »Bill, ich habe viele dieser Punkte schon bei Wes und Ihrem Vorgänger angesprochen. Sie haben den CIO überredet, einen Management Waiver abzuzeichnen, in dem steht, dass er das Risiko akzeptiert – und dann nichts getan. Wenn einige dieser Punkte jetzt unter den wiederkehrenden Problemen zu finden sind, glaube ich nicht, dass wir uns dieses Mal da rauswinden können.«

      Er wendet sich Nancy zu: »Bei den vorherigen Managern waren IT Controls ganz klar nicht im Fokus, aber ich bin zuversichtlich, dass Bill dem mehr Beachtung schenken wird, wenn sich die ganzen Probleme jetzt nicht mehr verstecken lassen.«

      Wes schaut John verächtlich an. Auch ich kann nicht glauben, dass sich John vor den Auditoren so produziert. In solchen Momenten frage ich mich, auf wessen Seite er steht.

      Unbeirrt von Wes und mir sagt John zu Nancy: »Meine Abteilung hat ein paar andere Punkte gerade gezogen, für die wir positiv erwähnt werden sollten. So haben wir zum Beispiel das Verschlüsseln der PII in unseren kritischen Finanzsystemen abgeschlossen, sodass wir zumindest dort aus dem Schneider sind.«

      Nancy sagt trocken: »Interessant. Das Vorhandensein von PII steht nicht im Fokus des SOX-404-Audits, daher wäre aus dieser Perspektive ein Konzentrieren auf die IT General Controls besser gewesen.«

      Moment. Johns dringende Verschlüsselungsänderung war überflüssig?

      Wenn das stimmt, müssen John und ich reden. Später.

      Ich sage langsam: »Nancy, ich weiß wirklich nicht, was wir bis Freitag liefern können. Wir stecken bis zum Hals in Arbeit mit dem Wiederherstellen der Systeme und kämpfen schon damit, den anstehenden Phoenix-Roll-out zu unterstützen. Welche dieser Punkte sind die, auf die wir auf jeden Fall reagieren sollten?«

      Nancy nickt Tim zu, der sagt: »Sicher. Der kritischste Punkt ist die potenzielle wesentliche Schwachstelle, die Sie auf Seite 7 finden. Dabei geht es darum, dass eine nicht genehmigte oder ungetestete Änderung an einer Anwendung für das Rechnungswesen in die produktive Umgebung gelangen kann. Das führt potenziell zu einer wesentlichen Schwachstelle –absichtlich oder ungewollt. Das Management hat keine Möglichkeit, solch eine Änderung zu erkennen oder gar zu verhindern.

      Zudem sind von Ihrer Gruppe keinerlei Protokolle der Change-Management-Meetings erstellt worden, die eigentlich laut Ihrer Richtlinien wöchentlich stattfinden sollten.«

      Ich versuche, mich nicht allzu deutlich zu winden, als ich daran denke, dass gestern keiner zum CAB-Meeting gekommen ist. Und während des Payroll-Problems waren wir so sehr auf Johns Verschlüsselungsänderung fokussiert, dass das SAN schließlich zerschossen war.

      Wenn wir schon solche Änderungen nicht mitbekommen, bezweifle ich, dass wir es erkennen würden, wenn jemand eine Sicherung abstellt, um eine kleine betrügerische Transaktion von vielleicht 100 Millionen Dollar durchzuführen.

      »Wirklich? Das ist unglaublich. Ich werde mir das genauer anschauen«, sage ich mit der hoffentlich passenden Menge an Überraschung und Empörung. Während ich so tue, als würde ich mir auf meinem Notizblock ein paar Details aufschreiben, und dabei zufällige Wörter umkreise und unterstreiche, nicke ich Tim zu, damit er fortfahren kann.

      »Als Nächstes haben wir eine Reihe von Servern gefunden, bei denen Entwickler administrativen Zugriff auf produktive Anwendungen und Datenbanken haben. Das verletzt die Funktionstrennung, mit der betrügerische Vorgänge verhindert werden sollen.«

      Ich schaue zu John hinüber. »Wirklich? Das ist ja ein Ding. Entwickler nehmen Änderungen an Anwendungen vor, ohne vorher eine Genehmigung dafür zu haben? Das klingt deutlich nach einem Sicherheitsrisiko. Was würde wohl passieren, wenn jemand einen Entwickler überredet, zum Beispiel Max, etwas Ungenehmigtes zu tun? Da müssen wir auf jeden Fall etwas gegen tun, oder, John?«

      John wird rot, sagt aber höflich: »Ja, natürlich. Ich stimme dem zu und helfe gerne mit.«

      Tim sagt: »Gut. Kommen wir nun zu den 16 signifikanten Punkten.«

      Eine halbe Stunde später leiert Tim immer noch Punkte herunter. Ich starre mürrisch auf die lange Liste. Die meisten Punkte haben die gleiche Qualität wie die langen, nutzlosen Berichte, die wir von der Information Security bekommen – ein weiterer Grund, warum John einen so schlechten Ruf hat.

      Das ist das unendliche Hamsterrad des Schmerzes: Die Information Security schickt Quartal für Quartal E-Mails mit langen Listen voll mit Empfehlungen zum sicheren Arbeiten.

      Als Tim endlich