Verteidigungsprinzipien
Die grundlegenden Konzepte Defense in Depth und Security by Design hast du in Modul B1 – Grundlegende Sicherheitskonzepte bereits kennengelernt. Hier betrachten wir sie gezielt im Kontext der Anwendungs- und Dienstsicherheit und ergänzen sie um ein Prinzip, das in der Praxis oft den Unterschied macht: die Härtung nach Hersteller-Richtlinien. Kurz zur Wiederholung:
Defense in Depth (Verteidigung in der Tiefe) bedeutet: Verlasse dich niemals auf eine einzige Schutzmaßnahme. Baue stattdessen mehrere Schutzschichten auf, sodass ein Angreifer mehrere Hürden überwinden muss. Wenn eine Schicht versagt, hält die nächste.
Konkret auf eine Webanwendung angewendet, kann jede eingehende Anfrage mehrere Sicherheitsebenen durchlaufen:
- Netzwerk-Verschlüsselung: Daten werden beim Transport (HTTPS) und bei der Speicherung verschlüsselt
- Firewall: filtert unerwünschten Netzwerkverkehr auf Netzwerkebene
- Web Application Firewall (WAF): prüft HTTP-Verkehr gezielt auf Angriffe wie SQL-Injection oder XSS
- Authentifizierung: der Nutzer muss sich mit gültigen Zugangsdaten ausweisen
- Autorisierung: es wird geprüft, ob der Nutzer die angeforderte Ressource überhaupt sehen darf
- Input-Validierung: alle Eingaben werden geprüft, bevor sie verarbeitet werden
- Datenträger-Verschlüsselung: Daten werden bei der Speicherung verschlüsselt
- Monitoring und Logging: Zugriffe werden protokolliert und auf Anomalien überwacht
Die nachfolgende Abbildung verdeutlicht die Sicherheitsebenen noch einmal grafisch:
Mitlesen der Daten wird durch Transportverschlüsselung verhindert. Wenn ein Angreifer die Firewall umgeht, steht er vor der WAF. Wenn er die WAF umgeht, muss er sich authentifizieren. Selbst wenn er sich Zugang verschafft, verwehrt ihm die Autorisierung möglicherweise den Zugriff auf sensible Daten. Hat er Zugriff auf den Server, verhindert die Datenträgerverschlüsselung, dass er auf die Daten zugreifen kann. Währenddessen werden alle verdächtigen Bewegungen überwacht und protokolliert, sodass auf Anomalien zeitnah reagiert werden kann.
Security by Design ergänzt dieses Schichtmodell durch einen zeitlichen Aspekt: Sicherheit muss von Anfang an mitgedacht und nicht erst nachträglich hinzugefügt werden, wenn Sicherheitslücken festgestellt werden.
Je später ein Sicherheitsproblem entdeckt wird, desto teurer und aufwändiger ist die Behebung. Ein Architekturproblem, das erst im Produktivbetrieb auffällt, erfordert möglicherweise einen kompletten Umbau der Anwendung.
In der Praxis bedeutet das:
- Threat Modeling bereits im Design: Schutzmaßnahmen schon in der Architektur verankern und sich immer die folgende Frage stellen: Was könnte ein Angreifer tun, um unsere Anwendung zu kompromittieren?
- Angriffsoberfläche minimieren: Nur aktivieren, was wirklich gebraucht wird. Unnötige Ports, Schnittstellen und Debug-Funktionen deaktivieren, bevor die Anwendung produktiv geht.
- Sichere Standardeinstellungen: Die Standardkonfiguration einer Anwendung sollte sicher sein. Sicherheit darf keine Option sein, die der Administrator erst einschalten muss.
Best-Practice-Konfiguration nach Hersteller-Richtlinien
Jeder seriöse Software-Hersteller veröffentlicht Sicherheitsrichtlinien für seine Produkte. Diese Richtlinien beschreiben, wie ein Produkt sicher konfiguriert und betrieben werden soll. Zudem gibt es generelle Sicherheitsrichtlinien verschiedener Institutionen. Sie zu kennen und umzusetzen ist kein optionaler Bonus, sondern Voraussetzung für den sicheren Betrieb. Beispiele für solche Richtlinien sind die folgenden. Klicke auf die Titel für weitere Informationen:
Microsoft veröffentlicht für jedes Windows-Produkt detaillierte Sicherheitskonfigurationen. Diese können als GPOs (Group Policy Objects) direkt in Active-Directory-Umgebungen importiert werden.
Das Center for Internet Security erstellt herstellerunabhängige Härtungsleitfäden für Betriebssysteme, Server, Cloud-Dienste und Anwendungen. Die Benchmarks beschreiben Schritt für Schritt, welche Einstellungen vorgenommen werden sollten.
Das Bundesamt für Sicherheit in der Informationstechnik stellt Bausteine bereit, die konkrete Maßnahmen für verschiedene Systeme und Szenarien definieren. In Modul B1 hast du auch schon andere Security Frameworks kennengelernt, die umfangreiche Maßnahmen-Kataloge bereitstellen.
Apache, Nginx, PostgreSQL, VMware, Cisco… praktisch jeder namhafte Hersteller hat eigene Hardening Guides.
Beispiele:
– https://httpd.apache.org/docs/2.4/misc/security_tips.html
– https://docs.nginx.com/nginx/admin-guide/security-controls/
– https://www.postgresql.org/support/security/
– https://www.vmware.com/resources/hardening-guides
– https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/hardening/threat_defense/Threat_Defense_Hardening_Guide_v76.html
„Aber warum ist das so ein großes Problem? Ist die Software an sich denn so unsicher?“
„Nein, aber Standardkonfigurationen sind fast nie sicher – auch wenn sie es sein sollten. Sie sind oft darauf ausgelegt, einen Dienst oder eine Anwendung schnell funktionsfähig zu machen und nicht darauf, direkt super sicher zu sein, da das oft auch gewisse Einschränkungen der Funktionalität mitbringt.“
Beispiele für unsichere Standardkonfigurationen sind z.B. folgende Situationen:
– Standardpasswörter öffentlich bekannt (admin/admin)
– Debug-Modi aktiviert
– Beispielseiten verraten die Software-Version
– Nicht benötigte Dienste laufen parallel mit
In Kursmodul B6 haben wir bereits über die Härtung der Endgeräte gesprochen – das gilt sinngemäß natürlich auch für zentrale Systeme und Anwendungen. Härtung in der Praxis folgt einem einfachen Grundsatz: Alles, was nicht benötigt wird, wird deaktiviert oder entfernt. Alles, was benötigt wird, wird sicher konfiguriert. Eine typische Härtungs-Checkliste umfasst:
- Standardpasswörter und -konten ändern oder entfernen
- Unnötige Dienste, Ports und Schnittstellen deaktivieren
- Software und Betriebssystem aktuell halten (Patch-Management)
- Dateiberechtigungen nach Least Privilege setzen
- Logging und Monitoring aktivieren
- Konfiguration regelmäßig gegen den Soll-Zustand prüfen (Compliance-Checks)
Mal sehen ob du aufgepasst hast. Bewerte die folgende Aussage: