Was gehört in die Informationssicherheitsrichtlinie für Softwareentwicklung?
Eine Informationssicherheitsrichtlinie für Softwareentwicklung ist das Dokument, in dem Sie festhalten, wie Ihre Organisation mit der Sicherheit von Informationen, Systemen und Code umgeht. Für ein Softwareunternehmen geht es gleichzeitig um zwei Dinge: die Sicherheit dessen, was Sie entwickeln, und die Sicherheit der Umgebung, in der Sie es entwickeln. Beide gehören in dasselbe Dokument, auch wenn sie inhaltlich unterschiedliche Themen sind.
Das bedeutet konkret, dass die Richtlinie normalerweise auf den Umfang eingeht (welche Systeme und welche Entwicklungsprojekte darunter fallen), die Verantwortlichkeiten (wer entscheidet, wer verwaltet, wer kontrolliert), die Art und Weise, wie der Zugriff auf Quellcode und Entwicklungsumgebungen geregelt ist, wie Schwachstellen im eigenen Code gefunden und behoben werden, wie mit Test- und Produktionsumgebungen umgegangen wird, wie Vorfälle dokumentiert werden, und wie die Richtlinie selbst gepflegt und überprüft wird. Ein Fragenkatalog eines Kunden fragt oft genau nach solchen Dokumenten als Nachweis, nicht nach einer technischen Beschreibung Ihres Quellcodes.
Zwei Ebenen: das Produkt und die Entwicklungsumgebung
Die erste Ebene betrifft das Produkt: die Software, die Sie an Kunden liefern. Dazu gehört eine Beschreibung, wie Sie mit Schwachstellen umgehen, die nach der Lieferung entdeckt werden, wie Updates und Patches bei Kunden ankommen, und wer in der Organisation dafür verantwortlich ist, Meldungen über Sicherheitsprobleme im Produkt zu verfolgen.
Die zweite Ebene betrifft die Entwicklungsumgebung: die Umgebung, in der Ihr Team arbeitet. Das ist die Versionskontrollumgebung, die Build- und Test-Pipeline sowie die Trennung zwischen Test- und Produktionsumgebungen. Es geht hier um Fragen wie wer auf den Quellcode zugreifen darf, wie Änderungen kontrolliert werden, bevor sie live gehen, und wie der Zugriff entzogen wird, wenn jemand das Team verlässt. Beide Ebenen können im selben Dokument stehen, werden aber oft separat beschrieben, weil sich die Risiken und die dafür Verantwortlichen unterscheiden.
Warum ein Kunde danach fragt
Organisationen, die selbst einer Sorgfaltspflicht unterliegen, sind verpflichtet, die Risiken bei ihren Lieferanten zu bewerten. Ein Softwareunternehmen, das für eine solche Organisation entwickelt, erhält dadurch Fragen, die nicht aus eigener Verpflichtung entstehen, sondern aus der Lieferkette. Eine Informationssicherheitsrichtlinie wird dann oft zuerst angefordert, weil sie in einem Dokument zeigt, wie strukturell die Sicherheit angegangen wurde. Fehlt sie, müssen Sie das in einem Fragenkatalog bei jeder Frage einzeln erklären, was mehr Zeit kostet und weniger überzeugend wirkt als ein bestehendes Dokument.
Ob Ihre Organisation selbst einer Sorgfaltspflicht unterliegt, durch die Lieferkette betroffen ist oder keines von beiden, ist nicht auf den ersten Blick zu erkennen. in ein paar Fragen sehen Sie, wo Ihre Organisation steht gibt dort einen ersten Anhaltspunkt mit Erklärung dazu, warum.
Wie sich diese Richtlinie zu den einzelnen Maßnahmen verhält
Eine Informationssicherheitsrichtlinie steht nicht für sich allein. Sie beschreibt in groben Zügen, wie Sie mit Sicherheit umgehen, während die einzelnen Maßnahmen — Zugriffskontrolle, Backups, Vorfallsdokumentation, Lieferantenbewertung — deren konkrete Umsetzung sind. Wer die Richtlinie schreibt, ohne die zugrundeliegenden Maßnahmen in Ordnung zu haben, hat ein Dokument, das nicht mit der Praxis übereinstimmt. Umgekehrt ist es auch schwierig: einzelne Maßnahmen ohne übergeordnete Richtlinie wirken fragmentiert auf denjenigen, der danach fragt. die Übersicht aller Themen pro Situation zeigt, wie diese Komponenten zusammenhängen.
Was in der Praxis oft fehlt
In vielen ersten Versionen solcher Richtlinien fehlt ein klarer Verantwortlicher für jeden Bereich: Wer ist zuständig dafür, die Zugangsrichtlinie aktuell zu halten, wer für die Patch-Richtlinie? Auch ein regelmäßiger Überprüfungstermin fehlt oft, weshalb eine Richtlinie von vor zwei Jahren immer noch als aktuell dargestellt wird, während sich die Entwicklungsumgebung inzwischen geändert hat. Und ein dritter häufig fehlender Punkt: eine explizite Verbindung zwischen der Richtlinie und den Nachweisen, die zeigen, dass sie tatsächlich umgesetzt wird, wie Zugriffsprotokolle oder eine Übersicht der durchgeführten Patches.
Beurteilen Sie Ihre eigene Situation
Welche Bestandteile genau erwartet werden, hängt von der Rolle Ihrer Organisation in der Lieferkette und von den spezifischen Anforderungen eines Kunden ab. Dieser Artikel beschreibt den üblichen Aufbau, keine verbindliche Vorlage, und die Gesetzesvorgaben selbst schreiben keine feste Gliederung vor. Für eine Bewertung Ihrer spezifischen Situation sind ein Jurist oder die zuständige Aufsichtsbehörde die richtige Anlaufstelle; die häufig gestellten Fragen zu solchen Dokumenten gibt einen ergänzenden Überblick über das, was häufig gefragt wird.
Möchten Sie sehen, wie solche Richtlinien zusammen mit den zugrunde liegenden Maßnahmen und Nachweisen in einer laufenden Dokumentation gepflegt werden, statt als separates Dokument? wie secria.eu die Informationen aufbaut und verwaltet zeigt das. Beginnen Sie alternativ mit der kostenlosen NIS2-Überprüfung, oder blättern Sie durch die Wissensdatenbank, um zu sehen, welche Themen für Ihre Organisation relevant sind.