Wir brauchen eine geringere Toleranz gegenüber laxer Sicherheit, aber wir müssen auch diejenigen ermutigen, die tatsächlich versuchen, das Richtige zu tun.
Die Informationssicherheitsbranche tendiert häufig dazu, sich auf das Negative zu konzentrieren. Es ist schwer, es nicht zu tun. Wenn wir nicht auf unsere zahlreichen Verstöße und veralteten Systeme hinweisen, geht es darum, dass wir von monatealten Schwachstellen angegriffen werden und nicht von dieser auffälligen Zero-Day- oder Advanced Persistent Threat.
Und es mag edel und „richtig“ klingen, wenn wir uns entschuldigen, dass wir es besser machen können und akzeptieren, dass wir dumm gemacht haben, Ich glaube, dass viele Informationssicherheitsexperten vermeidbare Fehler machen und oft einfach zu streng mit sich selbst und ihren Mitmenschen umgehen Kollegen. Warum? Denn wenn Sicherheit richtig gemacht wird, hört man selten davon.
Hören wir jemals, dass dem CISO gratuliert wird, dass schon wieder eine Woche vergangen ist und das Unternehmen es nicht in die Schlagzeilen geschafft hat, um etwas zu beaufsichtigen? Haben wir jemals gehört, wie die Leute vor Ort gratulierten, weil sie einen Fehler in ihrer Software entdeckt hatten? und schaffte es, es zu schließen, bevor einer der Tausenden von Angreifern, die ihr System untersuchten, es entdeckte Es? Haben wir jemals im Geschäftsbericht des Unternehmens gelesen, wie die Maßnahmen eines Reaktionsteams viele Millionen gerettet haben? Dollar an entgangenen Einnahmen, Reputationsschäden, Bußgeldern bei Nichteinhaltung oder möglichen Untersuchungen durch Datenschutzbehörden?
Natürlich tun wir das nicht – es ist einfacher, diese Dinge als normale Aufgaben ihres Jobs abzutun.
Ich hätte damit kein so großes Problem – jede Branche hat ihre heimlichen Helden – aber es ist, wenn man an der Spitze steht Für die bestehende Arbeit, für die sie keine Anerkennung erhalten, wollen oder fordern wir sogar, dass Informationssicherheitsexperten sich rächen weiter
PayPal beispielsweise weigerte sich, im Rahmen seines Bug-Bounty-Programms Zahlungen für den 17-jährigen Robert Kugler zu leisten. Kugler entdeckte eine Cross-Site-Scripting-Schwachstelle auf der PayPal-Seite, wurde jedoch von der Teilnahme ausgeschlossen, da er noch nicht 18 Jahre alt war. Meine erste Reaktion war ungläubig. Sollte er warten, bis er das richtige Alter erreicht hatte, und es bis dahin verwundbar lassen? Und wo steht in den PayPal-Bedingungen, dass er ein bestimmtes Alter haben muss? Was sagt das über jüngere Hacker? Dass sie nicht gut genug sind?
Aber so sehr ich die Aktionen von PayPal für dumm hielt, konnte ich die Tatsache nicht leugnen, dass sie viel mehr tun als einige andere Unternehmen. Und als PayPal dem jungen Hacker zurückschrieb und ihm in einer Art versteckter Beleidigung mitteilte, dass er keine „verantwortungsvolle Offenlegung“ praktiziert habe, war ich wütend, musste mich aber langsam dazu zwingen, zuzustimmen.
Ich verstehe, dass es eine frustrierende Erfahrung ist, von einer Schwachstelle zu wissen, deren Behebung eigentlich trivial sein sollte, und doch nichts passiert passiert, aber ich war auch dabei, Code zu schreiben und zu sehen, wie kleine Änderungen erhebliche Auswirkungen auf eine haben können Projekt. Wir ärgern uns zum Beispiel, wenn wir keine Verwendung von vorbereiteten Anweisungen zur Vermeidung von SQL-Injection-Angriffen sehen, aber tatsächlich kann es ein Albtraum sein, Legacy-Code durchzugehen und alles neu zu schreiben. Es dauert nur ein paar Minuten, ein Tool wie Acunetix auf einer Website auszuführen, aber es kann Tage dauern, den Code zu durchforsten – oft nicht einmal Ihren eigenen.
Deshalb finde ich es nicht fair, wenn wir von Unternehmen erwarten, dass sie Probleme innerhalb weniger Stunden nach der Meldung beheben, und von Ingenieuren und Entwicklern verlangen, dass sie es besser machen. Wir tun dies oft, ohne Rücksicht darauf zu nehmen, was hinter den Kulissen passiert, oder auf die schwierigen Entscheidungen, einen Dienst vollständig einzustellen.
Und wenn sie in dem Moment gefangen sind, in dem sie etwas entdecken, was sie übersehen haben, ist es leicht zu glauben, wir wüssten es besser. Nicht jeder tut es, aber es ist allzu einfach, auf dem „Ich habe es dir ja gesagt“-Zug der Rechtschaffenheit zu fahren. So entstehen Hacktivisten-Gruppen, deren Ziel es ist, zu zeigen, wie schwach die Systeme aller sind. Die Absicht ist positiv, aber oft werden die aufgedeckten Schwachstellen nicht aktiv ausgenutzt und am Ende entsteht ein noch größeres Durcheinander, als wir begonnen haben.
Wohin führt uns das dann? Lassen wir zu, dass sich Unternehmen hinter dem Konzept der verantwortungsvollen Offenlegung verstecken? Gar nicht. Offenlegung kann ein wichtiges Instrument sein, um ein Unternehmen zu motivieren, etwas zu tun, aber wir müssen realistischer sein innerhalb des Zeitrahmens, der für die Behebung von Problemen für bestimmte Arten von Schwachstellen auf beiden Seiten des Zauns vorgesehen ist.
Das Argument ist nicht für oder gegen eine vollständige oder sogenannte verantwortungsvolle Offenlegung, sondern darum, klug mit dem umzugehen, was offengelegt wird. Verantwortungslose Bug-Jäger neigen dazu, nicht weit genug vorauszudenken und zu bedenken, wie schlimm die Informationen missbraucht werden könnten. Nachdem Google gesagt hatte, dass wir unsere Definition einer angemessenen Offenlegungsfrist auf sieben Tage verkürzen sollten, Ich mache mir Sorgen, dass die meisten Fehlerreporter dies als den Segen von Google ansehen, dass sie alles, was sie sehen, ohne Verzögerung vollständig offenlegen.
Allerdings war die Formulierung von Google sehr bewusst, als sie ihre Aufforderung auf den Sieben-Tage-Zeitraum beschränkten und feststellten, dass dieser für kritische Schwachstellen geeignet sei, die „aktiv ausgenutzt“ würden. Ich stimme durchaus zu, dass 60- bis 90-tägige Offenlegungssperren heutzutage veraltet sind, aber wir müssen aufpassen, dass dies nicht geschieht Offenlegen Sie voreilig Schwachstellen, die, so traurig es auch ist, durch ein gewisses Maß an Sicherheit geschützt waren Dunkelheit. Die Sieben-Tage-Frist gilt eigentlich für Schwachstellen, die bereits so weit verbreitet sind, dass sie ausgenutzt werden Die Vorteile, alle anderen darüber zu informieren, überwiegen die Nachteile, wenn man es jedem Hacker mitteilt Werkzeugkasten.
Wenn wir nicht darauf achten, die Meldungen nur auf diese Schwachstellen zu beschränken, schaffen wir lediglich mehr Arbeit für unsere ohnehin schon überforderten Informationssicherheitsexperten. Anstatt wichtige, kritische Schwachstellen zu entdecken oder zu beheben, jagen sie Fehler, die nur deshalb ausgenutzt werden, weil sie das heißeste Ding sind, das jemand durchgesickert hat. Es ist wie mit dem Psychiater, der, obwohl er sich um jemanden kümmert, der seine eigenen Sorgen hat, aufhören muss was er unternimmt, um mit dem frustrierten Klienten klarzukommen, der alle im Wartezimmer erschießt, um zu beweisen, dass er es getan hat Probleme.
PayPal musste dieses Problem mit großer Sorgfalt angehen. Ich war einer von vielen, die ihre Wut vertan haben, und es gibt wahrscheinlich unzählige da draußen, die die Botschaft von PayPal nicht verstanden haben, dass es etwas Besseres gibt Bei der Offenlegung geht es eigentlich darum, ihrem Sicherheitsteam keine unangemessene Arbeit zu bereiten und gleichzeitig sicherzustellen, dass Menschen wie Kugler die Anerkennung erhalten, die sie erhalten verdienen. Es ging nicht darum, Kugler zu sagen, dass er das Falsche getan hat und dass Kinder, die sich nicht an die Regeln halten, nicht willkommen sind – es ging darum, ihm zu zeigen, was der beste Weg ist Es wäre gewesen, Sicherheitsteams wie ihrem zu helfen, und höflich vorzuschlagen, wem er in Zukunft helfen könnte, würde die verantwortungsvolle Offenlegung ebenfalls zu schätzen wissen Route.
Aber wie sich herausstellt, hat PayPal durchaus das Recht, eine Zahlung abzulehnen, denn auch wenn die Geschäftsbedingungen lückenhaft sind, ist die Zahlung abgedeckt. Es stimmt, dass PayPal dies nicht eindeutig angibt Bug-Bounty-Programm dass Personen unter 18 Jahren nicht berechtigt sind, aber es heißt eindeutig, dass für die Zahlungsannahme ein verifiziertes PayPal-Konto verwendet werden muss.
Dies ist wichtig, da PayPal allgemein gilt Geschäftsbedingungen Geben Sie an, dass Kontoinhaber mindestens 18 Jahre alt sein müssen. Vor diesem Hintergrund wäre Kugler nicht in der Lage gewesen, eine Zahlung anzunehmen. Es stellt sich auch heraus, dass PayPal offenbar bereits durch einen früheren Reporter von dem Fehler wusste. In seinem Prämienprogramm heißt es, dass nur die erste Person belohnt wird, die die Sicherheitslücke meldet, sodass die Altersdebatte kein Thema ist.
Hätte PayPal mehr tun können? Sicher. Und es wurde anerkannt, dass dies möglich gewesen wäre. In ihrem Brief an Kugler versprach sie ihm ein offizielles Anerkennungsschreiben ihres CISO – eine Premiere für ihr Programm –, dankte ihm und bot ihm sogar einen Anruf für ein Gespräch an. Jedem anderen, der bei einer Bug-Bounty den zweiten Platz belegt hätte, hätte man zu Recht sagen können, dass es zu spät sei.
Ein Teil von mir war zwar niedergeschlagen, dass dies das Beste ist, was PayPal aufbringen konnte, aber wenn ich darüber nachdenke, was PayPal hätte tun können – gesagt Das Kind soll eine Wanderung machen – mir wurde klar, dass es ein weiterer Fall ist, in dem so viele von uns einem Unternehmen gegenüber viel zu streng sind versuchen.
Die Realität ist, dass es nur wenige Unternehmen gibt, deren Sicherheit auf einem Niveau liegt, das auch den anspruchsvollsten von uns gerecht wird, und noch weniger, die über Bug-Bounty-Programme verfügen. Anstatt jedoch auf die Mängel derjenigen hinzuweisen, die es versuchen, sollten wir andere dazu ermutigen, mehr Fehlerreportern zuzuhören.
Wir werden nicht erleben, dass sich andere der Herausforderung stellen, verantwortungsvolle Offenlegung zu belohnen, wenn das Einzige, was wir tun, darin besteht, auf die Mängel bestehender Programme hinzuweisen. Und so traurig es auch sein mag, ein fehlerhaftes Programm ist besser als gar keines.