Die Formulierungen im Gesetzestext sind eher abstrakt und unkonkret gehalten. Die genauere Bestimmung der einzuhaltenden Sicherheitsstandards obliegt dem Bundesamt für Sicherheit in der Informationstechnik (BSI). Ein zentraler Punkt ist der Schutz personenbezogener Daten. Hier werden Website-Entwickler in die Pflicht genommen. Für Authentifizierung, Verschlüsselung und damit zusammenhängende Mechanismen zum Schutz persönlicher Daten hat das BSI konkrete Richtlinien erarbeitet, die den im Gesetz so genannten „Stand der Technik“ definieren sollen.

Wir haben eine Checkliste für Sie vorbereitet mit den einzuhaltenden Standards in den Bereichen Verschlüsselung, Serverzertifikat, Login und Session Management:

• Alle Seiten mit Formularen und Seiten, die nicht öffentlich sind (z. B. Login-Bereiche, Extranets oder Intranets), werden über https übertragen (auch eingebundene Stylesheets, JavaScript, Bilder, …).
• Login- und Logout-Seite selbst werden über https verschlüsselt.
• Die https-Verbindung lässt nur TLS 1.2 zu (ältere Protokollversionen – auch SSL – sind unsicher und alle gängigen Browser unterstützen TLS 1.2 bereits seit Jahren).
• Für alle https Seiten ist der http Header „HTTP Strict Transport Security“ gesetzt, der den Browser dazu zwingt, keine unsichere Verbindung ohne https zur jeweiligen Domain zuzulassen.
• Auch das Intranet (geschützter Internetbereich innerhalb eines Unternehmens) läuft über https (für den Fall, dass jemand einbricht).
• Https-Seiten werden nicht über http ausgespielt.
• Alle Benutzer- und Session-Cookies haben das „secure“-Flag gesetzt (sonst könnte z.B. Angriffscode in der Seite einen http-Request absetzen, in dem das unverschlüsselte Session-Cookie enthalten ist).
• In URL-Parametern sind keine sensiblen Daten enthalten (die URL wird zwar bei TLS auch mitverschlüsselt, aber dennoch über den Browser als „referrer“ bei Links auf andere https-Seiten preisgegeben).
• Seiten mit sensiblen Daten werden nicht gecacht (also http-Header „Cache-Control: no-cache, no-store“ und „Expires: 0″, für alte Browser „Pragma: no-cache“).

Lesen Sie zum Thema Verschlüsselung auch unseren Blogbeitrag vom März: https – für mehr Sicherheit im Internet!

• Die Schlüssellänge beträgt mindestens 2048bits.
• Der private Schlüssel ist geschützt aufbewahrt mit minimalen Dateiberechtigungen.
• Der Common Name (CN) des Serverzertifikats entspricht exakt der Domain bzw. dem Domain Name (DN). Wenn eine Domain mit und ohne „www“ erreichbar sein soll, dann sind 2 Zertifikate oder ein „Multi Domain Zertifikat“ mit Subject Alternate Names (SANs) notwendig.
• Es werden keine Zertifikate für private IP-Adressen verwendet (192.168/16, 172.16/12, 10/8.).
• Es werden keine selbst-signierten Zertifikate benutzt.
• Wenn der Zertifizierungspfad Zwischenzertifikate enthält, dann werden diese auch zur Verfügung gestellt.
• SHA256 wird für den gesamten Zertifizierungspfad verwendet (SHA1 Zertifikate sollten bis spätestens 01.01.2017 abgelaufen sein).

• Die Authentifizierung erfolgt zumindest über Username und Passwort. (Grundsätzlich ist eine Authentifizierung über Username und Passwort sicher. Nur bei erhöhtem Schutzbedarf ist eine sogenannte Zwei-Faktor-Authentifizierung erforderlich – z. B. TAN oder mTAN.)
• Es werden keine Selbstimplementierungen, sondern bewährte Bibliotheken eingesetzt (z.B. OWASP-Security API).
• Die Passwortstärke wird eingeblendet.
• Großbuchstaben, Kleinbuchstaben, Sonderzeichen und Zahlen sind zwingende Bestandteile des Passworts.
• Die Passwortlänge beträgt mindestens 8 Zeichen.
• Voreingestellte Passwörter („Einmalpasswörter“) müssen vom Benutzer sofort geändert werden.
• Nach Passwortwechseln kann das alte Passwort nicht mehr benutzt werden.
• Jeder Benutzer kann sein eigenes Passwort jederzeit ändern.
• Passwörter werden nicht im Klartext im System gespeichert (sondern nur als Hash-Wert).
• Es findet eine erneute Authentifizierung bei sicherheitskritischen Aktionen statt (z.B. Passwortänderung, Löschen von Daten).
• Es ist ein Grenzwert für die Anzahl gescheiterter Anmeldeversuche gesetzt (zur Vermeidung von brute-force-Angriffen).
• In Netzen, in denen Passwörter unverschlüsselt übertragen werden, werden Einmalpasswörter dauerhaft verwendet.

• Die Session-ID beträgt mindestens 128 bit (= mind. 16 Zeichen).
• Die Session-ID wird nicht als URL-Parameter übertragen, da sie so im beteiligten System auftauchen kann (z. B. Server Logs) oder in andere Systeme gelangen kann (referrer Feld im http header). Deshalb werden nur Cookies zur Sessionerhaltung verwendet.
• Im Session-Cookie ist ein geeigneter path gesetzt (z. b. /webapp) – „secure“- und „httpOnly“-Flag setzen.
• Die Session-ID wird nach Login und nach Wechsel von http auf https gewechselt (zum Schutz vor Session-Fixation-Angriffen).
• Die Sessiondauer ist beschränkt.
• Die Session wird nach einer bestimmten Zeit der Inaktivität beendet.
• Bei Logout wird serverseitig die Session invalidiert.
• Bei schwerwiegenden Fehlern (Exceptions) in der Anwendung findet ein Logout statt (da der Fehler eventuell durch einen Angriff verursacht sein könnte).

Wer als Entwickler von Webanwendungen mit Login-geschützten-Bereichen die aufgezählten Anforderungen weitgehend beherzigt, sollte also „auf der sicheren Seite“ sein, was das IT-Sicherheitsgesetz angeht.

Zusätzlich zu den genannten Punkten gibt es eine Reihe weiterer Vorgaben, die beachtet werden sollten. In unserem Blogartikel Neue Pflichten für Anbieter von Internetseiten durch das IT-Sicherheitsgesetz spricht unser Rechtsexperte Prof. Clemens Pustejovsky darüber, stets die eingesetzten Systeme (z. B. CMS) auf dem neuesten Stand zu halten. Insbesondere Bugfixes sollten zeitnah eingespielt werden.