Der zweite und dritte Tag des DSB-Kongresses:

Unklarheiten nur bei praxisfremden Randfragen

19.05.1978

DÜSSELDORF - Vor allem der zweite Tag des DSB-Kongresses '78 sollte jedem Datenschutzbeauftragten etwas bieten, gleich ob Jurist oder EDV-Mann, ob für große oder für kleinere Systeme zuständig. Nach einer Aufwärmung mit vier parallelen Vorträgen über organisatorische Fragen des BDSG und des DSB war das Plenum hellwach, um Prof. Dr. Bayer (TU München) über "Konsequenzen des BDSG für Datenvorbereitung und Programmierung" zuzuhören. Er zog diese Konsequenzen aus einer "absichtlich strengen Interpretation aus der Sicht des DV-Spezialisten". Er dachte einfach zu Ende: Was muß das BDSG gewollt haben, wenn es den Betroffenen wirklich schützen will? Welche Maßnahmen sind nach der Anlage zu ° 6 wirklich zur Datensicherung geeignet? Daß Datensicherung nur erforderlich ist, wenn der Aufwand in angemessenem Verhältnis zum erreichten Schutz steht, focht ihn nicht an: Soweit der Aufwand bei der Programmierung entsteht, ist er bei anständiger Organisation ohnehin weitestgehend erforderlich. Im übrigen werden die Maßnahmen billiger, wenn die Hersteller sie realisieren und anbieten.

Dipl.-Ing. Sehmitz von der IABG setzte das Thema mit Erfahrungen aus dem militärischen Bereich fort, wo häufig sehr viel mehr an Datensicherheit erforderlich ist. ("Die Wirksamkeit von Schutzmechanismen in DV-Systemen - heute und morgen.") Er demonstrierte, daß man nachträglich nicht viel tun könne; man müsse von vornherein aus den Sicherheitsbedürfnissen Sicherheitsanforderungen an die Konstruktion von EDV-Systemen ableiten. Einiges aus dem militärischen Bereich wird davon auch für den kommerziellen Bereich abfallen. Aber auch heute könne man schon einiges tun z. B. Assemblerprogrammierung über den Bildschirm verbieten (weil dabei zu leicht ein privilegierter Status erreicht werden könne). Er berichtete von sog tigerteams, die Schwachstellen aufsuchen und nachweisen:

- Was kann der berechtigte Benutzer tun, der seine Befugnisse mißbraucht?

- Was kann der Experte tun, der von außen in das System eindringen will (penetrator)?

In den USA werde das Problem Datensicherheit sehr viel ernsthafter und gründlicher auf allen Ebenen behandelt als in Deutschland.

Nachmittags traf man sich in Gruppen, um Erfahrungen über Einsatzmöglichkeiten der System-Software für technische Datensicherung bei Großsystemen auszutauschen. Zumindest bei einem sehr großen Anwender scheinen die Anwender die angebotenen Möglichkeiten noch nicht auszunutzen (s. oben: Wer seine Basis in den USA hat, muß eben schon eine ganze Menge parat haben).

BDSG und kleinere Systeme

Für Kleinrechner faßte Prof. Dr. Thome (Uni Heidelberg) die Situation mit Unterstützung von Herstellervertretern zusammen. Von den Gefahren her gesehen, sind kleine Systeme gute Systeme für Datenschutz und Datensicherung. Aber: Funktionentrennung und 4-Augen-Prinzip fallen als Sicherungsmaßnahmen fast aus. Die Hälfte der Anwender setze solche Systeme nebenbei ein, habe also gute Vorkenntnisse für Datenschutz. Für die andere Hälfte ergäben sich aber Probleme:

- die Rechner seien vielfach gar nicht programmierbar, so daß man nichts softwareunterstützt machen könne,

- viele Anwender übernähmen fertige Systeme, sie wären gar nicht in der Lage, programmtechnisch etwas zu unternehmen.

Es kommt also - und darin ging es vor allem auch in der Diskussion - darauf an, vieles durch organisatorische Maßnahmen zu lösen. Da die Gefahren hier meist nicht so groß sind, geht das auch. Abgesehen davon - wie Prof. Thome ausführte - , daß man erst einmal einiges organisatorisch tun kann, um seine Anwendungen überhaupt aus dem BDSG herauszubringen.

Die Programmierbarkeit nimmt zu: Die Hersteller stellen sich in ihren Produkten darauf ein (oder haben es sogar schon getan), was der anspruchsvolle Anwender benötigt. Das wird wohl dazu führen, daß die Hersteller dieses Niveau auch den Anwendern "verkaufen" werden, die das gar nicht benötigen.

Podiumsdiskussion siehe letzte Seite.