SecurityDevOps & InfrastructureQA & TestingCustom Software Development

Sicherheit ist keine Phase

Der Penetrationstest in der letzten Woche findet Symptome. Die Ursachen wurden Monate vorher entschieden: wie Daten transportiert werden, worauf das Produkt steht, wie eine Änderung in Produktion gelangt und wer was darf. Sicherheit ist eine Eigenschaft dieser Entscheidungen, kein Schritt danach.

Foto: Google Gemini · AI-generated

Der Penetrationstest ist für die letzte Woche vor dem Launch gebucht. Alle kennen den Termin. Im Plan steht er als Kästchen mit dem Namen „Sicherheit“.

Dieses Kästchen ist das Problem. Ein Test in der letzten Woche findet nur, was schon da ist. Bis dahin ist längst entschieden, wie Daten transportiert werden, worauf das Produkt steht, welchen Weg eine Änderung in die Produktion nimmt und wer was darf. Der Test meldet Symptome. Die Ursachen sind Monate alt.

Sicherheit ist keine Phase. Sie ist eine Eigenschaft ganz gewöhnlicher Entscheidungen. Die meisten davon fallen früh, und oft merken die Beteiligten gar nicht, dass sie gerade über Sicherheit entscheiden.

Was eine Phase kostet

Wenn Sicherheit eine Phase ist, kommen die Befunde zum schlechtesten Zeitpunkt: Alles ist gebaut, der Termin steht, und die Korrekturen sind strukturell.

Die teuren Befunde sind immer von derselben Art. Ein Identitätsmodell, das mit echten Nutzern darin neu gebaut werden muss. Eine Datenbank, die von Orten aus erreichbar ist, von denen sie nie erreichbar sein sollte. Eine Abhängigkeit, die niemand bewusst gewählt hat und die jetzt eine kritische Sicherheitswarnung trägt. Keinen dieser Punkte findet ein Scanner in Woche eins. Alle sind in Woche eins billig und in der letzten Woche ruinös.

Vier Stellen, an denen Sicherheit entschieden wird, bevor jemand testet

Wie Daten reisen und wo sie liegen. Für ein Unternehmen der Wasseraufbereitung haben wir ReportSync gebaut. Es bringt Prüfberichte von Geräten im Außendienst ins CRM des Unternehmens. Der Transport lief von der ersten Version an über einen gesicherten Tunnel, und jeder fehlgeschlagene Upload wird protokolliert, wiederholt und einem Menschen angezeigt. Auch das ist Sicherheit. Einem System, das Daten still verliert, kann man nicht vertrauen, egal wie gut es verschlüsselt.

Worauf das Produkt steht. Ein Medizintechnikhersteller kam mit dem Wunsch nach einem Onlinekatalog mit mehr als 10.000 Produkten zu uns. Die naheliegende Antwort war eine Shop-Plattform mit Plugins. Wir haben davon abgeraten, teils wegen der Performance, teils weil Plugin-Wildwuchs in dieser Größe Angriffsfläche ist. Jedes Plugin ist Code, den jemand anderes pflegt, nach seinem Zeitplan, innerhalb Ihrer Anwendung. Die Wahl der Plattform war die Sicherheitsentscheidung. Sie sah nur nicht so aus.

Wie eine Änderung in die Produktion gelangt. Das Nachunternehmerportal für ein Bauunternehmen läuft in einer privaten deutschen Cloud, und jede Änderung geht denselben Weg: Entwicklung, QA, Test, Live, jeweils in einer eigenen Umgebung. Niemand bearbeitet einen Live-Server von Hand, weil es dafür keinen Weg gibt. Das ist kein Sicherheitsmerkmal im Produkt. Es ist die Form der Auslieferung, und sie beseitigt eine ganze Klasse von Vorfällen.

Wer was darf, und wie man es hinterher weiß. Ein Hersteller mit 5.800 Mitarbeitenden brauchte ein Compliance-Onboarding für Besucher an mehreren Standorten: Unterweisungen, Unterschriften, dokumentierte Freigaben, bevor jemand ein Werk betritt. Das Wort des Kunden war „Nachvollziehbarkeit“. Rollen, Freigaben und der Nachweis, wer was getan hat, sind Fachmodellierung. Wer sie sauber modelliert, bekommt den Prüfpfad, weil das System funktioniert, nicht weil später jemand Logging ergänzt hat.

Wie das in einem Sprint aussieht

Nichts davon ist heldenhaft. Eine zehnminütige Bedrohungsskizze, wenn eine Funktion entworfen wird: Welche Daten, wer fasst sie an, was will ein Angreifer damit. Abhängigkeits-Scans in der Pipeline, damit eine Sicherheitswarnung ein fehlgeschlagener Build ist und keine Überraschung. Sichere Voreinstellungen: verboten, solange nicht erlaubt, minimale Rechte für jedes Dienstkonto. Geheimnisse, die nie in ein Repository gelangen. Protokolle, die „wer hat wann was getan“ beantworten, ohne dass daraus ein Forensikprojekt wird.

Jedes davon ist eine kleine Gewohnheit. Zusammen sorgen sie dafür, dass der Test in der letzten Woche bestätigt statt entdeckt.

Der Test findet trotzdem statt

Wir buchen den Penetrationstest weiterhin. Der Unterschied ist, wozu. Wenn Sicherheit eine Phase ist, erfährt man im Test, wo man steht. Wenn Sicherheit eine Eigenschaft ist, beweist man es dort. Derselbe Test, entgegengesetzte Bedeutung.

Wenn bei Ihnen ein Launch ansteht und im Plan ein Kästchen „Sicherheit“ wartet, lohnt sich ein Gespräch, bevor das Kästchen an der Reihe ist. Lesen Sie, wie wir Auslieferung und Infrastruktur betreiben, oder sprechen Sie uns an.