Skip to content

Security Policy - Ein einfaches Beispiel, Teil 2

In dieser Folge geht es mit der Entwicklung der Sicherheitsrichtline (Security Policy) für das in der vorherigen Folge vorgestellte Beispielunternehmen weiter.

Die technischen Schutzmaßnahmen für Web-, Application- und Datenbankserver haben wir bereits festgelegt, jetzt sind die dazu gehörenden organisatorischen und administrativen Schutzmaßnahmen an der Reihe.

Die organisatorischen Schutzmaßnahmen

Im Rahmen der organisatorischen Schutzmaßnahmen muss z.B. festgelegt werden, wer welche Aufgaben zu erledigen hat und welche Zugriffsrechte er dafür benötigt. Dies kann analog zum Grundsatz "Wer darf was wo?" bei der Konfiguration eines Paketfilters erfolgen: Ein Personal-Sachbearbeiter darf auf keinen der drei Server zugreifen, ein Webentwickler hat nur auf Web- und Applicationserver Schreib- und Leserechte, für den Datenbankserver aber nur Leserechte usw..

Entsprechend kann auch der Netzwerkverkehr gefiltert werden: Nur aus den Teilnetzen der Verwaltung und EDV-Abteilung darf auf die Server zugegriffen werden, nicht aus Produktion oder Lagerhallen. Dies führt zu den administrativen Schutzmaßnahmen:

Die administrativen Schutzmaßnahmen

Wie sind die IT-Systeme zu konfigurieren, um die gewünschten Schutzmaßnahmen umzusetzen? Organisatorische Maßnahmen wie z.B. "Zugriffe sind nur aus der Verwaltung und EDV-Abteilung erlaubt" führen dabei zu einer entsprechenden Konfiguration z.B. des inneren Paketfilters: "Pakete aus dem Teilnetz a.b.c.* an Web-, Application- und Datenbankserver werden weitergeleitet; Pakete aus allen anderen Teilnetzen an diese Server verworfen".

Das Notfallkonzept

Außer den vorbeugenden Schutzmaßnahmen ist ein Notfallkonzept (Emergency Response Plan) (überlebens)wichtig: Was passiert, wenn etwas passiert?

Wenn es brennt, ruft man die Feuerwehr und versucht, bis zu deren Eintreffen mit den zur Verfügung stehenden Mitteln das Beste zu erreichen. Im IT-Bereich ist das nicht ganz so einfach: Zum einen gibt es keine öffentliche "IT-Feuerwehr", zum anderen ist ein Notfall nicht immer sofort erkennbar.

Ein Beispiel: Was passiert, wenn sich ein Wurm im Internet ausbreitet und die eigenen Systeme verwundbar sind?

Getreu dem Motto "Gefahr erkannt, Gefahr gebannt" muss die Gefahr zuerst einmal überhaupt im Unternehmen bekannt werden. D.h.: Wer ist dafür verantwortlich, sich über aktuelle Schwachstellen und Bedrohungen auf dem Laufenden zu halten und wie tut er das? Im diesem Falle könnte die Antwort lauten "Entsprechende Mailinglisten werden auf eine extra eingerichtete Mailadresse abonniert und intern an einen bestimmtem Mitarbeiter bzw. bei dessen Abwesenheit an seinen Vertreter weitergeleitet".

Weiter geht es mit der Frage, wer befugt ist, über notwendige Gegenmaßnahmen zu entscheiden und wer diese Maßnahmen ausführt. Dies wird meist der zuständige Administrator oder Projektleiter sein, da sie das betroffene System am besten kennen. Trotzdem sollte vorab z.B. geklärt werden, in welchen Fällen Patches oder Workarounds ohne weitergehende Prüfung sofort im Produktivsystem eingesetzt werden sollen. Soll ein bedrohtes System außer Betrieb genommen werden, bis ein Patch verfügbar ist, oder ist das Risiko, es ungeschützt im Betrieb zu lassen, vertretbar? Ebenso sind Regelungen für z.B. die Kompromittierung eines Servers oder auch einfach nur eines Stromausfalls zu treffen.

Schritt 4: Wirksamkeit der Maßnahmen prüfen

Nach der Ermittlung und Umsetzung der nötigen Schutzmaßnahmen gilt es, deren Wirksamkeit zu prüfen. Zum Testen der technischen Schutzmaßnahmen kann z.B. von außen ein Penetrationstest und/oder Schwachstellenscan durchgeführt werden. Um die organisatorischen und administrativen Schutzmaßnahmen zu testen kann man das beliebte "Was wäre, wenn..." durchspielen: Der für das Lesen der Mailinglisten-Mails zuständige Mitarbeiter ist nicht da - wer liest die Mails? Eine fehlerbereinigte Software steht zur Verfügung - wer installiert sie und wann tut er das? ...

Schutz des internen Netzes

Nachdem Web-, Application- und Datenbankserver gesichert sind muss noch das interne Netz geschützt werden. Zuerst soll der interne Server betrachtet werden: Die Firewall verhindert Zugriffe aus dem Internet, aber aus dem gesamten internen Netz ist der Zugriff auf den Server weiterhin möglich. Um unerwünschte Verbindungen zu verhindern kann ein Paketfilter vor dem Server positioniert werden, und ein IPS kann mögliche Angriffe abwehren, siehe Abbildung 1.

Netzwerk der Bratkartoffel KG mit Paketfilter und IPS vor dem internen Server
Abb. 1: Netzwerk der Bratkartoffel KG mit Paketfilter und IPS vor dem internen Server (Klick für großes Bild in neuem Tab/Fenster)

Das IPS befindet sich hinter dem Paketfilter, da es sonst auch den Netzwerkverkehr verarbeiten müsste, den der Paketfilter anschließend sofort verwirft. Der Nachteil dieser Kombination ist, dass vom Paketfilter abgewehrte mögliche Angriffe nicht erkannt werden. Sollen alle möglichen Angriffe erkannt werden, muss das IPS vor dem Paketfilter positioniert oder dort ein zusätzliches netzwerkbasiertes IDS installiert werden.

Als zusätzliche Schutzmaßnahme kann ein Honeypot installiert werden, um Angreifer vom internen Server abzulenken, siehe Abbildung 2. Böswillige Mitarbeiter, denen der richtige Server bekannt ist, werden auf den Honeypot allerdings selten hereinfallen.

Netzwerk der Bratkartoffel KG mit Honeypot
Abb. 1: Netzwerk der Bratkartoffel KG mit Honeypot (Klick für großes Bild in neuem Tab/Fenster)

Für organisatorische und administrative Schutzmaßnahmen gilt entsprechend das oben Geschriebene. In der nächsten Folge wird die Entwicklung der Sicherheitsrichtlinie mit dem Schutz des restlichen lokalen Netzes abgeschlossen.

Carsten Eilers

>
        </div>
                
        <footer class= Kategorien: Grundlagen

Trackbacks

Keine Trackbacks