Bundesamt für Sicherheit in der Informationstechnik

M 2.71 Festlegung einer Policy für ein Sicherheitsgateway

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Administrator, IT-Sicherheitsbeauftragter

Die Policy des Sicherheitsgateways bestimmt das Verhalten des Sicherheitsgateways. Sie definiert, welche Informationen, Dienste und Protokolle das Sicherheitsgateway wie behandelt und wer sie nutzen darf. Die Policy ist nicht zu verwechseln mit der Sicherheitsrichtlinie für das Sicherheitsgateway, in der Vorgaben für den sicheren Betrieb des Sicherheitsgateway selbst gemacht werden.

Kommunikationsanforderungen

Für die Erstellung einer Policy muss als erstes festgelegt werden, welche Arten der Kommunikation mit dem äußeren Netz zugelassen werden. Bei der Festlegung der Kommunikationsanforderungenmüssen speziell die folgenden Fragen beantwortet werden:

  • Welche Informationen dürfen durch das Sicherheitsgateway nach außen hindurch- bzw. nach innen hereingelassen werden?
  • Welche Informationen soll das Sicherheitsgateway verdecken (z. B. die interne Netzstruktur oder die Benutzernamen)?
  • Welche Authentisierungsverfahren sollen innerhalb des zu schützenden Netzes bzw. für das Sicherheitsgateway benutzt werden (z. B. Einmalpasswörter oder Chipkarten)?
  • Welche Zugänge werden benötigt (z. B. nur über einen Internet-Service-Provider oder auch über einen Modem-Pool)?
  • Welcher Datendurchsatz ist zu erwarten?

Auswahl der Dienste

Aus den Kommunikationsanforderungen wird dann abgeleitet, welche Dienste im zu sichernden Netz erlaubt werden.

Es muss unterschieden werden zwischen denjenigen Diensten, die für die Benutzer im zu schützenden Netz und denjenigen, die für externe Benutzer zugelassen werden.

Wenn zum Beispiel E-Mail empfangen werden soll (was im allgemeinen die Minimalanforderung ist) muss das Protokoll SMTP vom Sicherheitsgateway durchgelassen werden können.

In der Policy muss explizit festgelegt werden, welche Dienste für welche Benutzer und/oder Rechner zugelassen werden sollen und für welche Dienste Vertraulichkeit und/oder Integrität gewährleistet werden müssen. Es sollten nur die Dienste zugelassen werden, die unbedingt notwendig sind. Alle anderen Dienste müssen verboten werden. Dies muss auch die Voreinstellung sein: Alle Dienste, für die noch keine expliziten Regeln festgelegt wurden, dürfen nicht zugelassen werden.

Für jeden erlaubten Dienst muss festgelegt werden, welche Funktionen des verwendeten Protokolls genutzt werden dürfen und welche unterbunden werden sollen (z. B. der "PORT"-Befehl von FTP zur Verhinderung von aktivem FTP) und welche der übertragenen Nutzdaten gefiltert werden sollen (z. B. zur Kontrolle auf Computer-Viren).

Es muss festgelegt werden, zu welchen Wochentagen und Tageszeiten die bereitgestellten Dienste genutzt werden können.

Für kurzzeitige Änderungen (z. B. für Tests) oder neue Dienste sollten Ausnahmeregelungen vorgesehen werden.

Es sind Forderungen an die Filter zu stellen, und zwar einmal an die Paketfilter, die die Header-Informationen der Dienste der Schichten 3 und 4 des OSI-Schichtenmodells (IP, ICMP , ARP , TCP und UDP) verwenden, sowie an die Sicherheitsproxies, die die Informationen der Dienste der Anwendungsschicht (z. B. Telnet, FTP, SMTP, DNS , NNTP, HTTP) verwenden. Einen Überblick, was für einen sicheren Einsatz der einzelnen Protokolle und Dienste zu beachten ist, gibt M 5.39 Sicherer Einsatz der Protokolle und Dienste . Darauf aufbauend müssen Filterregeln formuliert werden (siehe M 2.76 Auswahl und Einrichtung geeigneter Filterregeln ).

Organisatorische Regelungen

Neben der sorgfältigen Aufstellung und Umsetzung der Filterregeln sind darüber hinaus folgende organisatorische Regelungen erforderlich:

  • Es müssen Verantwortliche sowohl für den Entwurf als auch für die Umsetzung und das Testen der Filterregeln benannt werden. Es muss geklärt werden, wer befugt ist, die Filterregeln z. B. für Tests neuer Dienste zu verändern.
  • Es muss festgelegt werden, welche Informationen protokolliert werden und wer die Protokolle auswertet. Es müssen sowohl alle korrekt aufgebauten als auch die abgewiesenen Verbindungen protokolliert werden. Die Protokollierung muss den datenschutzrechtlichen Bestimmungen entsprechen.
  • Die Benutzer müssen über ihre Rechte, insbesondere auch über den Umfang der Nutzdaten-Filterung umfassend informiert werden.
  • Es ist empfehlenswert, den Benutzern eine Dokumentation zur Verfügung zu stellen, aus der hervorgeht, welche Dienste in welchem Umfang genutzt werden können und ob dabei besondere Dinge zu beachten sind.
  • Angriffe auf das Sicherheitsgateway sollten nicht nur erfolgreich verhindert, sondern auch schnell erkannt werden können. Angriffe können über die Auswertung der Protokolldateien erkannt werden. Das Sicherheitsgateway sollte aber auch in der Lage sein, aufgrund von vordefinierten Ereignissen, wie z. B. häufigen fehlerhaften Passworteingaben auf einem Application-Level-Gateway oder Versuchen, verbotene Verbindungen aufzubauen, Warnungen auszugeben oder evtl. sogar Aktionen auszulösen.
  • Es ist zu klären, welche Aktionen bei einem Angriff gestartet werden, ob z. B. der Angreifer verfolgt werden soll oder ob die Netzverbindungen nach außen getrennt werden sollen. Da hiermit starke Eingriffe in den Netzbetrieb verbunden sein können, müssen Verantwortliche bestimmt sein, die entscheiden können, ob ein Angriff vorliegt und die entsprechende Maßnahmen einleiten. Die Aufgaben und Kompetenzen für die betroffenen Personen und Funktionen müssen eindeutig festgelegt sein.

Folgende Fragen müssen bei der Festlegung der Policy geklärt werden:

  • Welcher Schaden kann im zu schützenden Netz verursacht werden, wenn das Sicherheitsgateway überwunden wird? Da es keine absolute Sicherheit geben kann, muss entschieden werden, ob der maximal auftretende Schaden tragbar ist oder ob zusätzliche Maßnahmen ergriffen werden müssen.
  • Welche Restrisiken existieren bei einem ordnungsgemäßen Betrieb des Sicherheitsgateways? Dies sind z. B. Schwachstellen in den benutzten Geräten und Betriebssystemen.
  • Wie schnell wird ein Angriff auf das Sicherheitsgateway bemerkt?
  • Welche Protokoll-Informationen sind auch nach einem erfolgreichen Angriff noch verfügbar?
  • Sind die Benutzer bereit, die Einschränkungen durch das Sicherheitsgateway zu akzeptieren?

In der Policy müssen die getroffenen Entscheidungen dokumentiert werden. Darüber hinaus ist es wichtig, dass auch die für die Entscheidungen relevanten Informationen und Entscheidungsgründe so dokumentiert sind, dass sie zu einem späteren Zeitpunkt (etwa bei der Revision der Policy) nachvollzogen werden können. Diese Hintergrundinformationen brauchen nicht direkt in der Policy selbst enthalten zu sein, sondern es ist eher empfehlenswert, sie in einem eigenen Dokument festzuhalten.

Prüffragen:

  • Existiert eine Policy für das Sicherheitsgateway, die das Verhalten in Bezug auf Informationen, Dienste und Protokolle definiert und nachvollziehbar dokumentiert?

  • Ist festgelegt, dass auf dem Sicherheitsgateway ausschließlich zwingend erforderliche Dienste und Programme verfügbar sein dürfen?

  • Sind Verantwortliche benannt, die für den Entwurf sowie für die Umsetzung und das Testen der Filterregeln zuständig sind?

  • Sind Gegen-Maßnahmen bei erkannten Angriffen gegenüber dem Sicherheitsgateway definiert?

  • Verfügt das Sicherheitsgateway über Alarmierungsmöglichkeiten für vordefinierte Ereignisse?

  • Sind die bestehenden Restrisiken bei einem ordnungsgemäßen Betrieb des Sicherheitsgateways bekannt?

Stand: 13. EL Stand 2013