If you suspend your transcription on amara.org, please add a timestamp below to indicate how far you progressed! This will help others to resume your work!
Please do not press “publish” on amara.org to save your progress, use “save draft” instead. Only press “publish” when you're done with quality control.
Sollte ein:e Sicherheitsforscher:in aktuell eine Sicherheitslücke finden und dabei ggf. auch noch über ein Datenleck stolpern, entstehen eine Reihe von Fragen:
* Habe ich mich strafbar gemacht, wenn ja wie dolle? #Hackerparagraph
* Wem melde ich die Lücke?
* Wem melde ich das Datenleck?
* Kann ich das ethisch vertreten?
* Wie viel Arbeit wird das?
Die Arbeit von ehrenamtlichen Sicherheitsforscher:innen wird von den Organisationen, deren Systeme betroffen sind, nicht notwendigerweise positiv aufgenommen - siehe CDU Connect-App [1]. Auch kann das Melden von Sicherheitslücken bei Bekanntwerden der meldenden Person für diese zu Repressalien führen wie der Fall der log4j Lücke gegenüber dem Unternehmen AliBaba [2][3].
Ebenfalls ist nicht immer einfach erkennbar, wem eine Lücke und ein entsprechendes Leck zu melden sind:
* der Organisation, die die Software einsetzt?
* der Organisation, die die Software anbietet oder entwickelt?
* Was ist zu tun, wenn es keine security.txt gibt?
* Wendet sich eins an die Adresse im Impressum?
* Im Falle eines Datenlecks, welcher LfDI ist zuständig?
* Der des Landes der Filiale, die im Impressum steht, der des Bundeslandes, in dem die Firma ihren Hauptsitz hat?
* Was passiert, wenn das Datenleck an den falschen LfDI gemeldet wird?
* Wieso wollen BfDI und LdDIs wissen wer ich bin?
* Wie kann ich sicher sein, dass das BSI aus der Lücke keinen Staatstrojaner macht?
etc. etc.
Wie das aus Sicht von Sicherheitsforscher:innen funktioniert, haben Zerforschung und Linus in dem Vortrag: “Deine Software, die Sicherheitslücken und ich” [5] dargestellt.
Damit sich das bessert wollen wir - als konstruktiven Beitrag zur Debatte um Sicherheitsforschung auf Bundes- [6] und Europäischer Ebene [7] - dem Bund vorschlagen, dass er Sicherheitsforscher:innen einlädt, ihn und die öffentliche Hand im Allgemeinen zu Hacken.
Dies durch das Ausloben eines “Bunten Bug Bounties” und das Einrichten einer one-stop-shop Meldestelle für Sicherheitslücken und Datenlecks.
Vorbilder gibt es genug, die Bundeswehr [8] und die Niederlande [9] machen das schon. Die Bundeswehr verspricht Sicherheitsforscher:innen sie nicht anzuzeigen, die Niederlande garantieren, dass die Meldung veröffentlicht werden darf und es gibt ein T-Shirt [10]. Die EU zahlt mit EU-Fossa [11] sogar Geld für Fixes von Lücken in relevanten Open Source Frameworks.
Ziel des Projektes ist es herauszufinden:
* Wie könnte ein entsprechender Prozess aussehen?
* Kann das rechtssicher gestaltet werden?
* Wie passt das mit dem Cyber Resilience Act der EU [12] zusammen?
Im Vortrag wollen wir den aktuellen Stand des Projektes vorstellen und die Community zur Diskussion einladen.
Weiteres Demnächst unter:
www.inoeg.de/b3
[1] https://www.zeit.de/digital/datenschutz/2021-08/cdu-connect-app-it-sicherheit-lilith-wittmann-forscherin-klage
[2] https://winfuture.de/news,127162.html
[3] https://www.scmp.com/tech/big-tech/article/3160670/apache-log4j-bug-chinas-industry-ministry-pulls-support-alibaba-cloud
[4] https://securitytxt.org/
[5] https://media.ccc.de/v/rc3-2021-xhain-278-deine-software-die-si
[6] https://netzpolitik.org/2022/hackerparagrafen-sicherheit-fuer-die-sicherheitsforschung/
[7] https://www.ccc.de/de/updates/2022/zero-day-schwarzmarkt-trockenlegen
[8] https://www.bundeswehr.de/de/security-policy
[9] https://www.government.nl/topics/cybercrime/fighting-cybercrime-in-the-netherlands
[10] https://medium.com/pentesternepal/hacking-dutch-government-for-a-lousy-t-shirt-8e1fd1b56deb
[11] https://joinup.ec.europa.eu/collection/eu-fossa-2/about
[12] https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act