Sicherheit ist wichtig. Keine Frage, das bestätigt jeder. Es wäre ja auch schwer, dagegen zu argumentieren. Eine andere Geschichte ist es dann, Sicherheit auch tatsächlich herzustellen. Da kommen dann die Argumente wie „jetzt keine Zeit“, „dieses Jahr nicht im Budget“ usw.

…implementiert werden

Trotz der oben angeführten „Argumente“ muss Sicherheit grundsätzlich implementiert werden. Auch das wird niemand ernstlich bestreiten. Man denke in diesem Zusammenhang nur an das „KontraG“, was ja speziell das Management in die Pflicht nimmt – bis hin zur Haftung mit dem persönlichen Vermögen. Gut, alle diese Argumente wurden diskutiert, ein Projekt wurde aufgesetzt. Spezialisten haben die iSeries nach allen Regeln der Kunst abgesichert. Jetzt kann sich also das Management beruhigt zurücklehnen, denn es kann ja nichts passieren. Frommer Wunsch! Was ist, wenn doch etwas passiert? Wenn jemand im kritischen Moment alle Spools (Lieferscheine, Rechnungen…) gelöscht hat, wenn Daten über die eigenen Kunden bei der Konkurrenz auftauchen?

…überwacht werden

Was nützt es, die Sicherheitsstufe der iSeries auf 40 zu stellen, wenn dann irgendwann irgendjemand kommt, der „gute Gründe“ hat, sie wieder auf 30 zurück zu stellen? Wer überwacht, was Herr X von der Firma Y gemacht hat, der „gute Gründe“ hatte, das Passwort für QSECOFR zu bekommen? Wenn das System richtig eingestellt wurde (QaudLvl …), wovon auszugehen ist, wenn Fachleute die Sicherheit eingerichtet haben, dann protokolliert das System dies alles. Aber wer kann das Protokoll lesen? Da kommen bei einem gut beschäftigten System schnell mehrere Millionen an Datensätzen zusammen (fast 2 Mio. Sätze pro Tag haben wir schon gesehen). Es wird also eine Anwendung gebraucht, die regelmäßig die Systemprotokolle liest und auswertet. Dabei ist das reine Lesen noch das Einfachste. Entscheidend ist, dem Verantwortlichen auf einigen wenigen Seiten ein Protokoll mit den wirklich wichtigen Informationen zu präsentieren. Die Präsentation dieser Informationen sollte in verschiedener Form möglich sein. Dies beginnt bei dem „klassischen“ SpoolOut, sollte aber auch „modernere“ Formen – wie z.B. PDF-Dateien – umfassen. Diese können dann auf CD archiviert werden. Sie können dann mit entsprechenden Werkzeugen maschinell weiter bearbeitet werden („Was war eigentlich letztes Jahr am …“).

…protokolliert werden

Der Verantwortliche muss dann die notwendigen Schritte unternehmen. Im Normalfall sollte sich das nur darauf beschränken, dass abgezeichnet wird, dass eine Prüfung stattgefunden hat und dass alles in Ordnung war.

…dokumentiert werden

Nur mit den Protokollen der regelmäßigen Überprüfungen wird Sicherheit revisionsfähig. Es ist mit Sicherheit ein wesentlich besseres Gefühl für den Verantwortlichen, wenn er auf die Frage des Revisors „Äh, und wie kontrollieren Sie, dass nichts unbefugtes …“ einfach hinter sich in das Regal greifen kann und sagen: „Nun, wir haben da eine regelmäßige Auswertung laufen. Die wird kontrolliert und abgezeichnet …“ Okay, alle sind überzeugt, es kann also losgehen. Wir haben jetzt zwei Alternativen: selber machen oder kaufen. Selber machen, d.h. Projekt aufsetzen, Programmierer bestimmen und los. Da kommen schnell ein paar Manntage zusammen und ein paar Tausend Euro sind verbraten. Dann kommen Änderungswünsche. Warum also nicht kaufen?

Es gibt ein Tool

Aus den Anforderungen der Innenrevision der Deutschen Bank ist das Tool „Sicherheitsdokumentation“ entstanden, das alle wichtigen Systemwerte und ihre Änderungen dokumentiert und das Audit-Journal auswertet. Für die Audit-Journal-Auswertung können je Journal-Code die anzulistenden Informationen ausgewählt und Einschluss- sowie Ausschluss-Filter gesetzt werden. Das Tool bewährt sich nicht nur bei einer Deutschen Bank-Tochter, sondern auch bei Unternehmen unterschiedlicher Größe aus verschiedenen Branchen.

EDV-Beratung Hermann Wagner

D–64297 Darmstadt

Telefon (+49) 06151/49412-6

www.sicherheits-dokumentation.de

rmedv

D-69214 Eppelheim

Telefon (+49) 06221/76786-0