Manche Szenarien lassen IT-Mitarbeitern die Haare zu Berge stehen: Gelangen vertrauliche Informationen in die Hände Dritter, weil ein Angestellter unbedacht eine E-Mail weiterleitet, die nicht für fremde Augen bestimmt ist, kann der Schaden groß sein. Aber auch einzelnen Mitarbeitern drohen Gefahren, etwa wenn sie für eine Weile ihren Arbeitsplatz verlassen. Währenddessen könnte beispielsweise ein Kollege vom verwaisten PC aus eine beleidigende Nachricht an den Vorstand schicken. Die Liste der möglichen Sündenfälle ließe sich beliebig fortsetzen. Sicherheitskonzepte können solche Risiken zwar nicht beseitigen, aber immerhin begrenzen. Zum Beispiel, indem sie festlegen, welche Daten nach außen gegeben werden dürfen oder daß Mitarbeiter ihren PC auszuschalten haben, wenn sie für längere Zeit nicht vor Ort sind.
Trotz der Vorteile, die eine sinnvolle Sicherheits-Policy bietet, verfügen längst nicht alle Firmen über ein solches Regelwerk. Während deutsche Berater und Hersteller diesen Mangel beklagen, stellt John Pescatore, Research Director for Network Security bei der Gartner Group, amerikanischen Anwendern ein besseres Zeugnis aus: "Etwa 80 Prozent der Unternehmen haben eine Policy", faßt der Marktforscher seine Erfahrungen zusammen. Am weitesten verbreitet sind die Konzepte bei Banken, Versicherungen und staatlichen Einrichtungen. Allerdings schränkt er ein, nur bei der Hälfte dieser Firmen sei das Konzept zeitgemäß. Manche klammerten noch ganze Themenblöcke wie Client-Server oder Internet aus der Betrachtung aus.
Dabei ist ein Sicherheitskonzept, das nicht alle Bereiche wie Technik, Organisation oder Training berücksichtigt, so gut wie sinnlos, denn jede Kette ist nur so stark wie ihr schwächstes Glied. Es nutzt wenig, eine Festplatte zu haben, die vor unerlaubten Zugriffen über das Netz hervorragend geschützt ist, wenn sie sich von jedem Laien aus dem Rechner ausbauen läßt. Auch wenn eine Policy in der Breite alle Themen abdecken muß, sollte sie nicht zu stark in die Tiefe gehen. Es empfiehlt sich, nicht zu viele Details wie zum Beispiel Filterregeln in das Papier aufzunehmen, weil ansonsten alle paar Wochen Änderungen fällig wären.
Zuerst sollte laut Magnus Harlander, Geschäftsführer der Genua GmbH aus Kirchheim bei München, geklärt werden, welche Anforderungen an die Sicherheit zu stellen sind. Diese müssen nicht für alle Bereiche gleich sein. Zum Beispiel ist es sinnvoll, die Personalabteilung durch Vorkehrungen wie eine Firewall gegenüber dem normalen Netz abzuschotten, damit Gehälter anderer nicht ausspioniert werden können. Das führt zu der Frage, welche unterschiedlichen Sicherheitslevels oder -zonen im Netz existieren. Von besonderem Interesse ist, wie die Übergabepunkte gestaltet werden und welche Daten über diese Wege fließen.
Neben der Einteilung der Netzinfrastruktur ist außerdem eine Klassifizierung der Daten nötig. Im Klartext heißt das eine exakte Definition von streng geheimen Informationen einerseits und Daten ohne besonders vertraulichem Charakter andererseits. Das gilt sowohl für den externen wie auch für den internen Verkehr. Kritische Daten für die Administration sollten beispielsweise von den normalen Benutzerdaten getrennt gehalten werden. Weiterhin muß bestimmt werden, wie die Übergabe von Daten nach draußen geregelt ist. Es klingt zwar banal, aber etliche Unternehmen richten gut abgesicherte zentrale Internet-Zugänge ein, vergessen jedoch, zuvor genutzte Modems zu deaktivieren. Damit werden unliebsamen Gästen Tür und Tor geöffnet.
Eine Policy muß konkrete Angaben zur einzusetzenden Sicherheitstechnik enthalten, zum Beispiel zu Verschlüsselung und Authentisierung. Ebenso wichtig wie die Überprüfung der Zugangsberechtigung beim Einloggen ist jedoch die Frage, wer diese vergibt und pflegt. Häufig sammeln sich nämlich bei Benutzern im Laufe der Zeit eine Reihe von Berechtigungen an, die sie nicht mehr benötigen und somit nicht mehr haben dürften. Es gehört in der Regel zu den Aufgaben eines Administrators, die vergebenen Rechte in regelmäßigen Zeitabständen zu überprüfen und zu ändern. Aber auch der Endanwender steht in der Pflicht. Ein Katalog sollte deshalb genau klären, welche Rechte und Pflichten Administratoren und Benutzer haben.
Neben der Festlegung verschiedener Vertrauensstufen und technischer Regeln kommt der Definition organisatorischer Bedingungen eine ebenso große Rolle zu. Zum Beispiel sollte nicht jede x-beliebige Person Zutritt zum Unternehmen oder gar zum Rechenzentrum haben. Um eine Kontrolle der DV-Abteilung durch den Sicherheitsbeauftragten zu ermöglichen, erscheint es außerdem ratsam, wenn dieser nicht in derselben Abteilung angesiedelt ist. Weiterhin könnte man festlegen, bis zu welcher Hierarchieebene Zeitarbeitskräfte eingesetzt werden dürfen. Eine solche Vorsichtsmaßnahme unterstellt, daß deren Loyalität geringer ist als die der Festangestellten.
Trotz aller Sorgfalt beim Verfassen eines Konzeptes stehen immer wieder Änderungen ins Haus, zum Beispiel ein Software-Update oder die Migration zu einem anderen Produkt. Kleinere Veränderungen sollte die Policy abfedern. Doch das wird immer an Grenzen stoßen. Gut ist daher, wenn sich die Verantwortlichen vorher Gedanken machen, wie Modifikationen schnell und flexibel integriert werden können. Zum Beispiel muß definiert werden, wer überhaupt welche Änderungen umsetzen darf: der Administrator oder sein Vorgesetzter. Es dient der Qualitätssicherung, wenn dieser Modifikationen nur nach Rücksprache mit einem kompetenten Partner vornimmt, da sich sonst leicht Fehler einschleichen. Sie müssen zudem gut dokumentiert werden, damit sie nachvollziehbar und überprüfbar bleiben. Eine Policy ist außerdem auf Widersprüche zu prüfen.
Zur ständigen Überwachung der Sicherheitsstrategie lassen sich die Log-Dateien der einzelnen Systeme heranziehen, die alle Aktionen aufzeichnen. In diesem Zusammenhang ist zu regeln, wer Zugriff darauf hat, ob die Log-Dateien archiviert und/oder ausgewertet werden. Wenn ja, muß außerdem festgelegt werden, wie die Auswertung aussehen soll (siehe auch CW 45, Seite 37, "Sicherheits-Audits müssen häufig wiederholt werden").
Alle diese Maßnahmen dienen letztlich der Vorsorge. Oft wird jedoch vergessen, einen Notfallplan zu vereinbaren. Scheint ein System gefährdet, gibt es zwei mögliche Verhaltensweisen: Entweder den Angreifer weiter beobachten oder ihm den Zugang verwehren - notfalls durch Abschalten des Systems. In einer Policy muß daher geregelt werden, ob beispielsweise die Verfügbarkeit der Firewall eine höhere Priorität hat oder die Sicherheit der Systeme dahinter. "Das dient dem Schutz des Administrators", erläutert Harlander.
Ein Handicap bei der Umsetzung von Policies liegt im Aufwand begründet, weil sie sich nicht an einem Tag aus dem Boden stampfen lassen. Schon die Feststellung des Ist-Zustandes im Netz kann sehr schwierig sein. Eine Projektdauer von mehreren Monaten ist daher keine Seltenheit. Dem stimmt auch Pescatore von der Gartner Group zu: "Das dauert lange. Viele Beratungsfirmen verdienen eine Menge Geld damit, Policies im Schnellverfahren anzubieten. Doch die sind das Papier nicht wert, auf dem sie gedruckt sind." Laut Harlander unterscheiden sich die Konzepte verschiedener Firmen stark voneinander. Einige bevorzugen starre, umfangreiche Konzepte, anderen genügt ein formloserer Ansatz - je nach Firmenkultur. "Eine Policy muß nicht mehr als vier bis fünf Seiten haben, aber man braucht Muße und Geld, um sie zu erstellen", bestätigt er. Auch andere Hersteller empfehlen, lieber mit einem kleinen Konzept anzufangen und dieses gegebenenfalls zu erweitern.
Außerdem besteht ein grundsätzlicher Konflikt zwischen Sicherheit und Geschäftszielen sowie der Benutzerfreundlichkeit. Ein sicheres System ist umständlich zu bedienen. Zum Beispiel, wenn das Paßwort jede Woche geändert werden soll. Es gilt, die strengsten Sicherheitsauflagen zu finden, die das Geschäft nicht behindern. "Vor der Formulierung einer Policy muß klar sein, was auf jeden Fall noch zu funktionieren hat", warnt Harlander, um böse Überraschungen zu vermeiden. Eine Schwierigkeit stellen daher insbesondere zu restriktive Sicherheitsregeln dar. Sie führen dazu, daß die Benutzer sie umgehen. Pescatore nennt als Beispiel das Verbot, PCs und E-Mail privat zu nutzen.
Die beste Policy nützt aber nichts, wenn die Akzeptanz der Benutzer oder der Unternehmensführung fehlt. Deshalb ist es wichtig, das Konzept von möglichst hochrangigen Mitarbeitern absegnen zu lassen. Ansonsten besteht die Gefahr einer Torpedierung durch das Topmanagement. Um den Mitarbeitern für die Bedeutung von Sicherheit die Augen zu öffnen, nehmen Schulungen eine zentrale Stellung ein. Am wirkungsvollsten ist es, den Teilnehmern an konkreten Beispielen zu zeigen, welche Gefahren und Konsequenzen drohen. Wer einmal eine gefälschte E-Mail bekommen hat, wird Sicherheitsfragen mit einer neuen Sensibilität begegnen. Da viele Policies Fragen behandeln, bei denen der Betriebsrat ein Mitspracherecht hat, gilt es, dieses Gremium frühzeitig einzubinden.
Manche Szenarien lassen IT-Mitarbeitern die Haare zu Berge stehen: Gelangen vertrauliche Informationen in die Hände Dritter, weil ein Angestellter unbedacht eine E-Mail weiterleitet, die nicht für fremde Augen bestimmt ist, kann der Schaden groß sein. Aber auch einzelnen Mitarbeitern drohen Gefahren, etwa wenn sie für eine Weile ihren Arbeitsplatz verlassen. Währenddessen könnte beispielsweise ein Kollege vom verwaisten PC aus eine beleidigende Nachricht an den Vorstand schicken. Die Liste der möglichen Sündenfälle ließe sich beliebig fortsetzen. Sicherheitskonzepte können solche Risiken zwar nicht beseitigen, aber immerhin begrenzen. Zum Beispiel, indem sie festlegen, welche Daten nach außen gegeben werden dürfen oder daß Mitarbeiter ihren PC auszuschalten haben, wenn sie für längere Zeit nicht vor Ort sind.
Trotz der Vorteile, die eine sinnvolle Sicherheits-Policy bietet, verfügen längst nicht alle Firmen über ein solches Regelwerk. Während deutsche Berater und Hersteller diesen Mangel beklagen, stellt John Pescatore, Research Director for Network Security bei der Gartner Group, amerikanischen Anwendern ein besseres Zeugnis aus: "Etwa 80 Prozent der Unternehmen haben eine Policy", faßt der Marktforscher seine Erfahrungen zusammen. Am weitesten verbreitet sind die Konzepte bei Banken, Versicherungen und staatlichen Einrichtungen. Allerdings schränkt er ein, nur bei der Hälfte dieser Firmen sei das Konzept zeitgemäß. Manche klammerten noch ganze Themenblöcke wie Client-Server oder Internet aus der Betrachtung aus.
Dabei ist ein Sicherheitskonzept, das nicht alle Bereiche wie Technik, Organisation oder Training berücksichtigt, so gut wie sinnlos, denn jede Kette ist nur so stark wie ihr schwächstes Glied. Es nutzt wenig, eine Festplatte zu haben, die vor unerlaubten Zugriffen über das Netz hervorragend geschützt ist, wenn sie sich von jedem Laien aus dem Rechner ausbauen läßt. Auch wenn eine Policy in der Breite alle Themen abdecken muß, sollte sie nicht zu stark in die Tiefe gehen. Es empfiehlt sich, nicht zu viele Details wie zum Beispiel Filterregeln in das Papier aufzunehmen, weil ansonsten alle paar Wochen Änderungen fällig wären.
Zuerst sollte laut Magnus Harlander, Geschäftsführer der Genua GmbH aus Kirchheim bei München, geklärt werden, welche Anforderungen an die Sicherheit zu stellen sind. Diese müssen nicht für alle Bereiche gleich sein. Zum Beispiel ist es sinnvoll, die Personalabteilung durch Vorkehrungen wie eine Firewall gegenüber dem normalen Netz abzuschotten, damit Gehälter anderer nicht ausspioniert werden können. Das führt zu der Frage, welche unterschiedlichen Sicherheitslevels oder -zonen im Netz existieren. Von besonderem Interesse ist, wie die Übergabepunkte gestaltet werden und welche Daten über diese Wege fließen.
Neben der Einteilung der Netzinfrastruktur ist außerdem eine Klassifizierung der Daten nötig. Im Klartext heißt das eine exakte Definition von streng geheimen Informationen einerseits und Daten ohne besonders vertraulichem Charakter andererseits. Das gilt sowohl für den externen wie auch für den internen Verkehr. Kritische Daten für die Administration sollten beispielsweise von den normalen Benutzerdaten getrennt gehalten werden. Weiterhin muß bestimmt werden, wie die Übergabe von Daten nach draußen geregelt ist. Es klingt zwar banal, aber etliche Unternehmen richten gut abgesicherte zentrale Internet-Zugänge ein, vergessen jedoch, zuvor genutzte Modems zu deaktivieren. Damit werden unliebsamen Gästen Tür und Tor geöffnet.
Eine Policy muß konkrete Angaben zur einzusetzenden Sicherheitstechnik enthalten, zum Beispiel zu Verschlüsselung und Authentisierung. Ebenso wichtig wie die Überprüfung der Zugangsberechtigung beim Einloggen ist jedoch die Frage, wer diese vergibt und pflegt. Häufig sammeln sich nämlich bei Benutzern im Laufe der Zeit eine Reihe von Berechtigungen an, die sie nicht mehr benötigen und somit nicht mehr haben dürften. Es gehört in der Regel zu den Aufgaben eines Administrators, die vergebenen Rechte in regelmäßigen Zeitabständen zu überprüfen und zu ändern. Aber auch der Endanwender steht in der Pflicht. Ein Katalog sollte deshalb genau klären, welche Rechte und Pflichten Administratoren und Benutzer haben.
Neben der Festlegung verschiedener Vertrauensstufen und technischer Regeln kommt der Definition organisatorischer Bedingungen eine ebenso große Rolle zu. Zum Beispiel sollte nicht jede x-beliebige Person Zutritt zum Unternehmen oder gar zum Rechenzentrum haben. Um eine Kontrolle der DV-Abteilung durch den Sicherheitsbeauftragten zu ermöglichen, erscheint es außerdem ratsam, wenn dieser nicht in derselben Abteilung angesiedelt ist. Weiterhin könnte man festlegen, bis zu welcher Hierarchieebene Zeitarbeitskräfte eingesetzt werden dürfen. Eine solche Vorsichtsmaßnahme unterstellt, daß deren Loyalität geringer ist als die der Festangestellten.
Trotz aller Sorgfalt beim Verfassen eines Konzeptes stehen immer wieder Änderungen ins Haus, zum Beispiel ein Software-Update oder die Migration zu einem anderen Produkt. Kleinere Veränderungen sollte die Policy abfedern. Doch das wird immer an Grenzen stoßen. Gut ist daher, wenn sich die Verantwortlichen vorher Gedanken machen, wie Modifikationen schnell und flexibel integriert werden können. Zum Beispiel muß definiert werden, wer überhaupt welche Änderungen umsetzen darf: der Administrator oder sein Vorgesetzter. Es dient der Qualitätssicherung, wenn dieser Modifikationen nur nach Rücksprache mit einem kompetenten Partner vornimmt, da sich sonst leicht Fehler einschleichen. Sie müssen zudem gut dokumentiert werden, damit sie nachvollziehbar und überprüfbar bleiben. Eine Policy ist außerdem auf Widersprüche zu prüfen.
Zur ständigen Überwachung der Sicherheitsstrategie lassen sich die Log-Dateien der einzelnen Systeme heranziehen, die alle Aktionen aufzeichnen. In diesem Zusammenhang ist zu regeln, wer Zugriff darauf hat, ob die Log-Dateien archiviert und/oder ausgewertet werden. Wenn ja, muß außerdem festgelegt werden, wie die Auswertung aussehen soll (siehe auch CW 45, Seite 37, "Sicherheits-Audits müssen häufig wiederholt werden").
Alle diese Maßnahmen dienen letztlich der Vorsorge. Oft wird jedoch vergessen, einen Notfallplan zu vereinbaren. Scheint ein System gefährdet, gibt es zwei mögliche Verhaltensweisen: Entweder den Angreifer weiter beobachten oder ihm den Zugang verwehren - notfalls durch Abschalten des Systems. In einer Policy muß daher geregelt werden, ob beispielsweise die Verfügbarkeit der Firewall eine höhere Priorität hat oder die Sicherheit der Systeme dahinter. "Das dient dem Schutz des Administrators", erläutert Harlander.
Ein Handicap bei der Umsetzung von Policies liegt im Aufwand begründet, weil sie sich nicht an einem Tag aus dem Boden stampfen lassen. Schon die Feststellung des Ist-Zustandes im Netz kann sehr schwierig sein. Eine Projektdauer von mehreren Monaten ist daher keine Seltenheit. Dem stimmt auch Pescatore von der Gartner Group zu: "Das dauert lange. Viele Beratungsfirmen verdienen eine Menge Geld damit, Policies im Schnellverfahren anzubieten. Doch die sind das Papier nicht wert, auf dem sie gedruckt sind." Laut Harlander unterscheiden sich die Konzepte verschiedener Firmen stark voneinander. Einige bevorzugen starre, umfangreiche Konzepte, anderen genügt ein formloserer Ansatz - je nach Firmenkultur. "Eine Policy muß nicht mehr als vier bis fünf Seiten haben, aber man braucht Muße und Geld, um sie zu erstellen", bestätigt er. Auch andere Hersteller empfehlen, lieber mit einem kleinen Konzept anzufangen und dieses gegebenenfalls zu erweitern.
Außerdem besteht ein grundsätzlicher Konflikt zwischen Sicherheit und Geschäftszielen sowie der Benutzerfreundlichkeit. Ein sicheres System ist umständlich zu bedienen. Zum Beispiel, wenn das Paßwort jede Woche geändert werden soll. Es gilt, die strengsten Sicherheitsauflagen zu finden, die das Geschäft nicht behindern. "Vor der Formulierung einer Policy muß klar sein, was auf jeden Fall noch zu funktionieren hat", warnt Harlander, um böse Überraschungen zu vermeiden. Eine Schwierigkeit stellen daher insbesondere zu restriktive Sicherheitsregeln dar. Sie führen dazu, daß die Benutzer sie umgehen. Pescatore nennt als Beispiel das Verbot, PCs und E-Mail privat zu nutzen.
Die beste Policy nützt aber nichts, wenn die Akzeptanz der Benutzer oder der Unternehmensführung fehlt. Deshalb ist es wichtig, das Konzept von möglichst hochrangigen Mitarbeitern absegnen zu lassen. Ansonsten besteht die Gefahr einer Torpedierung durch das Topmanagement. Um den Mitarbeitern für die Bedeutung von Sicherheit die Augen zu öffnen, nehmen Schulungen eine zentrale Stellung ein. Am wirkungsvollsten ist es, den Teilnehmern an konkreten Beispielen zu zeigen, welche Gefahren und Konsequenzen drohen. Wer einmal eine gefälschte E-Mail bekommen hat, wird Sicherheitsfragen mit einer neuen Sensibilität begegnen. Da viele Policies Fragen behandeln, bei denen der Betriebsrat ein Mitspracherecht hat, gilt es, dieses Gremium frühzeitig einzubinden.
Ratgeber Sicherheits-Policies
1. Legen Sie die Policy mindestens auf drei bis fünf Jahre an. Widmen Sie ihr entsprechend viel Aufmerksamkeit und Ressourcen.
2. Die Policy soll nur die grundlegenden Weichenstellungen enthalten. Verzichten Sie auf Detailregelungen. Die werden sich ohnehin nicht halten.
3. Die Policy regelt Rechte und Pflichten der Anwender.
4. Die Policy sollte auch die Rechte und Pflichten der Administratoren regeln.
5. Die Policy enthält arbeits- und personalrechtliche Punkte. Beteiligen Sie die Personalvertretung.
6. Die Policy muß von einem möglichst hochrangigen Manager abgesegnet sein, damit sich ein Systemverwalter darauf berufen kann.
7. Die Policy muß einen Notfall- und Eskalationsplan enthalten.
8. Die Policy sollte Entscheidungsbefugnisse klarstellen.
9. Sicherungsverfahren wie Verschlüsselung und Authentifizierung müssen in einer Policy verbindlich festgelegt werden.
10. Nutzen Sie den Denkprozeß bei der Erstellung einer Internet-Policy zum Beginn einer Diskussion über interne Sicherheit.
Quelle: Harlander