Ohne Software lässt sich keine Daten- und Informationsverarbeitung betreiben. Softwareentwicklung fokussiert sich in erster Linie auf das aufgabenspezifische Funktionieren von Algorithmen. Dass allerdings das schlechte Schreiben von Programmcode häufig auch Sicherheitsprobleme begründet, wie zum Beispiel fehlerhafte Zugriffskontrolle, SQL-Injection, falsche Session-Verwaltung und ‑Authentifizierung, Cross-Site-Scripting etc., ist mittlerweile hinlänglich bekannt.

Der hohe Stellenwert sicherer Kodierungspraktiken wird in den aktualisierten Standards für Informationssicherheit ISO/IEC 27001:2022 und ISO/IEC 27002:2022 hervorgehoben. Als neue Informationssicherheitsmaßnahme (Control) erhalten die Grundsätze für ein „Sicheres Coding“ in der Softwareentwicklung Einzug in den Maßnahmenkatalog des Anhang A der ISO/IEC 27001. Welche Bedeutung diese Maßnahme für Ihre Informationssicherheit hat und was dies für künftige Audits bedeutet, lesen Sie in unserem Blogbeitrag.

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 %.

neue-iso-iec-27001-2022-blog-dqs-projektmanager unterhalten sich bei benutzung eines tablets in einer zentrale
Loading...

Auch interessant:

Die neue ISO/IEC 27001:2022 – wesentliche Änderungen

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 den neuen Normen ISO/IEC 27002 und 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/ISO 27002:2022 sind die Handlungsempfehlungen zum Control 8.28 in die drei Abschnitte „Planung und Vorcodierung“, „Während der Codierung“ sowie „Überprüfung und Wartung“ unterteilt, deren Kerninhalte nachfolgend skizziert werden.

Cyberattack - Bildschirm zeigt Zahlencodes mit Warnsignalen
Loading...

Auch interessant:

Detektion und Prävention im Informationssicherheitsmanagement

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.

fragen-antwort-dqs-fragezeichen auf wuerfeln aus holz auf tisch
Loading...

Zertifizierung nach ISO 27001

Mit welchem Aufwand müssen Sie rechnen, um Ihr ISMS nach ISO 27001 zertifizieren zu lassen? Informieren Sie sich kostenfrei und unverbindlich.

Wir freuen uns auf das Gespräch mit Ihnen.

Secure Coding – Fazit

Sicherer Code ist ein elementares Fundament, um potenziellen Angriffen einen Riegel vorzuschieben. Das neue Control 8.28 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 optimaler Ansprechpartner und stehen Ihnen beim Thema Informationssicherheit und Zertifizierungen nach den Normen ISO/IEC 27001:2022 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:

Zertifizierungsbereitschaft nach ISO/IEC 27001:2022

  • voraussichtlich ab April 2023 (abhängig von der Deutschen Akkreditierungsstelle GmbH (DAkkS))

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

  • nach dem 31. Oktober 2023 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 ISMS 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.

fragen-antwort-dqs-fragezeichen auf wuerfeln aus holz auf tisch
Loading...

Sie haben Fragen?

Kontaktieren Sie uns!

Ganz unverbindlich und kostenfrei.

Autor
Markus Jegelka

DQS-Fachexperte für Informationssicherheitsmanagementsysteme (ISMS) und langjähriger Auditor für die Regelwerke ISO 9001, ISO/IEC 27001 und IT-Sicherheitskatalog § 11 Abs. 1a EnWG.

Loading...