Worum geht es?
Fehlerhafter oder unsicher entwickelter Code führt schnell zu auch gravierenden Sicherheitslücken. Dementsprechend ist Software jeglicher Art zum Hauptangriffsziel geworden.
Die Norm ISO 27002 fordert entsprechend, dass Organisationen verbindliche Prozesse zur sicheren Codierung einführen. Dabei geht es nicht nur um selbstentwickelte Software, sondern auch um Open Source Lösungen und Angebote von dritter Seite. Richtigerweise wird auch betont, dass in diesem Zusammenhang die kontinuierliche Verbesserung ganz besondere Bedeutung hat.
Software soll nicht nur möglichst sicher geschrieben, sondern auch möglichst sicher gehalten werden.
Was empfiehlt die ISO 27002?
Die Norm gibt in Kapitel 8.28 verschiedene Empfehlungen für die verschiedenen Phasen des Lebenszyklus von Software.
Jede Codierung sollte auf Basis dokumentierter Grundsätze erfolgen, die sowohl für Neuentwicklungen als auch für Anpassungen an bestehender Software gelten. Diese als Planungsgrundlage dienenden Grundsätze sollten folgende Themen behandeln:
- Eigene Erwartungen sowie die allgemein anerkannten Grundsätze an die sichere Codierung
- Vorgaben für die Programmierung unter Vermeidung bekannter Fehlerquellen und Schwachstellen. Es sollte beispielsweise klar sein, dass es so etwas wie „SQL-Injection“ gibt und diese Schwachstelle bereits bei der Programmierung vermieden werden muss.
- Die Vorgaben sollten möglichst durch den Einsatz geeigneter und aktueller Entwicklungswerkzeuge unterstützt werden, die die Erstellung von sicherem Code erzwingen oder wenigstens begünstigen.
- Dass die Entwicklung in einer gesicherten und vor allem kontrollierten Umgebung erfolgt, gehört selbstverständlich dazu.
- Natürlich müssen auch die eingesetzten Entwickler die notwendige Qualifikation besitzen, sicheren Code zu schreiben.
- Um die Anforderungen im Einzelfall festzulegen, ist es notwendig, eine konkrete Bedrohungsmodellierung durchzuführen.
Für die Phase der Codierung sind die folgenden Maßnahmen vorgeschlagen:
- Die für die jeweils verwendete Programmiersprache spezifischen Codierungspraktiken sind zu beachten
- Die Programmierung sollte stets strukturiert erfolgen.
- Der Code und insbesondere die Beseitigung von Programmierfehlern muss dokumentiert sein.
- die gewählte Programmiertechnik sollte sich an geeigneten Best-Practice orientieren. Beispielsweise Pair-Programming, Peer Review oder testgestützte Entwicklung.
- Nicht sichere Gestaltungstechniken dürfen nicht verwendet werden. So sollte es beispielsweise jedem einleuchten, dass etwa Passwörtern niemals im Code enthalten sein dürfen.
- Vor Abschluss der Programmierungsarbeiten sollte stets erneut überprüft werden, ob sich Angriffsflächen noch weiter reduzieren lassen. Hierzu gehört insbesondere auch der kritische Blick, ob das Prinzip der geringsten Privilegien beachtet wurde. Ebenfalls sollten überprüft und dokumentiert werden, dass die häufigsten Programmierfehler nicht unterlaufen sind.
Für Code im Einsatz wird folgendes empfohlen:
- Nachträglich bekannt gewordene Schwachstellen sollten behandelt werden. Hierzu ist es insbesondere notwendig, Fehler und vermutete bzw. erfolgte Angriffe zu protokollieren und auszuwerten, um gegebenenfalls die notwendigen Anpassungen am Code vorzunehmen.
- Der Quellcode selbst muss vor unbefugtem Zugriff und Manipulationen geschützt sein. Veränderungen müssen bemerkt werden und nachvollzogen werden können.
- Insbesondere auch bei externen Tools und Bibliotheken muss sichergestellt sein, dass diese entsprechend verwaltet und aktualisiert werden.
- In diesem Zusammenhang sollte auch darauf geachtet werden, dass die benötigten Tools und Bibliotheken auch auf die voraussichtlich benötigte Dauer hin bereitstehen und genutzt werden können.
- Bei jeder Änderung von Software muss darauf geachtet werden, dass diese keinen Einfluss auf eingebaute Kontrollmechanismen und Integritätsprozesse hat.
- Schließlich müssen Updates sicher (getestet und möglichst signiert) bereitgestellt und kontrolliert verteilt werden.
Fazit
Sichere Codierung ist unverzichtbar zur Reduzierung von Risiken für die Informationssicherheit. Primär den Blick auf die gewünschte Funktionalität zu richten und die Software dann im Einsatz reifen zu lassen, ist keine akzeptable Herangehensweise. Wenn es Schwächen gibt, werden diese erfahrungsgemäß auch sofort ausgenutzt.
Organisationen sollten daher dringlich prüfen, ob die hier beschriebenen Maßnahmen berücksichtigt werden und gegebenenfalls die notwendigen Anpassungen vorantreiben.
Helfen kann in diesem Zusammenhang auch eine SBOM (Software Bill of Materials oder Software-Stückliste) als detaillierte Liste aller Softwarekomponenten, Bibliotheken und Abhängigkeiten, die in einer Anwendung verwendet werden. Sie dient dazu, Transparenz in die Software-Lieferkette zu bringen, Sicherheitslücken zu identifizieren, Risiken im Zusammenhang mit Open-Source-Software zu managen und die Einhaltung von Vorgaben sicherzustellen.