Seminarvortrag RFC Eine Arbeit von Heinrich Vogt, I6m

Transkript

1 Seminarvortrag RFC 2196 Eine Arbeit von Heinrich Vogt, I6m Fachhochschule Aargau Departement Technik Studiengang Informatik Betreuender Dozent: Prof. Dr. Harald von Fellenberg

2 Inhaltsverzeichnis EINLEITUNG WARUM RFC 2196? SICHERHEIT KLASSIFIKATION DER SICHERHEIT ANGRIFFSARTEN ARTEN DER SICHERHEIT PHYSIKALISCHE SICHERHEIT PERSONELLE SICHERHEIT HOSTSICHERHEIT Benutzernamen und die Passwort-Datei Das Dateisystem Dienste SetUID- / SetGID-Root-Programme Logging /Auditing Der Superuser Verschlüsselung und digitale Signaturen NETZWERKSICHERHEIT Grundsätzliche Überlegungen Grundregeln Firewalls POLICY EINLEITUNG DEFINITION UND AUFBAU EINER POLICY Sicherheit im Sinne einer Policy Inhalt und Struktur einer Policy Verschiedene Arten von Policies ZIELE EINER POLICY ZUSÄTZLICHE DOKUMENTE: STANDARDS UND RICHTLINIEN ERSTELLUNG UND UMSETZUNG EINER POLICY Voraussetzungen und Vorbereitungen Erstellung: Informationsbeschaffung und Koordination Risiko- und Schwachstellenanalyse INCIDENT HANDLING ZUSAMMENSPIEL UMSETZUNG DER POLICY UND KONTROLLE ZUSAMMENFASSUNG...27 Heinrich Vogt

3 Einleitung Mit der wachsenden Vernetzung von Computern und dem vermehrten Bereitstellen von kommerziellen Diensten über Netzwerke steigt auch die Anzahl der Angriffe auf die Computersysteme. Lag die Zahl der vom Computer Emergency Response Team gemeldeten Sicherheitsvorfälle im Jahre 1989 nur bei 132, so waren es im Jahre 1996 bereits 2573, wobei die Zahl der betroffenen Netzwerke bei mehr als lag. Heutzutage werden tausende Angriffe täglich auf Netzwerke durchgeführt. Durch die zunehmende Verarbeitung sensitiver Daten auf Computern sind die Folgekosten von Angriffen deutlich gestiegen. Die meisten dieser Angriffe nutzen Schwächen der Betriebssysteme, Netzwerkprotokolle und Netzwerkhardware aus. Insbesondere im Bereich der Netzwerkprotokolle und ihrer Implementationen sind seit Mitte der achtziger Jahre viele Schwächen aufgezeigt geworden. Um das Risiko eines Angriffs einschätzen zu können, sind detaillierte Kenntnisse der Systemschwächen nötig. Dieser Artikel soll daher einen Überblick über die Sicherheitsprobleme von vernetzten Systemen geben sowie auch einige Lösungsmöglichkeiten vorschlagen. Dazu wird zunächst auf den Begriff der Sicherheit eingegangen und eine Klassifikation von Sicherheit gegeben. Darauf folgt eine Beschreibung der wichtigsten Schwachpunkte und Probleme und zum Schluss wird die Sicherheitspolicy vorgestellt. Heinrich Vogt

4 1. Warum RFC 2196? Die Wegweisung RFC 2196 ist ein Leitfaden für die Erstellung von Computer Sicherheits Richtlinen und Vorgänge für System die einen Zugang an ein Netzwerk resp. ans Internet haben. Die Absicht von diesem Handout ist, dass der Administrator eine praktische Hilfestellung bekommt, damit er die Dienste und Prozesse sicherer machen kann. Sicherheit gibt es nicht zum Nulltarif. Sie kostet Zeit und Geld. Doch noch teurer kann es für Unternehmen werden, keine oder unzureichende informationstechnische Sicherheitsmassnahmen für den laufenden Betrieb realisiert zu haben. Aufgrund von Sicherheitslücken in der Informationstechnik treten unterschiedliche Schäden in Unternehmen auf. Einen Eindruck vermitteln einige Aussagen aus der Studie "IT-Security": 1,2 Millionen Tage Ausfall hatten die Computersysteme in den deutschen Unternehmen in einem Jahr durch Attacken auf die IT-Infrastruktur. 42 Prozent der Angriffe sind nach Ansicht der Unternehmen auf Computerviren zurück zu führen. Als Urheber vermuten die Firmen zu 42 Prozent Hacker und zu 32 Prozent eigene Mitabeiter. Fremdzugriffe und eine Bombardierung mit s (Spam) wurden von je einem Zehntel der Unternehmen als Probleme genannt. Als Auswirkungen von Angriffen nannten 35 Prozent der Unternehmen Ausfälle von EDV-Programmen oder -Systemen, 24 Prozent Netzwerkausfälle und 13 Prozent Diebstahl vertraulicher Informationen. Diese Umfrageergebnisse zeigen, wie angreifbar Unternehmen durch ihre Internetanwendungen sind. Der allein durch Computerviren verursachte wirtschaftliche Schaden ergibt für die Schweiz jährlich einen zweistelligen Millionen-Betrag - mit steigender Tendenz. Die infizierten Computersysteme wieder lauffähig zu machen, kostet nicht nur Arbeitszeit und Geld, sondern ist unter Umständen auch mit Einnahmeausfall und Imageschaden verbunden. Technisches Versagen, menschliche Fehlhandlungen, vorsätzliche Handlungen, organisatorische Mängel und höhere Gewalt können Gefahrenpotentiale sein. Die täglichen Nachrichten über Hackerattacken, Virenbefall, betrügerisch manipulierte Daten, Sabotagen und IT-Schäden nach Naturkatastrophen erinnern immer wieder an notwendige Sicherheitsmassnahmen. Nicht nur in den bekannt gewordenen Schadensfällen waren die Betroffenen nicht ausreichend auf solche Gefahren vorbereitet. Sie hatten nicht alle Vorkehrungen zur Vorbeugung und Vermeidung getroffen. Es kostete sie daher umso mehr Aufwand, die Schäden zu beseitigen und auch juristische Auseinandersetzungen durchzustehen. Denn ausser technischen und organisatorischen Sicherheitsvorkehrungen sind auch noch gesetzliche Auflagen, Datenschutzanforderungen, betriebsinterne Richtlinien und vertragliche Verpflichtungen einzuhalten. Die Sicherheit der Informationstechnik zu gewährleisten, ist eine Aufgabe, die professionell geplant und angemessen umgesetzt werden muss. Deshalb wurde ein Dokument von verschiedenen hochkarätigen Personen verfasst, welche eine Anleitung und Wegweisung von einer guten Sicherheitsplanung im Betrieb repräsentiert. Heinrich Vogt

5 2. Sicherheit Beim Einsatz von Computern gibt es i.d.r. zwei Zielsetzungen, die den Begriff der Sicherheit definieren: Verhinderung unbefugter Aktivitäten an, mit oder durch das eigene System. Gewährleisten gewollter Aktivitäten an, mit oder durch das System. Zunächst muss also definiert werden, welche Aktivitäten im Umgang mit den Systemen gewollt und nötig sind und welche Handlungen diesen Zielen entgegenstehen. Dies geschieht ganz allgemein in einer Policy und detaillierter in Standards und Handbüchern. Gibt eine Policy die Grundregeln für die Systemnutzung vor, so bleibt das Problem bestehen, dass sich nicht unbedingt jeder Anwender an diese Regeln hält. Dies gilt insbesondere bei Systemen, die nicht nur einer beschränkten Gruppe von Mitarbeitern zugänglich sind, sondern über ein Netzwerk auch Zugriff von aussen ermöglichen. Der Zugriff auf die Ressourcen des Systems wie z.b. Daten, Netzwerk, Computer oder Drucker muss also durch das System selbst so eingeschränkt werden, dass zumindest grobe Verstösse gegen die Policy unmöglich sind. Folgende Eigenschaften sollen bei der Umsetzung eines Sicherheitskonzeptes durchgesetzt werden: Verfügbarkeit: Vertraulichkeit: Integrität: Authentizität: Nutzungsmöglichkeit der Betriebsmittel für gewollte Aktivitäten Einschränkung des Zugriffs auf Daten Unverändertheit von Daten Identität des Verfassers Der Aspekt der Korrektheit von Systemen soll hier nicht betrachtet werden. Abbildung A zeigt exemplarisch die Angriffsmöglichkeiten auf, die diese Eigenschaften verletzen. Abb. A: Verschiedene Angriffsarten Heinrich Vogt

6 3. Klassifikation der Sicherheit In den folgenden zwei Abschnitten erfolgt eine Klassifikation von Angriffsarten und von Arten der Sicherheit. 3.1 Angriffsarten Die in Abbildung A gezeigten Angriffe lassen sich auf Grund ihrer Eigenschaften in folgende zwei Klassen einteilen: Passive Angriffe: Abhören Aktive Angriffe: Unterbrechung, Modifikation, Fälschung Die passiven Angriffe sind i.d.r. nur sehr schwer zu entdecken, da sie keine sichtbare Veränderung des Systems mit sich bringen. Die einzigen Entdeckungsmöglichkeiten sind, den Täter auf frischer Tat zu ertappen (z.b. einen heimlich ans Netz angeschlossenen Rechner) oder spürbare Folgen des Abhörens (jemand kennt offensichtlich vertrauliche Daten des Unternehmens). Passiven Angriffen kann man jedoch vorbeugen, indem sensitive Daten nur verschlüsselt gespeichert und übertragen werden. Die aktiven Angriffe weisen gegenteilige Eigenschaften auf. Sie sind kaum zu verhindern, da dies die Kenntnis aller Angriffsmöglichkeiten voraussetzt. Weiterhin müsste jedes übertragene Paket inhaltlich analysiert werden. Hier hilft nur, diese Angriffe zu entdecken und entsprechende Massnahmen gegen den Täter einzuleiten (z.b. Strafverfolgung). Solche Massnahmen sollten langfristig auch abschreckende Wirkung haben. Im Falle eines Angriffs aus einem externen Netz ist es jedoch oftmals unmöglich, den Täter ausfindig zu machen; Firewalls sollten zur Erhöhung der Sicherheit des internen Netzes eingesetzt werden. Im Gegensatz zu den passiven Angriffen können aktive Angriffe jedoch erkannt werden. Voraussetzung dafür sind Massnahmen, die ungewöhnliche Vorfälle auf den Systemen protokollieren. Dies geschieht in Form eines ausführlichen Auditing, das sowohl ein Mitprotokollieren des Netzwerkverkehrs (z.b. Meldungen über ungewöhnlich viele ICMP-Pakete) als auch das Erkennen von Veränderungen von wichtigen Systemdateien (mittels Prüfsummen, die aus den Originaldateien berechnet werden, wie es z.b. das Werkzeug tripwire anbietet) beinhalten sollte. 3.2 Arten der Sicherheit Die Möglichkeiten, Sicherheit in einer Umgebung vernetzter Rechner zu gewährleisten, lassen sich einteilen nach den Schwachstellen, die für Angriffe ausgenutzt werden können. Angriffspunkte sind die einzelnen logischen Ebenen, aus denen das System besteht. Auf jeder dieser Ebenen muss das System abgesichert werden. 3.3 Physikalische Sicherheit Angriffe können jederzeit erfolgen, wenn der Angreifer physikalischen Zugang zum System hat. Schwachstellen sind hierbei öffentlich zugängliche Systemkomponenten, also Rechner, Router, Switches, Verteilerschränke und Netzkabel. Beispiele für Angriffe auf die Verfügbarkeit, die Vertraulichkeit, die Authentizität oder die Integrität sind z.b. die folgenden: Ausbau von Festplatten Neustart eines Systems von einer Diskette, um unkontrollierten Zugriff auf die Festplatten zu erlangen Anschluss eines Rechners an das Netz, um den Netzwerkverkehr abzuhören Umkonfigurieren von Routern und Switches Versenden von s vom Account eines Benutzers, der sich nicht ausgeloggt hat. Heinrich Vogt

7 Nicht zuletzt sind öffentlich zugängliche Büros eine Möglichkeit, nach Passwörtern von Mitarbeitern (z.b. auf Zetteln in der Umgebung des Rechners) oder vertraulichen Daten in gedruckter Form zu suchen. Eine Beschränkung des physikalischen Zugangs zum System ist also Grundvoraussetzung für einen gesicherten Betrieb. Dieser Aspekt der Sicherheit, der fälschlicherweise oftmals vernachlässigt wird, umfasst alle Massnahmen, die dem physikalischen Schutz der Hard- und Software vor äusseren Einflüssen dienen. Da es sich bei Computern und deren Bauteilen um sehr empfindliche Geräte handelt, ist dafür Sorge zu tragen, dass sie keinen schädlichen Umgebungseinflüssen ausgesetzt sind. Zu diesen schädlichen Einflüssen zählen Feuer, Rauch, Feuchtigkeit, Staub, Erschütterungen, usw. Durch spezielle Rechnerräume sollten die meisten dieser Faktoren ausgeschaltet werden können. Da auch Spannungsschwankungen und -ausfälle Schäden nach sich ziehen können, sollten wichtige Systeme zum einen elektrisch getrennt abgesichert und eventuell mit einer eigenen unterbrechungsfreien Stromversorgung (USV) ausgerüstet werden. Beispiele für Angriffe auf die Verfügbarkeit, die Vertraulichkeit, die Authentizität oder die Integrität sind z.b. die folgenden: Ausbau von Festplatten. Neustart eines Systems von einer Diskette, um unkontrollierten Zugriff auf die Festplatten zu erlangen. Anschluss eines Rechners an das Netz, um den Netzwerkverkehr abzuhören. Umkonfigurieren von Routern und Switches. Versenden von s vom Account eines Benutzers, der sich nicht ausgeloggt hat. Nicht zuletzt sind öffentlich zugängliche Büros eine Möglichkeit, nach Passwörtern von Mitarbeitern (z.b. auf Zetteln in der Umgebung des Rechners) oder vertraulichen Daten in gedruckter Form zu suchen. Hierbei gilt es nicht nur für einen abgeschlossenen Raum zu sorgen, sondern es sollten auch weitere Faktoren wie abgehängte Decken, grosse Klimaanlagen und Fensterfronten mit in die Überlegungen einbezogen werden. Durch diese Massnahmen gelingt es, manuelle Sabotagen zu verhindern oder zumindest stark zu erschweren. 3.4 Personelle Sicherheit Es gibt weitere Faktoren, die die Sicherheit eines Systems beeinflussen. Insbesondere menschliche Schwächen lassen sich ausnutzen, um an sicherheitsrelevante Informationen zu gelangen. Diese Art von Angriffen wird häufig als Social Hacking oder Social Engineering bezeichnet. Hierzu gehört das Auskundschaften von Passwörtern im Gespräch, oft per Telefon. Oftmals geben sich Angreifer als Systemadministratoren aus und erklären, sie bräuchten das Passwort des Angerufenen für dringliche administrative Aufgaben. Insbesondere in grossen Firmen kennen die Mitarbeiter die Systembetreuer i.d.r. nicht und geben ihr Passwort preis. Weiterhin sind vielen Mitarbeitern die Gefahren und Sicherheitsrisiken des Systems nicht bewusst. Auch Systemadministratoren einzelner Abteilungen können unabsichtlich durch leichtfertige Konfiguration einzelner Rechner die Sicherheit des Gesamtsystems gefährden. Eine gute Schulung der Mitarbeiter ist deshalb wichtig, um das Sicherheitsbewusstsein der Anwender zu schärfen. Auch eine ständige Weiterbildung der Systemverwalter trägt dazu bei, dass Sicherheitslücken frühzeitig erkannt und geschlossen werden oder gar nicht erst entstehen. Bereits bei der Einstellung neuer Arbeitnehmer sollte besondere Sorgfalt auf deren Auswahl gelegt werden. Dies beinhaltet neben persönlichen Gesprächen auch die Nutzung aller verfügbaren Informationen (Zeugnisse, Tests,...).Weiterhin sollten gegebenenfalls Sondervereinbarungen mit den Angestellten betreffs Verschwiegenheit und Treue getroffen werden. Heinrich Vogt

8 Zahlen möglichst so Seminar RFC 2196 Ein sehr wichtiger Punkt besteht in der regelmässigen Weiterbildung der Angestellten, da gerade im IT-Bereich die Entwicklung sehr schnell voranschreitet. Neben der Belehrung über die Pflichten sollte die Information über die Rechte der Mitarbeiter ebenfalls nicht vernachlässigt werden, damit es nicht zu der bekannten Situation kommt, in der ein Angestellter telefonisch dem vermeintlichen Administrator sein Passwort mitteilt. Diese Belehrungen haben das Ziel, ein Sicherheitsbewusstsein beim Benutzer selbst zu erreichen. Der Benutzer sollte verstehen, weshalb er manche Sachen machen darf und andere wiederum nicht. Ferner sollte er darüber informiert werden, welcher Personenkreis innerhalb der Firma für bestimmte Rechnerprobleme ansprechbar (und befugt) ist. 3.5 Hostsicherheit Jeder einzelne Rechner eines Systems bietet Ansatzpunkte für einen Angriff. Ursache dafür sind Schwächen in Entwurf und Implementierung der Algorithmen. Wesentliche Schwachstellen sind hierbei der Passwort-Mechanismus, Systemaufrufe, SetUID-Programme und unsichere Anwendungen und Dienste. Angriffe erfolgen i.d.r. über das Netzwerk, so dass insbesondere die Dienste, die Netzwerkzugriffe ermöglichen, abgesichert werden müssen. Die Sicherheitsmassnahmen, die die Sicherheit eines einzelnen Rechners gewährleisten sollen, werden unter dem Begriff der Hostsicherheit zusammengefasst Benutzernamen und die Passwort-Datei Unter Unix sollte jeder Benutzer einen Benutzernamen und ein Passwort besitzen. Dabei beginnt eine wirkungsvolle Hostsicherheit bereits mit der Verwendung «guter» Passwörter. Unter guten Passwörtern sind solche zu verstehen, die nicht allzu einfach erraten werden können. Sie sollten _ aus Gross- und Kleinbuchstaben bestehen, _ und Sonderzeichen enthalten, _ leicht zu merken sein, dass sie nicht notiert werden müssen und _ lang sein. Als Beispiel sind hier Dwe-g-Pw (Dies war ein gutes Passwort) oder hmu8usin (heute morgen Um 8 Uhr schlafe Ich noch). Diese Regeln lassen sich erzwingen, indem der Systemadministrator z.b. die cracklib -Routine in den Passwortmechanismus einbindet, wodurch nur noch Passwörter akzeptiert werden, die bestimmten Kriterien genügen. Ein weiterer Schutz besteht darin, die Passwörter mit einem Verfallsdatum auszustatten und eine History über bereits verwendete zu führen, so dass die Benutzer in regelmässigen Abständen zur Änderung aufgefordert werden und ihr Passwort auch tatsächlich ändern müssen. Da die Passwörter in dieser History vielleicht auf anderen Systemen noch benutzt werden und sich aus der History eventuell das neue Passwort eines Benutzers ableiten lässt, ist sicherzustellen, dass sie nicht missbräuchlich genutzt werden kann. Da auf die Passwortdatei von vielen Programmen zugegriffen wird, ist sie standardmässig für jeden Benutzer lesbar. Da dies einen Brute-Force-Angriff, das (gezielte) Ausprobieren der verschiedenen Passworte, stark vereinfacht, ist es angeraten, die eigentlichen Passwörter nur mit Root-Rechten lesen zu können (shadow) und lediglich die sonstigen Benutzerinformationen allgemein lesbar zu belassen. Eine Veränderung der crypt()-routine kann ebenfalls die Sicherheit der Accounts erhöhen, da ein Brute-Force-Angriff meist mit Standardtools erfolgt. Hierzu zählt beispielsweise eine Erhöhung der Verschlüsselungsiterationen. Durch den Einbau eines Zählers, welcher Fehlversuche mitprotokolliert und Benutzerkonten gegebenenfalls temporär sperrt wird das mehrfache Einloggen zum Ausprobieren eine Passwortes stark erschwert. Der Einsatz eines verbesserten Zufallszahlengenerators, der die standardmässig in den Betriebssystemen enthaltenen Generatoren ersetzt und keine erratbaren Ergebnisse liefert, trägt ebenfalls zu einer Erhöhung der Sicherheit bei. Natürlich nutzen die sichersten Passwörter nicht viel, wenn der Loginvorgang beispielsweise durch einen Sniffer mitprotokolliert werden kann. Deshalb ist es angeraten, von ausserhalb nur sichere (=verschlüsselte) Verbindungen zuzulassen, d.h. z.b. POP3 Heinrich Vogt

9 und FTP-Zugänge, bei denen Benutzername und Passwort unverschlüsselt übertragen werden, zu sperren sowie den telnet-zugang nicht mehr zuzulassen und durch SSH zu ersetzen. Nach dem Motto Vertrauen ist gut, Kontrolle ist besser sollte der Administrator regelmässig versuchen, unsichere oder nicht mehr benutzte Accounts selbst aufzufinden. Dies kann durch Passwort-Cracker und andere Hilfsmittel erfolgen. Es sollte allerdings darauf geachtet werden, dass etwaige Ausgaben und Logfiles nicht auf dem geprüften Rechner verbleiben, da sie einem potentiellen Angreifer ebenfalls sehr nützlich sein können. Der sicherste und auch komplizierteste Mechanismus zum Schutz der Accounts besteht aus der Verwendung von Einmalpasswörtern. Diese haben den Vorteil, dass sie jeweils nur einmal gelten und somit Passwörter, die durch Sniffer entdeckt werden, nutzlos sind Das Dateisystem In die Überlegungen zur Hostsicherheit sollte auch das Dateisystem mit seinen bereits vorhandenen Schutzmechanismen einbezogen werden. Bei den gängigen Unix-Dateisystemen wird zwischen dem Besitzer (user), der Gruppe (group) und anderen Benutzern (other) unterschieden. Für jede Kategorie lassen sich eigene Zugriffsrechte zum Lesen (read), Schreiben (write) und Ausführen (execute) von Dateien und Verzeichnisse setzen. So können vertrauliche Dateien oder Programme bereits durch -rwx vor unbefugtem Zugriff anderer Nutzer geschützt werden. In Arbeitsgruppen können Dateien mit -rwxrwx--- ausgestattet werden, wodurch gewährleistet ist, dass zusätzlich Benutzer der jeweiligen Gruppe auf die Dateien zugreifen können. Dies setzt jedoch eine sinnvolle Verwaltung der verschiedenen Gruppen voraus. Diese Schutzmassnahmen des Dateisystems gelten jedoch nicht für den Superuser. Wenn Daten auch vor dem Administrator oder einem Benutzer mit Root-Rechten geschützt werden sollen, ist der Einsatz von Verschlüsselungssoftware erforderlich, z.b. CFS (Cryptographic File System) Dienste Da die meisten Angriffe gegen Rechner über Schwachstellen in den laufenden Netzwerk- Diensten (telnetd, ftpd, httpd,... ) geführt werden, sind grundsätzlich auf jedem Rechner nur solche Dienste zu starten, die unbedingt zum ordnungsgemässen Betrieb benötigt werden. Ist es nicht möglich, auf einen bestimmten, bekanntermassen unsicheren Dienst zu verzichten, so kann dieser eventuell durch einen sichereren ersetzt werden, der über die gleiche Funktionalität verfügt, aber zusätzliche Sicherheitsfunktionen beeinhaltet. Beispielsweise ist es sehr ratsam, die r-dienste (rlogind, rshd,... ) durch das SSH-Paket zu ersetzen. Als weiteres Beispiel dient der finger -Daemon, welcher in seiner Standardkonfiguration sehr viele Informationen über die Benutzer eines Rechners liefert (Loginname, Zeit, Homeverzeichnis,... ), die einem Angreifer hilfreich sein können. Abhilfe kann hier z.b. der restricted finger -Daemon liefern, bei dem die Ausgaben frei konfigurierbar sind. Darüberhinaus sollte der TCP-Wrapper eingesetzt werden, der den Zugriff auf die Netzwerk- Dienste nur von bestimmten Rechnern aus gestattet SetUID- / SetGID-Root-Programme Dateien, bei denen das SetUID- bzw. das SetGID-Bit gesetzt ist, werden mit den Rechten des Eigentümers bzw. der Gruppe ausgeführt. Dies gestaltet sich besonders problematisch, wenn bei diesen Programmen Root als Eigentümer ausgewiesen ist. Denn in diesem Fall kann der Ausführende, beispielsweise duch einen Buffer Overflow oder andere Fehler innerhalb des Programms, ebenfalls Root-Rechte erlangen. Ein Beispiel für solch ein Programm ist passwd: -r-sr-xr-x 3 root sys Apr /bin/passwd Programme wie passwd oder su benötigen dieses Bit. Meist gibt es allerdings in einer Standardinstallation etliche SetUID-Programme, die entweder nicht benötigt werden oder die Heinrich Vogt

10 unnötigerweise mit diesen Rechten ausgestattet worden sind. Daher sollten nach der Installation von neuer Software oder Patches regelmässig nach diesem Bit gesucht werden. Der folgende Aufruf erledigt dies, wobei es in Abhängigkeit vom jeweiligen Betriebssystem wiederum zu Unterschieden kommen dürfte: find / \( -perm o -perm \) -type f -print Die SetUID / SetGID-Bits der gefundenen Programme können anschliessend mit dem chmod- Befehl zurückgesetzt werden. Als Schutzmassnahme vor unbekannten Dateisystemen können diese mit der Option nosuid in das Dateisystem einhängt werden, wodurch eine generelle Ignorierung der SetUID /SetGID-Bits erreicht wird. Sollte auf bekanntermassen unsichere SetUID-Root-Programme nicht verzichtet werden können, so sind diese in einer Chroot - Umgebung auszuführen. Eine Chroot-Umgebung ist ein Verzeichnisbaum, der alle zur Ausführung benötigten Dateien enthält und von den dort laufenden Programmen nicht ohne grösseren Aufwand verlassen werden kann. Auf diese Art und Weise erhält ein Angreifer nach einem Buffer-Overflow lediglich Zugriff auf eben diesen einzelnen Verzeichnisbaum und nicht auf das komplette Dateisystem Logging /Auditing Um zu gewährleisten, dass ein Angriff bzw. eine missbräuchliche Nutzung eines Rechners bemerkt wird, ist es erforderlich, alle relevanten Daten und Vorgänge zu protokollieren und auch auszuwerten. Dabei muss allerdings beachtet werden, dass Logfiles auf einem kompromittierten Rechner üblicherweise verändert oder gelöscht werden. Eine Änderung dieser Situation könnte sich z.b. mit Einführung eines neuen Syslog-Daemon ergeben, der in der Lage ist, Logfiles zu signieren. Daher bietet es sich an, einen besonders gesicherten Loghost zu betreiben, der zentral alle Logmeldungen entgegen nimmt. Der immer noch bestehenden Gefahr des Logfloodings, dem drohenden Überlauf des Logmediums mit dem damit verbundenen Verlust an wichtigen Logmeldungen, kann z.b. durch entsprechende Filterung der Meldungen oder einem ausreichend dimensionierten Speicherplatz begegnet werden. Bei einer Filterung ist darauf zu achten, dass nicht gerade diejenige Information, die ein Angreifer in den vielen Logmeldungen verstecken will, verloren geht. Bei allen Logvorgängen darf nicht ausser acht gelassen werden, dass teilweise gesetzlich festgelegt ist, welche Daten gespeichert werden dürfen, wie lange diese maximal aufzubewahren sind, usw. Weiterhin empfiehlt sich der Einsatz von Prüfsoftware, die Prüfsummen der zu schützenden Dateien oder Verzeichnisse erstellt und somit eine Veränderung dieser Dateien erkennen lässt. Wichtig ist bei der Nutzung solcher Software vor allem, dass sie auf ein sauberes System aufsetzt, von dem bekannt ist, dass noch keine Daten verändert wurden. Sobald Patches oder neue Softwarekomponenten eingespielt werden, ist ein Update der Prüfsummen erforderlich, um diese legalen Veränderungen zu autorisieren. Weiterhin müssen die Prüfsummen auf einem Medium abgelegt sein, dass auch für Root nur lesbar ist, beispielsweise CD-Roms oder Festplatten mit Hardware-Schutz, da im Falle eines Einbruchs davon auszugehen ist, dass der Angreifer Root-Rechte erlangen kann und somit in der Lage ist, selbst neue Prüfsummen zu erstellen Der Superuser Da der Superuser (Root) auf einem Unix-System unbegrenzte Rechte besitzt, gilt es, ihn besonders zu schützen. Neben den bereits beschriebenen Aspekten zur Passwortvergabe sind noch ein paar weitere Punkte zu beachten. So darf der Pfad zur Ausführung von Programmen ($PATH) des Superusers nicht das aktuelle Verzeichnis (./) enthalten, da sonst unter Umständen nicht der gewünschte Befehl, sondern ein von einem Angreifer installiertes, gleichnamiges Programm aufgerufen wird, welches sich im aktuellen Verzeichnis befindet. Kann trotzdem nicht auf das aktuelle Verzeichnis im Pfad verzichtet werden, dann sollte es nur am Ende des Heinrich Vogt

11 Suchpfades aufnommen werden, um zu gewährleisten, dass erst die Systemverzeichnisse durchsucht werden. Um illegale Root-Logins bzw. deren Versuche rechtzeitig zu erkennen, sollte regelmässig nach bad logins in den Dateien /var/log/messages/ und/oder /var/log/sulog gesucht werden. In Abhängigkeit vom Betriebssystem können sich diese Dateien auch unter /var/adm/ oder /usr/adm/ befinden. Um zu verhindern, dass bei der Kompromittierung eines Root- Passwortes auch alle anderen bekannt werden, ist es ratsam, jedem Rechner ein anderes Root- Passwort zu geben. Eine Massnahme, die sich bei mehreren zu verwaltenden Rechnern allerdings schwierig und umständlich gestalten dürfte Verschlüsselung und digitale Signaturen Die Zugriffskontrollen des Dateisystems sind aufgehoben, sobald ein Benutzer Administratorrechte (Root-Rechte) besitzt. Deshalb sollte nicht nur auf diesen eingebauten Dateischutz zur Wahrung der Vertraulichkeit und Integrität vertraut werden, sondern die sensiblen Daten sollten zusätzlich verschlüsselt werden. Möglichkeiten Die Verschlüsselung erfüllt verschiedene Eigenschaften von Sicherheit. Zunächst wird durch Verschlüsselung sowohl die Vertraulichkeit einzelner Daten auf einem Rechner als auch die Vertraulichkeit des Datentransports erreicht. Ferner können durch digitale Signaturen die Integrität und die Authentizität von Daten sichergestellt werden. Mit dem Programm PGP (Pretty Good Privacy erhält jeder Benutzer die Möglichkeit, seine Daten wirkungsvoll zu verschlüsseln. Da mit PGP ebenfalls Daten signiert und somit etwaige Veränderungen erkannt werden können, stellt PGP ein gutes Werkzeug dar, um Vertraulichkeit und Integrität von einzelnen Dateien sicherstellen zu können. Durch CFS (Cryptographic File System) werden komplette Verzeichnisse verschlüsselt gespeichert, wodurch die Vertraulichkeit der Daten selbst bei einem Hardwarediebstahl gewahrt bleibt. Wird ein NFS-Server betrieben, so ist es möglich, verschlüsselte Dateisysteme zu exportieren und erst auf dem Klienten wieder zu entschlüsseln, um eine vertrauliche Übertragung zu gewährleisten. Zu diesem Zweck und zur sicheren Authentisierung des Kommunkationspartners wird SSH eingesetzt. SSH eignet sich besonders als Ersatz für telnet und die sog. r-dienste, da einerseits keine Klartext-Passwörter mehr verschickt werden müssen und andererseits sowohl auf Server- als auch auf Klientenseite eine starke Authentisierung stattfindet. Dies stellt einen wirkungsvollen Mechanismus zur Verhinderung von Passwortsniffing, IP- Spoofing, Man-in-the-middle - Angriffen und TCP-Hijacking dar. Grenzen Verschlüsselung besitzt prinzipbedingte Grenzen. Eine verschlüsselte Datei ist zwar nur noch für den Schlüsselinhaber lesbar, kann aber, die entsprechenden Zugriffsrechte vorausgesetzt, unwiderruflich gelöscht oder modifiziert werden, so dass die Vertraulichkeit zwar gewahrt bleibt, die Verfügbarkeit jedoch nicht. Eine weitere Gefahr besteht darin, dass eine wichtige Datei bereits vor der Verschlüsselung angegriffen werden kann. Auch die Verschlüsselungssoftware selbst ist ein mögliches Angriffsziel. Ein solcher Angriff kann zur Folge haben, dass beispielsweise der Verschlüsselungsalgorithmus falsch funktioniert oder vielleicht die Passphrase, das Passwort oder der Klartext aufgezeichnet und weiterversandt wird. Falls ein Angreifer einen bis dato unbekannten Weg der Entschlüsselung findet, ist davon auszugehen, dass die Vertraulichkeit und gegebenenfalls die Authentizität nicht mehr länger gewahrt werden kann. Da bei verschlüsselten s zwar der eigentliche Inhalt, die Angaben im Header über Adressat und Absender jedoch frei lesbar sind, besteht die Möglichkeit von Verkehrsanalysen bzw. der Erstellung von Kommunikationsprofilen. Die Folgen können von der Heinrich Vogt

12 Zusendung unerwünschter bis hin zur Entlassung eines Mitarbeiters reichen, wenn dieser mit einer feindlichen Firma Daten austauscht. Heutzutage kommt es bei vielen Nachrichten auf die ordentliche und exakte Zustellung an. Gerade im Hinblick auf den elektronischen Handel können Replay oder Delay-Angriffe, d.h. das wiederholte oder das verzögerte Senden einer Nachricht, grosse Schäden anrichten. Diese Gefahren werden leider nicht durch blosse Verschlüsselung behoben, da auch eine verschlüsselte und signierte Nachricht aufgehalten oder mehrfach versendet werden kann. Um auch hier die Sicherheit wieder herzustellen, sind umfangreiche organisatorische und administrative Massnahmen erforderlich, vor allem der Einsatz von Zeitstempeln. Diese Massnahmen sind jedoch nicht Gegenstand dieses Beitrags. 3.6 Netzwerksicherheit Auch das Netzwerk selbst ist eine Schwachstelle, die das System angreifbar macht. Dies betrifft zum einen die Protokolle, die das Versenden und Empfangen von Daten ermöglichen, zum anderen die verwendete Technologie und Topologie eines Netzwerkes. Zu den entsprechenden Angriffsmöglichkeiten zählen hier z.b. das Fälschen von Absenderadressen, das Verändern der dynamischen Routingtabellen eines Rechners oder Routers, um den Datenstrom umzuleiten, oder die Unterbrechung des Netzwerkzugangs. Massnahmen zur Beseitigung dieser Angriffsmöglichkeiten dienen der Netzwerksicherheit. Die exakte Trennung zwischen Hostsicherheit und Netzwerksicherheit ist hierbei genau so schwierig wie die Trennung zwischen Netzwerk und Rechner selbst, der Übergang ist fliessend Grundsätzliche Überlegungen Es sollten nur diejenigen Rechner vernetzt werden, die diese Anbindung unbedingt benötigen. Oftmals gibt es Alternativen zu einem Netzanschluss. Die einfachste Methode ist der Datentranport mittels Wechseldatenträgern, eine Praxis, die in Hochsicherheitsumgebungen täglich angewandt wird Grundregeln Wenn ein Rechner vernetzt werden soll, haben bezüglich der laufenden Dienste die gleichen Punkte Beachtung zu finden, die bereits in Abschnitt zu den Diensten hinsichtlich der Hostsicherheit genannt wurden. Das heisst, dass alle nicht benötigten Dienste abgeschaltet und alle unbedingt benötigten unsicheren Dienste durch sicherere Programme ersetzt werden müssen. Dies gilt im besonderenmasse für das Ersetzen der unsicheren r-dienste durch die entsprechenden SSH-Versionen. Vor allem ist hervorzuheben, dass diese Sicherungsmassnahmen vor dem Anschluss des Rechners an ein Netz zu erfolgen haben, da ein potentieller Angreifer unter Zuhilfenahme von Scripten in wenigen Sekunden einen Rechner automatisch auf Schwachstellen untersuchen und die gefundenen Lücken sofort ausnutzen kann, um den Rechner zu kompromittieren. Jeder einzelne Rechner eines Netzwerkes lässt sich absichern. Der damit verbundene Sicherungsund Administrationsaufwand dürfte bei kleinen Netzen noch praktikabel sein. Doch schon bei grösseren Netzen mit mehreren unterschiedlichen Rechnertypen und Betriebssystemen wird dieser Aufwand nicht mehr zu bewältigen sein. Daher bietet es sich an, an zentraler Stelle einen abgesicherten Rechner bzw. Rechner-Router- Kombination aufzustellen, welche die Sicherheit der nachgeschalteten internen Rechner gegenüber externen Angriffen gewährleistet Firewalls Eine Firewall ist eine Schwelle zwischen Netzen mit verschiedenen Sicherheitsniveaus. Durch technische und administrative Massnahmen wird dafür gesorgt, dass jede Kommunikation Heinrich Vogt

13 zwischen den Netzen über die Firewall geführt werden muss. Auf der Firewall sorgen Zugriffskontrolle und Audit dafür, dass nur berechtigte Verbindungen zwischen den Netzen aufgebaut werden und potentielle Angriffe schnellstmöglich erkannt werden. Einer der wichtigsten Punkte dieser Definition ist, dass es nur genau eine Verbindung zwischen den Netzen gibt. Sollte es Abweichungen von dieser Regel geben, hier sind vor allem Modemverbindungen zu nennen, muss dies explizit in einer Policy (siehe Abschnitt 4.2.2) festgehalten werden. Als Ausnahme kann beispielsweise eine Modemverbindung zu einem Mailserver zugelassen werden, damit Mitarbeiter auch von auswärts Zugriff auf ihre Daten haben. Meist wird davon ausgegangen, dass eine Firewall ein lokales Netz (LAN) vom Internet abtrennt. Aber gerade bei grösseren Firmen wird das interne Netz oftmals weiter unterteilt und durch interne Firewalls geschützt. Beispielsweise kann durch eine interne Firewall das Rechnernetz der Personalabteilung vom restlichen Firmennetz geschützt werden, damit nicht jeder Angestellte Zugang zu vertraulichen Daten aus dem Personalwesen erlangen kann. Es gibt verschiedene Möglichkeiten, eine Firewall zu realisieren. Sie reichen von ganz einfachen Konfigurationen bis hin zu komplizierten, sehr aufwendigen Implementationen. Eine grobe Unterteilung kann in vier Klassen erfolgen: Packet Screens (Abb. B) Gateways Kombinationen von Packet Screen und Bastion sowie Mischtechniken Abbildung B: Zwei Netze durch einen Packet Screen verbunden Packet Screens bilden die einfachste Möglichkeit, eine Firewall aufzubauen. Dafür kann ein bereits vorhandener Router so konfiguriert werden, dass er nur bestimmte Pakete durchlässt und andere hingegen abblockt. Daher werden Packet Screens auch oftmals als Screening Router bezeichnet. Mit einer Packet Screen ist es möglich, eine Zugriffssteuerung anhand der Quell- und Zieladressen sowie der Quell- und Zielports zu realisieren. Durch Filterregeln für Quell- und Zieladressen lässt sich die Erreichbarkeit einzelner Rechner oder Subnetze festlegen. Die Einschränkung der erreichbaren Dienste (http, ftp, telnet,...) erfolgt durch die Filterung der Quell- und Zielports. Bei den Filterregeln wird zwischen Deny Filtern und Pass Filtern unterschieden. Ein Vorteil von Packet Screens sind ihre geringen Kosten, da die notwendige Hardware, in Form eines Routers, meist bereits vorhanden ist und der Router lediglich umkonfiguriert werden muss. Ein weiterer Vorteil ist die Transparenz einer Packet Screen. Solange keine unerlaubten Dinge versucht werden, wird ein Benutzer die Packet Screen nicht bemerken. Eine Packet Screen besitzt allerdings auch einige Nachteile, von denen im folgenden einige genannt werden. Die nur indirekte Kontrolle der übertragenen Protokolle ist ein solcher Nachteil. Heinrich Vogt

14 Da nicht nach Protokollen, sondern nach Portnummern gefiltert wird, ist es nicht gesichert, dass auf den verschiedenen Ports auch nur die gewünschten Protokolle übertragen werden. Durch Tunneling -Techniken können so auch Ports und Rechner angesprochen werden, die nicht erreichbar sein sollten. Abbildung C: Zwei Netze durch ein Gateway mit Proxy-Server verbunden Ein Rechner, der Verbindung zu zwei Netzen hat, wird als Gateway bezeichnet, wenn Verbindungen, die über diesen Rechner laufen, auf Applikationsebene realisiert werden. Bieten diese Applikationen weiterhin die Möglichkeit einer Zugriffskontrolle und eines Audits, so kann der Rechner als Gateway- Firewall genutzt werden. Als einen Proxy bzw. Proxy-Server wird ein Dämon bezeichnet, der auf einem vorher definierten Port des Gateways auf eine Verbindung eines Klienten wartet. Der Proxy-Server prüft, ob der Verbindungswunsch des Klienten erlaubt ist. Ist dies der Fall, stellt der Proxy die Verbindung zum Zielrechner her. Proxy-Server können für beliebige Protokolle eingesetzt werden. Am gebräuchlichsten sind Proxies für Telnet, FTP und HTTP. Ein wichtiger Vorteil liegt in der grossen Auswahl an Kriterien für die Zugangskontrolle. Neben den Quell- und Zieladressen sowie den Quell- und Zielports können z.b. auch Benutzername und Passwort oder Zeitangaben zusätzlich zur Überprüfung herangezogen werden. Weiterhin ist es möglich, innerhalb eines Protokolls einzelne Befehle herauszufiltern, um beispielsweise zu verhindern, dass Daten über FTP exportiert werden. Ein anderes Beispiel wäre ein HTTPProxy, der nur bekannten, ungefährlichen Code zurückliefert und alles andere blockiert bzw. für eine spätere Auswertung speichert. Ein Nachteil einer Gateway-Firewall sind wiederum die zu erwartenden Einbussen in der Performanz, da die einzelnen Pakete nicht nur geroutet, sondern bis zur Applikationsebene hochgereicht werden müssen. Durch eine Firewall erfolgt lediglich eine Zugriffskontrolle und ein entsprechendes Audit. Sie bietet jedoch keinen Schutz einzelner Verbindungen, z.b. vor Abhören. Deshalb ist es für einen äusseren Angreifer beispielsweise möglich, eine von der Firewall autorisierte telnet-verbindung zu übernehmen (hijacking) und somit in das interne Netz einzudringen. Trotz einer Firewall kann ein potentieller Angreifer einem geschützten Netz grossen Schaden zufügen oder dieses ausspionieren, indem er einen autorisierten, internen Benutzer dazu veranlasst, eintrojanisches Pferd oder einen simplen Virus im internen Netz zu starten. Als Trojanische Pferde werden Programme bezeichnet, die neben ihrer eigentlichen noch eine weitere, versteckte Aufgabe erledigen. Dabei kann es sich um die Zerstörung von Daten oder das portionierte Herausschleusen von Informationen per handeln. Ein ebenfalls nicht zu unterschätzendes Problem stellen interne Angriffe dar, d.h. von einem internen Rechner auf einen anderen im gleichen Netz. Da eine Firewall nur Verbindungen zwischen Netzen kontrolliert und keine Verbindungen interner Rechner untereinander, können Angriffe eines internen Rechners auf einen anderen im gleichen Netz nicht durch diese Firewall verhindert oder protokolliert werden. Heinrich Vogt

15 4. Policy 4.1 Einleitung Die Absicherung eines vernetzten Systems stellt, heute mehr denn je, eine komplexe Aufgabe dar. Nicht nur in Bereichen mit von Natur aus hohem Sicherheitsbedürfnis, wie zum Beispiel bei Banken oder dem Militär, sondern im alltäglichen Einsatz von vernetzten Systemen sind die Verfügbarkeit und Verlässlichkeit, und damit die Sicherheit dieser Systeme, ein wichtiger Faktor. Vernetzte Systeme werden immer mehr in unternehmenskritischen Bereichen eingesetzt, deren Sicherheit unbedingt gewährleistet werden muss. Auch die zunehmende Einführung von ecommerce und Online-Banking, also der Abwicklung von Geschäften mittels Computern über das Internet, stellt einen Bereich mit hohem Schutzbedürfnis dar. Hier werden durch einen Angriff auf die Sicherheit eines Systems nicht allein Daten des Betreibers gefährdet, sondern auch solche von Kunden und Geschäftspartnern (persönliche Daten, Kreditkartennummern usw.). Mit den wachsenden Aufgaben ist die Komplexität der eingesetzten Systeme stark gestiegen, was ihre Absicherung weiter erschwert. Neben der grösseren Anzahl an Servern, die über das Internet erreichbar sind, ist ein Grund hierfür besonders die Verfügbarkeit von Standard Software (sog. Cracker-Tools), um Angriffe auf entfernte Systeme automatisch und ohne grosses technisches Wissen durchzuführen. You can have easy, cheap or secure. Pick two! Internet-Weisheit _ Ebenso vielfältig wie die Zahl der möglichen Angriffe auf ein vernetztes System ist die Zahl der vorgeschlagenen Lösungsmöglichkeiten. Je nach Prioritäten und gewünschtem Grad von Sicherheit gibt es ganz unterschiedliche Ansätze und Vorgehensweisen, die sich oft ergänzen, manchmal aber auch behindern oder gegenseitig ausschliessen. Sicherheitsmassnahmen verhindern leider nicht nur die unrechtmässige Nutzung eines Systems, sondern sie behindern meistens auch die Arbeit der rechtmässigen Benutzer. Auch die Kosten für die Absicherung eines Systems sind oft beträchtlich. Somit stellen Sicherheitsmassnahmen immer auch einen Kompromiss von Sicherheit gegenüber Benutzbarkeit und Wirtschaftlichkeit dar. Aus all diesen Gründen ist eine Policy, also ein Gesamtkonzept, das Ziele, Mittel und Verantwortliche der Bemühungen um Sicherheit definiert und gliedert, hier zwingend erforderlich. Nur wenn klar definiert ist, was von wem wie geschützt werden soll, kann die Fülle der möglichen Sicherheitsmassnahmen effektiv angewendet und so der Aufgabe der Absicherung effektiv und effizient begegnet werden. 4.2 Definition und Aufbau einer Policy Sicherheit im Sinne einer Policy A system is secure if it behaves the way you expect it will. Die Sicherheit eines Systems ist immer ein relativer Begriff. Dies gilt für jeden einzelnen der Teilbereiche, die den Begriff der System-Sicherheit ausmachen: Heinrich Vogt

16 Verfügbarkeit Vertraulichkeit Integrität Konsistenz Kontrolle Audit Um nun die Sicherheit eines Systems zu bewerten, wird ein Ist-Zustand mit einem Soll-Zustand verglichen. Ein System ist dann sicher, wenn diese beiden Zustände übereinstimmen. Während sich der Ist-Zustand meistens unmittelbar aus dem betrachteten System ergibt, muss der Soll- Zustand vorab definiert und niedergeschrieben werden. Dabei wird jeder einzelne dieser Teilbereiche bewertet und festgelegt, wieweit und durch welche Massnahmen die Sicherheit hier gewährleistet werden soll. Ausschlaggebend ist hier der Wert der zu schützenden Systeme und Daten (materiell wie immateriell) bzw. der Schaden, der bei einem Bruch der Sicherheit auftritt, sowie ausserdem die technischen Möglichkeiten der Absicherung. Jedes System und jede Gruppe von Nutzern des Systems hat individuell unterschiedliche Bedürfnisse, auf die die Massnahmen jeweils zugeschnitten werden müssen Inhalt und Struktur einer Policy Eine Policy ist eine Niederlegung von Zielen, Konzepten und Methoden in einer allgemeinen und nicht-technischen Weise. Sie ist das Gesamtkonzept für einen genau definierten Gültigkeitsbereich, zum Beispiel eine Firma. Obwohl die obige Definition aus einer Zeit vor Computern oder Netzwerken stammt, hat sich diese bis heute praktisch nicht geändert, und sie deckt sich weitgehend mit dem Begriff der Policy, wie er heute bei der Absicherung von vernetzten Systemen gebraucht wird. Die Regelungen, die in einer Policy getroffen werden, stellen immer Kompromisse oder Abwägungen dar. Neben technischen Aspekten spielen hier besonders betriebswirtschaftliche und (firmen-) politische Überlegungen eine Rolle. Da absolute Sicherheit nie zu erreichen ist, muss für jeden Bereich entschieden werden, wie weit Bemühungen um Sicherheit gehen dürfen, damit sich deren Anwendung und Umsetzung noch lohnt und diese nicht zu einschränkend sind. Beispielsweise könnte eine Policy zwischen einem filternden HTTP-Proxy auf der eine Seite und einem freien Zugang zum WWW auf der anderen Seite abwägen. Ist zum Beispiel die Bedrohung durch aktive Inhalte wie JavaScript so gross, dass die Benutzer keinen freien WWW-Zugang erhalten sollten? Ein anderer Kompromiss könnte bei der Absicherung des Netzwerkverkehrs notwendig werden. Sollen Daten schon auf der Schicht 3 (z.b. IP) verschlüsselt werden, was den Nutzen von Packet- Screens erheblich einschränkt oder lieber allein auf eine Firwall vertraut werden? Hier behindern sich also zwei Sicherheitsmassnahmen gegenseitig, und eine Entscheidung muss getroffen werden. Dabei müssen die Regelungen jedoch immer umsetzbar bleiben. Es ist nicht sinnvoll, ein sehr hohes Sicherheitsmass vorzuschreiben, das theoretisch zwar alles abdeckt, aber in der Praxis nicht umsetzbar ist. Es muss auch festgeschrieben sein, wer dann für die Umsetzung der einzelnen Teilbereiche der Policy verantwortlich ist. Eine Vorschrift, dass etwas zu sein hat, ist wenig effektiv, wenn nicht gleichzeitig festgelegt ist, wer dafür Sorge trägt, dass dies auch passiert. Eine Policy klärt also: Was? (Objekte) Auf welche Dinge wird Bezug genommen? Welche Ziele sollen erreicht werden? Wer? (Subjekte) Welche Mitarbeiter sind dafür verantwortlich? Wie? (Vorgehen) Wie soll dabei vorgegangen werden? Heinrich Vogt

17 Die Regelungen, die dabei von der Policy getroffen werden, sind absolut. Sie dürfen von niemandem umgangen werden und es gibt keine Ausnahmen. Es können jedoch innerhalb der Policy selbst Ausnahmen von Regelungen festgelegt werden. Dies sind dann aber keine Ausnahmen von der Policy, sondern Ausnahmen im Sinne der Policy. Wenn eine Policy als zu einschränkend empfunden wird, kann sie geändert werden, dies sollte jedoch nur sehr selten vorkommen. Insgesamt kann man bei den Formulierungen einer Policy zwei Grundrichtungen wählen: Positiv: Es ist alles erlaubt, was nicht explizit verboten ist. Oder Negativ: Es ist alles verboten, was nicht explizit erlaubt ist. Beide Formen haben unterschiedliche Anwendungsgebiete. Die positive Form ist für eine Umgebung mit niedrigem bis mittlerem Sicherheitsniveau besser geeignet, da die Anzahl der notwendigen Regelungen kleiner gehalten wird, als bei einem hohen Niveau, bei dem viele Dinge durch die Policy ausgeschlossen werden sollen, und so wesentlich mehr Regelungen notwendig würden. Die positive Form ist jedoch möglicherweise zu liberal, da ein Fehler in der Policy wie das Vergessen einer Regelung zur Folge hätte, dass etwas erlaubt ist, was der eigentlichen Intention der Policy widerspricht. Ein Anwendungsgebiet für eine Policy mit positiven Formulierungen sind firmenweite, allgemeine Richtlinien. Die negative Form der Policy hingegen findet ihre Anwendung eher in Bereichen mit restriktiven Regelungen und höherem Sicherheitsbedürfnis. Diese Art ist jedoch möglicherweise zu restriktiv. Ein Fehler in Form einer fehlenden oder falsch formulierten Regulierung führt hier dazu, dass etwas verboten ist, was eigentlich erlaubt sein sollte. Die negative Grundrichtung bietet sich besonders für restriktive Spezial-Policies wie zum Beispiel Sicherheits- oder Datenschutz Policies an. Diese beiden Arten stellen natürlich nur Grundformen dar, die in ihrer reinen Form in der Praxis wenig zu gebrauchen sind. Hier wird man meistens eine Mischform wählen, die jedoch einen klaren Schwerpunkt auf einer der beiden Arten hat. Für eine effektive Umsetzung ist es unbedingt notwendig, dass das ganze Dokument öffentlich ist. Idealerweise zugänglich für wirklich jeden, mindestens aber öffentlich für alle, die von ihr in irgendeiner Weise betroffen sind, also alle Mitarbeiter, aber auch Kunden oder Lieferanten. Firmengeheimnisse oder Dinge, die die Sicherheit gefährden könnten, wenn sie bekannt würden, gehören nicht in eine Policy. Manche Firmen sind inzwischen dazu übergegangen, ihre Policies, sofern sie für Kunden von Interesse sein könnten, zum Beispiel im WWW zu veröffentlichen und mit ihnen als eine Art Qualitätssiegel zu werben. Policies, die für eine solche Veröffentlichung in Frage kommen, sind zum Beispiel solche über firmeninternen Datenschutz. Auf spezifische Systeme oder Mitarbeiter wird dabei kein Bezug genommen, sondern nur auf Arten von Systemen sowie Positionen und Funktionen von Mitarbeitern und Benutzern. Eine mögliche Formulierung lautet daher nicht Herr Meier ist für die S/Key-Passwörter auf dem Server foobar.fnord.com zuständig., sondern besser Für die Zugangskontrolle eines Servers ist der jeweilige Administrator verantwortlich. Heinrich Vogt

18 So ist sichergestellt, dass auch bei Änderungen von Systemen oder in der Personalstruktur keine Änderungen der Policy notwendig werden. Zusätzlich ist es im allgemeinen besser, Gebote anstatt von Verboten erlassen, soweit diese den gleichen Sinngehalt haben. Eine Policy, die aus einer langen Aufzählung von Dingen besteht, die ein Mitarbeiter alle nicht darf, wird sicher nicht so gut aufgenommen wie eine Policy mit eher positiven Formulierungen. Jeder Mitarbeiter hat für die Geheimhaltung seines Pass wortes Sorge zu tragen. ist besser als Mitarbeiter dürfen auf keinen Fall anderen Personen ihr Passwort zugänglich machen Durch die allgemeinen Formulierungen in der Policy bleiben aber auch auf jeden Fall Lücken und Unklarheiten in den Anweisungen, die sie trifft. Daher gibt es zu jeder Policy weiterführende Dokumente wie zum Beispiel Richtlinien, die die Policy mit Leben füllen, also klar definieren, wie die Anweisungen der Policy umzusetzen sind. Auf diese Dokumente wird im Abschnitt 4.3 gesondert eingegangen. Zusätzlich zu den Vorschriften, die mit einer Policy erlassen werden, sollten auch Sanktionen erarbeitet werden, die bei einem Verstoss gegen die Policy verhängt werden, sowie Vorgehensweisen, wie und wann dies passiert. Um zu gewährleisten, dass auch immer die gültige Version der Policy verfügbar ist und Anwendung findet, muss das Dokument zusätzlich noch Informationen über einen Gültigkeitsbereich und -zeitraum, eine Version und eine eindeutige Dokumenten-Identifikation tragen, sowie einen Hinweis, wo die jeweils aktuelle Version der Policy erhältlich ist. Gedruckte Versionen sollten eine Unterschrift der Person tragen, die sie in Kraft gesetzt hat (Abteilungsleiter, Vorstandsmitglied), digitale Versionen eine kryptographische Signatur. Wenn die Unterschrift auf der Papierform nur gedruckt ist, sollte vermerkt sein, wo eine Version mit einer Originalunterschrift einsehbar ist Verschiedene Arten von Policies Neben Unterschieden in Formulierung und Art der Regelungen, gibt es auch in Bezug auf den Gültigkeitsbereich verschiedene Klassen, in die sich Policies einteilen lassen. Es gibt allgemeine Policies, von einer solchen wurde im vorigen Abschnitt ausgegangen, und Spezial- Policies für einen bestimmten Bereich. Welche man wählt, hängt hauptsächlich davon ab, ob man ein festes Gerüst für alle Vorgänge erstellen, oder nur einen einzelnen Bereich, wie zum Beispiel die Sicherheit von EDV-Anlagen, genauer regeln möchte. Eine allgemeine Policy regelt alle Vorgänge innerhalb ihres Gültigkeitsbereiches. Ein solches Dokument kann jedoch, besonders bei grossen Firmen, schnell unübersichtlich und unhandlich werden, sowohl für den Leser als auch für diejenigen, die die Policy betreuen und pflegen. Daher kann es sinnvoll sein, eine Policy in verschiedene einzelne Dokumente aufzuspalten. Beispiele für Policies und mögliche Regelungen: Benutzer-Policy: Welche Arten von Accounts gibt es? Welche Rechte und Pflichten haben diese jeweils? Netzwerk-Policy: Was ist normaler Netzwerk-Verkehr? Wer darf welche Ressourcen nutzen? Was ist bei Ausfällen zu tun? Backup-Policy: Welche Daten werden wann gesichert? Heinrich Vogt

19 Wer sichert und verwaltet die Daten? Audit-Policy: Welche Audit-Daten werden gesammelt? Wie werden diese aufbereitet und gespeichert? Wer hat Zugriff auf diese Daten? Bei dieser Aufteilung wird nun jeder Teilbereich durch eine eigene Policy geregelt, wobei alle diese Teil-Policies zusammen wieder ein Gesamtkonzept ergeben. Durch die kleineren Einheiten bleiben diese gut verständlich und sind einfacher zu handhaben und zu pflegen. Die Erstellung einer Gesamtpolicy ist ein aufwendiger und komplexer Vorgang, der viel Zeit benötigt und damit Kosten erzeugt. Besonders kleinere Firmen werden hiervor zurückscheuen und meistens eine schlankere Lösung bevorzugen, die nur einzelne Bereiche abdeckt, die von besonderem Interesse sind. Dies kann duch eine Sicherheits-Policy geschehen. Dies ist eine Policy, die nur Punkte der Sicherheit der Daten und Dienste betrachtet, Dinge von nur allgemeiner Bedeutung jedoch aussen vor lässt. Als dritte Form von Policies gibt es Spezial-Policies, die nur einen einzelnen Bereich abdecken, der besondere Beachtung benötigt; zum Beispiel die Zertifizierungs-Policy einer Policy Certification Authority (PCA). Hier hat die Policy neben der alleinigen Regelung auch die Funktion, Dienste und Vorgänge nach aussen zu dokumentieren. 4.3 Ziele einer Policy Durch eine gemeinsame Policy wird innerhalb ihres Geltungbereiches eine gemeinsame Arbeits- Grundlage über Ziele, Vorgehensweisen und Begrifflichkeiten gelegt. Erst durch eine Policy ist eine effektive Umsetzung von Sicherheit, sowie die Kontrolle deren Umsetzung möglich. Die Policy regelt und legt Ziele fest, gibt Anleitung, wie diese umzusetzen sind, und bietet einen Massstab für die Qualität der Umsetzung. Damit kann auch eine Dokumentation von Leistungen und deren Qualität nach aussen, also an Kunden und Vertragspartner, stattfinden. 4.4 Zusätzliche Dokumente: Standards und Richtlinien Die Regelungen und Formulierungen innerhalb einer Policy sind zwar bindend für den jeweiligen Bereich, aber sie sind auch im Normalfall nur allgemein formuliert und legen lediglich ein Gerüst fest, nach dem vorgegangen werden soll. Damit diese Regelungen wirklich effizient angewendet werden können, müssen sie noch mit Leben gefüllt werden, das heisst, es muss festgelegt werden, wie diese Regelungen zu verstehen sind und wie sie in der Praxis angewendet und durchgeführt werden sollen. Zu diesem Zweck werden der Policy weitere Dokumente beigestellt. Das Verhältnis ist hier ähnlich wie bei einem Gesetz und dessen Durchführungsverordnungen und Kommentartexten. Besonders bei ausführlichen Policies gibt es hier mehrere Ebenen an Dokumenten, die unterhalb der Policy angeordnet werden. Die Ausführlichkeit hängt jedoch auch hier wieder stark von der jeweiligen Situation ab. Eine mögliche Hierarchie ist: Policy: Die Policy ist absolut bindend, jedoch nur sehr kurz und allgemein gefasst. Sie sollte jedem Mitarbeiter ausgehändigt werden und bekannt sein. Standard: Ein Standard gestattet seltene Ausnahmefälle, ist aber ausführlicher und detaillierter. Er richtet sich an eine kleinere Personengruppe, wie zum Beispiel eine Abteilung oder eine bestimmte Art von Mitarbeitern. Heinrich Vogt

20 Richtlinie bzw. Handbuch: Eine Richtlinie ist nur schwach bindend, aber sehr ausführlich und spezifisch. Sie richtet sich nur an die Person, die die beschriebene Aufgabe in der Praxis durchführt. Richtlinien für einzelne Bereiche können zu Handbüchern zusammengefasst werden, zum Beispiel die Richtlinien zu Datensicherung und Speicherung von Daten zu einem Handbuch Datenhaltung. Je weiter oben ein Dokument in dieser Hierarchie steht, desto bindender ist es und um so weniger Ausnahmen lässt es zu. Je weiter unten ein Dokument steht, desto ausführlicher und spezifischer werden die Anweisungen und Erklärungen und desto kleiner wird der Personenkreis, für den das Dokument relevant ist. Da sich alle Dokumente nur auf Funktionen von Mitarbeitern und Einrichtungen beziehen, muss zu jeder Zeit klar ersichtlich sein, welche Mitarbeiter jeweils aktuell diese Funktionen ausüben. Legt z.b. ein Standard eine Aufgabe in den Bereich eines Operators, dann muss klar ersichtlich sein, welche Mitarbeiter als Operatoren tätig sind und wann diese Dienst haben. Auch diese Aufstellungen sollten jedem Mitabeiter zugänglich sein, für den ein jeweiliges Dokument gilt. Eine Regelung zur Datensicherung könnte im obigen Modell folgendermassen formuliert werden: Policy: Alle kritischen Daten müssen regelmässig gesichert werden. Standard: Backups sollen wöchentlich durch den Operator auf ein geeignetes Medium vorgenommen werden. Richtlinie: Backups sollten an jedem Freitagabend mit dem Programm tar auf DAT-Band gespeichert und mindestens ein Jahr gelagert werden. Nach dem Schreiben sollte das Band durch Wiedereinlesen auf Korrektheit geprüft werden. Bei diesen Beispielen stellen die Formulierungen für Richtlinie und Standard jeweils natürlich nur einen kleine Auszug des Textes zur Umsetzung des jeweils darüberliegenden Dokumentes dar. Während die Aufgabe einer Policy weitgehend darin besteht, Ge- und Verbote auszusprechen, haben der Standard und besonders die Richtlinien zusätzlich auch helfende und erklärende Aspekte. Sie legen nicht nur fest, welche Dinge getan werden sollen, sondern geben Hilfen wie dies am sinnvollsten und effizientesten erreicht werden kann und idealerweise auch, in begrenztem Rahmen, warum eine Regelung so gewählt wurde. Die Dokumente, die einer Policy beigefügt sind, sollen den Benutzern in erster Linie helfen, die Policy korrekt und ohne grosse Behinderungen umzusetzen bzw. anzuwenden. 4.5 Erstellung und Umsetzung einer Policy Voraussetzungen und Vorbereitungen Die Erarbeitung einer Policy ist ein komplexes und aufwendiges Projekt, das sorgfältig geplant und vorbereitet werden muss, um zu gelingen. Dies liegt zum einen daran, dass keine zwei Policies gleich sind und für jede Firma individuell ein Konzept erstellt werden muss, zum anderen daran, dass Nachbesserungen, aufgrund der Natur dieses Dokumentes, besonders ärgerlich sind und in der Umsetzung abermals grosse Kosten erzeugen können, wenn ein ganzer Betrieb auf die geänderte Policy umgestellt wird. Die Erstellung einer Policy für eine Firma kann durch eigene Mitarbeiter geschehen oder als Auftrag an eine externe Beraterfirma gegeben werden. Eine Erstellung durch eigene Mitarbeiter hat den Vorteil, dass diese die Betriebsabläufe sehr wahrscheinlich besser kennen und Heinrich Vogt