Die gefährlichsten Softwarefehler 2019: Ein weiterer Beweis dafür, dass sich die Geschichte wiederholt

Dieser Artikel erschien ursprünglich in Information Security Buzz und wurde von mehreren anderen Medien aufgegriffen. Er wurde für die hiesige Veröffentlichung aktualisiert.

Gegen Ende letzten Jahres veröffentlichte die großartige Community von MITRE ihre Liste der 25 gefährlichsten Softwarefehler (CWE Top 25), die die Welt im Jahr 2019 betrafen. Diese Liste basiert nicht auf Meinungen, sondern ist das Ergebnis einer vielschichtigen Analyse unter Einbeziehung der Arbeit von Organisationen wie NIST sowie öffentlich zugänglicher Daten zu Common Vulnerabilities and Exposures (CVE). Um die „Top“-Schwachstellen zu ermitteln, wird ein Wert basierend auf Schweregrad, Ausnutzbarkeit und Verbreitung in aktueller Software vergeben. Es ist definitiv keine Liste, für die man Auszeichnungen gewinnen möchte.

Im Gegensatz zu den meisten Jahresrückblicken sind viele der Einträge auf dieser Liste jedoch schon einmal aufgetaucht... immer und immer wieder. Wären dies die Billboard Hot 100, wäre es so, als würden Britney Spears' Baby One More Time und die Backstreet Boys' I Want It That Way jedes einzelne Jahr seit ihrer Erstveröffentlichung in den Charts stehen. Und warum habe ich diese Songs gewählt? Nun, sie sind ungefähr zwanzig Jahre alt (fühlen Sie sich jetzt alt?), genau wie einige dieser gefährlichen Softwarefehler, die uns trotz ihrer Entdeckung vor Jahrzehnten auch im Jahr 2020 noch plagen.

Warum sind alte Fehler immer noch so gefährlich? Wissen wir nicht, wie man sie behebt?

Nummer sechs auf der aktuellen MITRE-Liste ist CWE-89, besser bekannt als SQL-Injection (SQLi). Die SQLi-Schwachstelle wurde erstmals 1998 entdeckt, als viele von uns noch Jeeves statt Google nach brennenden Fragen fragten. Kurz darauf wurde ein Fix bekannt, und dennoch bleibt dies eine der am häufigsten verwendeten Hacking-Techniken im Jahr 2019. Der State of the Internet-Bericht von Akamai enthüllte, dass SQLi bei zwei Dritteln aller Webanwendungsangriffe der Übeltäter war.

Was die Komplexität angeht, ist SQL-Injection weit davon entfernt, ein Exploit auf Genie-Niveau zu sein. Für einen Webentwickler ist es eine einfache Korrektur, und wir wissen zweifellos, wie man verhindert, dass diese Schwachstelle wertvolle Daten einem Angreifer preisgibt... das Problem ist, dass Sicherheit für viele Entwickler auch heute noch keine Priorität hat. Vor zwanzig Jahren mag das einfacher gewesen sein, aber bei der schieren Menge an Software, die heute und in Zukunft erstellt wird, kann dies nicht länger die Norm bleiben.

Entwickler arbeiten (meistens) in einem kaputten System.

Es ist nur allzu leicht, sich zurückzulehnen und Entwicklern die Schuld für „schlechten“ Code zu geben. Die Wahrheit ist, dass ihre Prioritäten stark von denen des Sicherheitsteams abweichen. Ihrem durchschnittlichen Entwicklungsteam wird gesagt, es solle so schnell wie möglich schöne, funktionale Software erstellen. Das unersättliche Bedürfnis der Gesellschaft nach Software sorgt dafür, dass Entwicklungsteams bereits überlastet sind und Sicherheit keine vorrangige Überlegung darstellt; schließlich, ist das nicht der Grund, warum es AppSec-Spezialisten gibt? Softwareentwickler sind an eine etwas unterkühlte Beziehung zur Sicherheit gewöhnt – sie hören nur von ihnen, wenn Probleme auftreten, und diese Probleme können die Produktion ihrer harten Arbeit aufhalten.

Auf der anderen Seite haben AppSec-Spezialisten es satt, jahrzehntealte 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 ist bei komplexen Sicherheitslücken weitaus besser aufgehoben, als immer wieder bekannte Fehler zu beseitigen.

Es herrscht eine unausgesprochene Kultur des gegenseitigen Schuldzuweisens zwischen diesen Teams, aber sie haben (oder sollten haben) das gleiche Ziel: sichere Software. Entwickler arbeiten in einer Umgebung, die ihnen selten die besten Erfolgschancen in Bezug auf sicheres Programmieren bietet; Best Practices für Sicherheit werden in ihrer Hochschulausbildung selten gelehrt, und die Ausbildung am Arbeitsplatz ist oft viel zu selten oder völlig ineffektiv. Es mangelt deutlich an der Betonung des Sicherheitsbewusstseins und einer fundierten, relevanten Ausbildung. Das Ergebnis sind astronomische Kosten für die Behebung alter Fehler in bereits committetem Code sowie die drohende Gefahr einer rufschädigenden Datenpanne.

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

Ein weiteres häufig auftretendes Problem ist, dass anstelle von Schulungen ein riesiges Arsenal an Sicherheitstools eingesetzt wird, um Probleme zu finden, bevor Software veröffentlicht wird. Die Palette an Tools für Anwendungsscans und -schutz (SAST/DAST/RASP/IAST) kann sicherlich bei der Produktion sicherer Software helfen, bringt aber ihre eigenen Probleme mit sich. Sich vollständig auf sie zu verlassen, garantiert keine Sicherheit, weil:

• Kein „einziges“ Tool kann auf jede Schwachstelle, in jedem Framework und in jedem Anwendungsfall scannen
• Sie können langsam sein, besonders wenn sie parallel laufen, um sowohl statische als auch dynamische Codeanalysen durchzuführen
• Fehlalarme bleiben ein Problem; diese stoppen oft die Produktion und erfordern unnötige manuelle Code-Überprüfungen, um die Warnungen zu verstehen
• Sie erzeugen ein falsches Sicherheitsgefühl, wobei sicheres Programmieren zugunsten der Erwartung, dass diese Tools alle Probleme finden, in den Hintergrund rückt.

Die Tools werden sicherlich Sicherheitslücken aufdecken, die gepatcht werden können, aber werden sie alles finden? Eine 100-prozentige Trefferquote ist unmöglich zu garantieren, und ein Angreifer braucht nur eine einzige offene Tür, um einzudringen und Ihnen den Tag gründlich zu verderben.

Glücklicherweise erkennen viele Unternehmen den menschlichen Faktor bei Softwareschwachstellen. Die meisten Entwickler sind nicht ausreichend für sicheres Programmieren geschult, und ihr allgemeines Sicherheitsbewusstsein ist gering. Sie stehen jedoch ganz am Anfang des Softwareentwicklungslebenszyklus und sind in der besten Position, um zu verhindern, dass Schwachstellen überhaupt in den Code gelangen. Wenn sie von Anfang an sicher programmieren würden, wären sie die erste Verteidigungslinie gegen verheerende Cyberangriffe, die uns jedes Jahr Milliarden kosten.

Entwicklern muss die Chance gegeben werden, sich zu entfalten – mit Schulungen, die ihre Sprache sprechen, für ihre Arbeit relevant sind und sie aktiv für Sicherheit begeistern. Fehlerfreier Code sollte ein Grund zum Stolz sein, genau wie der Aufbau von etwas funktional Genialem einem den Respekt der Kollegen einbringt.

Ein modernes Sicherheitsprogramm sollte eine geschäftliche Priorität sein.

Entwicklungsteams können nicht aus eigener Kraft eine unternehmensweite Sicherheitskultur etablieren. Sie benötigen die richtigen Werkzeuge, das nötige Wissen und die volle Unterstützung, um Sicherheit von Anfang an fest in den Softwareentwicklungsprozess zu integrieren.

Herkömmliche Schulungsmethoden sind offensichtlich wirkungslos, wenn die MITRE-Liste nach wie vor so viele alte Sicherheitslücken aufweist. Zeit für einen neuen Ansatz. Suchen Sie nach Trainingslösungen, die:

• Praxisnah sind; Entwickler lernen am besten durch „Learning by Doing“ statt durch trockene Videovorträge
• Relevant sind; vermeiden Sie C#-Schulungen, wenn im Alltag Java zum Einsatz kommt
• Motivierend sind; kompakte Lerneinheiten sind leicht verdaulich und ermöglichen es, kontinuierlich auf vorhandenem Wissen aufzubauen
• Messbar sind; haken Sie Schulungen nicht einfach nur ab. Stellen Sie deren Effektivität sicher und schaffen Sie Wege zur gezielten Verbesserung
• Spaß machen; fördern Sie das Sicherheitsbewusstsein und eine positive Sicherheitskultur, um den Teamzusammenhalt nachhaltig zu stärken.

Sicherheit sollte für jeden im Unternehmen oberste Priorität haben. Der CISO muss dabei transparent und auf allen Ebenen kommunizieren, wie wir unsere Daten besser schützen. Wer will schon immer wieder das gleiche Lied hören? Es ist an der Zeit, alte Schwachstellen endgültig zu beseitigen.