Einordnung der Website im Informationssicherheitsmanagement
In Scope
Dieser Beitrag ordnet Websites als geschäftsrelevante digitale Services im Kontext eines Informationssicherheitsmanagementsystems ein.
Die beschriebenen Härtungs- und Sicherheitsmaßnahmen beziehen sich überwiegend auf WordPress-basierte Websites und deren typische technische Abhängigkeiten, insbesondere Hosting, Webserver, Domain, DNS, TLS, Plugins, Schnittstellen und externe Dienstleister.
Sie beschreiben die Sicherheitsprinzipien und den risikoorientierten Arbeitsansatz des Autors. Die konkrete Umsetzung richtet sich immer nach Geschäftsprozess, Schutzbedarf, Risikobewertung, technischer Architektur und den jeweiligen betrieblichen Anforderungen.
Out of Scope
Der Beitrag stellt keine allgemeingültige oder vollständige Sicherheitsvorgabe für jede Website dar und ersetzt keine individuelle Risikoanalyse, Sicherheitskonzeption oder Prüfung des konkreten Betriebsumfelds.
Die beschriebenen Maßnahmen begründen keine automatische ISO/IEC-27001-Konformität und stellen keine Garantie für vollständige Sicherheit dar. Sie sind als mögliche technische und organisatorische Umsetzung von Sicherheitsanforderungen zu verstehen – nicht als isolierte Checkliste.
Die Website ist der erste Touchpoint
Ob eine Website besonders schützenswert ist, hängt nicht davon ab, ob sie als Marketing-Website, Shop, Portal oder Anwendung bezeichnet wird.
Entscheidend sind ihre Bedeutung für Geschäftsprozesse sowie die möglichen Auswirkungen einer Beeinträchtigung ihrer Vertraulichkeit, Integrität und Verfügbarkeit.
Eine Website kann beispielsweise zentraler Kontakt-, Informations-, Lead-, Vertriebs-, Onboarding-, Buchungs-, Support- oder Transaktionskanal eines Unternehmens sein. In diesem Fall ist sie als geschäftsrelevanter digitaler Service und als mit den Geschäftsprozessen verbundenes Asset in die Betrachtung des Informationssicherheitsmanagementsystems einzubeziehen.
Ihre Kompromittierung kann unter anderem zu folgenden Auswirkungen führen:
- Beeinträchtigung oder Unterbrechung von Geschäftsprozessen
- Umsatz- oder Leadverlusten
- Manipulation veröffentlichter Informationen
- Phishing oder manipulierten Weiterleitungen
- Verbreitung manipulierter Dateien oder Inhalte
- Datenschutzverletzungen
- Beeinträchtigung der Kundenkommunikation
- Reputations- und Vertrauensschäden
- Beeinträchtigung angebundener Systeme und Dienste
Der tatsächliche Schutzbedarf ist dabei risikoorientiert und für die einzelnen Schutzziele getrennt zu bewerten.
Vertraulichkeit
Bei öffentlich bestimmten Inhalten kann der Vertraulichkeitsbedarf gering sein.
Sobald jedoch personenbezogene Daten, Kontaktanfragen, Benutzerkonten, Transaktionen, Sitzungsinformationen, interne Schnittstellen oder andere nichtöffentliche Informationen verarbeitet werden, steigt der Schutzbedarf entsprechend.
Integrität
Die Integrität einer öffentlichen Website kann einen hohen oder sehr hohen Schutzbedarf besitzen.
Manipulierte Inhalte, ausgetauschte Downloads, veränderte Kontaktdaten, Phishing-Weiterleitungen, eingeschleuste Scripts oder manipulierte Formulare können unmittelbar Kunden, Geschäftspartner und die Reputation des Unternehmens betreffen.
Die Tatsache, dass Informationen öffentlich zugänglich sind, reduziert deshalb nicht ihre Integritätsanforderungen.
Verfügbarkeit
Die erforderliche Verfügbarkeit richtet sich nach der geschäftlichen Bedeutung des über die Website bereitgestellten Dienstes.
Werden über die Website beispielsweise Leads generiert, Bestellungen angenommen, Verträge angebahnt, Kunden unterstützt oder andere wesentliche Geschäftsprozesse durchgeführt, kann auch ein kurzfristiger Ausfall erhebliche Auswirkungen haben.
Aus dieser Bewertung können Anforderungen an Wiederherstellungszeiten, Datensicherung, Redundanz, Notfallverfahren und Wiederanlauf entstehen.
Einordnung in das ISMS
Die Website wird einschließlich ihrer wesentlichen Abhängigkeiten als Bestandteil der Informationsverarbeitung betrachtet.
Dazu gehören insbesondere Domain und DNS, Hosting, Webserver, CMS beziehungsweise Anwendung, Erweiterungen, Datenbanken, externe Dienstleister, E-Mail-Kommunikation, Schnittstellen, Formulare, Authentisierungssysteme, Zahlungsdienstleister und weitere angebundene Dienste.
Für den Service werden Verantwortlichkeiten, Schutzbedarf, technische und organisatorische Abhängigkeiten sowie relevante Informationssicherheitsrisiken dokumentiert.
Hierzu gehören insbesondere:
Business Ownership
Verantwortung für Geschäftszweck, Schutzbedarf, Risikoakzeptanz und Priorisierung.
Technical Ownership
Verantwortung für Hosting, Konfiguration, Aktualisierung, Backup, Deployment, Änderungen, Monitoring und Wiederherstellung.
Asset Management
Erfassung der Website und ihrer wesentlichen technischen und informationellen Abhängigkeiten innerhalb des Asset Managements.
Risk Management
Bewertung relevanter Bedrohungen und Schwachstellen sowie ihrer möglichen Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit.
Configuration Management
Definierte und nachvollziehbare Sicherheitskonfiguration von Webserver, Anwendung und zugehörigen Komponenten.
Vulnerability Management
Identifikation, Bewertung und Behandlung technischer Schwachstellen.
Change Management
Kontrollierte Durchführung sicherheitsrelevanter Änderungen an System, Software und Konfiguration.
Logging und Monitoring
Erkennung sicherheitsrelevanter Ereignisse und Unterstützung von Analyse und Incident Response.
Backup und Recovery
Sicherstellung einer geeigneten Wiederherstellbarkeit von Daten und Systemzuständen.
Business Continuity
Festlegung geeigneter Wiederanlauf- und Notfallmaßnahmen entsprechend der geschäftlichen Bedeutung des Dienstes.
Wir müssen bedenken, dass auch die Unabhängigkeit von einer, möglicherweise temporär betreuenden, Agentur gewährleistet sein muss.
Das heißt im Klartext: Exit-STrategie muss immer eingeplant werden. Und ein Agenturwechsel darf ebenfalls keine Unterbrechung des Betriebs zur Folge haben.
Technische Härtung als präventive Maßnahme
Die technische Härtung des Webservers, der Anwendung und der Browser-Sicherheitsmechanismen ist eine präventive Maßnahme zur Reduzierung der identifizierten Angriffsfläche.
Sie folgt insbesondere den Prinzipien:
Attack Surface Reduction
Nicht benötigte Funktionen, Schnittstellen und Zugriffsmöglichkeiten werden entfernt oder gesperrt.
Least Functionality
Es werden nur diejenigen Funktionen bereitgestellt, die für den vorgesehenen Betrieb erforderlich sind.
Least Privilege
Zugriffe und Berechtigungen werden auf das erforderliche Maß beschränkt.
Allowlisting
Wo technisch sinnvoll, werden ausdrücklich erlaubte Zugriffe und Funktionen definiert, anstatt ausschließlich bekannte unerwünschte Zugriffe zu blockieren.
Defense in Depth
Webserver, Transportverschlüsselung, Browser-Sicherheitsmechanismen und Anwendung bilden voneinander unabhängige Schutzschichten.
Die technische Härtung ist damit kein isoliertes „Security Add-on“, sondern eine operative Umsetzung der aus Schutzbedarf und Risikobewertung abgeleiteten Sicherheitsanforderungen.
Sie wird im Rahmen des Konfigurations-, Schwachstellen- und Änderungsmanagements gepflegt und bei Änderungen der Website, ihrer Geschäftsprozesse oder ihrer technischen Abhängigkeiten erneut bewertet.
ISO/IEC-27001-Bezug
Abhängig von der konkreten Risikobewertung und dem Anwendungsbereich können insbesondere folgende Controls der ISO/IEC 27001:2022 relevant sein:
A.5.2 – Information security roles and responsibilities
A.5.9 – Inventory of information and other associated assets
A.5.19–A.5.22 – Information security in supplier relationships und ICT supply chain
A.5.24–A.5.28 – Information security incident management
A.5.29 – Information security during disruption
A.5.30 – ICT readiness for business continuity
A.5.34 – Privacy and protection of PII
A.8.3 – Information access restriction
A.8.8 – Management of technical vulnerabilities
A.8.9 – Configuration management
A.8.13 – Information backup
A.8.15 – Logging
A.8.16 – Monitoring activities
A.8.20 – Networks security
A.8.24 – Use of cryptography
A.8.25 – Secure development life cycle
A.8.26 – Application security requirements
A.8.27 – Secure system architecture and engineering principles
A.8.29 – Security testing in development and acceptance
A.8.32 – Change management
Welche dieser Maßnahmen anzuwenden sind und in welcher Ausprägung sie umgesetzt werden, ergibt sich aus dem Geltungsbereich des ISMS, der Risikobewertung und der daraus abgeleiteten Risikobehandlung.
Technische Härtung der Website
Die Website ist auf Webserver-Ebene so konfiguriert, dass typische und unnötige Angriffswege bereits abgefangen werden, bevor sie die eigentliche Anwendung erreichen.
Dazu zählt insbesondere die Reduktion der Zugangswege.
Schutz vor Einbettung in fremde Websites
Die Website kann nicht ohne Weiteres in eine fremde Website eingebettet werden.
Damit wird insbesondere erschwert, Besuchern eine manipulierte Oberfläche zu präsentieren, während im Hintergrund tatsächlich unsere Website bedient wird. Solche sogenannten Clickjacking-Angriffe werden auf Browser-Ebene blockiert.
Ausschließliche Nutzung verschlüsselter Verbindungen
Besucher werden auf die verschlüsselte HTTPS-Verbindung geführt.
Dadurch wird verhindert, dass die Website regulär über eine unverschlüsselte HTTP-Verbindung genutzt wird. Der Browser wird zusätzlich angewiesen, nach einem erfolgreichen HTTPS-Aufruf für einen festgelegten Zeitraum nur noch verschlüsselte Verbindungen zu verwenden.
Schutz vor manipulierten Domain-Anfragen
Der Webserver akzeptiert ausschließlich die für die Website vorgesehenen Domainnamen.
Anfragen, bei denen ein fremder oder manipulierter Hostname übermittelt wird, werden abgewiesen. Dadurch werden unter anderem Angriffe erschwert, bei denen manipulierte Domaininformationen für Weiterleitungen, Links oder andere serverseitige Prozesse missbraucht werden sollen.
Kein öffentliches Durchsuchen von Verzeichnissen
Verzeichnisse können nicht einfach über den Browser aufgelistet werden.
Selbst wenn sich in einem Verzeichnis keine eigene Startseite befindet, erhält ein Besucher keine automatisch erzeugte Liste der darin enthaltenen Dateien.
Dadurch werden interne Dateistrukturen nicht unnötig offengelegt.
Schutz interner Konfigurations- und Entwicklungsdateien
Typische interne Dateien und Verzeichnisse werden vom öffentlichen Zugriff ausgeschlossen.
Dazu gehören beispielsweise:
- Konfigurationsdateien
- Protokolldateien
- Datenbankexporte
- Sicherungsdateien
- Umgebungsdateien
- Versionsverwaltungsverzeichnisse
- temporäre Entwicklungsdateien
Damit wird das Risiko reduziert, dass versehentlich auf dem Server verbliebene interne Informationen öffentlich abrufbar werden.
Schutz vor eingeschleusten Programmen im Upload-Bereich
Im für hochgeladene Dateien vorgesehenen Bereich dürfen keine PHP-Programme ausgeführt werden.
Sollte es einem Angreifer beispielsweise gelingen, eine als Datei getarnte PHP-Datei in diesen Bereich einzuschleusen, kann sie dort nicht einfach als serverseitiges Programm ausgeführt werden.
Damit wird ein wichtiger Angriffsweg für sogenannte Webshells deutlich reduziert.
Nicht benötigte WordPress-Schnittstellen sind nicht öffentlich erreichbar
Mehrere standardmäßig vorhandene WordPress-Einstiegspunkte, die für den Betrieb dieser Website nicht benötigt werden, sind bereits auf Webserver-Ebene gesperrt.
Dazu gehören unter anderem direkte Zugriffe auf:
- die Standard-WordPress-Anmeldung
- XML-RPC
- Trackback-Funktionen
- WordPress-Konfigurationsdateien
- öffentlich auslesbare WordPress-Informationsdateien
Damit wird die öffentlich erreichbare WordPress-Angriffsfläche bewusst verkleinert.
Reduzierung unnötiger HTTP-Angriffsmöglichkeiten
HTTP-Methoden, die für den normalen Betrieb der Website nicht erforderlich sind und überwiegend Diagnose- oder Spezialzwecken dienen, werden abgewiesen.
Damit stehen Angreifern weniger unnötige Kommunikationswege zum Webserver zur Verfügung.
Schutz vor falscher Interpretation von Dateien
Der Browser wird angewiesen, vom Server deklarierte Dateitypen zu respektieren und Inhalte nicht eigenständig als einen anderen Dateityp zu interpretieren.
Dadurch wird ein Angriffsweg reduziert, bei dem beispielsweise vermeintlich harmlose Inhalte vom Browser fälschlicherweise als ausführbarer Code behandelt werden.
Einschränkung besonders sensibler Browserfunktionen
Die Website erteilt eingebetteten Webinhalten grundsätzlich keine Berechtigung für Funktionen wie:
- Kamera
- Mikrofon
- Standortbestimmung
- USB-Geräte
Da diese Funktionen für den vorgesehenen Betrieb nicht benötigt werden, stehen sie auch nicht unnötig zur Verfügung.
Keine klassischen Browser-Plugins oder eingebetteten Objekte
Die Website erlaubt keine klassischen eingebetteten Objektinhalte.
Damit werden veraltete oder unnötige Einbettungsmechanismen als möglicher Angriffsweg ausgeschlossen.
Schutz vor Manipulation der Basisadresse einer Seite
Eine Webseite kann technisch eine Basisadresse definieren, anhand derer der Browser relative Links interpretiert.
Diese Möglichkeit wird auf die eigene Website begrenzt.
Damit wird erschwert, dass eingeschleuster Inhalt beispielsweise Links oder Ressourcen scheinbar zur eigenen Website gehören lässt, sie tatsächlich aber über einen fremden Server aufruft.
Automatische Aufwertung unsicherer Ressourcenaufrufe
Werden innerhalb einer verschlüsselt ausgelieferten Seite versehentlich Ressourcen mit einer unverschlüsselten Adresse referenziert, wird der Browser angewiesen, diese nach Möglichkeit ebenfalls verschlüsselt anzufordern.
Dadurch wird das Risiko sogenannter Mixed-Content-Verbindungen reduziert.
Begrenzung weitergegebener Herkunftsinformationen
Beim Wechsel von unserer Website zu externen Websites wird die Menge der automatisch vom Browser übertragenen Herkunftsinformationen begrenzt.
Insbesondere werden nicht unnötig vollständige interne Seitenadressen an externe Websites weitergegeben.
Bei besonders sensiblen Bereichen wird die Weitergabe solcher Referrer-Informationen vollständig unterbunden.
Sensible Bereiche werden nicht öffentlich zwischengespeichert
Dynamische und benutzerspezifische Bereiche wie beispielsweise:
- Onboarding
- Warenkorb
- Checkout
- Kundenkonto
- bestimmte Verarbeitungsschnittstellen
werden bewusst vom öffentlichen Seitencache ausgeschlossen.
Der Browser erhält zusätzlich die Anweisung, entsprechende Antworten nicht dauerhaft zwischenzuspeichern.
Damit wird insbesondere das Risiko reduziert, dass personenbezogene oder sitzungsbezogene Inhalte versehentlich zwischen unterschiedlichen Besuchern oder Sitzungen wiederverwendet werden.
Weniger Informationen über die eingesetzte Servertechnik
Nicht erforderliche technische Informationen über die serverseitig eingesetzte Software werden soweit möglich nicht zusätzlich über HTTP-Antworten bekanntgegeben.
Das verhindert keine Angriffe allein, reduziert aber unnötige Informationen, die einem Angreifer bei der gezielten Vorbereitung eines Angriffs helfen könnten.
Sicherheitsprinzip
Die Härtung folgt dabei einem einfachen Grundsatz:
Was für den vorgesehenen Betrieb der Website nicht benötigt wird, soll von außen möglichst auch nicht erreichbar oder nutzbar sein.
Dadurch wird die Anzahl potenzieller Angriffswege reduziert und ein Angriff muss mehrere voneinander unabhängige Schutzschichten überwinden, bevor die eigentliche Anwendung erreicht wird.
Diese Maßnahmen ersetzen keine kontinuierliche Pflege und Sicherheitsüberwachung. Sie sorgen jedoch dafür, dass zahlreiche typische Webangriffe bereits auf einer vorgelagerten technischen Ebene blockiert oder erheblich erschwert werden.
Mapping der technischen Website-Härtung auf ISO/IEC 27001:2022
Die folgende Tabelle ordnet die beschriebenen technischen Härtungsmaßnahmen konservativ den jeweils am stärksten einschlägigen Controls der ISO/IEC 27001:2022 zu.
Dabei wird zwischen einem primär zugeordneten Control und einem gegebenenfalls vorhandenen ergänzenden Bezug unterschieden.
Eine einzelne technische Maßnahme begründet für sich keine Konformität mit einem Control. Sie kann jedoch als konkrete technische Umsetzung beziehungsweise Evidenz einer aus Risikobewertung und Risikobehandlung abgeleiteten Sicherheitsanforderung dienen.
| Beschriebene Maßnahme | Primär zugeordnetes ISO/IEC-27001:2022-Control | Ergänzender Bezug | Sicherheitsfunktion | Begründung |
| Gesamte technische Härtungsbaseline mit Allowlisting, Least Functionality, deaktivierten Funktionen, definierten Headern und Webserver-Regeln | A.8.9 – Configuration management | A.8.27, sofern die Prinzipien zusätzlich als Architekturvorgaben dokumentiert sind | Sichere Konfigurationsbaseline / Attack Surface Reduction | Die Härtung definiert einen beabsichtigten und reproduzierbaren Sicherheitszustand des Webservers und der Anwendung. Nicht benötigte Funktionen werden deaktiviert, erlaubte Betriebszustände festgelegt und sicherheitsrelevante Konfigurationen dauerhaft vorgegeben. |
| Erzwingung eines kanonischen HTTPS-Zugangs und Weiterleitung unverschlüsselter HTTP-Aufrufe auf HTTPS | A.8.9 – Configuration management | A.8.24 – Use of cryptography | Transportweg erzwingen | Der Redirect selbst ist keine kryptographische Funktion, sondern eine sichere Webserverkonfiguration. Er sorgt dafür, dass reguläre Zugriffe auf den durch TLS geschützten Transportweg geführt werden. |
| Verwendung von HTTPS/TLS für die Übertragung zwischen Browser und Website | A.8.24 – Use of cryptography | – | Schutz der Datenübertragung | TLS stellt den kryptographischen Schutz des Kommunikationskanals bereit und dient insbesondere dem Schutz von Vertraulichkeit und Integrität während der Übertragung. |
| HTTP Strict Transport Security – HSTS | A.8.9 – Configuration management | A.8.24 – Use of cryptography | Durchsetzung des verschlüsselten Transportwegs | HSTS ist selbst kein kryptographischer Mechanismus. Die Sicherheitskonfiguration weist den Browser jedoch an, den Dienst ausschließlich über HTTPS und damit über den kryptographisch geschützten Transportweg anzusprechen. |
| Automatische Aufwertung unsicher referenzierter HTTP-Ressourcen innerhalb einer HTTPS-Seite durch upgrade-insecure-requests | A.8.26 – Application security requirements | A.8.24 – Use of cryptography | Mixed-Content-Vermeidung | Die Anwendung gibt dem Browser eine Sicherheitsanforderung für das Laden eingebundener Ressourcen vor. Unsichere HTTP-Ressourcen sollen nicht neben einer verschlüsselten Hauptseite verwendet werden. |
| Domain-Allowlist und Abweisung von Requests mit nicht vorgesehenem Hostnamen | A.8.9 – Configuration management | A.8.26 – Application security requirements | Host-Validierung / Host Header Injection Reduction | Der Webserver akzeptiert ausschließlich definierte Hostnamen. Dadurch wird ein zulässiger Betriebszustand technisch festgelegt und die Verarbeitung manipulierter Host-Kontexte reduziert. |
| Deaktivierung des automatischen Directory Listings | A.8.9 – Configuration management | A.8.3 – Information access restriction | Reduzierung von Information Disclosure und Reconnaissance | Die automatische Ausgabe von Verzeichnisinhalten wird durch eine sichere Webserverkonfiguration deaktiviert. Dadurch werden Dateinamen und interne Verzeichnisstrukturen nicht unnötig offengelegt. |
| Sperre des öffentlichen Zugriffs auf .env, .git, Sicherungsdateien, Logs, Datenbank-Dumps, Konfigurations- und Entwicklungsdateien | A.8.3 – Information access restriction | A.8.9 – Configuration management | Schutz nichtöffentlicher Informationen | Informationen, die nicht für die öffentliche Bereitstellung vorgesehen sind, werden technisch vom Zugriff durch externe Besucher ausgeschlossen. Die konkrete Sperre ist zugleich Bestandteil der Webserver-Konfigurationsbaseline. |
| Sperre des öffentlichen Zugriffs auf WordPress-Konfigurations- und Informationsdateien | A.8.3 – Information access restriction | A.8.9 – Configuration management | Verhinderung von Configuration und Information Disclosure | Nicht für Besucher bestimmte technische Informationen und Konfigurationsressourcen werden vom öffentlichen Zugriff ausgeschlossen. |
| Verbot der PHP-Ausführung innerhalb des Upload-Verzeichnisses | A.8.9 – Configuration management | A.8.26 – Application security requirements | Trennung von Daten und ausführbarem Code | Der Upload-Bereich wird als nicht ausführbarer Datenbereich konfiguriert. Hochgeladene Inhalte sollen unabhängig von ihrem Dateinamen nicht als serverseitiger Anwendungscode ausgeführt werden können. |
| Sperre nicht benötigter WordPress-Standardendpunkte wie direkter Standard-Login, XML-RPC oder Trackback | A.8.9 – Configuration management | A.8.26 – Application security requirements | Attack Surface Reduction / Least Functionality | Nicht benötigte Funktionen werden dem öffentlichen Zugriff entzogen. Dadurch stehen automatisierten Angriffen weniger Standardendpunkte zur Verfügung. |
| Sperre von TRACE und TRACK | A.8.9 – Configuration management | – | Least Functionality / HTTP Method Hardening | Nicht für den vorgesehenen Geschäftsbetrieb benötigte HTTP-Methoden werden auf Webserver-Ebene deaktiviert und stehen damit auch nicht als zusätzliche Angriffsoberfläche zur Verfügung. |
| Schutz gegen Einbettung der Website durch frame-ancestors und X-Frame-Options | A.8.26 – Application security requirements | A.8.9 – Configuration management | Clickjacking-/UI-Redressing-Schutz | Die Anwendung gibt dem Browser vor, ob und durch wen ihre Inhalte innerhalb fremder Frames dargestellt werden dürfen. Dadurch wird eine konkrete clientseitige Sicherheitsanforderung durchgesetzt. |
| Ausschluss eingebetteter Objektinhalte durch object-src ’none‘ | A.8.26 – Application security requirements | A.8.9 – Configuration management | Content-/Object-Injection Reduction | Die Anwendung definiert über ihre Content Security Policy, dass nicht benötigte Objekt- und Plugin-Inhalte nicht eingebettet werden dürfen. |
| Begrenzung der HTML-Basisadresse durch base-uri ’self‘ | A.8.26 – Application security requirements | A.8.9 – Configuration management | Schutz vor Base-URI-Manipulation | Die Anwendung beschränkt die zulässige Basisadresse für relative Ressourcen und Links auf den vorgesehenen eigenen Ursprung. |
| Content Security Policy als Browser-Sicherheitsgrenze | A.8.26 – Application security requirements | A.8.9 – Configuration management | Content Injection / XSS Impact Reduction / Browser-Allowlisting | Die Anwendung definiert Sicherheitsanforderungen für die Verarbeitung und Einbettung von Webinhalten im Browser. Die technische Richtlinie wird über die Webserverkonfiguration ausgeliefert. |
| Unterbindung von MIME Sniffing durch X-Content-Type-Options: nosniff | A.8.26 – Application security requirements | A.8.9 – Configuration management | Content-Type-Validierung | Der Browser wird angewiesen, den vom Server angegebenen Inhaltstyp zu respektieren und Inhalte nicht eigenständig als anderen beziehungsweise ausführbaren Inhaltstyp zu interpretieren. |
| Einschränkung nicht benötigter Browserfunktionen über Permissions Policy | A.8.26 – Application security requirements | A.8.9 – Configuration management | Least Privilege für Browser-APIs | Die Webanwendung definiert explizit, welche Browser- und Gerätefunktionen verwendet werden dürfen. Nicht erforderliche Berechtigungen werden nicht bereitgestellt. |
| Einschränkung der übermittelten Referrer-Informationen | A.8.26 – Application security requirements | A.8.3 – Information access restriction | Reduzierung von Referrer Leakage | Die Anwendung legt fest, welche Herkunftsinformationen der Browser bei Navigationen und externen Requests offenlegen darf. Dadurch wird die unnötige Weitergabe interner URLs reduziert. |
| Vollständige Unterbindung der Referrer-Übertragung für besonders sensible Bereiche | A.8.3 – Information access restriction | A.8.26 – Application security requirements | Schutz kontextbezogener Informationen | Informationen über aufgerufene interne beziehungsweise sensible URLs werden nicht an nachgelagerte externe Empfänger weitergegeben. |
| Ausschluss personalisierter beziehungsweise sensibler Bereiche aus gemeinsam genutzten Webserver- oder Proxy-Caches | A.8.3 – Information access restriction | A.8.26 – Application security requirements | Schutz vor Cross-User Cache Leakage | Sitzungsbezogene oder personenbezogene Inhalte sollen nicht über einen Shared Cache an andere Benutzer beziehungsweise Sitzungen ausgeliefert werden können. |
| Browserseitiges no-store beziehungsweise vergleichbare Cache-Vorgaben für sensible Antworten | A.8.3 – Information access restriction | A.8.26 – Application security requirements | Reduzierung lokaler Speicherung sensibler Inhalte | Die Anwendung legt fest, dass besonders sensible Antworten nicht dauerhaft in Browser- oder Zwischen-Caches gespeichert werden sollen. |
| Reduzierung nicht erforderlicher Informationen über eingesetzte Servertechnik | A.8.9 – Configuration management | – | Server Fingerprinting / Reconnaissance Reduction | Nicht erforderliche technische Identifikationsinformationen werden durch die Serverkonfiguration soweit möglich nicht zusätzlich offengelegt. Dies erschwert die automatisierte technische Profilbildung, ohne für sich allein einen Sicherheitsmechanismus gegen Exploits darzustellen. |
| Verwendung eines Allowlist-Prinzips für zulässige Zugriffe und Betriebswege | A.8.9 – Configuration management | A.8.27 – Secure system architecture and engineering principles, sofern als verbindliches Architekturprinzip dokumentiert | Default Deny / Positive Security Model | Statt ausschließlich bekannte unerwünschte Zustände zu sperren, werden vorgesehene und zulässige Zustände definiert. Dadurch wird die Angriffsfläche auch gegenüber bislang nicht explizit betrachteten Zugriffspfaden reduziert. |
| Least Functionality als Grundsatz: Nicht benötigte Funktionen, Methoden und Endpunkte werden deaktiviert | A.8.9 – Configuration management | A.8.27, sofern als Engineering-Prinzip institutionalisiert | Attack Surface Reduction | Die technische Konfiguration stellt nur Funktionen bereit, die für den vorgesehenen Betrieb erforderlich sind. |
| Defense in Depth: Webserver, Transportebene, Browser-Sicherheitsmechanismen und Anwendung bilden getrennte Schutzschichten | A.8.27 – Secure system architecture and engineering principles | – | Mehrschichtige Sicherheitsarchitektur | Die Zuordnung ist belastbar, wenn Defense in Depth als bewusstes Architektur- und Engineering-Prinzip dokumentiert, gepflegt und bei Entwicklung sowie Änderungen angewendet wird. Die Wirksamkeit beruht dann nicht auf einem einzelnen Sicherheitsmechanismus. |
Einordnung des Mappings
Die Tabelle stellt bewusst kein 1:1-Compliance-Mapping im Sinne „technische Einstellung = Control erfüllt“ dar.
Die belastbare Wirksamkeits und Nachweiskette innerhalb eines ISMS lautet vielmehr:
Geschäftlicher Kontext und Asset
↓
Schutzbedarf
↓
Informationssicherheitsrisiko
↓
Sicherheitsanforderung
↓
Risikobehandlung und ausgewähltes Control
↓
technische oder organisatorische Maßnahme
↓
dokumentierter Konfigurationszustand
↓
Wirksamkeitsprüfung und Nachweis
Die technische Website-Härtung ist damit die operative Umsetzung bestimmter Sicherheitsanforderungen und kann als Evidenz für die Durchführung der jeweiligen Risikobehandlung dienen.
Primäre Controls der Website-Härtung
Aus der Gesamtheit der Maßnahmen ergeben sich insbesondere fünf zentrale Controls:
A.8.9 – Configuration management
Dies ist der wesentliche Hauptanker der Webserver-Härtung.
Hierunter fallen insbesondere:
- sichere Konfigurationsbaselines
- deaktivierte Funktionen
- Allowlisting
- Least Functionality
- HTTP-Method-Hardening
- Directory-Listing-Konfiguration
- Host-Allowlisting
- HSTS-Konfiguration
- technische Security-Header
- Sperren bestimmter Dateien und Endpunkte
- Trennung zwischen ausführbaren und nicht ausführbaren Bereichen
- Reduzierung unnötiger technischer Informationen
A.8.24 – Use of cryptography
Dieses Control ist insbesondere für die eigentliche TLS-gesicherte HTTPS-Kommunikation relevant.
HSTS, HTTPS-Redirects und Mixed-Content-Regeln unterstützen deren konsequente Verwendung, sind aber selbst nicht mit dem kryptographischen Verfahren gleichzusetzen.
A.8.26 – Application security requirements
Dieses Control bildet einen wesentlichen Anker für Sicherheitsanforderungen, die das Verhalten der Webanwendung und des Browsers bestimmen.
Hierzu gehören insbesondere:
- Content Security Policy
- Schutz vor unerwünschtem Framing
- Content-Type-Sicherheit
- Einschränkung von Browserberechtigungen
- Referrer-Regeln
- Cache-Anforderungen
- Host-Kontext-Anforderungen
- Trennung hochgeladener Daten von ausführbarem Anwendungscode
A.8.3 – Information access restriction
Dieses Control ist dort der stärkste Bezug, wo die Maßnahme unmittelbar verhindert, dass nicht für die Öffentlichkeit bestimmte Informationen unberechtigt zugänglich werden.
Hierzu gehören insbesondere:
- Sperre interner Dateien
- Schutz von Konfigurationsinformationen
- Schutz von Logs und Datenbank-Dumps
- Verhinderung von Cache Leakage
- Einschränkung der Weitergabe sensibler Referrer-Informationen
A.8.27 – Secure system architecture and engineering principles
Dieses Control ist für übergeordnete Sicherheitsprinzipien wie Defense in Depth, Allowlisting oder Least Functionality nur dann als eigenständiger Mapping-Anker zu verwenden, wenn diese nicht lediglich zufällig aus der aktuellen Konfiguration resultieren.
Sie sollten als:
- dokumentierte Architekturprinzipien,
- verbindliche Engineering-Vorgaben,
- bei Änderungen anzuwendende Sicherheitsanforderungen und
- dauerhaft gepflegte Designentscheidungen
etabliert sein.
Erst dann wird aus einer einzelnen technischen Konfiguration ein nachvollziehbares Secure-System-Architecture-and-Engineering-Prinzip.
Wichtig ist, dass hier keine absolute Sicherheit vermittelt werden soll. Vielmehr ist das die Mindestanforderung an ein gehärtetes Betriebsumfeld bei einem exponierten Webauftritt.
Es spielt für Ihre Reputation überhaupt keine Rolle, was Sie öffentlich anbieten.
Sie muss Vertrauen erwecken, integer und verfügbar sein.