Dieser Artikel erschien ursprünglich in Informationssicherheit Buzzund wurde von mehreren anderen Medien aufgegriffen. Er wurde für die Syndizierung hier aktualisiert.

Gegen Ende des letzten Jahres veröffentlichte die erstaunliche Community von MITRE ihre Liste der CWE Top 25 der gefährlichsten Softwarefehler, die die Welt im Jahr 2019 betreffen. Diese Liste ist nicht meinungsgesteuert, sondern das Ergebnis einer vielschichtigen Analyse, die sich auf die Arbeit von Organisationen wie NIST sowie auf die veröffentlichten CVE-Daten (Common Vulnerabilities and Exposures) stützt. Um die "Top"-Schwachstellen zu bestimmen, wird ihnen eine Punktzahl zugewiesen, die auf ihrem Schweregrad, ihrer Ausnutzbarkeit und ihrer Verbreitung in aktueller Software basiert. Das ist keine Liste, die mit Lob überschüttet wird, soviel ist sicher.

Doch anders als bei den meisten Jahresrückblicken sind viele der Teilnehmer dieser Liste schon einmal erschienen... immer und immer wieder. Wenn dies die Billboard Hot 100 Charts wären, 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 ersten Veröffentlichung erscheinen. 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 noch bis ins Jahr 2020 plagen, obwohl sie schon vor Jahrzehnten entdeckt wurden.

Warum sind alte Bugs immer noch so gefährlich? Wissen wir nicht, wie wir sie beheben können?

Nummer sechs auf der aktuellen MITRE-Liste ist CWE-89, besser bekannt als SQL-Injection (SQLi). Die SQLi-Schwachstelle wurde erstmals 1998 entdeckt, damals, als viele von uns noch ihre brennenden Fragen an Jeeves statt an Google stellten. Ein Fix wurde bald darauf bekannt gegeben, und dennoch bleibt dies eine der meistgenutzten Hacking-Techniken im Jahr 2019. Der Akamai Zustand des Internets Bericht zeigte, dass SQLi der Übeltäter bei zwei Dritteln aller Angriffe auf Webanwendungen war.

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

Entwickler arbeiten in einem kaputten System (die meiste Zeit).

Es ist allzu einfach, sich zurückzulehnen und den Entwicklern die Schuld dafür zu geben, dass sie "schlechten" Code liefern. Die Wahrheit ist, dass ihre Prioritäten sich stark von denen des Sicherheitsteams unterscheiden. Ihr durchschnittliches Entwicklungsteam hat den Auftrag, so schnell wie möglich schöne, funktionale Software zu erstellen. Das unstillbare Bedürfnis der Gesellschaft nach Software sorgt dafür, dass die Entwicklerteams bereits überlastet sind und die Sicherheit keine primäre Rolle spielt; schließlich gibt es deshalb AppSec-Spezialisten. Software-Ingenieure sind an ein etwas kühles 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 aufhalten.

Auf der anderen Seite des Zauns sind AppSec-Spezialisten es leid, jahrzehntealte Fehler zu beheben, die bei jedem Scan und jeder manuellen Codeüberprüfung auftauchen. Diese Spezialisten sind teuer und rar, und ihre Zeit ist weitaus besser für komplexe Sicherheitslücken eingesetzt, anstatt bekannte Fehler immer wieder zu beseitigen.

Es gibt eine unausgesprochene Kultur des Schuldzuweisens zwischen diesen Teams, aber sie haben (oder sollten) das gleiche Ziel haben: sichere Software. Entwickler agieren in einer Umgebung, die ihnen kaum die besten Erfolgschancen in Bezug auf sichere Programmierung bietet; bewährte Sicherheitspraktiken werden nur selten als Teil ihrer Hochschulausbildung gelehrt, und Schulungen am Arbeitsplatz sind oft viel zu selten oder völlig ineffektiv. Die Folge sind astronomische Kosten für die Behebung alter Bugs in fehlerhaftem Code und die unmittelbare Gefahr einer rufschädigenden Datenpanne.

Der menschliche Faktor, a.k.a. "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 eingesetzt wird, um Probleme zu finden, bevor die Software in die freie Wildbahn entlassen wird. Das Arsenal an Anwendungs-Scan- und Schutz-Tools(SAST/DAST/RASP/IAST) kann sicherlich bei der sicheren Software-Produktion helfen, aber sie bringen ihre eigenen Probleme mit sich. Vollständiges Vertrauen in sie garantiert keine Sicherheit, denn:

• Kein "einziges" Tool kann nach jeder Schwachstelle, in jedem Framework, in jedem Anwendungsfall suchen
• Sie können langsam sein, besonders wenn sie im Tandem laufen, um sowohl statische als auch dynamische Code-Analyse zu liefern
• False Positives sind nach wie vor ein Problem; diese halten oft die Produktion an und erfordern eine unnötige manuelle Codeüberprüfung, um den Sinn der Alarme zu verstehen
• Sie schaffen ein falsches Gefühl der Sicherheit, wobei sichere Kodierung in der Erwartung, dass diese Tools alle Probleme aufspüren, vernachlässigt wird.

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

Zum Glück erkennen viele Unternehmen den menschlichen Faktor, der bei Software-Schwachstellen eine Rolle spielt. Die meisten Entwickler sind nicht ausreichend für die sichere Programmierung geschult, und ihr Sicherheitsbewusstsein ist insgesamt gering. Sie stehen jedoch ganz am Anfang des Lebenszyklus der Softwareentwicklung und sind in der besten Position, um zu verhindern, dass Schwachstellen jemals 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.

Entwickler müssen die Chance haben, sich zu entfalten, mit Schulungen, die ihre Sprache sprechen, die für ihre Arbeit relevant sind und sie aktiv für das Thema Sicherheit begeistern. Fehlerfreier Code sollte ein Punkt des Stolzes sein, ähnlich wie das Bauen von etwas funktional Großartigem Ihnen den Respekt der Kollegen einbringt.

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

Entwicklungsteams können sich nicht selbst an den Ärmeln hochziehen und ein positives Sicherheitsbewusstsein im gesamten Unternehmen durchsetzen. Sie benötigen die richtigen Tools, das Wissen und die Unterstützung, um Sicherheit von Anfang an in den Softwareentwicklungsprozess einzubauen.

Alte Trainingsmethoden funktionieren offensichtlich nicht, wenn die MITRE-Liste immer noch so viele alte Sicherheitsfehler aufzeigt, also versuchen Sie etwas Neues. Suchen Sie nach Trainingslösungen, die sind:

• Hands-on; Entwickler lieben es, "durch Handeln zu lernen", nicht durch das Betrachten von sprechenden Köpfen auf Videos
• Relevant; lassen Sie sie nicht in C# trainieren, wenn sie jeden Tag Java benutzen
• Fesselnd; mundgerechtes Lernen ist leicht verdaulich und ermöglicht es Entwicklern, auf bereits vorhandenem Wissen weiter aufzubauen
• Messbar; kreuzen Sie nicht einfach ein Kästchen an und gehen Sie weiter. Sicherstellen, dass das Training effektiv ist und Wege zur Verbesserung schaffen
• Spaß; schauen Sie sich an, wie Sie das Sicherheitsbewusstsein zusätzlich zur Unterstützung einer positiven Sicherheitskultur aufbauen können und wie dies eine kohäsive Teamumgebung schaffen kann.

Sicherheit sollte für jeden im Unternehmen eine Priorität sein, wobei der CISO die Bemühungen auf jeder Ebene, unsere Daten sicherer zu machen, sichtbar und transparent macht. Ich meine, wer will schon das gleiche alte Lied in der Wiederholung hören? Es ist an der Zeit, sich ernsthaft mit der Beseitigung alter Bugs zu beschäftigen.