Anwendungssicherheit ist ein Qualitätsproblem: 6 Testtipps zum Nutzen von Qualität und Sicherheit

Kürzlich las ich einen Beitrag auf LinkedIn, in dem jemand nach dem Unterschied zwischen mehreren Anbietern von Sicherheit für statische Analysen gefragt hatte. Eine Person, nicht überraschend ein Anbieter, antwortete, dass ihre Lösung besser sei, da andere Unternehmen sich zwar auf Qualität und Sicherheit konzentrierten, aber ausschließlich Sicherheit betreiben.

Das war natürlich eine lächerliche Aussage. Und vielleicht ist diese Art des Denkens ein Hinweis auf das derzeit weit verbreitete Problem der Anwendungssicherheit in der Branche. Zum Beispiel Organisationen, die versuchen, ihre Sicherheitsgruppe vollständig vom Rest des SDLC zu trennen (sowohl Entwicklungs- als auch Testbemühungen). In diesem Modell führt das Sicherheitsteam eigene Tests durch, wobei hauptsächlich versucht wird, die Software zu beschädigen, und gibt dann Sicherheitslücken an das Entwicklerteam zurück. Mit anderen Worten, der Versuch, die Sicherheit in ihrem Code zu testen. Ich kann Ihnen versichern, dass dies nicht effektiver ist als Testen der Qualität in Ihrem Code.

Sicher, diese Art von Sicherheitstests ist notwendig, aber es reicht einfach nicht aus. Obwohl das Brechen der Software in der Tat nützlich ist, führt das Vertrauen in sie als Methode zur Verbesserung der Sicherheit dazu, dass Fehler zu einem zu späten Zeitpunkt gefunden und unterdrückt werden. Insbesondere Probleme mit der Grundursache wie falsche Frameworks und Algorithmen werden unter den Teppich gekehrt, da der Zeitplan den Konflikt zwischen dem Umschreiben des Codes und dem Herausholen der Version gewinnt.

In dem oben erwähnten Linkedin-Kommentar führt der Anbieter einen ahnungslosen potenziellen Kunden in gefährlicher Weise in die Irre, indem er behauptet, seine Software sei irgendwie besser, ohne tatsächlich etwas Nützliches darüber zu sagen, wie oder warum es besser ist. Ich möchte keinen bestimmten Werkzeughersteller auswählen, zumal ich für einen arbeite. Ich bin jedoch frustriert über solche Strohmann-Argumente, die den Anschein von Schlangenöl erwecken. In diesem Fall kann das Produkt des Anbieters zwar interessante, einzigartige Merkmale aufweisen, aber wir haben den Eindruck, dass Sicherheit auf magische Weise anders ist als Qualität, was unser Verständnis der Anwendungssicherheit beeinträchtigt und uns alle ein wenig weniger sicher macht.

Sicherheit muss wie Qualität behandelt werden, und Qualität muss auf ausgereiften Konstruktionspraktiken basieren, denn die Wahrheit ist, dass Sie ein Sicherheitsproblem haben, wenn Sie ein Qualitätsproblem haben. Studien zeigen, dass überall von 50-70% der Sicherheitsmängel sind Qualitätsmängel. Mit anderen Worten, gute, altmodische Qualitätsfehler werden zu Sicherheitslücken, die Eindringlinge / Hacker / schlechte Schauspieler nutzen, um in Ihre Anwendung einzudringen (wir nennen diese „Null Tage").

"Die Forscher sind sich einig, dass mindestens die Hälfte und möglicherweise sogar 70% der häufig auftretenden Sicherheitslücken in der Software grundlegende Probleme mit der Codequalität sind, die durch das Schreiben besserer Software verhindert werden könnten. Schlampige Codierung"

- Jim Bird “Echte Software erstellen"

Wenn Sie sich immer noch nicht sicher sind, wie Qualität und Sicherheit sich überschneiden, sehen Sie sich einige Beispiele aus dem an CWE-Top 25. Die folgenden möglichen Sicherheitsergebnisse stammen aus dem Technische Auswirkungen von CWE Arbeit:

• #3 KWE 120 - Pufferkopie ohne Überprüfung der Eingabegröße („Klassischer Pufferüberlauf“) - kann zur Ausführung von nicht autorisiertem Code oder nicht autorisierten Befehlen führen, möglicher nicht autorisierter Datenzugriff möglich Denial of Service (DOS)
• #20 KWE 131 - Falsche Berechnung der Puffergröße (führt zu Pufferüberlauf) - Mögliches DoS, Ausführung von nicht autorisiertem Code oder nicht autorisierten Befehlen, mögliches nicht autorisiertes Lesen / Ändern des Speichers
• #25 KWE 190 - Integer Overflow oder Wraparound (führt zu undefiniertem Verhalten und stürzt daher ab) - mögliche DoS, mögliche Speichermodifikation, mögliche Ausführung von nicht autorisiertem Code oder Befehlen, mögliche Ausführung von willkürlichem Code

Wenn Sie weiter in die vollständige CWE-Liste (über 800 Elemente) gehen, finden Sie viele andere, dh alle Arten von Überlauf / Unterlauf, Initialisierung, unkontrollierte Rekursionusw. Dies sind alles gängige Sicherheitsangriffe sowie offensichtliche Qualitätsprobleme.

Bauen Sie es ein

Die Komplexität von Softwaresystemen wächst sehr schnell. Der Versuch, jede mögliche Variation schnell zu testen, wird nahezu unmöglich. Wie Richard Bender drückt es aus"Die Anzahl der möglichen Tests übersteigt die Anzahl der Moleküle im Universum", was nur eine unterhaltsamere Art ist, zu sagen, dass Sie es niemals schaffen werden. Oder von Jim Bird: "Für ein großes System benötigen Sie eine unendliche Anzahl von Stifttestern auf einer unendlichen Anzahl von Tastaturen, die unendlich viele Stunden arbeiten, um möglicherweise alle Fehler zu finden."

Daher müssen sowohl Sicherheit als auch Zuverlässigkeit entwickelt und entwickelt werden. Sie können sie nicht testen. Solange Sicherheit ein „Extra“ ist, wird sie darunter leiden.

Was kann getan werden?

Hier sind einige Dinge, die Sie tun können, um Ihre Softwarequalität zu verbessern und  Sicherheit zur gleichen Zeit.

1. Trainieren Sie Entwickler in sicherer Entwicklung. Wenn Sie Ihre Entwickler angemessen in sicheren Entwicklungspraktiken schulen, können sie Sicherheitsprobleme verhindern oder zumindest finden und beheben.
2. Entwerfen und bauen Sie Ihr System mit einem bewussten Fokus auf Qualität und Sicherheit. Vermeiden Sie Code, der „funktioniert“, aber keine gute Wahl ist, da er potenzielle Sicherheitsprobleme aufweist. (Oder Sicherheitsprobleme.) Die statische Analyse hilft Ihnen dabei, indem Sie Ihren Code nicht nur auf Fehler überprüfen, sondern auch auf die Einhaltung bekannter Best Practices.
3. Verlassen Sie sich nicht mehr auf Kantenwerkzeuge. Erkennen Sie Ihre tatsächliche Belichtung und Angriffsflächen. Firewall und Antivirus gleichen unsicheren Code nicht aus - Sie müssen Ihre Anwendung härten.
4. Sammeln / messen Sie Fehlerdaten und verwenden Sie diese, um Ihre Entwicklungspraktiken zu bewerten und zu verbessern. Welcher Code oder welche Komponenten verursachen die meisten Probleme? Welcher Code ist der beste? Wie wurden sie getestet? Wiederholen Sie die guten Ideen und spülen Sie die schlechten.
5. Verwenden Sie eine strikte statische Analyse. Akzeptieren Sie nicht einfach die Einschätzung einer Person, dass ein gemeldeter Defekt kein wichtiges Problem ist oder nicht Fehlalarm. Holen Sie sich ein gutes Regelwerk, das sowohl Erkennung als auch Prävention umfasst, und leben Sie danach. Der beste Weg, dies zu tun, ist ein technischer Ansatz in Bezug auf Best Practices (die Rolle von Codierungsstandards wie CWE, CERT und OWASP). Durch statische Analyse können Sie sicherstellen, dass die Best Practices eingehalten werden.
6. Verwenden Sie die Laufzeitanalyse. Es wird echte Probleme finden (insbesondere böse Speicherprobleme) und es zeigt Ihnen genau, wo und was schief gelaufen ist, ohne dass es zu Fehlalarmen gekommen ist.

Wir müssen also damit beginnen, Sicherheit in unseren Code zu integrieren. Dies ist der beste Weg, um es wirklich zu härten, anstatt nur bekannte Löcher zu flicken. Die Integration all Ihrer Softwareentwicklungsergebnisse aus Codierung, Erstellung und Test in ein zentrales Repository bietet Kontrolle, Messung und Rückverfolgbarkeit. Dies ist die Basis für zukünftige Verbesserungen.

Und denken Sie daran, dass die Kosten für eine solide Prävention geringer sind als die Kosten für den Umgang mit schlechter oder unsicherer Software. Es gibt also wirklich keine Entschuldigung.