Secure Coding – Herausforderung in der Informationssicherheit

• Sicherheitslücken im Code
• Open Source Code und Supply-Chain-Angriffe
• Informationssicherheitsmaßnahme 8.28 Sicheres Coding
• Grundsätze der sicheren Codierung
• Fazit
• Revision von ISO 27001: Was bedeutet das Update für Ihre Zertifizierung?
• Ihre DQS – Maximale Kompetenz in der Informationssicherheit

Sicherheitslücken im Code

Betriebssystemsoftware, Anwendungssoftware oder Firmware in einem Embedded System sind elementare Bestandteile jeder digitalen Infrastruktur. Häufig jedoch führen zunehmende Beschleunigung und Termindruck in Digitalisierungsprojekten zu einer Vernachlässigung zwingend notwendiger Informationssicherheitsaspekte. Die Entwicklungsanforderungen an Software sind in der Regel funktionszentriert und betonen konstruktive Aspekte, so dass der destruktive Blickwinkel auf potenzielle Sicherheitsschwachstellen zumeist diametral gegenläufig zu den eigentlichen Entwicklungszielen ist: vielen Programmierern fehlt schlicht auch der strukturierte und geschärfte Blick auf Cybersicherheit.

Unter diesen Rahmenbedingungen haben es Entwicklerteams schwer, die Kodierung ihrer Software kontinuierlich zu überprüfen und konsistent abzusichern, wie die vielen Schwachstellen belegen, die die gemeinnützige MITRE Corporation jedes Jahr in ihrer CVE-Liste (Common Vulnerabilities and Exposures) veröffentlicht. Die regelmäßigen Sicherheitspatches auch namhafter Softwarehersteller sind ein Indikator für die Sisyphusaufgabe, sicherheitsrelevante Fehler zu schließen geschweige denn schon vor Markteinführung zu identifizieren.

Spezialfall: Open Source Code

Bei der Kodierung eigenentwickelter Software greifen Programmierer gerne auf Open Source‑Bibliotheken und -Bausteine zurück. Die praktischen Vorteile liegen auf der Hand: Wer das Rad nicht immer wieder neu erfinden muss, profitiert von diesem Technologie-Boost, zügiger Entwicklung, geringeren Entwicklungskosten, mehr Transparenz durch offenen Quellcode und höherer Interoperabilität durch offene Standards und Schnittstellen.

Gerne wird auch kolportiert, dass Code aus Open Source ein hohes Maß an Sicherheit mitbringt, weil der Code von vielen Anwendern validiert sei und die Schwarmintelligenz der Open Source Community eine schnelle und effiziente Fehlerbehebung ermögliche.

In der Praxis ist dieses Vertrauen mittlerweile differenziert und kritisch zu bewerten. Als gravierendstes Beispiel sei die im November 2021 entdeckte Zero-Day-Sicherheitslücke Log4Shell in der weit verbreiteten Protokollierungsbibliothek Log4J für Java-Anwendungen erwähnt. Wir erinnern uns, dass das Bundesamt für Sicherheit in der Informationstechnik (BSI) für Log4Shell die Warnstufe Rot ausgegeben hat. Die Bibliothek Log4J hat sich, als zuverlässig funktionierender Quasi-Standard über die Apache Foundation verteilt, seit 2013 in vielen Systemen etabliert – darunter auch bekannten Webservices wie Amazon AWS.

Die Komplexität dieser gut entwickelten und auch gewarteten Bibliotheken bietet implizit mächtige Funktionalitäten, deren Möglichkeiten sich ein importierender Entwickler in seiner eigenen, kombinierten Neuentwicklung häufig nicht bewusst ist, die aber von Angreifern ausgenutzt werden können.

Ein weiterer Unsicherheitsfaktor von Open-Source-Komponenten sind sogenannte Supply-Chain-Angriffe, also beabsichtigt eingebaute Schwachstellen von bösartigen Akteuren, die sich als Teil der Open Source Community ausgeben und bei der Code-Entwicklung unterstützen. Eine solche Schwachstelle ist für Hacker eine überaus effiziente Variante, um eine Vielzahl nachgelagerter Anwenderorganisationen zu attackieren. Kein Wunder also, dass dieser Angriffsvektor rasant wächst: Eine Sonatype-Studie diagnostizierte im Vergleich der Jahre 2020 und 2021 eine Steigerung von 650 %.

Informationssicherheitsmaßnahme 8.28 Sicheres Coding

Zur zeitgemäßen Absicherung des Softwareentwicklungsprozesses hat die International Organization for Standardization (ISO - Gremium ISO/IEC JTC 1/SC 27) „Sicheres Coding“ als neues Control 8.28 in der neuen Normen ISO/IEC 27002 und der neuen ISO/IEC 27001:2022, Anhang A aufgenommen. Zweck der technischen Maßnahme zur sicheren Kodierung ist der präventive Schutz von Software.

Bereits beim Schreiben wird auf Grundlage prozessualer Regelungen ein Mindestmaß an Sicherheit geschaffen, um so die Anzahl potenzieller Sicherheitslücken in der Software zu minimieren. Der Regelungsrahmen für eine sichere Codeerzeugung ist dabei ganzheitlich sowohl auf eigenen Programmcode als auch auf Software von Dritten und Open-Source-Quellen zu übertragen. Nennenswerte Prinzipien für die Umsetzung sind Security by Design und Least Privilege, die auch beim Coding berücksichtigt werden müssen.

Grundsätze der sicheren Codierung

Die Maßnahme 8.28 adressiert mehrfach sogenannte Grundsätze der sicheren Codierung. Orientierung, welche das sein könnten, liefern zahlreiche Organisationen und Institute, die regelmäßig Leitfäden und Best Practices für sichere Codierung herausgeben. Dazu zählen zum Beispiel die Secure Coding Practices der OWASP Foundation, die Secure Coding Standards des Computer Emergency Response Teams (CERT) des Software Engineering Institutes (SEI) oder auch der Maßnahmenkatalog Sicherheit von Webanwendungen des BSI. Trotz der unterschiedlichen Quellen weisen die Ausarbeitungen dabei viele Parallelen auf, etwa mit Blick auf folgende Punkte:

• Validierung von Dateneingaben
• Absicherung der Authentifizierung und Passwortverwaltung
• sichere Zugangskontrolle
• einfacher, transparenter Code
• nachhaltig geprüfte kryptografische Maßnahmen und Komponenten
• Fehlerbehandlung und Protokollierung
• Datenschutz
• Bedrohungsmodellierung

In der Norm ISO/IEC 27002:2022 sind die Handlungsempfehlungen zum Control 8.28 in folgende drei Abschnitte unterteilt, deren Kerninhalte nachfolgend skizziert werden:

• Planung und Vorcodierung
• Während der Codierung
• Überprüfung und Wartung

Planung und Vorcodierung

Sowohl bei der Neuentwicklung als auch bei der Wiederverwendung von Code gilt es, die Grundsätze der sicheren Codierung anzuwenden – unabhängig davon, ob der Code für interne Software oder für externe Produkte und Dienstleistungen geschrieben wird. Dies setzt im Vorfeld die Evaluierung der organisationsspezifischen Erwartungshaltung und Festlegung anerkannter Grundsätze voraus. Darüber hinaus berücksichtigen die Handlungsempfehlungen zur Planung und Vorcodierung bekannte gängige und historische Codierungspraktiken und Fehler, die zu Schwachstellen führen könnten.

Die Konfiguration von Entwicklungswerkzeugen sollte, zum Beispiel regelbasiert in integrierten Entwicklungsumgebungen (IDE), die Erstellung von sicherem Code erzwingen. Ganz entscheidend ist die Qualifikation der Entwickler und deren Vertrautheit mit sicheren Architekturen und Programmierstandards. Die Einbindung von Informationssicherheitskompetenz im Entwicklerteam versteht sich selbstredend.

Während der Codierung

Im laufenden Codierungsprozess spielen vor allem die Codierungspraktiken und strukturierte Programmiertechniken eine Rolle, unter Berücksichtigung des spezifischen Anwendungsfalls und dessen Sicherheitsbedürfnissen. Unsichere Design-Techniken – zum Beispiel fest codierte Kennwörter – sind konsequent zu verbieten. Der Code sollte ausreichend dokumentiert und überprüft werden, um sicherheitsrelevante Fehler bestmöglich zu beseitigen. Die Codeprüfung sollte sowohl während als auch nach der Entwicklung erfolgen, zum Beispiel über statische Anwendungssicherheitstests (SAST). Statische Testverfahren unterstützen den Shift Left Ansatz („Teste früh und oft“) durch Linksverschiebung im Lebenszyklus, indem früh der sichtbare Code auf Regelkonformität geprüft wird.

Damit lassen sich „tainted Code“ (verunreinigter Code), Verbindungen zu Dateien oder bestimmten Objektklassen oder aber Lücken auf Applikationsebene, die für unbemerkte Interaktion mit Fremdprogrammen missbraucht werden können, frühzeitig als ausnutzbare Schwachstellen identifizieren. Vor Inbetriebnahme der Software verlangt das Control 8.28 eine Bewertung von Angriffsflächen und der Umsetzung des Least-Privilege-Prinzips. Die durchgeführte Analyse der häufigsten Programmierfehler und Dokumentation ihrer Behebung sollten bewertet werden.

Überprüfung und Wartung

Auch nach der Inbetriebnahme der Software bleibt das Thema sicheres Coding relevant. Hierzu gehören sichere Updates sowie Kontrollen, ob bekannt gewordene Schwachstellen im eigenen Code vorhanden sind. Darüber hinaus müssen Fehler und vermutete Angriffe dokumentiert werden, um notwendige Anpassungen zeitnah vornehmen zu können. In jedem Fall muss der unbefugte Zugriff auf den Quellcode durch geeignete Tools zuverlässig ausgeschlossen werden.

Open Source Code

Im Bereich Überprüfung und Wartung listet Maßnahme 8.28 zusätzlich explizite Handlungsanweisungen für den Einsatz externer Tools und Bibliotheken – wie zum Beispiel Open Source Software – auf. Diese Code-Bestandteile sollten in Inventarlisten verwaltet, aktualisiert und gewartet werden. Dies kann unter anderem über eine Software Bill of Material (SBOM) erfolgen. Eine SBOM ist eine formale, strukturierte Aufzeichnung über die Pakete und Bibliotheken einer Software und ihre Beziehungen untereinander sowie innerhalb der Lieferkette, um insbesondere den Überblick über wiederverwendeten Code und Open-Source-Komponenten zu behalten. Die SBOM unterstützt die Wartbarkeit von Software und zielgerichtete Sicherheitsupdates.

Secure Coding – Fazit

Secure Coding ist ein elementares Fundament, um potenziellen Angriffen einen Riegel vorzuschieben. Das neue Control 8.28 aus ISO/IEC 27001:2022 trägt dieser leidgeprüften Einsicht Rechnung und wertet die Schlüsselrolle des sicheren Codings in seiner Bedeutung für die Informationssicherheit auf. Da die Maßnahme jedoch eine Vielzahl detaillierter Handlungsempfehlungen umfasst und technisch anspruchsvoll ist, wird ihre Umsetzung mit einem vergleichsweise hohen Aufwand verbunden sein – dies gilt es bereits bei der Planung zu bedenken.

Mit dem professionellen Blick unserer erfahrenen Auditoren unterstützen wir Sie bei der konformen Umsetzung der Maßnahme. Mit unserer Audit- und Zertifizierungs-Expertise aus über 35 Jahren sind wir Ihr kompetenter Ansprechpartner und stehen Ihnen beim Thema Informationssicherheit und der Zertifizierung nach ISO 27001 gerne zur Seite.

Revision von ISO 27001: Was bedeutet das Update für Ihre Zertifizierung?

ISO/IEC 27001:2022 wurde am 25. Oktober 2022 veröffentlicht. Daraus ergeben sich für Anwender folgende Fristen und Zeiträume für den Übergang:

Letzter Termin für die Erst-/Rezertifizierungsaudits nach der „alten“ ISO 27001:2013

• nach dem 30. April 2024 wird die DQS Erst- und Rezertifizierungsaudits nur noch nach der neuen Norm ISO/IEC 27001:2022 durchführen

Umstellung aller bestehenden Zertifikate nach der „alten“ ISO/IEC 27001:2013 auf die neue ISO/IEC 27001:2022

• es gilt eine 3-jährige Übergangsfrist ab dem 31. Oktober 2022
• ausgestellte Zertifikate nach ISO/IEC 27001:2013 bzw. DIN EN ISO/IEC 27001:2017 sind längstens bis zum 31. Oktober 2025 gültig oder müssen zu diesem Datum zurückgezogen werden.

Ihre DQS: Maximale Kompetenz in der Informationssicherheit

Unternehmen haben dank der Übergangsfristen ausreichend Zeit, um ihr Informationssicherheits-Managementsystem gemäß den neuen Anforderungen anzupassen und zertifizieren zu lassen. Doch die Dauer und der Aufwand des gesamten Change-Prozesses sind nicht zu unterschätzen – vor allem, wenn Sie nicht ausreichend über spezialisiertes Fachpersonal verfügen. Wer auf Nummer sicher gehen möchte, setzt sich lieber früher als später mit dem Thema auseinander und greift bei Bedarf auf erfahrene Spezialisten zurück.

Als Audit- und Zertifizierungsexperten mit über 35 Jahren Expertise unterstützen wir Sie gerne bei der Evaluierung Ihres Ist-Zustands, eventuell  im Rahmen eines Delta-Audits. Informieren Sie sich bei unseren zahlreichen erfahrenen Auditoren über die wichtigsten Änderungen und deren Relevanz für Ihre Organisation. Gemeinsam erörtern wir Ihr Verbesserungspotenzial und unterstützen Sie bis zum Erhalt des neuen Zertifikats. Wir freuen uns auf Ihre Kontaktaufnahme.

Vertrauen und Expertise  

Unsere Texte und Broschüren werden ausschließlich von unseren Normexperten oder langjährigen Auditoren verfasst. Sollten Sie Fragen zu den Textinhalten oder unseren Dienstleistungen an unseren Autor haben, senden Sie uns gerne eine E-Mail.

Hinweis: Wir verwenden aus Gründen der besseren Lesbarkeit das generische Maskulinum. Die Direktive schließt jedoch grundsätzlich Personen jeglicher Geschlechteridentitäten mit ein, soweit es für die Aussage erforderlich ist.