Qualität und Sicherheit

Applikations-Sicherheit als Qualitätsproblem: 6 Test-Tipps für die Praxis

| Autor / Redakteur: Arthur Hicken / Redaktion IoT

Security und Qualität sollten gleichberechtigt sein.
Security und Qualität sollten gleichberechtigt sein. (www.pixabay.com)

Die Sicherheit von Applikationen gewinnt an Bedeutung. Doch macht es Sinn, diese losgelöst von dem Prozess der Softwareentwicklung zu betrachten? Ein Plädoyer für die Gleichbehandlung von Qualität und Sicherheit.

Kürzlich las ich auf LinkedIn einen Beitrag, in dem nach dem Unterschied zwischen den verschiedenen Anbietern statischer Analyseprodukte gefragt wurde. Eine Person, bei der es sich – was kaum überraschen dürfte – um einen Anbieter handelte, antwortete, die von seinem Unternehmen angebotene Lösung sei die bessere, denn während andere Anbieter auf Qualität und Security fokussiert seien, würde sich sein Unternehmen ausschließlich dem Thema Security widmen.

Vielleicht ist diese Einstellung kennzeichnend für das Problem mit der Applikations-Sicherheit, das derzeit in der Branche immer mehr an Bedeutung gewinnt. Zum Beispiel gibt es Organisationen, die versuchen, ihr Security-Team vollkommen losgelöst vom übrigen Softwareentwicklungs-Prozess, also sowohl von den Entwicklungs- als auch von den Prüf-Maßnahmen, zu betreiben. Nach diesem Konzept führt das Security-Team seine eigenen Tests durch (meist wird dabei versucht, die Software zu knacken), und die gefundenen Bugs werden dem Entwicklungs-Team mitgeteilt. Mit anderen Worten: Man versucht, den Code durch Testen sicher zu machen. Ich kann Ihnen versichern, dass das genauso erfolgreich ist als wenn Sie versuchen würden, Ihrem Code durch Testen Qualität zu verleihen.

Security-Tests reichen nicht aus

Damit hier kein Zweifel aufkommt: Natürlich sind Security-Tests dieser Art notwendig, aber sie reichen nicht aus. Die Software zu knacken, ist sicherlich sinnvoll. Wenn man es aber als Methode zur Verbesserung der Sicherheit nutzt, führt dies dazu, dass Fehler zu spät gefunden werden und unter den Tisch fallen. Insbesondere tiefere Ursachen wie ungeeignete Frameworks und Algorithmen werden gern unter den Teppich gekehrt. Denn die Abwägung, ob der Code neu geschrieben oder das Release einfach herausgegeben wird, geht oft zugunsten der Einhaltung des Zeitplans aus.

In dem eingangs erwähnten LinkedIn-Kommentar verleitet der Anbieter einen arglosen potenziellen Kunden auf gefährliche Weise zu der Annahme, seine Software sei irgendwie besser. Dabei bleibt unausgesprochen, in welcher Weise oder weshalb sie besser ist. Ich möchte hier keinem bestimmten Toolanbieter etwas anhängen, zumal ich ja selbst für ein solches Unternehmen arbeite. Mich frustrieren aber solche hohlen Argumente, die einen glauben lassen sollen, dort würde eine Art Wundermittel angeboten. In diesem Fall mag das Produkt des betreffenden Anbieters tatsächlich eine Reihe interessanter und einzigartiger Features bieten. Es wird jedoch der Eindruck vermittelt, dass Security auf geheimnisvolle Weise etwas anderes ist als Qualität. Dies aber reduziert unser Verständnis von Applikations-Sicherheit und macht uns alle etwas weniger sicher.

Qualitätsproblem gleich Sicherheitsproblem

Security und Qualität müssen gleichbehandelt werden, und Qualität muss sich auf ausgereifte technische Verfahrensweisen stützen. Tatsache ist doch: Wenn Sie ein Qualitätsproblem haben, haben Sie auch ein Sicherheitsproblem. Schließlich zeigen Untersuchungen, dass es sich bei 50 bis 70 Prozent der Security-Defekte um Qualitäts-Defekte handelt. Oder, um es mit anderen Worten zu sagen: Die guten alten Qualitätsmängel stellen sich als Schwachstellen heraus, die von Angreifern (bzw. Hackern oder anderen Böswilligen) genutzt werden, um Ihre Applikation zu knacken (wir nennen das ‚Zero Days‘).

Forscher sind übereinstimmend der Auffassung, dass es sich mindestens bei der Hälfte, vielleicht sogar bei 70 % der Software-Schwachstellen um grundlegende Codequalitäts-Probleme handelt, die sich durch das Schreiben von besserem Code vermeiden ließen. Nachlässige Programmierung also.“  - (Jim Bird “Building Real Software”)

Beispiele aus den CWE Top 25

Wenn Sie sich immer noch nicht sicher sind, in welcher Weise sich Qualität und Security überschneiden, sehen Sie sich doch ein paar Beispiele aus den CWE Top 25 an. Die folgenden möglichen Security-Folgen entstammen dem CWE Technical Impact:

    • 3: CWE 120 – Puffer-Kopie, ohne die Größe des Eingangswerts zu überprüfen (der klassische Pufferüberlauf). Dies kann zur Ausführung von nicht autorisiertem Code oder Befehlen, möglichen nicht autorisierten Datenzugriffen oder Denial-of-Service (DoS) führen.
    • 20: CWE 131 – Unkorrekte Berechnung der Puffergröße (mit der Folge eines Pufferüberlaufs). Mögliche Folgen sind DoS, die Ausführung von nicht autorisiertem Code oder Befehlen und das mögliche nicht autorisierte Lesen/Modifizieren von Speicherinhalten.
    • 25: CWE 190 – Integer-Überlauf oder Wraparound (mit der Folge von undefiniertem Verhalten oder Abstürzen). Mögliche Folgen sind DoS, die Modifikation von Speicherinhalten, die Ausführung von nicht autorisiertem Code oder Befehlen oder die Ausführung von beliebigem Code.

Wenn Sie sich genauer mit der kompletten, mehr als 800 Punkte umfassenden CWE-Liste befassen, finden Sie noch viele weitere Beispiele – darunter jegliche Arten von Über- und Unterlauf, Initialisierung, unkontrollierter Rekursion usw. All dies sind gängige Security-Attacken, gleichzeitig aber auch offensichtliche Qualitätsmängel.

Security von Anfang an einbauen

Die Softwaresysteme nehmen rapide an Komplexität zu, und es ist deshalb nahezu unmöglich, alle denkbaren Variationen zu testen. Es gilt die Aussage von Richard Bender: „Die Zahl der potenziellen Tests übersteigt die Zahl der Moleküle im Universum“. Er sagt damit auf spaßige Weise, dass wir es hier mit einer nicht zu bewältigenden Aufgabe zu tun haben. Jim Bird drückt es so aus: „Bei einem großen System müssten unendlich viele Pen Tester unendlich lange an unendlich vielen Tastaturen arbeiten, um vielleicht alle Fehler zu finden.“

Sicherheit und Zuverlässigkeit müssen also von Anfang an eingebaut werden, denn sie lassen sich nicht durch Testen nachrüsten. Solange die Security als ‚Extra‘ behandelt wird, wird sie Mängel aufweisen.

Was kann man tun?

Es folgen einige Tipps dazu, was Sie tun können, um sowohl die Security als auch die Qualität Ihrer Software zu verbessern:

  1. Schulen Sie Ihre Entwickler in der Entwicklung sicherer Software. Wenn Sie Ihre Entwickler richtig in die Entwicklung sicherer Software einweisen, können sie Security-Probleme entweder von vornherein vermeiden oder sie zumindest finden und beseitigen.
  2. Entwerfen und bauen Sie Ihre Systeme mit einer bewussten Fokussierung auf Qualität und Security. Vermeiden Sie Code, der zwar funktioniert, aber nicht wirklich gut ist, weil er potenzielle Security-Probleme (und damit auch Probleme mit der funktionalen Sicherheit) birgt. Die statische Analyse kann Ihnen hierbei helfen, indem sie Ihren Code nicht nur auf Bugs prüft, sondern auch auf die Einhaltung der bekannten optimalen Verfahrensweisen.
  3. Verlassen Sie sich nicht mehr auf Edge-Tools. Machen Sie sich Ihre tatsächliche Risiko-Exposition und Ihre Angriffsoberfläche bewusst. Firewalls und Virenschutz können die Mängel von unsicherem Code nicht kompensieren. Stattdessen sind Sie gefordert, Ihre Applikation angriffsresistent zu machen.
  4. Sammeln und messen Sie Defektdaten und nutzen Sie diese zur Beurteilung und Verbesserung Ihrer Entwicklungspraktiken. Welcher Code und welche Komponenten bringen die meisten Probleme? Welcher Code ist am besten? Wie wurden diese Teile geprüft? Wiederholen Sie gute Ideen und verwerfen Sie die schlechten.
  5. Nutzen Sie eine strikte statische Analyse. Akzeptieren Sie nicht einfach die Einschätzung eines Anderen, ein gemeldeter Defekt sei unwichtig oder ein Fehlalarm. Wenden Sie gute Regeln an, die Detektierung und Vermeidung beinhalten, und befolgen Sie sie. Am besten geht das mit einem auf optimalen Verfahrensweisen (Best Practices) gestützten Konzept. Hier kommen Codierstandards wie CWE, CERT und OWASP ins Spiel. Am besten lässt sich die Einhaltung der optimalen Verfahrensweisen mit der statischen Analyse gewährleisten.
  6. Machen Sie von der Laufzeit-Analyse Gebrauch. Sie deckt reale Probleme (insbesondere hinterhältige Speicherprobleme) auf und zeigt Ihnen ohne Fehlalarme genau, was an welcher Stelle schiefgegangen ist.

Wir müssen damit beginnen, Security gleich von Anfang an in den Code einzubauen. So wird der Code von Grund auf angriffsresistent, und man muss keine bekannten Sicherheitslücken nachträglich stopfen. Wenn Sie alle Ihre Softwareentwicklungs-Ergebnisse aus Codierung, Build und Test in einen zentralen Bestand einbringen, ist für Kontrollierbarkeit, Messbarkeit und Rückverfolgbarkeit gesorgt, was die beste Basis für künftige Verbesserungen darstellt.

Vergessen Sie nie, dass die Aufwendungen für solide Sicherheitsvorkehrungen geringer sind als die Kosten, die durch schlechte oder unsichere Software entstehen. Es gibt also keine Ausflüchte.

Kommentare werden geladen....

Kommentar zu diesem Artikel abgeben

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 0 / Security)