Sicherheitsrichtlinien gelten auch für die Chefetage

Die IT-Abteilung eines metallverarbeitenden Produktionsbetriebes hat in Zusammenarbeit mit der Geschäftsführung eine neue Policy entworfen, die die IT-Sicherheit verbessern soll. Bisher gab es im Unternehmen keine eindeutigen Sicherheitsrichtlinien für die IT, alles wurde auf dem "kurzen Dienstweg" geregelt. In den letzten Jahren ist das Unternehmen jedoch deutlich gewachsen. Die Auftragsbücher sind voll und statt der ursprünglich 15 Büroangestellten zählt die Bürobelegschaft nun über 70 Mitarbeiter. Nach der neuen Policy sind Wechseldatenträger wie USB-Sticks ab sofort nicht mehr erlaubt und auch der Besuch bestimmter Webseiten wurde reglementiert. Eine entsprechende Software stellt die Einhaltung der Richtlinien sicher. Jeder Mitarbeiter soll nun die Policy unterzeichnen.
Nur der Leiter des Zentraleinkaufs, Herr Kerzel, der schon seit Gründung des Unternehmens mit an Bord ist, sieht das nicht ein. Er setzt den IT-Mitarbeiter, der ihm das Dokument gebracht hat, massiv unter Druck. Er fragt ihn, was er sich eigentlich einbilde, ihm Vorschriften machen zu wollen. Solche Regelungen seien nur für Leute da, die nicht vorsichtig genug sind und sich ständig auf irgendwelchen „komischen Webseiten“ herumtreiben. Und überhaupt sei in all den 17 Jahren, die er nun schon dabei ist, nie etwas passiert. Außerdem würde ihn die Policy bei der Arbeit behindern. So zieht der IT-Mitarbeiter zunächst unverrichteter Dinge wieder von dannen. Nachdem die Ausnahme für den leitenden Mitarbeiter nach tagelangem Tauziehen genehmigt ist (verbunden mit einem süffisanten „Na also, es geht doch - warum nicht gleich so?“), schlägt eine Schadsoftware im Netzwerk zu.

Die Quelle: ein privater USB-Stick, der an den Firmen-Laptop von Herrn Kerzel angeschlossen wurde. Glück im Unglück: dank einer Datensicherung sind kaum Daten verloren gegangen. Einige Dateien konnten jedoch nicht wiederhergestellt werden, darunter auch Angebotsdaten zu einer wichtigen Ausschreibung für ein großes städtisches Bauprojekt. Diese waren noch lokal auf dem PC von Herrn Kerzel gespeichert und noch nicht im täglichen Backup gesichert - und die Neuerstellung würde zu lange dauern, um noch rechtzeitig zum Abgabeschluss fertig zu werden. Ergebnis: ein potenzieller Auftrag mit hohem Volumen kommt nicht zustande.

Natürlich ist sich unser hypothetischer Abteilungsleiter darüber im Klaren, dass er nun einen Zwischenfall zu verantworten hat, der durch die Umsetzung der Policy in ihrer ursprünglichen Form vermieden worden wäre. Nun muss ein Schuldiger her: Die Sicherheitssoftware hat zu langsam reagiert, das EDV-Team hat nicht über die Risiken aufgeklärt…oft ist jede Begründung in solchen Fällen recht. Aber wie man es auch dreht und wendet: Hätte der Mitarbeiter die Policy wie alle anderen auch unterschrieben und befolgt, wäre dieser Vorfall entweder nie eingetreten oder hätte durch rechtzeitiges Eingreifen einer PolicyManagement-Lösung weit weniger dramatische Folgen gehabt.

Eine Policy steht und fällt mit der Art und Weise, wie sie von der Geschäftsleitung getragen wird. Wenn sich ein Geschäftsführer nicht an die Richtlinien gebunden fühlt, dann ist es nicht weiter verwunderlich, wenn auch die Mitarbeiter die Policy ignorieren oder nach eigenem Gutdünken auslegen. Egal, wie eine Sicherheitsrichtlinie aussehen mag: sie ist nie vom ersten Tag an perfekt und erfordert mit der Zeit Anpassungen an die Erfordernisse des Geschäftsbetriebes. Hier kommt es auf gute Zusammenarbeit auf allen Ebenen an. Stellt sich eine Maßnahme, die in der Policy festgeschrieben ist, als unwirksam oder als ernsthaftes Hindernis für den Geschäftsbetrieb heraus, dann ist eine Anpassung der Sicherheitsrichtlinie angebracht. Hierbei gilt es, mit Fingerspitzengefühl vorzugehen. Ein IT-Mitarbeiter empfindet eine Verzögerung von wenigen Sekunden vielleicht nicht als störend, aber das kann in einer anderen Abteilung schon ganz anders aussehen. Für einen Mitarbeiter in der Auftragsbearbeitung kann sich beispielsweise eine Verzögerung von zehn Sekunden negativ auf die Anzahl der bearbeiteten Aufträge pro Stunde auswirken und den Unterschied zwischen 20 und 30 Bearbeitungen bedeuten.

IT-Verantwortliche müssen auch diese Faktoren in ihre Pläne mit einbeziehen und sollten diese nicht als „prinzipbedingte Nörgelei“ abtun oder rundweg ignorieren.  Mitarbeiter sollten das Gefühl haben, dass sie in die Entwicklung neuer Prozesse aktiv eingebunden werden, statt diese nur „von oben herab“ verordnet zu bekommen. Gerade in solchen Fällen werden Anwender überaus erfinderisch und versuchen, Schutzmaßnahmen zu umgehen, um Arbeitsabläufe zu optimieren. Beispiel: eine neue Sicherheitsrichtlinie sieht Zutrittskontrollen für die Büroräume vor. So soll protokolliert werden, wer wann die Räume betritt. Ein Mitarbeiter muss vor dem Zutritt eine Karte vor ein Lesegerät halten und eine persönliche sechsstellige PIN eingeben. Dieser Prozess dauert in der Regel 7-10 Sekunden. Muss ein Mitarbeiter nur zweimal am Tag durch diese Tür, ist die Maßnahme sicher unproblematisch. Ein Mitarbeiter, der aber pro Stunde mehrmals durch diese Tür hindurchmuss, wird eventuell versuchen, die lästige Zutrittskontrolle mit einem Holzkeil zu umgehen, um nicht jedes Mal die Karte zücken und seine PIN eingeben zu müssen. Alternativ könnten Mitarbeiter auch in die Versuchung kommen, die eigene PIN auf „111111“ festzulegen, um die Eingabe zu beschleunigen. Außerdem: oft kommen einige Mitarbeiter morgens gemeinsam an und gehen auch gemeinsam durch die Tür, nachdem der erste sie geöffnet hat. Die Kontrolle behindert also einige Mitarbeiter und bringt nicht den gewünschten Effekt der Zutrittskontrolle, da nicht jeder Mitarbeiter immer seine Karte scannt und seine PIN eingibt. Hier ist also eine Anpassung der Richtlinie sinnvoll.

Wichtig ist, bei der Entwicklung einer Policy so wenig Kompromisse einzugehen wie möglich. Jeder Kompromiss, jede Ausnahme und jede Sonderregelung schwächt das Gesamtkonstrukt und muss daher gut begründet sein. Ein Kompromiss mag am Anfang nach einer guten Lösung aussehen, wird aber in vielen Fällen den eigentlichen Zweck der Regelung unterlaufen. So weiß manch einer aus leidvoller Erfahrung zu berichten, dass nichts länger hält als ein Provisorium.

Um eine wirksame Policy einzuführen, sind daher einige wesentliche Bestandteile notwendig:

1.        Die volle und aktive Unterstützung der Geschäftsleitung, die mit gutem Beispiel vorangeht.
2.        Eine umfassende Bedarfsanalyse - Hier können auch externe Dienstleister Unterstützung leisten wie etwa die G DATA Advanced Analytics.
3.        Aktives Einbeziehen der betroffenen Mitarbeiter in die Planungs- und Testphase
4.        Genug Spielraum, um nachträglich möglichst allgemeingültige Anpassungen vornehmen zu können – damit können IT-Verantwortliche ein undurchsichtiges Konstrukt aus Sonderregelungen und Ausnahmen vermeiden
5.        Einsatz einer geeigneten Policy Management-Lösung wie der G DATA EndpointProtection