Von Grund auf sichere Software, Teil 1 Warum Shift-Left-Sicherheit sinnvoll ist

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

FIS Informationssysteme und Consulting GmbH

Bei der Shift Left Securiy geht es darum, ein Software-Produkt von Grund auf sicher zu gestalten. Das hat einige handfeste Vorteile, nicht nur für das Endprodukt, sondern auch für die Software-Entwicklung selbst.

Computer und ihre Software sind heutzutage permanent an das Internet angebunden. Das verlangt – egal ob bei Smartphones oder großtechnischen Anlagen – eine von Grund auf sicherere Software. Der alte Software-Produktionsansatz, der das Testen auf Funktionalität und Sicherheit erst spät im Entwicklungsprozess einbrachte, hat in dieser hochvernetzten Welt inzwischen seine Gültigkeit verloren.

Treten beim Testing erhebliche Probleme auf, muss möglicherweise an einem relativ frühen Punkt der Software-Entwicklung angesetzt werden. Das erzeugt nicht nur einen Flaschenhals, da mehrere Ebenen des Entwicklungsprozesses rückwärts überschritten werden müssen; diese alte Form des Software-Entwicklungsprozesses stört auch moderne Prozesse wie DevOps, Agile Development und Continuous Integration, Delivery und Deployment.

Links oder rechts?

Genau deshalb wurde der Entwicklungs-Ansatz der Shift-Left-Security entworfen: Die Verschiebung der Sicherheit „nach links“ hängt mit den traditionellen vier Schritten auf dem Zeitstrahl der Software-Entwicklung zusammen: Nach europäischer Lesart steht links der Anfang, also der Entwurf der Software, und rechts das Ende, also das fertige, zur Auslieferung bereite Produkt. Dazwischen steht Coding an zweiter und Security/Testing an dritter Stelle. Beim Shift-Left-Ansatz geht es also darum, Sicherheit und Testzyklen so früh wie möglich im Entwicklungsprozess zu integrieren, idealerweise schon in der Design-Phase.

Sicherheit schon beim Design-Prozess

Der große Vorteil dieses Ansatzes ist, dass Sicherheit gegenüber anderen Aspekten der Software priorisiert wird. Mögliche Sicherheitsprobleme, deren Auftreten im klassischen Ablaufplan der Software-Entwicklung erst spät entdeckt wird, können so von Grund auf ausgemerzt werden. Das ist auch wichtig, denn moderne Software-Produkte greifen nicht selten im großen Stil auf Open-Source-Code zurück, der seinerseits möglicherweise unentdeckte Lücken mitbringt.

Werden diese früh im Entwicklungsprozess aufgespürt, lassen sich kostspielige Fehlerbehebungen vermeiden. Ein Beispiel dafür ist die Zero-Day-Lücke, die über das vielerorts verwendete Log4j-Framework in vielen Software-Produkten eingebaut war. Insofern trägt der Shift-Left-Ansatz auch zur Realisierung von Security by Design bei, auch wenn die Begriffe natürlich nicht deckungsgleich sind.

Shift Left Security spart Kosten

Durch das frühe Evaluieren der Software-Qualität und -Sicherheit per Shift-Left-Ansatz können zudem Fehler vermieden werden, die im Nachgang enorme Kosten verursachen können. Denn wenn schon im Designprozess Sicherheitsüberlegungen angestellt werden, sind diese anschließend leicht im Coding umsetzbar und können jederzeit im laufenden Prozess überprüft werden.

Treten sicherheitsrelevante Fehler auf, werden sich durch das Testen schnell ermittelt und können aus der Welt geschafft werden. Das wiederum verhindert, dass derartige Fehler erst zu einem deutlich späteren Zeitzpunkt entdeckt und dann aufwändig behoben werden müssen.

Sicherheitsrelevant oder nicht?

Hinzu kommt, dass frühzeitige Überlegungen bezüglich der Software-Sicherheit auch Szenarien zutage fördern können, die möglicherweise sonst nicht bedacht worden wären, weil Sicherheit hier nur eine untergeordnete Rolle gespielt hat. Klassische Beispiele sind zum Beispiel Systeme, die bislang eher selten Opfer von Angriffen wurden, weil sie schlicht nicht vernetzt oder aufgrund mangelnder Möglichkeiten für den Angreifer uninteressant waren.

Dazu zählen etwa Heim-Entertainment-Systeme, Haushaltsgeräte, Smart-TVs und KFZ-Software, aber auch industrielle Systeme wie etwa Produktionslinien oder Roboter, die, wenn hier eine Sicherheitslücke im System schlummert, Angreifern im schlimmsten Fall Zugang zu anderen, wichtigeren Systemen ermöglichen könnten. Die mit solchen Fällen zusammenhängenden möglichen Folgekosten sind kaum kalkulierbar, wodurch es immer sinnvoll ist, auch bei der Entwicklung solcher Systeme den Shift-Left-Ansatz anzuwenden.

Kontinuierliche Überprüfungen notwendig

Natürlich müssen solche Sicherheitslücken nicht zwangsläufig von außen kommen: Code-Fehler, die in der Praxis recht häufig auftreten, aber mangels Funktionsproblemen zunächst nicht entdeckt werden, können sich wie der klassische Schneeball, der zur Lawine wird, in Zukunft eine erhebliche Sicherheitslücke produzieren. Diesem Problem ist nur durch kontinuierliches Testen und Überprüfen beizukommen.

Betriebswirtschaftlich ist es sinnvoll, die Entwickler genau dazu anzuhalten: Zwar mag das schon in einem frühen Entwicklungsstadium der Software scheinbar unnötig Kräfte binden – hinten heraus macht sich dieser Einsatz jedoch schnell bezahlt, denn der Kosteneinsatz zur Behebung einer tiefsitzenden Sicherheitslücke ist um ein Vielfaches höher.

Automatismen etablieren

Um den Schritt nach Links durchzuführen, sind allerdings hier und da Optimierungen nötig. Software-Unternehmen müssen zunächst dafür sorgen, dass überhaupt eine nutzbare Sicherheits-Strategie für das Aufspüren von Code-Fehler und (potentiellen) Sicherheitsproblemen existiert. Dinge wie Vision, Verantwortung und Meilensteine können hier kurz und knapp oder im Detail ausformuliert festgehalten werden.

In einem zweiten Schritt sollte ermittelt werden, wo und wie Software überhaupt entsteht: Wer zum Beispiel mit freien Entwicklern arbeitet, wird hier möglicherweise interessante Erkenntnisse gewinnen. Anschließend ist es wichtig, Standards für das Testing der Sicherheit zu entwickeln und Automatismen zu etablieren, die letztlich auch von allen Verantwortlichen und Entwicklern umgesetzt werden müssen.

Aufwand lohnt sich

Am Ende des Tages ist Shift Left Security ein Ansatz zur Qualitätssicherung schon früh im Produktionsprozess von Software-Produkten. Das Umschwenken auf diese Philosophie erfordert zunächst einen gewissen Aufwand und kontinuierliches Training inklusive eines gewissen Grades an Selbstreflexion im Management. Allerdings dürften sich diese zunächst kostspieligen Maßnahmen zeitnah rechnen: Dann nämlich, wenn im hochkomplexen Endprodukt Sicherheitsprobleme gar nicht auftreten oder schnell und günstig lokalisiert und entfernt werden können.

(ID:48094640)