„security.txt“
nach RFC 9116
Schon mal etwas von der Möglichkeit gehört, eine "security.txt" nach RFC 9116 auf dem Webserver zu platzieren? Nein? Dann einfach mal fix weiterlesen *Zwinkersmiley*
Findet jemand eine Sicherheitslücke, so sollte man ihm sinnvollerweise auch die Gelegenheit geben, diese dem Verantwortlichen kurzfristig mitteilen zu können. Doch an wen konkret wendet man sich in einem solchen Fall? Häufig wird das nicht transparent kommuniziert und allein die entsprechenden Informationen zu finden, wird schon zur ersten Herausforderung für den Meldenden.
Hier möchte das RFC 9116 Abhilfe schaffen und stellt mit der so genannten "security.txt" eine standardisierte und (theoretisch auch) automatisiert auswertbare Informationsquelle für die Meldung von Sicherheitsproblemen zur Verfügung. In der "security.txt" werden dazu verschiedene Informationen platziert, bspw. die URL, wo die "security.txt" selbst zu finden ist, die Kontaktdaten des Ansprechpartners für die Meldung sowie ggf. auch schon kryptographisches Schlüsselmaterial für eine sichere Kommunikation. Eine "security.txt" MUSS dabei nach RFC 9116 unter dem Pfad "/.well-known/" platziert werden. Für meine Domäne we.secure-your.it lautet der vollständige Pfad somit "https://we.secure-your.it/.well-known/security.txt". Dies in aller Kürze, alle weiteren Vorgaben und Möglichkeiten lassen sich natürlich im RFC 9116 nachlesen.
Aber Achtung: Wenn man eine sichere Kommunikationsmöglichkeit -bspw. durch Verwendung eines Public-Key-Pairs- zur Verfügung stellen möchte, sollte auch sichergestellt sein, dass alle jeweiligen Ansprechpartner über das notwendige Schlüsselmaterial -in diesem Fall also den zugehörigen Private Key- verfügen, denn nur dann ist eine (lesbare) Kommunikation sichergestellt. Es kann durchaus hilfreich sein, das genaue Vorgehen und das notwendige Schlüsselmaterial erst nach einem erfolgreichen Erstkontakt -in dessen Verlauf natürlich keine brisanten Informationen übermittelt werden sollten- auszutauschen.
Vortrag zum Thema
„Löschen nach DSGVO“
Am 14. März 2024 halte ich anlässlich der am 14. und 15. März 2024 in Hamburg stattfindenden "Datenschutz-Fachtagung" des TÜV Nord am ersten Veranstaltungstag zusammen mit Joerg Heidrich einen Vortrag zum Thema "Datenschutzkonformes Löschen: Konzept, technische Möglichkeiten und rechtliche Implikationen".
In diesem interdisziplinären Vortrag diskutieren wir die Fragen, was überhaupt "datenschutzkonformes" Löschen ist, wann man personenbezogene Daten konkret löschen muss und ob bzw. wie man diese eigentlich datenschutzkonform löschen kann. Das klingt erst einmal trivial, entpuppt sich aber bei näherer Betrachtung oft als große Herausforderung, denn nahezu in jedem Unternehmen gibt es eine Vielzahl von Verarbeitungsprozessen und Speicherorten für personenbezogene Daten, die muss man erst einmal alle kennen.
Hinzu kommen Löschfristen, die je nach Anwendungsfall völlig unterschiedlich sein können. Und insbesondere beim Cloud-Computing stellt sich bspw. die Frage, ob und wie man Daten in der Cloud überhaupt datenschutzkonform löschen kann.
Bei all diesen Fragen kann übrigens ein Löschkonzept sehr hilfreich sein und daher ist dieses Thema ebenfalls Bestandteil unseres Vortrags.
KRITIS-DachG-E:
Ablösung der BSI-KritisV?
Wer sich den aktuellen Entwurf zur Umsetzung der europäischen RCE-Richtlinie, das neue KRITIS-Dachgesetz (KRITIS-DachG), schon genauer angeschaut hat, wird in Abschnitt B des Entwurfs vlt. so wie ich über folgende Formulierung gestolpert sein:
Um ein Auseinanderfallen kritischer Anlagen im Sinne des BSIG einerseits und im Sinne des KRITIS-DachG andererseits zu vermeiden, werden Betreiber kritischer Anlagen künftig nur noch durch das KRITIS-DachG und die dazugehörige Rechtsverordnung bestimmt. Mit der Rechtsverordnung wird ersichtlich, welche Verpflichtungen für Betreiber kritischer Anlagen und weiterer Einrichtungen im Hinblick auf physische Resilienzmaßnahmen nach dem KRITIS-DachG und im Hinblick auf die IT-Sicherheit nach dem BSIG gelten.
Dies bedeutet dann wohl, dass die bisherige BSI-KritisV durch die noch zu erstellende Rechtsverordnung nach § 16 KRITIS-DachG-E abgelöst werden wird.
Diese Vereinheitlichung ist sicherlich auch geboten und wünschenswert, insbesondere wenn man vor Augen hat, welche "Unstimmigkeiten" es bereits bei den Entwürfen des NIS2UmsCG und des KRITIS-DachG gegeben hat.
Und das, obwohl dasselbe Ministerium federführend in der Ausgestaltung ist und man doch erwarten sollte, dass es hier eine entsprechende interne Abstimmung der einzelnen zuständigen Abteilungen bzw. Personen gibt. Es bleibt also zu hoffen, dass die Konsolidierung der Rechtsverordnungen hier einen echten Mehrwert schafft, also mehr ist, als das reine "Zusammenschreiben" von zwei nicht miteinander abgestimmten Verordnungen *Zwinkersmiley*
Denn nur so lassen sich Unstimmigkeiten vermeiden. Zugleich sollte sichergestellt werden, dass die Verordnung durch regelmäßige und öffentlich einsehbare Evaluierungen auch am "Puls der Zeit" bleibt.
Roundtable
zur NIS-2-Richtlinie
Auch in diesem Jahr findet wieder eine IT-Defense statt, diesmal vom 31. Januar bis 2. Februar 2024 in Stuttgart. Und auch in diesem Jahr bin ich mit dabei und werde am Freitag, 2. Februar 2024 einen Roundtable zum Thema "Neue Anforderungen durch NIS-2 und Co. - aber was bedeutet das eigentlich für unser/mein Unternehmen?" halten.
Da kann man dann erfahren, wer überhaupt betroffen sein wird, welche Anforderungen auf die jeweils Betroffenen zukommen und wie weit die Umsetzung der europäischen Vorgaben durch unseren Gesetzgeber mittlerweile gediegen ist.
Und natürlich werde ich auch meine persönliche Meinung zu dem ein oder anderen Sachverhalt nicht verheimlichen und das Ganze kritisch bewerten *Zwinkersmiley*