Warum wir neugierige Köpfe im Bereich Sicherheit unterstützen und nicht bestrafen sollten

Jüngste Berichte des jugendlichen Sicherheitsforschers Bill Demirkapi, in denen er die wichtigsten Schwachstellen in der von seiner Schule verwendeten Software aufdeckte, haben sicherlich einige Erinnerungen bei Ihnen geweckt. Ich erinnere mich, dass ich als neugieriges Kind die Haube der Software angehoben habe, um einen Blick darauf zu werfen und zu sehen, wie alles funktioniert und, was noch wichtiger ist, ob ich es entschlüsseln konnte. Seit Jahrzehnten streben Softwareingenieure nach kontinuierlicher Verbesserung und Stärkung ihrer Produkte, und die Sicherheitsgemeinschaft (wenn auch manchmal mit einem etwas dreisten Ansatz) spielt eine wichtige Rolle bei der Aufdeckung von Fehlern und möglichen Katastrophen, hoffentlich bevor ein Bösewicht dasselbe tut.

Das Problem hierbei ist jedoch, dass er aufgrund seiner Entdeckungen vorübergehend von der Schule suspendiert wurde. Und das geschah erst, nachdem er alle Möglichkeiten ausgeschöpft hatte, um privat mit dem Unternehmen (Corporación Follett) in Kontakt zu treten, und sich schließlich für eine ziemlich öffentliche Aktion entschied, um sich selbst und seine Fähigkeit, in das System einzudringen, bekannt zu machen. Seine wiederholten Versuche, die Follett Corporation auf ethische Weise zu warnen, blieben unbeantwortet, während die Software weiterhin anfällig war und Unmengen von Schülerdaten relativ leicht zugänglich waren, da ein Großteil davon nicht verschlüsselt war.

Er suchte auch nach Fehlern in der Software eines anderen Unternehmens: Blackboard. Obwohl die Daten von Blackboard zumindest verschlüsselt waren, hätten potenzielle Angreifer auf Millionen weiterer Datensätze zugreifen und diese an sich reißen können. Seine Schule verwendete sowohl diese Software als auch das Produkt von Follett.

Die Erzählung vom „bösen Hacker“ ist problematisch.

Demirkapi präsentierte seine Erkenntnisse im ICONO DE DEFINICIÓN, und die frechsten Details seiner Streiche wurden vom Publikum mit Applaus bedacht. Die Wahrheit ist, dass er zwar anfangs in den falschen Büchern stand und viele Hindernisse überwinden musste, damit seine Entdeckungen anerkannt wurden, aber die Follett Corporation dankte ihm für seine Bemühungen und folgte seinen Ratschlägen, um letztendlich ihre Software sicherer zu machen und zu verhindern, dass die Krise zu einer weiteren Statistik über Datenverstöße wurde. Nach dem Abschluss der High School wird er außerdem das Rochester Institute of Technology besuchen, sodass er eindeutig auf dem besten Weg ist, ein gefragter Sicherheitsspezialist zu werden.

Als Sicherheitsbeauftragter fällt es schwer, mit der Art und Weise, wie diese Situation gehandhabt wurde, nicht einverstanden zu sein. Obwohl in diesem Fall alles gut ausgegangen ist, wurde er zunächst wie ein lästiger Drehbuchautor behandelt, der sich in Dinge einmischt, die ihn nichts angehen. Eine Google-Suche zu diesem Vorfall liefert Artikel, in denen er als „Hacker” bezeichnet wird (in den Augen eines Sicherheitsexperten macht ihn das in vielerlei Hinsicht zum Bösewicht), obwohl sein Ansatz (und der vieler anderer) in Wirklichkeit dazu beiträgt, unsere Daten zu schützen.

Wir brauchen neugierige, intelligente und sicherheitsbewusste Menschen, die heimlich nachschauen, und wir brauchen das viel häufiger. Seit Juli waren allein in diesem Jahr mehr als vier Milliarden Datensätze böswilligen Datenverstößen ausgesetzt. Dank des Einbruchs bei der Mode- und Lifestyle-Marke Poshmark im August könnten weitere 50 Millionen zu dieser Zahl hinzukommen.

Wir machen immer wieder dieselben Fehler, und was noch besorgniserregender ist: Oft handelt es sich um einfache Schwachstellen, die uns ins Stolpern bringen.

Skripte zwischen Websites und SQL-Injektionen sind nicht verschwunden.

Laut CABLEADO entdeckte Demirkapi, dass die Software Blackboards Community Engagement und das Folletts Student Information System gängige Sicherheitslücken wie Cross-Site-Scripting (XSS) und SQL-Injection enthielten, die Sicherheitsexperten seit den 1990er Jahren ein Dorn im Auge sind. Wir haben ihre Existenz schon seit langer Zeit toleriert, und genau wie Hypercolor-T-Shirts und -Disketten sollten sie längst der Vergangenheit angehören.

Das sind sie jedoch nicht, und es ist klar, dass es nicht genügend Entwickler gibt, die ein ausreichendes Sicherheitsbewusstsein zeigen, um deren Einfügung in ihren Code zu verhindern. Scan-Tools und manuelle Codeüberprüfungen sind nicht sehr hilfreich, und es gibt viel komplexere Sicherheitsprobleme als XSS- und SQL-Injektionen, sodass diese kostspieligen und zeitaufwändigen Maßnahmen besser genutzt werden könnten.

Personen wie Bill Demirkapi sollten Entwickler dazu inspirieren, einen höheren Code-Standard zu schaffen. Mit nur 17 Jahren hat er zwei stark frequentierte Systeme durch Bedrohungsvektoren kompromittiert, die bereits vor der Ausführung des Codes hätten erkannt und behoben werden müssen.

Gamifizierung: Der Schlüssel zum Engagement?

Ich habe viel darüber geschrieben, warum Entwickler nach wie vor weitgehend desinteressiert an Sicherheit sind, und die kurze Antwort lautet, dass auf organisatorischer und pädagogischer Ebene nicht viel unternommen wird, um Entwickler dazu zu bewegen, sich um Sicherheit zu kümmern. Wenn Unternehmen Zeit in die Schaffung einer Sicherheitskultur investieren, die Engagement belohnt und anerkennt, einschließlich der Einführung von Schulungen, die die Sprache der Entwickler sprechen und sie motivieren, weiterzumachen, beginnen diese lästigen Relikte der Verwundbarkeit aus der von uns verwendeten Software zu verschwinden.

Natürlich hat Demirkapi ein außerberufliches Interesse an Sicherheit und hat sich die Zeit genommen, um zu lernen, wie man Malware rückentwickelt, Fehler aufspürt und, nun ja, Dinge kaputt macht, die von außen nicht kaputt zu sein scheinen. Im Gespräch mit VICIO (und anhand seiner DEF CON-Folien) machte er jedoch eine interessante Aussage über seine Selbstbildung ... er hat sie gamifiziert:

„Mit dem Ziel, etwas in der Software meiner Schule zu finden, war es eine unterhaltsame und spielerische Art, mir eine Vielzahl von Penetrationstests beizubringen. Obwohl ich meine Recherche mit der Absicht begann, mehr Informationen zu erhalten, stellte ich schließlich fest, dass die Lage viel schlimmer war, als ich erwartet hatte“, erklärt er.

Auch wenn nicht alle Entwickler sich auf Sicherheit spezialisieren wollen, sollten doch alle die Möglichkeit haben, sich mit diesem Thema auseinanderzusetzen, da die Grundlagen fast wie eine „Lizenz zum Programmieren“ innerhalb einer Organisation gelten, insbesondere in solchen, die eine große Menge unserer vertraulichen Daten verwalten. Wenn alle Entwickler die einfachsten Sicherheitslücken beheben können, noch bevor sie geschrieben werden, sind wir gegenüber denen, die Schaden anrichten wollen, in einer viel sichereren Position.

Sind Sie neugierig auf gamifizierte Schulungen? Sehen Sie sich unsere Reihe „Coders Conquer Security” unter XSS und SQL-Injection.