Snort (update)

Vor zwei Jahren haben wir ein kritisches Dokument für den Umgang mit Snort in Unternehmen ins Netz gestellt. (Dort ist auch erläutert, wie Snort grundsätzlich funktioniert. Hier ist ein weiteres Dokument zur Funktionsweise von IDS-Systemen.)

Die Kritik bezog sich damals auf die großen Probleme, die es bereitet, wenn man das System in einer Betriebsvereinbarung regeln möchte. Auch wenn der Einsatz von Snort zum Erkennen von sicherheitsgefährdenden Aktivitäten gedacht ist, kann man mit der Software auch sensible Informationen über Mitarbeiterverhalten protokollieren, etwa die Benutzung von Chats, Internet-Radio oder den Aufruf von Webseiten. So kehrt sich denn auch der für die Systemadministration entscheidende Vorteil der vielfältigen und flexiblen Einsatzmöglichkeiten des Tools für Betriebs- und Personalräte ins Gegenteil um: Die Möglichkeiten der Software sind nur mit sehr hohem Spezialwissen zu durchschauen und zudem ist ihr Einsatz kaum kontrollierbar.

Die Probleme sind in den vergangenen Jahren leider nicht geringer geworden. In der Zwischenzeit hat sich der Einsatz von Intrusion-Detection-Systemen wie Snort in deutschen Unternehmen weiter durchgesetzt, auch das Bundesamt für Sicherheit in der Informationstechnik (BSI) empfiehlt seinen Einsatz und es dürfte immer schwerer werden, den Einsatz des Tools im eigenen Unternehmen rundweg abzulehnen.

Wir möchten an dieser Stelle die Eckpunkte einer Vereinbarung dokumentieren, die mit unserer Unterstützung in einem Medienunternehmen abgeschlossen worden ist. Aber bitte mit Vorsicht lesen: Erfahrungen mit der Regelung müssen erst noch gemacht werden, zudem entwickeln sich Snort und vergleichbare Systeme immer weiter und weiter. Wir raten daher dringend, die Regelungsideen nicht gedankenlos abzukupfern, sondern sich fachkundig zu machen, ob sie so im jeweiligen Unternehmen adäquat umsetzbar sind...

Das System dient dem Zweck der gezielten Erkennung von Angriffen und sonstigen Ursachen, die die Sicherheit und Leistungsfähigkeit des Netzwerks gefährden. Merke: Ziel ist nicht die Analsye von Mitarbeiterverhalten. Dieses liegt nur dann im Fokus einer Protokollierung, wenn damit sicherheitsgefährdende Aktivitäten verbunden sein sind.

Unterstrichen wird dieser Anspruch, indem ausdrücklich festgehalten wird, dass Signaturen, die Inhalte von Mails und Anlagen, Webseitenaufrufe, Chats, oder die Nutzungsdaten von Diensten und Software überprüfen, nicht eingesetzt werden dürfen, wenn mit ihnen keine Sicherheitsaspekte überprüft werden.

Der Netzwerkverkehr wird von Snort mit bekannten Angriffsmustern verglichen. Für Treffer wird der Umfang der Protokollierung festgehalten, u.a. werden auch Sender und Empfänger-Kennung gespeichert, die notwendig sind, um der Systemadministration nähere Analysen zu ermöglichen. Nach einem Monat werden die Daten gelöscht. Der Zugriff auf die Protokolldaten ist wegen der sensiblen Möglichkeiten nur drei namentlich benannten Administratoren erlaubt. Eine Änderung der Anlage ist nur einvernehmlich mit dem Betriebsrat zulässig.

Es folgen die Kernsätze der Vereinbarung:

"Die IDS-Administratoren überprüfen die Protokolldaten im Sinne der Zweckbestimmung dieser Vereinbarung. Die Analyse erfolgt ohne zielgerichteten Bezug auf einzelne Mitarbeiter oder Mitarbeitergruppen. Mitarbeiter werden in dieser Phase nicht von den Administratoren identifiziert."

Als nächstes werden Auffälligkeiten benannt, die die eine weitergehende personenbezogene Datenanalyse nach sich ziehen können, etwa wenn ein Rechner innerhalb einer kurzen Zeitspanne ein hohes Traffic-Volumen erzeugt, oder innerhalb einer kurzen Zeitspanne mit vielen Kommunikationspartnern verbunden ist.

Nur in diesen Fällen darf die Administration die betroffenen Mitarbeiter identifizieren und weitere Massnahmen ergreifen. Diese sind in einem Stufenverfahren geregelt:

1. Zunächst soll der Systemadministrator die Situation direkt mit dem betroffenen Mitarbeiter klären ohne dass weitere Stellen benachrichtigt werden. (Der Betriebsrat erhält hierüber jährlich einen anonymisierten Bericht.)

2. Kann eine Klärung nicht erfolgen oder liegt nach Ansicht des Administrators ein schwerwiegender sicherheitsrelevanter Verstoß vor, werden Betriebsrat und Arbeitgeber über den Fall informiert, allerdings ohne Namensnennung.

3. Erst, wenn Betriebsrat und Arbeitgeber in einer gemeinsamen Bewertung zu der Erkenntnis gelangen, dass eine weitere Datenanalyse gerechtfertigt ist, wird der Name des Mitarbeiters deanonymisiert. Dem Mitarbeiter wird umgehend die Möglichkeit gegeben, zu den Vorwürfen Stellung zu nehmen.

Vereinbart ist ferner ein Beweisverwertungsverbot, falls Daten unter Verstoß gegen diese Bestimmungen erhoben worden sind.

Fazit:

Die Vereinbarung baut darauf auf, dass die Mitarbeiter der Systemadministration die aufgestellten Grundsätze tatsächlich befolgen. Ist das der Fall, kann der Betriebsrat davon ausgehen, dass kleinere Unregelmäßigkeiten ohne viel Aufheben auf dem "kleinen Dienstweg" geregelt werden. Hegt die Administration indes einen hinreichenden Verdacht auf schwerwiegende sicherheitsgefährdende Aktivität durch Mitarbeiter, ist durch Anwendung des Stufenverfahrens eine faire Beteiligung von Betriebsrat und Mitarbeiter gewährleistet. Und für den Fall, das die Administration über die Stränge schlägt, ist als Sicherheitsnetz immer noch das Beweisverwertungsverbot für den Mitarbeiter aufgespannt.

Problematisch bleibt: Faktisch können Betriebs- oder Personalrat nicht überprüfen, ob sich die Administration tatsächlich an die Bestimmungen der Vereinbarung hält. (Ein Einwand, den man auch bei 95% aller anderen IT-Systeme anbringen kann.) Er kann allerdings im Stufenverfahren eine Deanonymisierung ggü. dem Arbeitgeber verhindern, er kann die Keule des Beweisverwertungsverbots schwingen und personell mitentscheiden, welche Administratoren Zugriff auf das System erhalten.

tse Hamburg

210 / 172