Ausgelagerte Entwicklung: So kaufen Sie Software sicher ein

Viele Unternehmen denken bei Anwendungssicherheit zuerst an den eigenen Code. Das ist zu eng. ISO 27001 A.8.30 zielt bewusst breiter: Sicherheitsanforderungen müssen bei Entwicklung oder Beschaffung von Anwendungen ermittelt, spezifiziert und genehmigt werden. Genau deshalb betrifft das Thema nicht nur Inhouse-Entwicklung, sondern genauso Standardsoftware, individuell beauftragte Software und größere Customizing-Projekte. NIST beschreibt den SSDF so, dass nicht nur Hersteller, sondern auch Softwarekäufer und -nutzer ihn für Beschaffung und Lieferantenkommunikation verwenden können.

Die kurze Antwort

Ausgelagerte Entwicklung ist nicht automatisch unsicher. Unsicher wird sie erst dann, wenn Unternehmen glauben, sie könnten die Notwendigkeit von Sicherheitsanforderungen einfach stillschweigend an den Lieferanten mit auslagern und sich darauf verlassen, dass der diese mitdenkt. Genau das funktioniert nicht. 

ISO 27001 A.8.30 ist im Kern eine Lieferantenanforderung

Der praktische Kern von A.8.30 ist simpel: Bevor Sie eine Anwendung entwickeln lassen, kaufen oder umfangreich anpassen, müssen Sie klären, welche Sicherheitsanforderungen diese Anwendung erfüllen soll. Das NCSC nennt in seiner Guidance zu sicherer Entwicklung Requirements Capture, also das Verstehen und Aufzeichnen von Sicherheits- und Nutzeranforderungen, als Teil eines guten sicheren Entwicklungsrahmens. Wird das ausgelassen, wird Sicherheit oft erst am Ende "drangeschraubt" – und das macht Projekte langsamer, teurer und schwächer.

Der häufigste Denkfehler

Der häufigste Denkfehler lautet: "Wenn wir eine etablierte Software kaufen oder einen guten Dienstleister beauftragen, wird Sicherheit schon mitgeliefert." Das ist nicht zu empfehlen. Sichere Softwareentwicklung ist eine Anforderung, die in der Verantwortung des anschaffenden Unternehmens liegt. Auch bei großen Namen oder schönen Demos.

Standardsoftware ist nicht automatisch aus der Verantwortung raus

"Von der Stange" klingt oft nach geringem Aufwand. In Wirklichkeit verschiebt Standardsoftware nur die Art der Sicherheitsarbeit. Sie entwickeln den Code nicht selbst, müssen aber trotzdem klären, ob das Produkt Ihre Anforderungen erfüllt. Sinnvoll ist es, vom Anbieter Nachweise zur Einhaltung eines Software Development Lifecycle einzufordern. Für Standardsoftware heißt das praktisch: nicht nur Funktionen kaufen, sondern auch Sicherheitsreife prüfen.

Wenn von großen Herstellern gekauft wird, ist eine individuelle Anfrage naturgemäß nicht möglich. In diesem Fall kann es auch helfen zu überprüfen, ob der Hersteller

• eine ISO 27001-Zertifizierung hat;
• Softwareentwicklung im Anwendungsbereich ist;
• welchen Status die Anforderungen an sichere Softwareentwicklung in der Anwendbarkeitserklärung (Statement of Applicability) haben;
• online zu überprüfen, ob die Software bereits in puncto Sicherheit negativ auffällig geworden ist.

Individuell beauftragte Software braucht klare Sicherheitsanforderungen im Vertrag

Bei Individualentwicklung oder größeren Customizing-Projekten ist die Lage sogar noch deutlicher. Wenn Sie einen Dienstleister beauftragen, ohne Sicherheitsanforderungen sauber zu benennen, bekommen Sie oft genau das: eine Lösung ohne klare Sicherheitsqualität. NIST empfiehlt, einen Kernsatz von Sicherheitsanforderungen für Softwarekomponenten zu definieren und ihn in Beschaffungsunterlagen, Softwareverträgen und anderen Vereinbarungen mit Dritten zu verankern. Genau das ist die praktische Übersetzung von A.8.30 in den Einkauf.

Zwei Fälle, ein Grundprinzip

Praktisch können Sie sich das so merken:

1. Standardsoftware

Hier müssen Sie prüfen, ob das Produkt Ihre Sicherheitsanforderungen erfüllt. Dazu müssen Sie diese vorab natürlich bestimmt haben. Fragen Sie sich also vorher: Was erwarten Sie von der Standardsoftware in puncto Sicherheit?

• Benötigen Sie bestimmte Redundanzanforderungen?
• Wie sieht es mit dem Backup der Daten aus, die die Software verarbeitet? Reichen da Abzüge der proprietären Datenbankstruktur aus?
• Wie soll das Berechtigungsmanagement aussehen für Benutzer der Software? Soll die Software an Ihr unterenhmenseigenes IAM angebunden werden?
• Wie sieht es aus beim Thema Logging und Monitoring?
• Bei Software in der Cloud: welche Anforderungen an die Verfügbarkeit haben Sie hier?

Auf den Entwicklungsprozess haben Sie in aller Regel keinerlei Einfluss. Wenn Sie überprüfen möchten, ob bzw. in welchem Umfang er vorhanden ist, müssen Sie den Lieferanten dazu befragen - da hilft es, ein Lieferantenaudit durchzuführen.

Ein Lieferantenaudit muss nicht immer so ablaufen, dass Sie den Lieferanten besuchen und ihm einen Tag lang peinliche Fragen stellen.

Sie können ihm beispielsweise einen Fragebogen senden oder im Internet recherchieren, ob die Software oder der Hersteller einen negativen Track Record hat.

2. Individual-Fremdentwicklung oder Customizing in größerem Ausmaß

Auch hier müssen Sie die Sicherheitsanforderungen vorher definieren und vertraglich verankern. Zu den Anforderungen selbst - siehe 1.

Darüber hinaus ist es bei Individualentwicklung häufig möglich, auch beim Entwicklungsprozess "mitzureden". Für den Fall, dass Ihr Unternehmen eine klare Vorstellung von einem sicheren Entwicklungsprozess hat - und Ihr Lieferant eher noch nicht, sind Sie gefragt: bringen Sie sich ein und nutzen Sie die Möglichkeit, hier Ihre Anforderungen an Sicherheit im Entwicklungsprozess umzusetzen. Der folgende Abschnitt gibt Ihnen eine Orientierung, woran Sie denken sollten.

Sicherheitsfragen, die Sie vorab klären sollten

Damit A.8.30 nicht zu abstrakt bleibt, helfen ein paar sehr konkrete Fragen.

Was darf die Anwendung auf keinen Fall falsch machen?

Das ist die wichtigste Frage überhaupt. Welche Daten verarbeitet die Anwendung? Welche Schäden drohen bei unbefugtem Zugriff, Datenverlust, Manipulation oder Ausfall? Requirements Capture und Data Management sind klar Bestandteile sicherer Entwicklung. Ohne diese Klarheit bleibt Sicherheit zu allgemein.

Backdoors und andere "überflüssige" Bestandteile?

Wie wird sichergestellt, dass nicht unnötige, nicht verlangte Funktionalität (Backdoors, Eastereggs) in die Software implementiert wird?

SBOM - was wird verwendet?

Keine Software wird "von Grund auf neu" entwickelt. Der Hersteller nutzt immer eine große Menge an bereits fertigen Modulen, Bibliotheken, Frankeworks und Komponenten in seinem SBOM (Software Bill of Materials) - die auch in aller Regel frei erhältlich sind.

"Frei erhältlich" bedeutet jedoch nicht, dass diese in jedem Fall lizenzrechtlich unbedenklich sind. Manche Lizenzen erlauben die Verwendung nur in nicht-kommerziellem Kontext, andere Lizenzen verpflichten den Hersteller dazu, dass die entstehende Software unter derselben Lizenz steht wie das verwendete Modul selbst (und dann der Quelltext bspw. offen gelegt werden muss) u. dgl.

Dieser Umstand wird sogar ausgenutzt: obskure Unternehmen scannen öffentlich zugängliche Webseiten daraufhin, welche Komponenten auf ihnen eingesetzt werden und versenden Abmahnungen, wenn der Einsatz nicht den Lizenzbedingungen entspricht.

Welche Wünsche haben Sie in Bezug auf die Nutzungsbedingungen Ihrer eigenen Software - und der enthaltenen Komponenten?

Testdaten

Wie bekommen die Softwareentwickler Zugang zu Testdaten aus dem Produktivsystem, die sie benötigen, um Fehler nachzustellen und zu beheben?

Secure Coding und Secure Design

Welche Ansprüche haben Sie an das Thema "Sichere Softwarearchitektur" und "Secure Coding"? Was erwarten Sie von Ihrem Hersteller hinsichtlich der Einhaltung? Hat dieser eine Secure Coding Guideline? Wie wird sie umgesetzt? Wie enforced?

Wie entwickelt oder pflegt der Anbieter eigentlich?

Das NCSC beschreibt einen etablierten sicheren Entwicklungsrahmen mit Themen wie Threat Modelling, Governance, Secure Coding und Teststrategie. Wenn ein Anbieter dazu gar nichts Belastbares sagen kann, ist das kein gutes Zeichen. Für Kunden empfiehlt es sich, die Versprechungen des Anbieters zu verifizieren und Nachweise zu bewerten.

Wie wird mit Schwachstellen und Updates umgegangen?

Software ist nie "einmal fertig und dann für immer sicher". Das NCSC fordert bspw. von Kunden, fortlaufende Assurance einzuholen, periodische Sicherheitsupdates zu verlangen und zu beobachten, ob Sicherheitskontrollen wirksam bleiben. Genau deshalb gehört in jede Beschaffungsentscheidung auch die Frage: Wie reagiert der Anbieter auf Sicherheitsprobleme?

Bugfixing

Wenn Sie an den Hersteller Fehler melden, die Sie während des Betriebs bemerken: wie geht der Hersteller damit um, diese zu beheben? Hat er Zugriff auf die Produktivdaten, um die Originalsituation nachstellen zu können? Müssen Sie den Zugriff erst genehmigen? Was geschieht mit für die Fehlernachstellung ausgehändigten Produktivdaten danach? Werden diese gelöscht? Wie wird das nachgewiesen?

Welche Nachweise bekommen Sie wirklich?

NIST und NCSC denken beide nicht nur in Versprechen, sondern in nachweisbaren Praktiken. Das NCSC empfiehlt Kunden, vom Lieferanten ein Assurance Principles & Claims-Dokument anzufordern und dessen Aussagen zu prüfen. Praktisch heißt das: Nicht nur "wir entwickeln sicher" akzeptieren, sondern zeigen lassen, woran das festgemacht wird.

Ausgelagerte Entwicklung heißt auch: Lieferantensteuerung

Sobald Entwicklung oder wesentliche Teile davon extern stattfinden, wird das Thema automatisch auch zur Lieferantensteuerung. Der Softwarehersteller wird automatisch ein sicherheitsrelevanter Lieferant. Es empfiehlt sich, dass Kunden die Einhaltung von Sicherheitsprinzipien in Verhandlungen, Verträgen und der laufenden Zusammenarbeit adressieren. Ausgelagerte Entwicklung ist also nicht nur ein Entwickler- oder Einkaufsproblem, sondern ein Steuerungsproblem.

Gute Anforderungen machen Projekte schneller, nicht langsamer

Manche Unternehmen fürchten, Sicherheitsanforderungen würden Ausschreibungen und Projekte unnötig verlangsamen. In der Praxis ist oft das Gegenteil der Fall. Wenn Sicherheit erst am Ende "angeschraubt" werden muss, führt das zu Verzögerungen und Mehrkosten. Wer ISO 27001 A.8.30 ernst nimmt, spart sich also häufig spätere Schleifen, Nachforderungen und unangenehme Überraschungen.

Ein pragmatischer Start für Unternehmen

Wenn Sie das Thema sauber, aber ohne Overhead angehen wollen, reicht für den Start oft schon diese Linie:

1. Sicherheitsanforderungen an die Software vor Beschaffung oder Entwicklung festhalten

Nicht nur Funktionen, sondern Rollen, Logging, Zugriffsmanagement,  Anbindung an IAM, Updatefähigkeit, Datenhaltung und Exit-Fragen. Das folgt sehr direkt aus A.8.30 und aus NCSC Principle 1.1 zu Requirements Capture.

2. Zwischen Standardsoftware und Individualentwicklung bzw. Customizing klar unterscheiden

Die Anforderungen bleiben ähnlich, aber die Steuerungshebel unterscheiden sich.

3. Lieferanten nicht nur auswählen, sondern bewerten

Es empfiehlt sich, Claims und Nachweise des Anbieters zu prüfen und in Verhandlungen sowie Verträgen zu nutzen.

4. Sicherheitsanforderungen in Verträge und Abnahme aufnehmen

Sicherheitsanforderungen an den Entwicklungsprozess - und allgemein an den Umgang mit sensitiven Daten (Produktivdaten, Sourcecode u.ä.) sollte in Verträgen  geregelt sein.

5. Laufende Sicherheit mitdenken

Updates, Schwachstellenprozesse, Änderungen und Nachweise gehören dazu!

Was will der Auditor sehen?

Ein Auditor will hier in der Regel nicht hören: "Der Anbieter ist bekannt, das wird schon passen." Er will erkennen, dass Sicherheitsanforderungen ermittelt, festgelegt, freigegeben und – je nach Fall – in Entwicklung, Beschaffung, Vertrag und Abnahme eingebunden wurden. Genau das ist die praktische Auditlogik hinter A.8.30. Die Guidance von NIST und NCSC kann hier helfen.

FAQ

Interesse geweckt?

Möchten Sie im Rahmen einer ISO 27001-Zertifizierung Ihre ausgelagerte Softwareentwicklung in den Griff bekommen möchten, dann sprechen Sie mit uns oder schreiben uns etwas gleich hier rechts unten auf der Seite in den Chat!