Montag, 1. März 2010


Topthema

Mittwoch, 10. Mai 2006 | Topthema

About Security #55: Security Policy — Ein Beispiel, 2

(Link zum Artikel: http://www.entwickler.de/php/kolumnen/028472)

Organisatorische und administrative Schutzmaßnahmen ergänzen die in About Security #54 festgelegten technischen Schutzmaßnahmen für Web-, Application- und Datenbankserver. 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 (About Security #30) erfolgen: Ein Personalsachbearbeiter 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: 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".

N E U ! Security aktuell
Täglich aktuelle Security-Infos!

Notfallkonzept

Außer den vorbeugenden Schutzmaßnahmen ist ein Notfallkonzept (ü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 bestimmten 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 er das betroffene System am besten kennt. 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 in Betrieb zu lassen, vertretbar? Ebenso sind Regelungen für z.B. die Kompromittierung eines Servers oder auch einfach nur für den Fall eines Stromausfalls zu treffen.

Wirksamkeit prüfen
About Security: Die komplette Serie

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 Schwachstellen-Scan 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 Zugriff 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. Ein IPS kann mögliche Angriffe abwehren.

Netzwerk der Bratkartoffel-KG mit Paketfilter und IPS vor dem internen Server

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. Böswillige Mitarbeiter, denen der richtige Server bekannt ist, werden auf den Honeypot allerdings selten hereinfallen.

Netzwerk der Bratkartoffel-KG mit Honeypot

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.

Wenn Sie Fragen oder Themenvorschläge haben, können Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

About Security – Übersicht zum aktuellen Thema "Entwicklung einer Security Policy"

Kommentare

Folgende Links könnten Sie auch interessieren