Zunehmende Computerkriminalität zwingt gerade Kreditinstitute und Versicherungsunternehmen zu verstärkten Schatzmaßnahmen ihrer DV-Programme und Datenbestände. Nach rund einem Einsatzjahr berichtet Reinhart Hüsecken aus der Abteilung Systemprogrammierung der Landesbank Rheinland-Pfalz aus Mainz über seine Erfahrungen mit dem Sicherungssystem "Security Access Controller" (SAC) der Westinghouse Management Systems. Als wichtig empfindet der Autor, daß diese Systeme auch mit zusätzlichen organisatorischen Maßnahmen eingesetzt werden können.
Immer häufiger sind in letzter Zeit teilweise recht spektakuläre Berichte über "elektronische Einbrüche in Rechenzentren" und mutwillige Übergriffe in DV-Anwendungen zu lesen. Der Anlaß, bei der Landesbank Rheinland-Pfalz ein Sicherheitssystem für das Rechenzentrum zu installieren, war weniger spektakulär. Es ergab sich zum einen aus der Notwendigkeit der Trennung zweier verschiedener Anwendergruppen die den selben Rechnerkomplex benutzen, nämlich die Landesbank selbst und das Sparkassenrechenzentrum Mainz (SRM). Der zweite Anlaß war die Feststellung, daß TSO-Benutzer und die RJE-Stationen in der Sparkassen einen größeren Aktionskreis haben, als sie zur Abwicklung ihrer Arbeit brauchen. Da könnten schon einmal, wenn auch ohne Vorsatz, Übergriffe auf "empfindliche" Daten vorkommen.
Die Praxis seit der Installation des Sicherheitssystems Mitte 82 hat aber gezeigt, daß im Verhältnis zur Zahl der Dateizugriffe insgesamt nur sehr wenige unzulässige Zugriffe vorkommen - die meisten von ihnen gehen auf das Konto Unwissenheit über die Zugriffsregelung.
Jeder Job-Benutzer wird bei der Eingabe in das System auf mehrere Sicherheitskriterien überprüft:
1. Art und Weise des Eintritts in das System (zum Beispiel darf die Sparkasse XY nur über "Line 47" oder zentral über die Arbeitsvorbereitung (AV) in das System eingeben)
2. Entsprechend der Job-Klasse und Account-Nummer gegenüber den vorgegebenen Regelungen und Zuordnungen
3. Berechtigung des Jobs, um Dateien anlegen und löschen zu können
4. Berechtigung des Jobs, Dateien und Peripheriegeräte ansprechen zu können, mit der Unterscheidungsmöglichkeit nach lesendem und schreibendem Zugriff.
Die Diskussion um die Auswahl und Beschaffung des "richtigen" Systems für unseren Bedarf begann, nachdem wir festgestellt hatten, daß eine Eigenentwicklung aus verschiedenen Gründen nicht in Betracht kommt. Ausschlaggebend waren dabei folgende Faktoren: Der Zeitaufwand für eine Eigenentwicklung war angesichts der Dringlichkeit des Problems zu groß und Systemänderungen sollten mit SMP durchgeführt werden. Hinzu kam die Tatsache, daß der Entwickler eines solchen Systems auch dessen Lücken kennt.
Abgestufter Übergang
Die Marktanalyse der verfügbaren Produkte dauerte nicht sehr lange, da nur sehr wenige Produkte angeboten werden. Im Vordergrund der Auswahlkriterien standen zwei wichtige Forderungen:
1. Das System mußte alle unsere Anwenderforderungen abdecken. Eine dieser Forderungen war die Möglichkeit der "Notfall-Verarbeitung", wenn wir mit Teilen unserer Programme und Daten auf ein Back-up-RZ ausweichen müssen.
2. Das System mußte benutzerfreundlich, das heißt, einfach zu erlernen und einfach in der Handhabung sein, und sollte möglichst keinen zusätzlichen Arbeitsplatz erfordern.
Im ersten Punkt zeigte sich, daß einige Sicherungssysteme nicht geeignet sind, da sie Schutzfunktionen in die Dateien einbauen und damit eine Verarbeitung in anderen Systemumgebungen, die mit den Standard-Zugriffsfunktionen des Betriebssystems operieren, nicht möglich ist. Das System SAC dagegen legt alle Schutzmechanismen im Betriebssystem selbst ab.
Das System erlaubt durch entsprechende Parametersteuerung einen abgestuften Übergang vom "alten" in den "überwachten" Zustand der Verarbeitung. Das ist wichtig, da die Lernphase der Anwender umso länger dauert, je mehr Teilnehmer an einem Rechenzentrum hängen. Durch die Bildung verschiedener Anwendergruppen haben wir die Kommunikationsprobleme und die damit verbundenen Reibungsverluste am Anfang der SAC-Installation stark eingeschränkt.
Diese Flexibilität ist deshalb so wichtig, weil ein "scharf" geschaltetes Sicherheitssystem jeden Job, der eine unerlaubte Manipulation ausführen will, sofort "cancelt", das heißt abbricht. Gerade am Anfang, wenn die Anwender noch nicht in allen Einzelheiten wissen, zu welchen Dateien sie Zugriff haben, treten häufig "Verstöße" gegen das Sicherheitssystem auf. Das kann nicht zu empfindlichen Beeinträchtigungen des Arbeitsablaufs, sondern in Extremfällen bis zum völligen Stillstand des Rechenzentrums führen.
Die Implementierung von SAC verändert kritische Systemteile des MVS durch zusätzlichen Code: zum Beispiel OPEN-, CATALOG- und DASD-Management-Routinen. Dadurch ist SAC von allen Änderungen des Betriebssystems abhängig. Im Falle einer Fehlerbeseitigung durch PTFs (Program Temporary Fixes) muß SAC zumindest teilweise zuvor ausgebaut und nach dem Patchen der PTFs wieder installiert werden. Alle Änderungen werden jedoch mit SHP durchgeführt.
SAC unterstützt MVS SP, Version 1. Obwohl wir die Abhängigkeit eines Produkts von Betriebssystemänderungen und die damit verbundenen erhöhten Wartungsaufwendungen nicht als positives Qualifikationsmerkmal ansehen, hielten wir diese Aufwendungen bei SAC insgesamt für akzeptabel.
Die erlaubten Zugriffspfade werden für jeden Job exakt festgelegt alle Verstöße gegen diese Festlegung zeigt das System an, wobei eine abgestufte Reglementierung der Systemreaktionen eingebaut ist: Bei Verstößen kann der Job entweder abgebrochen werden, oder es werden Hinweise ausgegeben, daß hier ein Verstoß gegen die vereinbarten Zugriffspfade statt fand. Da jeder Datenzugriff wiederum nach fünf Zugriffsarten aufgeschlüsselt ist, sind insbesondere im Dialogbetrieb unbeabsichtigte Regelverletzungen recht häufig.
Bei der Auswertung der von SAC erstellten Zugriffsprotokolle kann der zuständige Bearbeiter jeden unerlaubten Datenzugriff genau verfolgen und rekonstruieren.
Wichtig erschien uns vor allem der Schutz gegen eine willkürliche Nutzung der Plattenspeicher. Mit SAC können wir verhindern, daß ein Benutzer Arbeitsdateien auf beliebigen Platten anlegen und dadurch Produktionsjobs, die diesen Platz dynamisch belegen wollen, zum Abbruch zwingen kann. Jeder Plattenstapel kann so gegen die Benutzung durch "fremde Jobs" geschützt werden.
Über eine Job-Klassifizierung können Test-User so abgeschottet werden, daß sie keine Produktionsläufe anstoßen können. Dies gilt auch dann, wenn die Namen der Produktionsjobs bekannt sind. Freilich muß hier eingeräumt werden, daß in unserem Falle die Sicherheit mit dem TSO-Passwort stark gekoppelt ist.
Insgesamt betrachtet läßt sich jede auch noch so fein gesponnene (...)cherheitsbestimmung mit SAC auf ein Anwendersystem übertragen. Durch die flexible Vorgehensweise kann die Einführung der Sicherheitsrestriktionen stufenweise erfolgen.
Anwender, die bereits eine Ordnung in den Dateinamen und eine Systematik in den Kennungen der Jobnamen haben, können innerhalb weniger Wochen einen vollständigen und wirkungsvollen Schutz des Systems erzielen.