Die gefährlichsten Softwarefehler des Jahres 2019: Weitere Hinweise darauf, dass sich die Geschichte wiederholt

Dieser Artikel erschien ursprünglich in Buzz zur Informationssicherheit, und wurde von mehreren anderen Verkaufsstellen abgeholt. Es wurde hier für die Syndizierung aktualisiert.

Gegen Ende letzten Jahres veröffentlichte die großartige Community von MITRE ihre Liste der CWE Top 25 der gefährlichsten Softwarefehler das betraf die Welt im Jahr 2019. Diese Liste ist nicht meinungsbasiert, sie ist das Ergebnis einer facettenreichen Analyse unter Verwendung der Arbeit von Organisationen wie NISTsowie veröffentlichte Daten zu Common Vulnerabilities and Exposures (CVE). Um die „häufigsten“ Sicherheitslücken zu ermitteln, wird anhand ihres Schweregrads, ihrer Ausnutzbarkeit und ihrer Häufigkeit in aktueller Software eine Bewertung vergeben. Es ist nicht die Art von Liste, die positive Auszeichnungen erhalten wird, das ist sicher.

Im Gegensatz zu den meisten jährlichen Zusammenfassungen sind viele der Teilnehmer auf dieser Liste jedoch schon einmal erschienen... immer und immer wieder. Wenn das die Billboard Hot 100-Charts wären, wäre sie wie die von Britney SpearsBaby noch einmal und die Backstreet BoysIch will es so erscheint jedes Jahr seit ihrer ersten Veröffentlichung. Und warum habe ich diese Songs ausgewählt? Nun, sie sind ungefähr zwanzig Jahre alt (fühlen Sie sich schon uralt?) , ähnlich wie einige dieser gefährlichen Softwarefehler, die uns bis 2020 plagen, obwohl sie vor Jahrzehnten entdeckt wurden.

Warum sind alte Käfer immer noch so gefährlich? Wissen wir nicht, wie man sie repariert?

Nummer sechs auf der aktuellen MITRE-Liste ist CWE-89, besser bekannt als SQL Injection (SQLi). Die SQLi-Sicherheitslücke wurde erstmals 1998 entdeckt, als viele von uns noch Jeeves statt Google ihre brennenden Fragen stellten. Bald darauf wurde ein Fix bekannt gegeben, und doch ist dies nach wie vor eine der am häufigsten verwendeten Hacking-Techniken im Jahr 2019. von Akamai Stand des Internets Ein Bericht ergab, dass SQLi in zwei Dritteln der alles Angriffe auf Webanwendungen.

Was die Komplexität angeht, ist SQL Injection alles andere als ein genialer Exploit. Es ist eine einfache Lösung für einen Webentwickler, und wir tun wissen ohne zu zögern, wie man verhindern kann, dass diese Sicherheitslücke einem Angreifer wertvolle Daten preisgibt... das Problem ist, dass Sicherheit für viele Entwickler auch heute noch keine Priorität hat. Dies mag vor zwanzig Jahren einfacher gewesen sein, aber angesichts der enormen Menge an Software, die heute und in Zukunft entwickelt wird, kann dies nicht länger die Norm bleiben.

Entwickler arbeiten (meistens) in einem kaputten System.

Es ist allzu einfach, sich zurückzulehnen und Entwicklern die Schuld für die Bereitstellung von „schlechtem“ Code zu geben. Die Wahrheit ist, dass sich ihre Prioritäten stark von denen des Sicherheitsteams unterscheiden. Einem durchschnittlichen Entwicklungsteam wird gesagt, dass es so schnell wie möglich schöne, funktionale Software erstellen soll. Der unersättliche Bedarf der Gesellschaft an Software sorgt dafür, dass die Entwicklungsteams bereits überlastet sind und Sicherheit nicht an erster Stelle steht. Gibt es nicht gerade deswegen AppSec-Spezialisten? Softwareingenieure sind an ein etwas kaltes Verhältnis zur Sicherheit gewöhnt. Sie hören nur von ihnen, wenn Probleme auftreten, und diese Probleme können die Produktion ihrer harten Arbeit behindern.

Auf der anderen Seite des Zauns haben AppSec-Spezialisten es satt, jahrzehntelange Fehler zu beheben, die bei jedem Scan und jeder manuellen Codeüberprüfung immer wieder auftauchen. Diese Spezialisten sind teuer und rar, und ihre Zeit lässt sich weitaus besser mit komplexen Sicherheitslücken verbringen, als bekannte Fehler immer wieder zu beheben.

Es gibt eine unausgesprochene Kultur des Schuldzuweisens zwischen diesen Teams, aber sie haben (oder sollten) dasselbe Ziel haben: sichere Software. Entwickler arbeiten in einer Umgebung, die ihnen in Bezug auf sichere Codierung selten die besten Erfolgschancen bietet. Bewährte Sicherheitsverfahren werden im Rahmen ihrer Hochschulausbildung selten vermittelt, und Schulungen am Arbeitsplatz sind oft viel zu selten oder völlig ineffektiv. Es mangelt deutlich an Sicherheitsbewusstsein und fundierter, relevanter Ausbildung, und das Ergebnis sind die astronomischen Kosten für die Behebung alter Fehler in festgeschriebenem Code sowie die unmittelbare Gefahr einer Datenschutzverletzung, die den Ruf vernichtet.

Der Faktor Mensch, auch bekannt als „Warum machen all diese Tools unsere Daten nicht sicherer?“

Ein weiteres Problem, das häufig auftritt, ist, dass anstelle von Schulungen ein riesiges Arsenal an Sicherheitstools zur Aufgabe gemacht wird, Probleme zu finden, bevor Software in die Wildnis eingeführt wird. Die Tools zum Scannen und Schutz von Array-Anwendungen (SAST/DAST/RASP/IAST) können sicherlich bei der sicheren Softwareproduktion helfen, aber sie haben ihre eigenen Probleme. Ein vollständiges Vertrauen in sie garantiert keine Sicherheit, denn:

• Kein „einziges“ Tool kann nach jeder Sicherheitslücke suchen, in jedem Framework, in jedem Anwendungsfall
• Sie können langsam sein, insbesondere wenn sie gleichzeitig ausgeführt werden, um sowohl statische als auch dynamische Codeanalysen zu ermöglichen
• Fehlalarme sind nach wie vor ein Problem; diese führen häufig zum Stillstand der Produktion und erfordern eine unnötige manuelle Codeüberprüfung, um die Warnmeldungen zu verstehen
• Sie erzeugen ein falsches Sicherheitsgefühl, da sichere Codierung in der Erwartung, dass diese Tools alle Probleme erkennen, an erster Stelle steht.

Die Tools werden sicherlich Sicherheitslücken aufdecken, die gepatcht werden können, aber werden sie alles finden? Eine 100-prozentige Trefferquote kann nicht garantiert werden, und ein Angreifer braucht nur eine offene Tür, um Zutritt zu erhalten und Ihren Tag wirklich zu ruinieren.

Zum Glück erkennen viele Unternehmen, dass der Faktor Mensch eine Rolle spielt Software-Sicherheitslücken. Die meisten Entwickler sind nicht ausreichend für sicheres Programmieren geschult, und ihr allgemeines Sicherheitsbewusstsein ist gering. Sie befinden sich jedoch ganz am Anfang des Softwareentwicklungszyklus und sind in der besten Position, um zu verhindern, dass Sicherheitslücken jemals ihren Weg in festgeschriebenen Code finden. Wenn sie von Anfang an sicher codieren würden, wären sie die vorderste Verteidigungslinie gegen verheerende Cyberangriffe, die uns jedes Jahr Milliarden kosten.

Entwicklern muss die Chance gegeben werden, erfolgreich zu sein, und zwar mit Schulungen, die ihre Sprache sprechen, für ihren Job relevant sind und sie aktiv für Sicherheit begeistern. Fehlerfreier Code sollte ein Punkt sein, auf den man stolz sein kann, ähnlich wie die Entwicklung von etwas, das funktionell umwerfend ist, einem den Respekt seiner Kollegen einbringt.

Ein modernes Sicherheitsprogramm sollte eine Unternehmenspriorität sein.

Entwicklungsteams können sich nicht selbst an ihren Stiefeln hochziehen und im gesamten Unternehmen ein positives Sicherheitsbewusstsein entwickeln. Sie benötigen die richtigen Tools, Kenntnisse und Unterstützung, um Sicherheit von Anfang an in den Softwareentwicklungsprozess einzubeziehen.

Alte Trainingsmethoden funktionieren eindeutig nicht, wenn die MITRE-Liste immer noch so viele alte Sicherheitslücken enthält. Probieren Sie also etwas Neues aus. Suchen Sie nach Trainingslösungen, die:

• Praktisch; Entwickler lieben es, „durch Handeln zu lernen“, anstatt sich in Videos die Redner anzusehen
• Relevant; lassen Sie sie nicht in C# trainieren, wenn sie täglich Java verwenden
• Fesselnd; das Lernen in kleinen Schritten ist leicht verdaulich und ermöglicht es Entwicklern, auf Vorkenntnissen aufzubauen
• Messbar; kreuzen Sie nicht einfach ein Kästchen an und fahren Sie fort. Stellen Sie sicher, dass das Training effektiv ist, und schaffen Sie Verbesserungsmöglichkeiten
• Unterhaltsam. Schauen Sie sich an, wie Sie zusätzlich zur Unterstützung einer positiven Sicherheitskultur ein Sicherheitsbewusstsein aufbauen können und wie dies zu einer kohärenten Teamumgebung führen kann.

Sicherheit sollte für jeden in der Organisation oberste Priorität haben. Der CISO muss sichtbar und transparent sein, was die Bemühungen auf allen Ebenen angeht, um die Sicherheit unserer Daten zu gewährleisten. Ich meine, wer will das gleiche alte Lied immer wieder hören? Es ist an der Zeit, ernsthaft damit zu beginnen, alte Käfer endgültig zu vernichten.