entwickler.com

Wie angekündigt wird diese Woche die Entwicklung der Beispiel-Sicherheitsrichtlinie mit dem Schutz des restlichen lokalen Netzes abgeschlossen. Für die Risikoanalyse wird das restliche lokale Netz in Gruppen mit gleicher Bedeutung für das Unternehmen und damit gleichem Schutzbedarf aufgeteilt. Die Teile entsprechen in diesem Fall den verschiedenen Teilnetzen. Nach dieser Aufteilung sind für die einzelnen Teile die Risiken und mögliche Schutzmaßnahmen zu ermitteln. Dies erfolgt analog zur Entwicklung der Sicherheitsrichtlinie für Web-, Application- und Datenbankserver (About Security #54 und #55) oder internen Server (About Security #55).

Zusätzlich muss das gesamte Netz betrachtet werden, da einige der Teilnetze miteinander kommunizieren müssen, um das Unternehmensziel zu erreichen. Diese notwendige Kommunikation muss ebenfalls sichergestellt werden. Es wäre sehr ungünstig, wenn zwar alle Teile separat wunderbar funktionieren, eine Zusammenarbeit aber aufgrund eines gestörten Netzwerks nicht möglich ist. Dafür kann man wieder einmal die Frage "Wer darf was wo?" stellen: Welche Verbindungen sind notwendig? Und was passiert, wenn die entsprechende Kommunikation fehlschlägt?

Zwei Beispiele:

• Die EDV-Abteilung soll zur Fernwartung auf alle Teilnetze zugreifen. Funktioniert dies nicht, müssen sich die Mitarbeiter zu Fuß auf den Weg machen. Das ist zwar lästig, beeinträchtigt aber das Erreichen des Unternehmensziels nicht.
• Die Maschinen in der Produktion erhalten ihre Steuerdaten vom zentralen Server und fordern benötigte Rohstoffe zum Teil automatisch aus den Lagern an. Kommt es hier zu Störungen, ist eine reibungslose Produktion gefährdet. Eine manuelle Umprogrammierung der Maschinen ist aufwändig und störanfällig, teilweise ist sie vielleicht sogar unmöglich. Daher ist eine ungestörte Kommunikation unerlässlich, entsprechend müssen Risiken möglichst ausgeschlossen werden.

Da eine ständige Verbindung der Teilnetze untereinander notwendig ist, betrifft ein möglicher Angriff u.U. alle Systeme. Entsprechend müssen Schutzmaßnahmen ergriffen werden, um die Auswirkungen eines Angriffs oder einer Störung zu begrenzen.

Bevor Schutzmaßnahmen ausgewählt werden können, sind mögliche Risiken zu ermitteln. Ein externer Angreifer sollte schon von Firewall und IPS gestoppt worden sein, sodass nur noch Angriffe von innen betrachtet werden müssen. Sollte ein externer Angreifer einen Weg durch Firewall und IPS finden und die Kontrolle über einen Rechner im lokalen Netz übernehmen, kann er danach wie ein interner Angreifer betrachtet werden.

Interne Angreifer verraten sich z.B. durch anomales Verhalten: Sie versuchen z.B., unbefugt auf Daten und Geräte zuzugreifen oder führen andere Aktionen durch, die im normalen Betrieb nicht vorkommen. Um solche Aktionen zu erkennen, bietet sich der Einsatz eines Intrusion-Detection- oder -Prevention-Systems an, das mit einer Anomalie-Erkennung arbeitet. Dies kann auch Schadprogramme erkennen, da diese ebenfalls ein ungewöhnliches Verhalten zeigen. Egal ob es sich um einen absichtlich eingeschleusten, speziell für den Angriff auf das Unternehmen entwickelten Trojaner oder einen unabsichtlich eingeschleppten "Standard"wurm oder -virus handelt, alle verraten sich früher oder später durch ungewöhnliches Verhalten. Schleppt z.B. ein Mitarbeiter unwissentlich über ein mobiles Gerät einen Wurm ein, könnte der sich ohne Schutzmaßnahmen im gesamten lokalen Netz ausbreiten. Ein IPS vor bzw. in allen Teilnetzen kann diese Ausbreitung verhindern oder verlangsamen und einen Alarm auslösen.

Zusätzlich zu den IPS können die einzelnen Teilnetze je nach Schutzbedarf durch Firewallkomponenten, weitere IPS und IDS, Virenfilter usw. geschützt werden.

Neben diesen direkt das Netzwerk betreffenden Maßnahmen sind weitere Punkte zu beachten. Diese betreffen zum Beispiel die bereits erwähnten mobilen Geräte, insbesondere Massenspeicher: Ihr Einsatz kann sowohl organisatorisch als auch technisch verhindert werden. Während eine Betriebsvereinbarung den Einsatz betriebsfremder Massenspeicher verbietet und bei einem Verstoß dagegen der entsprechende Mitarbeiter abgemahnt oder sogar entlassen werden kann, ermöglichen Schutzprogramme die technische Durchsetzung dieses Verbots. Wie in "About Security: Ein Bericht von der CeBIT" beschrieben, erlauben solche Programme eine sehr feine Einteilung in erlaubte und verbotene Geräte bis hin zur Zulassung eines einzelnen, spezifischen USB-Sticks bei gleichzeitigem Verbot aller anderen. Ein weiterer Punkt ist der Datenaustausch mit der Versuchsküche. Um die Daten sicher zu transportieren stehen verschiedene Möglichkeiten zur Verfügung. Vom USB-Stick, den ein Mitarbeiter in die Zentrale bringt, über einen Versand als verschlüsselte E-Mail bis zur Übertragung über eine gesicherte Verbindung über das Internet. Dafür können z.B. die Secure Shell (kurz SSH) oder ein Virtual Private Network (VPN, Virtuelles Privates Netz) verwendet werden.

Die sichere Kommunikation über das Internet wird in einem zukünftigen Feature behandelt. In der übernächsten Woche (nächste Woche fällt das Feature feiertagsbedingt aus) geht es um das Netzwerkprotokoll TCP/IP und mögliche Angriffe darauf.

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