Holen Sie sich die neuesten wichtigen Update-Informationen für die Log4j-Sicherheitslücke. Sehen Sie sich an, wie Sie das Problem mithilfe der Parasoft-Anleitung beheben können. Erfahren Sie mehr >>

X
BLOG

Warum Appsec-Sicherheitslücken als "theoretisch" oder "falsch" abgetan werden

Warum Appsec-Sicherheitslücken als "theoretisch" oder "falsch" abgetan werden Lesezeit: 6 Minuten

Dieser Inhalt wurde ursprünglich am veröffentlicht Der Code Curmudgeon Blog.

By Arthur Hicken, Chefevangelist bei Parasoft

In einem previous post In Bezug auf theoretische Appsec-Schwachstellen habe ich erläutert, wie „theoretisch“ von Personen missbraucht wird, die versuchen, die Behebung einer Sicherheitslücke zu vermeiden oder die Verantwortung dafür zu übernehmen - zum Beispiel die Lenovo Superfish VerletzungHeartbleedund Airline-WLAN-Angriffe.

Die Vorstellung, dass eine Sicherheitslücke nur theoretisch ist, ist nicht nur unwissend, sondern auch gefährlich. Software-Exploits treten auf, weil schlechte Akteure unerwartete Lücken in einem Softwaresystem finden. Stellen Sie sich das so vor - wenn Sie Ihre Tür unverschlossen gelassen haben, handelt es sich um ein Sicherheitsproblem? Oder vielleicht "Wenn eine unverschlossene Tür nie betreten wird, ist sie wirklich unverschlossen", wenn Sie ein Philosoph sind. Man könnte behaupten, dass das Risiko theoretisch ist, aber die meisten von uns würden sagen, dass eine solche Aussage lächerlich ist. (Requisiten für diejenigen, die in einem Bereich leben, in dem keine Türsicherheit erforderlich ist.)

Software-Schwachstellen sind genau wie unverschlossene Türen. Sie sind nicht theoretisch, sondern ein tatsächliches Ganzes oder Öffnungen in Ihrer Software, als dies möglich ist und wahrscheinlich ausgenutzt wird. Wenn wir sichere Anwendungen haben wollen, müssen wir erwachsen werden und nicht mehr so ​​tun, als wären die Schwachstellen, mit denen wir konfrontiert sind, nicht real. Wir müssen einen proaktiven präventiven Engineering-Ansatz verfolgen, der Schwachstellen als echte Risiken behandelt. Nur dann können wir sicher sein.

Trotzdem rechtfertigen die Menschen weiterhin das Ignorieren der Ergebnisse ihrer Sicherheitsscanner. Wie rationalisieren sie das? In keiner bestimmten Reihenfolge…

Lärm

Lärm, Lärm, Lärm! Wie auch immer Sie es nennen, ob es sich um Fehlalarme, Fehlalarme, theoretische Probleme, zu viele Nachrichten oder irgendetwas anderes handelt, Lärm ist ein großer Schmerz. Jeff sagt, Genauigkeit ist wichtig und das tut es auch. Aber meiner Erfahrung nach sind Entwickler sehr schnell dabei, den "Rausch" -Auslöser zu betätigen. Es würde Spaß machen, eine Umfrage / ein Quiz mit ein paar echten Codebeispielen durchzuführen und zu sehen, was Entwickler denken. Das Quiz zur grundlegenden Anwendungssicherheit Bei der AppSec Notes-Blog Die Wissensprobleme beim Erkennen realer Sicherheitslücken im tatsächlichen Code werden jedoch nicht offengelegt. Mit anderen Worten, würden Sie erkennen, warum ein Code gefährlich ist, wenn Sie ihn sehen? Ich würde gerne das Quiz sehen, das sowohl gute als auch schlechte Codebeispiele enthält, sowie die Frage „Sicherheitsproblem oder OK“. Dies ist schwieriger als es zunächst klingt, da Sie nicht nur schlechten Code und festen Code haben können, sondern auch schlechten Code und dann verdächtigen Code benötigen, der wahrscheinlich einen Fehlalarm auslösen würde. Jetzt gibt es einen echten Test. Wenn jemand von einem solchen Tier weiß oder eines bauen möchte, lass es mich wissen.

Das Rauschen kann noch verschlimmert werden, wenn Sie falsche Ziele und Metriken haben. Wenn Sie den Erfolg beispielsweise auf der Anzahl der gefundenen Probleme basieren, werden Sie wahrscheinlich die größte Anzahl unwichtiger Probleme finden. In der Präsentation werden bessere Definitionen des Erfolgs erörtert AppSec Broken Window-Theorie das ist lesenswert. Ein schnelles Beispiel ist die Verfolgung des Erfolgs anhand der Anzahl der in neuen Anwendungen nicht gefundenen „Fehler“.

Ein weiterer Punkt zum Thema Lärm, insbesondere im Bereich dessen, was Menschen gerne als falsch positiv bezeichnen. Ich habe das "Curmudgeon-Gesetz der Nützlichkeit statischer Analysewerkzeuge". Je cleverer ein statisches Analysewerkzeug ist, desto wahrscheinlicher wird seine Ausgabe als falsch positiv wahrgenommen. Dies liegt daran, dass es einfach ist, ein Ergebnis zu akzeptieren, das Sie verstehen. Wenn jedoch ein Tool versucht, Ihnen etwas zu sagen, das Sie nicht wissen (dh das nützlichste Ergebnis), ist es am unwahrscheinlichsten, dass Sie es akzeptieren. Deshalb setze ich mich immer wieder für a) eine bessere Präsentation der Ergebnisse ein, um zu erklären, WARUM es wichtig ist, und b) ein besseres Training.

Schlechter Workflow oder Prozess

Dies hängt eng mit dem Rauschproblem zusammen. Wenn Sie einen schlechten Workflow, Prozess oder eine schlechte Konfiguration haben, ist das Scannen Ihrer Sicherheit schmerzhaft. Manchmal ist dieser Schmerz Lärm, manchmal zusätzliche Anstrengung, langsame Arbeit oder andere Symptome. Zum Beispiel hatte ich gesehen, wie Leute statische Analysen auf Legacy-Code scannten, bei denen die Unternehmensrichtlinie "keine Änderungen, es sei denn, es liegt ein vor Ort gemeldeter Fehler vor" lautete. Das Scannen von Code, den Sie nicht reparieren möchten, oder das Suchen nach Elementen, die Sie nicht reparieren möchten, trägt zweifellos zu Rauschen, Aufwand und Kosten bei.

Zum Mitnehmen müssen Sie sicherstellen, dass Ihre Tools optimal konfiguriert sind und die Art und Weise, wie sie in Ihren Prozess integriert werden, keine Kopfschmerzen verursacht. Ich könnte mich schon lange mit diesem Thema befassen, aber wir werden das für einen weiteren Tag aufheben. Wie können Sie feststellen, ob es Kopfschmerzen verursacht? Fragen Sie diejenigen, die die Tools verwenden, und diejenigen, die die Ausgabe der Tools adressieren müssen.

Eine weitere gute Lektüre zu diesem Thema ist Kommt der Fortschritt von Sicherheitsprodukten oder -prozessen? wo Gunnar Peterson sagt “Die Verfahrenstechnik ist zutiefst unsexy. Es ist ungefähr so ​​weit entfernt von der glamourösen Modenschau-Welt der Sicherheitskonferenzen, wie Sie sich vorstellen können, aber hier finden die tatsächlichen Änderungen statt."

Priorisierung

Auch dies ist eine Kategorie, die eng mit Lärm verbunden ist. Rauschen ist ein Symptom für eine mangelnde Priorisierung Ihrer Appsec-Ergebnisse. Im Idealfall speichern Sie die gesamte Ausgabe aller Sicherheitstools in Ihrem Arsenal in einem intelligenten datengesteuerten System, mit dessen Hilfe Sie ermitteln können, welche Elemente am wichtigsten sind. Niemand möchte Wochen damit verbringen, etwas zu reparieren, was unwahrscheinlich ist, und selbst wenn dies der Fall ist, sind die Konsequenzen minimal.

Die AppSec-Priorisierung muss das Risiko berücksichtigen. Wird das passieren? Passiert das heute? Wie schwer ist es auszunutzen? Wie schwer ist es zu verhindern? Plus alle anderen üblichen Fragen zum Risikomanagement. Sie wissen, was zu tun ist. Wenn Sie zu viel Lärm von Ihren Werkzeugen haben, müssen Sie etwas Intelligenz dahinter stecken, um zu dem zu gelangen, worauf es ankommt.

Beachten Sie, dass ich mit Priorisierung nicht unbedingt Triage meine. Triage impliziert einen vom Menschen angetriebenen Prozess (siehe Engpass), der in kurzer Zeit schmerzhafte Kompromisse eingeht, anstatt einen geordneten, durchdachten Prozess. In dem Gebrochenes Windows Präsentation, die ich zuvor erwähnt habe Erik Peterson sagt "Triage! = Application Security Program" und ich stimme voll und ganz zu.

Aus diesem Grund bin ich ein Fan des Versuchs, umfassende Frameworks für Risikoanwendungen zu entwickeln. Einige davon sind die Gemeinsames Schwächen-Bewertungssystem (CWSS), das bei Mitre verwaltet wird. CWSS schlägt eine Möglichkeit vor, Sicherheitsergebnisse im Kontext Ihrer Anwendung richtig abzuwägen, um eine bessere automatisierte Priorisierung zu ermöglichen. Dies geht Hand in Hand mit dem Gemeinsamer Rahmen für die Analyse von Schwachstellenrisiken (CWRAF).

Ich weiß, dass sie alles andere als perfekt sind und in der Tat häufig viel zu kompliziert und schmerzhaft sind, um sie zu verwenden. Die Forschung in diesem Bereich wird eine kontinuierliche Verbesserung sicherstellen, und ich gehe davon aus, dass dies letztendlich der entscheidende Treiber im Bereich des Appsec-Scannens sein wird.

Testen Sie die Sicherheit in

Wir haben alle das Sprichwort gehört, dass Sie "die Qualität einer Anwendung nicht testen können". Dies basiert auf Demings drittem Prinzip: „Hören Sie auf, von der Inspektion abhängig zu sein, um Qualität zu erreichen.“ Früher waren viele mit Deming nicht einverstanden, aber heute ist es eine akzeptierte Wahrheit, dass Inspektion allein Ihre Probleme nicht lösen wird. Doch irgendwie glauben viele in AppSec, dass wir "die Sicherheit in einer Anwendung testen" können. Diese Einstellung ist leicht zu erkennen, da sie zu Sicherheitsprozessen führt, die vollständig orthogonal zur Entwicklung sind und durch alle Sicherheitsaktivitäten hervorgehoben werden, die QA-ähnliche Aktivitäten nach der Entwicklung sind. Diese Methode hat nicht für die Qualität und nicht für die Sicherheit funktioniert.

Um den Sicherheitsaspekten der Software einen Schritt voraus zu sein, müssen wir zunächst mit der Erstellung sicherer Software beginnen. Es gibt eine großartige Seite, die von der US-Regierung gesponsert wird Bauen Sie Sicherheit ein und es hat viele großartige Informationen, die Sie zum Laufen bringen. Schauen Sie sich auch die an Gebäudesicherheit im Reifegradmodell. Mir ist klar, dass es so ist leichter zu sagen "Einbauen" als es tatsächlich zu tun ist und das Einbauen bringt seine eigenen Herausforderungen mit sich. Aber wie bei Herstellung und Qualität ist dies der einzige Weg, um langfristig eine nachhaltige Verbesserung zu erzielen.

Ausbildung

Der SANS Institut tat ein Umfrage zu Anwendungssicherheitsprogrammen und -praktiken und gefunden

„Obwohl Lieferanten die Geschwindigkeit und Genauigkeit von SAST-Tools weiter verbessern und ihre Verwendung vereinfachen, benötigen Entwickler Sicherheitsschulungen oder Expertenhilfe, um zu verstehen, was die Tools ihnen sagen, welche Schwachstellen wichtig sind, warum sie behoben werden müssen und wie repariere sie."

Der Bericht stellt fest, dass nur 26% der Organisationen über eine sichere Codierung verfügten, die gut funktionierte oder vorgeschrieben war. Weiter liest es

„Ein Mangel an Wissen und Fähigkeiten hält Appsec-Programme heute zurück und verhindert, dass Unternehmen in Zukunft echte Fortschritte in Appsec erzielen. Das größte Hindernis für den Erfolg, über das in der diesjährigen Umfrage berichtet wurde, ist der Fachkräftemangel, der Teil eines größeren Problems der IT-Sicherheitsbranche im Allgemeinen ist, wie jüngste Studien von Forrester Research13 und (ISC) 214 zeigen.

Um diesen Fachkräftemangel zu beheben, sind Schulungen und Schulungen erforderlich - nicht nur die Schulung weiterer Infosec- und Appsec-Spezialisten, sondern auch die Schulung von Entwicklern und Managern. Weniger als ein Viertel der Befragten verfügt über fortlaufende und gut funktionierende Schulungsprogramme, und sichere Codierungstrainings stehen in der Liste der Praktiken, auf die Unternehmen in ihren Appsec-Programmen heute angewiesen sind, ganz unten. Das muss sich ändern. ”

OWASP spricht über die Wichtigkeit der Ausbildung

"Aus Sicht der Informationssicherheit sollte der ganzheitliche Ansatz zur Anwendungssicherheit beispielsweise Sicherheitsschulungen für Softwareentwickler sowie Sicherheitsbeauftragte und -manager umfassen."

Umfrage in 2010 zeigten, dass kein Sicherheitstraining durchgeführt wurde und ich vermute, dass sich heute wenig geändert hat.

"Fast 80% der Mitarbeiter von Regierungsbehörden und Auftragnehmern gaben an, dass ihre Organisation laut einer neuen Umfrage keine ausreichende Schulung und Anleitung für die Entwicklung und Bereitstellung von Softwaresicherheitsanwendungen bietet."

Zusammenfassung

Werkzeuge allein und Werkzeuggenauigkeit lösen die Probleme von AppSec nicht vollständig. Wieder aus der Sans-Umfrage

„Es gibt keine Tools der nächsten Generation oder andere Silberkugeln am Horizont, die das Problem sicherer Software lösen könnten. Beim Schreiben sicherer Software geht es um Grundlagen: durchdachtes Design, sorgfältige Codierung, disziplinierte Tests und informiertes und verantwortungsbewusstes Management. Je früher Unternehmen dies verstehen - und damit beginnen - desto eher werden sie ihre Sicherheitsprobleme lösen. ”

Fehlalarme und Genauigkeit sind ein großes Problem. So ist der Mangel an Ausbildung. Ich würde nicht argumentieren wollen, dass einer wichtiger ist als der andere, weil ich leicht beide Seiten streiten könnte. Beides ist wichtig. Bis wir eine haben perfektes SicherheitstoolDas heißt, keine Fehlalarme und ebenso wichtig, keine Fehlalarme. Die Schulung spielt eine notwendige integrale Rolle für die Anwendungssicherheit (appsec) und die Software-Sicherheit (swsec).

Geschrieben von

Parasoft

Die branchenführenden automatisierten Softwaretest-Tools von Parasoft unterstützen den gesamten Softwareentwicklungsprozess, vom Schreiben der ersten Codezeile über Unit- und Funktionstests bis hin zu Leistungs- und Sicherheitstests, wobei simulierte Testumgebungen genutzt werden.

Erhalten Sie die neuesten Nachrichten und Ressourcen zum Testen von Software sofort.