Der vergessene menschliche Faktor bei Sicherheitslücken in Webanwendungen
Der vergessene menschliche Faktor bei Sicherheitslücken in Webanwendungen
Der 2018 Verizon Data Breach Investigations Report ist wieder einmal eine großartige Lektüre, die uns über Cybersicherheit auf dem Laufenden hält, einschließlich aktueller Trends zur Cyberkriminalität und Treiber von Vorfällen, Analysen und Einblicke, die Unternehmen helfen können, ihr Sicherheitsprogramm zu reifen. In diesem Jahr analysierten die Ermittler von Verizon mehr als 53.000 Vorfälle und rund 2.200 Sicherheitsverletzungen, und es gibt viele greifbare Erkenntnisse darüber, worauf man achten sollte und was man nicht tun sollte, sowie wertvolle Empfehlungen, worauf man seine Sicherheitsanstrengungen konzentrieren sollte. Der Bericht 2018 fühlt sich an, als sei er mit der Zeit gegangen und für ein breiteres Geschäftspublikum relevant, da sich die Auswirkungen von Sicherheitsverletzungen ausbreiten und zunehmend als Mainstream-Geschäftsproblem erkannt werden.
Neben vielen interessanten Erkenntnissen bestätigt der Bericht 2018, dass die meisten Hacks nach wie vor durch Einbrüche in Webanwendungen erfolgen (es gibt sogar eine coole interaktive Grafik, die dies zeigt).
Angriffe aus Webanwendungen umfassen alle Vorfälle, bei denen eine Webanwendung der Angriffsvektor war. Dies umfasst sowohl die Ausnutzung von Schwachstellen auf Code-Ebene in der Anwendung als auch die Aushebelung von Authentifizierungsmechanismen. Es ist bemerkenswert, dass die Anzahl der Verstöße in diesem Muster durch das Herausfiltern von Botnetz-bezogenen Angriffen auf Webanwendungen unter Verwendung von Anmeldeinformationen, die von kundeneigenen Geräten gestohlen wurden, zurückgegangen ist. Die Verwendung gestohlener Zugangsdaten ist nach wie vor die häufigste Angriffsart bei Sicherheitsverletzungen von Webanwendungen, gefolgt von SQLi (mehr zu SQL später...).
Ein Thema, das im diesjährigen Bericht hervorsticht, ist, wie entscheidend der "menschliche Faktor" in der Sicherheitsgleichung ist, sowohl als Teil des Problems als auch der Lösung. Der Bericht befasst sich sowohl mit externen als auch mit internen Akteuren und berichtet, dass bei fast jedem fünften (17 %) Sicherheitsverstoß Fehler die Ursache waren. Verstöße traten auf, wenn Mitarbeiter es versäumten, vertrauliche Informationen zu schreddern, wenn sie eine E-Mail an die falsche Person schickten und wenn Webserver falsch konfiguriert waren. Der Bericht weist darauf hin, dass zwar keiner dieser Fehler absichtlich böswillig war, er sich aber dennoch als kostspielig erweisen kann.
Aber es gibt einen oft vergessenen menschlichen Faktor, der viele Sicherheitsverletzungen verursacht, und das ist die hohe Häufigkeit, mit der Entwickler Code erstellen, der Sicherheitslücken enthält, die zu Schwachstellen in Webanwendungen führen, die wiederum zu diesen Vorfällen und Verletzungen führen.
Anwendungstests haben in den letzten 5 Jahren keine große Verbesserung bei der Anzahl der gefundenen Schwachstellen gezeigt und die gleichen alten Fehler tauchen immer wieder auf. Ein Veracode-Bericht aus dem Jahr 2017, der auf 400.000 Anwendungsscans basiert, zeigt, dass Anwendungen nur in 30 % der Fälle die OWASP Top 10-Richtlinie bestanden. Erstaunlich ist, dass SQL-Injektionen in fast jeder dritten neu gescannten Anwendung in den letzten 5 Jahren auftraten, einschließlich des letzten Jahres.Ich sage erstaunlich, weil es SQL-Injektionen schon seit 1999 gibt. Die Tatsache, dass immer wieder die gleichen Fehler, einschließlich SQL-Injections, gefunden werden, ist ein Beweis dafür, dass dieses Problem des "menschlichen Faktors" unter den Entwicklern nicht angemessen angegangen wird.
An diesem Punkt muss ich aufstehen und rufen, dass ich auf der Entwicklerseite dieses Arguments stehe. Wie sollen Entwickler sicheren Code schreiben, wenn ihnen niemand jemals beibringt, warum das wichtig ist, welche Konsequenzen unsicherer Code hat und vor allem, wie man das Schreiben dieser Schwachstellen in ihren jeweiligen Programmier-Frameworks von vornherein verhindert?
Das ist es, was wir bei Secure Code Warrior tun, und wir sehen eindeutige Beweise dafür, dass Unternehmen, die praktische Schulungen für sicheren Code in den Alltag ihrer Entwickler einbauen, die Anzahl der entstehenden Schwachstellen in Webanwendungen reduzieren. Damit Entwickler sicheren Code schreiben können, müssen sie regelmäßig Zugang zu praktischen Schulungen haben, die sie aktiv dazu anregen, ihre Fähigkeiten zur sicheren Programmierung auszubauen. Sie müssen über kürzlich identifizierte Schwachstellen lernen, in echtem Code und speziell in ihren eigenen Sprachen/Frameworks. Diese Lernerfahrung sollte ihnen helfen zu verstehen, wie man bekannte Schwachstellen lokalisiert, identifiziert und behebt. Entwickler brauchen auch ein Qualitäts-Toolset in ihrem Prozess, das Sicherheit einfach macht, sie nicht ausbremst und sie in Echtzeit über gute und schlechte Codierungsmuster anleitet.
Auf diese Weise können wir die Zahl der Verstöße gegen Webanwendungen spürbar und positiv beeinflussen.
Ich stimme heftig mit Verizon überein, dass es notwendig ist, das Sicherheitsbewusstsein unternehmensweit zu schulen. Mein P.S. zu diesem Thema an CIOs und CISOs lautet: "Vergessen Sie nicht Ihre Entwickler!". Diese Architekten Ihrer modernen Unternehmen können ein wesentlicher "menschlicher Faktor" sein, der routinemäßig Zugangspunkte für Hacker generiert, oder sie können Ihre erste Verteidigungslinie sein, Ihre Sicherheitshelden.
Effektive Sicherheitsschulungen für Entwickler könnten einen echten Unterschied zu den von Verizon in zukünftigen Berichten berichteten Ergebnissen machen. Es wäre schön, wenn der Bericht für 2019 die Sicherheitsschulung von Entwicklern als eine wichtige Strategie zur Risikominderung für Unternehmen berücksichtigen würde. Ich bin ein Optimist, aber ich würde mein Haus darauf verwetten, dass die Anzahl der Schwachstellen in Webanwendungen in diesem Bericht deutlich sinken würde, wenn Unternehmen ihren Entwicklern beibringen würden, wie sie Injektionsfehler vermeiden können.
Werfen Sie einen Blick auf unsere Plattform in Aktion, um zu sehen, wie sich Entwickler in einer idealen, gamifizierten Trainingsumgebung schnell weiterbilden können:
Spielen Sie eine sichere Kodierungsherausforderung
Besuchen Sie unsere kostenlosen Lernressourcen
Wie sollen Entwickler sicheren Code schreiben, wenn ihnen niemand beibringt, warum das wichtig ist, welche Konsequenzen unsicherer Code hat und vor allem, wie sie diese Schwachstellen in ihren jeweiligen Programmier-Frameworks gar nicht erst schreiben?
Pieter Danhieux
Pieter Danhieux ist ein weltweit anerkannter Sicherheitsexperte mit mehr als 12 Jahren Erfahrung als Sicherheitsberater und 8 Jahren als Principal Instructor für SANS, wo er offensive Techniken lehrt, wie man Organisationen, Systeme und Einzelpersonen auf Sicherheitsschwächen hin untersucht und bewertet. Im Jahr 2016 wurde er als einer der "Coolest Tech People in Australia" (Business Insider) ausgezeichnet, erhielt die Auszeichnung "Cyber Security Professional of the Year" (AISA - Australian Information Security Association) und besitzt die Zertifizierungen GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.
Verwandte Artikel, die wir empfehlen
Verwandte Artikel, die wir empfehlen
Tauchen Sie ein in unsere neuesten Erkenntnisse über sichere Kodierung im Blog.
Unsere umfangreiche Ressourcenbibliothek zielt darauf ab, die menschliche Herangehensweise an eine sichere Weiterbildung im Bereich der Programmierung zu stärken.
Holen Sie sich die neuesten Forschungsergebnisse zur entwicklergesteuerten Sicherheit
Unsere umfangreiche Ressourcenbibliothek ist voll von hilfreichen Ressourcen, von Whitepapers bis hin zu Webinaren, die Ihnen den Einstieg in die entwicklungsorientierte sichere Programmierung erleichtern. Erforschen Sie sie jetzt.
Der vergessene menschliche Faktor bei Sicherheitslücken in Webanwendungen
Der 2018 Verizon Data Breach Investigations Report ist wieder einmal eine großartige Lektüre, die uns über Cybersicherheit auf dem Laufenden hält, einschließlich aktueller Trends zur Cyberkriminalität und Treiber von Vorfällen, Analysen und Einblicke, die Unternehmen helfen können, ihr Sicherheitsprogramm zu reifen. In diesem Jahr analysierten die Ermittler von Verizon mehr als 53.000 Vorfälle und rund 2.200 Sicherheitsverletzungen, und es gibt viele greifbare Erkenntnisse darüber, worauf man achten sollte und was man nicht tun sollte, sowie wertvolle Empfehlungen, worauf man seine Sicherheitsanstrengungen konzentrieren sollte. Der Bericht 2018 fühlt sich an, als sei er mit der Zeit gegangen und für ein breiteres Geschäftspublikum relevant, da sich die Auswirkungen von Sicherheitsverletzungen ausbreiten und zunehmend als Mainstream-Geschäftsproblem erkannt werden.
Neben vielen interessanten Erkenntnissen bestätigt der Bericht 2018, dass die meisten Hacks nach wie vor durch Einbrüche in Webanwendungen erfolgen (es gibt sogar eine coole interaktive Grafik, die dies zeigt).
Angriffe aus Webanwendungen umfassen alle Vorfälle, bei denen eine Webanwendung der Angriffsvektor war. Dies umfasst sowohl die Ausnutzung von Schwachstellen auf Code-Ebene in der Anwendung als auch die Aushebelung von Authentifizierungsmechanismen. Es ist bemerkenswert, dass die Anzahl der Verstöße in diesem Muster durch das Herausfiltern von Botnetz-bezogenen Angriffen auf Webanwendungen unter Verwendung von Anmeldeinformationen, die von kundeneigenen Geräten gestohlen wurden, zurückgegangen ist. Die Verwendung gestohlener Zugangsdaten ist nach wie vor die häufigste Angriffsart bei Sicherheitsverletzungen von Webanwendungen, gefolgt von SQLi (mehr zu SQL später...).
Ein Thema, das im diesjährigen Bericht hervorsticht, ist, wie entscheidend der "menschliche Faktor" in der Sicherheitsgleichung ist, sowohl als Teil des Problems als auch der Lösung. Der Bericht befasst sich sowohl mit externen als auch mit internen Akteuren und berichtet, dass bei fast jedem fünften (17 %) Sicherheitsverstoß Fehler die Ursache waren. Verstöße traten auf, wenn Mitarbeiter es versäumten, vertrauliche Informationen zu schreddern, wenn sie eine E-Mail an die falsche Person schickten und wenn Webserver falsch konfiguriert waren. Der Bericht weist darauf hin, dass zwar keiner dieser Fehler absichtlich böswillig war, er sich aber dennoch als kostspielig erweisen kann.
Aber es gibt einen oft vergessenen menschlichen Faktor, der viele Sicherheitsverletzungen verursacht, und das ist die hohe Häufigkeit, mit der Entwickler Code erstellen, der Sicherheitslücken enthält, die zu Schwachstellen in Webanwendungen führen, die wiederum zu diesen Vorfällen und Verletzungen führen.
Anwendungstests haben in den letzten 5 Jahren keine große Verbesserung bei der Anzahl der gefundenen Schwachstellen gezeigt und die gleichen alten Fehler tauchen immer wieder auf. Ein Veracode-Bericht aus dem Jahr 2017, der auf 400.000 Anwendungsscans basiert, zeigt, dass Anwendungen nur in 30 % der Fälle die OWASP Top 10-Richtlinie bestanden. Erstaunlich ist, dass SQL-Injektionen in fast jeder dritten neu gescannten Anwendung in den letzten 5 Jahren auftraten, einschließlich des letzten Jahres.Ich sage erstaunlich, weil es SQL-Injektionen schon seit 1999 gibt. Die Tatsache, dass immer wieder die gleichen Fehler, einschließlich SQL-Injections, gefunden werden, ist ein Beweis dafür, dass dieses Problem des "menschlichen Faktors" unter den Entwicklern nicht angemessen angegangen wird.
An diesem Punkt muss ich aufstehen und rufen, dass ich auf der Entwicklerseite dieses Arguments stehe. Wie sollen Entwickler sicheren Code schreiben, wenn ihnen niemand jemals beibringt, warum das wichtig ist, welche Konsequenzen unsicherer Code hat und vor allem, wie man das Schreiben dieser Schwachstellen in ihren jeweiligen Programmier-Frameworks von vornherein verhindert?
Das ist es, was wir bei Secure Code Warrior tun, und wir sehen eindeutige Beweise dafür, dass Unternehmen, die praktische Schulungen für sicheren Code in den Alltag ihrer Entwickler einbauen, die Anzahl der entstehenden Schwachstellen in Webanwendungen reduzieren. Damit Entwickler sicheren Code schreiben können, müssen sie regelmäßig Zugang zu praktischen Schulungen haben, die sie aktiv dazu anregen, ihre Fähigkeiten zur sicheren Programmierung auszubauen. Sie müssen über kürzlich identifizierte Schwachstellen lernen, in echtem Code und speziell in ihren eigenen Sprachen/Frameworks. Diese Lernerfahrung sollte ihnen helfen zu verstehen, wie man bekannte Schwachstellen lokalisiert, identifiziert und behebt. Entwickler brauchen auch ein Qualitäts-Toolset in ihrem Prozess, das Sicherheit einfach macht, sie nicht ausbremst und sie in Echtzeit über gute und schlechte Codierungsmuster anleitet.
Auf diese Weise können wir die Zahl der Verstöße gegen Webanwendungen spürbar und positiv beeinflussen.
Ich stimme heftig mit Verizon überein, dass es notwendig ist, das Sicherheitsbewusstsein unternehmensweit zu schulen. Mein P.S. zu diesem Thema an CIOs und CISOs lautet: "Vergessen Sie nicht Ihre Entwickler!". Diese Architekten Ihrer modernen Unternehmen können ein wesentlicher "menschlicher Faktor" sein, der routinemäßig Zugangspunkte für Hacker generiert, oder sie können Ihre erste Verteidigungslinie sein, Ihre Sicherheitshelden.
Effektive Sicherheitsschulungen für Entwickler könnten einen echten Unterschied zu den von Verizon in zukünftigen Berichten berichteten Ergebnissen machen. Es wäre schön, wenn der Bericht für 2019 die Sicherheitsschulung von Entwicklern als eine wichtige Strategie zur Risikominderung für Unternehmen berücksichtigen würde. Ich bin ein Optimist, aber ich würde mein Haus darauf verwetten, dass die Anzahl der Schwachstellen in Webanwendungen in diesem Bericht deutlich sinken würde, wenn Unternehmen ihren Entwicklern beibringen würden, wie sie Injektionsfehler vermeiden können.
Werfen Sie einen Blick auf unsere Plattform in Aktion, um zu sehen, wie sich Entwickler in einer idealen, gamifizierten Trainingsumgebung schnell weiterbilden können:
Spielen Sie eine sichere Kodierungsherausforderung
Besuchen Sie unsere kostenlosen Lernressourcen
Wie sollen Entwickler sicheren Code schreiben, wenn ihnen niemand beibringt, warum das wichtig ist, welche Konsequenzen unsicherer Code hat und vor allem, wie sie diese Schwachstellen in ihren jeweiligen Programmier-Frameworks gar nicht erst schreiben?
