entwickler.com

Wie angekündigt geht es diese Woche um die Erweiterung der technischen Möglichkeiten und ihr organisatorisches Konzept: Die Sicherheitsrichtlinien (Security Policy). Die technischen Schutzvorrichtungen wie z.B. Firewall, Intrusion-Detection- und Prevention-System oder Honeypot schützen vor vielen Gefahren, die sich aus der Anbindung eines Netzwerks an das Internet ergeben. Aber damit sie das richtig tun können, müssen sie auch richtig eingesetzt werden. Eine Firewall weiß nicht von sich aus, welche Pakete sie abweisen und welche sie passieren lassen soll. Dafür muss sie entsprechend konfiguriert werden. Ebenso ein IDS: Welche Pakete einen Alarm auslösen sollen und welche harmlos sind, muss definiert werden. Diese und alle weiteren sicherheitsrelevanten Maßnahmen und Entscheidungen müssen irgendwo festgelegt werden. Dieses "Irgendwo" sind die Sicherheitsrichtlinien. Kurz gesagt geht es dabei darum, verbindlich festzulegen, wie das IT-System geschützt wird und was zu tun ist, wenn seine Sicherheit gefährdet wird.

Dabei ist es nicht damit getan, einmal Sicherheitsrichtlinien festzulegen. Diese müssen laufend an die sich ändernden Bedingungen in Unternehmen (z.B. Hinzukommen neuer Anforderungen) und Umfeld (z.B. Auftreten neuer Bedrohungen) angepasst werden. Dafür hat sich ein schrittweises Vorgehen, wie es in vielen Normen (z.B. ISO 13335, BS 7799,...) beschrieben wird, bewährt. Dabei wird von vier Projektphasen ausgegangen:

• (Sicherheits-)Ziele setzen,
• Risiken erkennen und minimieren ("Risikomanagement"),
• entsprechende Schutzmaßnahmen umsetzen und
• deren Wirksamkeit sicherstellen.

Hauptziel der IT-Sicherheit ist der zuverlässige Betrieb der IT-Systeme entsprechend den Notwendigkeiten der Geschäftsprozesse. Das konkrete Ziel einer Sicherheitslösung können dabei je nach Anwendungsfall Effektivitätsziele (z.B. "maximale Sicherheit"), ergonomische Ziele (z.B. "möglichst einfache Bedienung") oder ökonomische Ziele (z.B. "minimale Anschaffungs- oder Betriebskosten") sein. Im Rahmen der Zielsetzung werden die einzelnen Ziele entsprechend ihrer Wichtigkeit bewertet, um bei sich widersprechenden Einzelzielen trotzdem ein optimales Ergebnis zu erreichen.

Beim Risikomanagement sind die bestehenden Risiken zu analysieren, entsprechende Schutzmaßnahmen auszuwählen und deren Umsetzung entsprechend der jeweiligen Priorität zu planen. Bei der Risikoanalyse wird das zu analysierende System vom Rest der IT-Welt abgegrenzt und in Einzelkomponenten oder Gruppen davon gegliedert. Jede Komponente bzw. Gruppe wird entsprechend ihrer Bedeutung für das Unternehmen bewertet. Danach werden mögliche Bedrohungen und Schwachstellen sowie vorhandene Schutzmaßnahmen untersucht. Darauf aufbauend werden die jeweiligen Risiken und geeignete Schutzmaßnahmen ermittelt. Danach kann entschieden werden, ob ein bestehendes Risiko toleriert und als unternehmerisches Risiko getragen werden kann oder ob ein zu hohes Risiko durch Schutzmaßnahmen auf ein akzeptables Maß reduziert werden soll.

Die Schutzmaßnahmen werden in drei Kategorien unterteilt:

• Organisatorische Schutzmaßnahmen optimieren die betrieblichen Abläufe.
  Beispiele sind der Umgang mit den Zugangs- und Zugriffsrechten eines Mitarbeiters bei dessen Ausscheiden, Vertretungsregelungen beim Ausfall eines Administrators usw.
• Administrative Schutzmaßnahmen optimieren die Verwaltung der IT-Systeme.
  Beispiele sind die Administration der Firewall, die Überwachung von Intrusion-Detection- und -Prevention-Systemen oder der Umgang mit Sicherheitsupdates. Auch die Kontrolle von Umsetzung, Weiterentwicklung und Wirksamkeit der Schutzmaßnahmen gehören dazu.
• Technische Schutzmaßnahmen stellen durch den Einsatz von Hard- und Software den gewünschte Schutz her.
  Beispiele sind Firewall, IDS/IPS, Virenscanner oder Verschlüsselungssoftware.

Um die Wirksamkeit der Schutzmaßnahmen sicherzustellen sind diese an drei Anforderungsbereiche auszurichten und regelmäßig zu überprüfen und weiterzuentwickeln:

• Systembedingte Anforderungen, die sich z.B. aus vorhandenen Schwachstellen oder Einschränkungen ergeben.
• Interne Anforderungen, z.B. neu hinzukommende Schutzfunktionen, Änderungen in der Organisation oder ein erhöhter Wert der zu schützenden Daten.
• Externe Anforderungen, z.B. das Bekanntwerden neuer Schwachstellen oder Angriffe.

Die Überprüfung der Wirksamkeit erfolgt z.B. durch Penetrationstests der Firewall-, Intrusion-Detection- und -Prevention-Systeme oder eine Kontrolle der Umsetzung der organisatorischen Schutzmaßnahmen. Dabei erkannte Schwachstellen sind, ggf. durch eine Anpassung der Sicherheitsrichtlinien, zu beheben. Im Rahmen der Weiterentwicklung sind die sich durch neu hinzukommende Anforderungen ergebenden Schutzmaßnahmen in die Richtlinien aufzunehmen bzw. vorhandene Schutzmaßnahmen entsprechend anzupassen.

Nächste Woche wird die Entwicklung von Sicherheitsrichtlinien an einem Beispiel demonstriert.

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 (#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