entwickler.com

Wie angekündigt wird diese Woche die weitere Entwicklung der Beispiel-Sicherheitsrichtlinie beschrieben. Nachdem letzte Woche die technischen Schutzmaßnahmen für Web-, Application- und Datenbankserver festgelegt wurden, sind nun die dazu gehörenden organisatorischen und administrativen Schutzmaßnahmen an der Reihe. 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 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: 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".

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 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 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.

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? ...

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.

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.

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

Carsten Eilers

• About Security (#1): IT-Sicherheit – Was ist das eigentlich?
• About Security (#2): Angriffsszenarien
• About Security (#3): Eindringlinge abwehren
• About Security (#4): Gefährdung aus der Peripherie
• About Security (#5): Der Pufferüberlauf
• About Security (#6): Ausnutzung von Pufferüberlauf-Schwachstellen
• About Security (#7): Gegenwehr – Pufferüberläufe verhindern
• About Security (#8): Vorbeugung – Pufferüberläufe verhindern
• About Security (#9): Sourcecode Audit – Pufferüberläufe finden
• About Security (#10): Software-Audit – Schwachstellensuche in Binaries
• About Security (#11): SQL-Injection
• About Security (#12): SQL-Injection verhindern
• About Security (#13): Mit Stored Procedures gegen SQL-Injection
• About Security (#14): Cross-Site Scripting
• About Security (#15): Cross-Site Scripting verhindern
• About Security (#16): Skriptcode einschleusen
• About Security (#17): HTTP Request Smuggling
• About Security (#18): Spielarten des HTTP Request Smuggling, 1
• About Security (#19): Spielarten des HTTP Request Smuggling, 2
• About Security (#20): HTTP Request Smuggling erkennen und verhindern
• About Security (#21): HTTP Response Splitting, 1
• About Security (#22): HTTP Response Splitting, 2
• About Security (#23): Caches vergiften
• About Security (#24): Caches indirekt vergiften
• About Security (#25): Entführen von Webseiten
• About Security (#26): Gefahren für Webanwendungen
• About Security (#27): Gefahren für Webserver
• About Security (#28): Standorte für Webserver
• About Security (#29): Die Firewall, 1
• About Security (#30): Die Firewall, 2
• About Security (#31): Die Firewall, 3
• About Security (#32): Die Firewall, 4
• About Security (#33): Die Firewall, 5
• About Security (#34): Die Firewall, 6
• About Security (#35): Die Firewall, 7
• About Security (#36): Die Firewall, 8
• About Security (#37): Logfiles – Welche Daten speichern?
• About Security (#38): Logfiles – Wie auswerten?
• About Security (#39): Paketfilter-Logfiles manuell auswerten
• About Security (#40): HTTP-Proxy-Logfiles manuell auswerten,1
• About Security (#41): HTTP-Proxy-Logfiles manuell auswerten, 2
• About Security (#42): Intrusion-Detection-Systeme – Grundlagen
• About Security (#43): Intrusion-Detection-Systeme – Positionierung
• About Security (#44): IDS-Kommunikation
• About Security (#45): IDS in hochverfügbaren Netzen
• About Security (#46): Angriffe auf IDS
• About Security (#47): Beispiele für IDS-Regeln
• About Security (#48): Umsetzung der IDS-Beispiele mit Snort
• About Security (#49): Intrusion Prevention
• About Security (#50): Honeypots
• About Security (#51): Ein Honeypot – Honeyd
• About Security (#52): Firewall, IDS, IPS & Honeypot
• About Security (#53): Security Policy
• About Security (#54): Security Policy – Ein Beispiel