Bei der Entwicklung von Software stellen sich die Entwicklungsverantwortlichen die Frage, ob die Software sicher ist und auch einer technischen Prüfung oder sogar einem Cyberangriff standhält. Hier sollten wir natürlich nicht an privat entwickelte Software z.B. für die Heimautomatisierung oder zum Sortieren der Urlaubsfotos denken, sondern an kommerzielle Software für den Einsatz im eigenen Unternehmen vorgesehen sind oder sogar über Produkte, die an Dritte verkauft werden.
Wie beginnt man jedoch eine sichere Software zu entwickelt?
Spoiler-Alarm: Bereits vor der Planungsphase!
Egal, ob man seine Software agil z.B. mit Scrum oder klassisch mit der Wasserfallmethode oder dem davon abgeleiteten V‑Modell entwickelt, muss für eine sichere Software-Entwicklung ein Software Development Lifecycle (SDLC) dokumentiert werden, der in allen Phasen die Informationssicherheit über Secure Design und Secure Coding berücksichtigt. Die folgenden acht Phasen des SDLC haben sich auch bei kleinen Entwicklerteams bewährt:


Risikoanalyse
1. Risikoanalyse: noch bevor es mit den technischen Details und den funktionellen Businessanforderungen los geht, müssen die Risiken in Bezug auf Vertraulichkeit, Integrität und Verfügbarkeit erhoben werden und notwendige Informationssicherheitsmaßnahmen festgelegt werden. Restrisiken müssen erkannt und vom Produktverantwortlichen akzeptiert werden.
2. Planung: In der Planungsphase müssen die zuvor identifizierten Risiken analysiert und Maßnahmen für deren Beseitigung konkretisiert werden. Das Hauptziel dieser Phase ist, ein fertiges Konzept inkl. Sicherheitsperspektive und deren Testfälle zu erzeugen, dass die zuvor erstellten Risiken mit einbezieht.


3. Design: Beim Design von Software sind neben den funktionellen Anforderungen in Abhängigkeit der Kritikalität der verarbeiteten Daten und der identifizierten Risiken die folgenden Schutzziele zu berücksichtigen:
— Vertraulichkeit, z.B. Authentisierung, Verschlüsselung, sichere Protokolle;
— Integrität, z.B. Prüfsummen und Signaturen, Einschränkung der Zugriffsrechte, Überwachung der Änderungen, Transaktionslogs;
— Verfügbarkeit, wie Hardware-Redundanzen, redundante Datenhaltung, DoS Schutz;
— sowie die erweiterten Schutzziele Authentizität, Nichtabstreitbarkeit, Zurechenbarkeit und Datenschutz.
4. Entwicklung: In dieser Phase findet die technische Umsetzung des Projektes statt. Hierbei müssen die vom Unternehmen festgelegten technische und organisatorische Maßnahmen (TOMs) berücksichtigt werden, aber auch von EntwicklerInnen aufgedeckte Schwachstellen und der Einsatz von KI geregelt werden.


5. Testen und Integration: Dieser verpflichtende Schritt vor jedem Release regelt die Software- und Funktionstests, die optimal über automatisierte Tests erfolgen. Berücksichtigen Sie in dieser Phase auch Unit-Tests / Modultests und den Einsatz von Cloud-basierter KI für die Software-Tests.
— Vertraulichkeit, z.B. Authentisierung, Verschlüsselung, sichere Protokolle;
— Integrität, z.B. Prüfsummen und Signaturen, Einschränkung der Zugriffsrechte, Überwachung der Änderungen, Transaktionslogs;
— Verfügbarkeit, wie Hardware-Redundanzen, redundante Datenhaltung, DoS Schutz;
— sowie die erweiterten Schutzziele Authentizität, Nichtabstreitbarkeit, Zurechenbarkeit und Datenschutz.
6. Freigabe von Release: Die Freigabe von Software-Releases (Releasebuilds) erfolgt gemäß einem dokumentierten Prozess und zu jeder Release wird eine Release-Dokumentation erstellt, die neben den funktionalen Aspekten der Software auch die Informationssicherheit berücksichtigt. Hierzu zählen auch die Software Bill of Materials (SBOM).


7. Wartung und Betrieb: Nachdem die Software abgenommen und alle Sicherheitstests erfolgreich bestanden wurden, erfolgt die Transformation des Entwickelten in einen Betriebszustand. Für die Bewahrung der Integrität und Wartung der Software muss ein Monitoring eingeführt werden, dass den Betriebszustand in Hinblick auf die Sicherheit regelmäßig überprüft.
8. Entsorgung: Bereits bei der Veröffentlichung einer Software-Release sollte das End-of-Sale und End-of-Life Datum festgelegt werden. Fristen für die entsprechenden Ankündigungen sind zu regeln und die Methode wie Kunden über EoS und EoL informiert werden sind zu definieren. Hier wird zukünftig der EU Cyber Resilience Act (CRA) eine große Rolle spielen, da gesetzlich mindestens für 5 Jahre kostenfreie Sicherheitsupdates angeboten werden müssen.

Was müssen Software entwickelnde Unternehmen zur Erfüllung von ISO 27001, TISAX®, DORA, NIS‑2 oder dem EU Cyber Resilience Act CRA tun?
- Regeln Sie die Verantwortlichkeiten für Informationssicherheit in Ihrem Entwicklungsteam.
- Erstellen Sie Vorgaben für die sichere Software-Entwicklung, Ausgangsbasis kann die Vorlage Secure Coding Manual der SEC4YOU sein.
- Legen Sie technische und organisatorische Maßnahmen fest, die von den EntwicklerInnen einzuhalten sind.
- Führen Sie einen SDLC Prozess ein, der die Informationssicherheit umfassend berücksichtigt und etablieren Sie den Prozess sowohl in Brownfield‑, als auch Greenfield-Projekten.
- Schulen Sie Ihre EntwicklerInnen und TesterInnen regelmäßig auf Secure Coding und Secure Design. Zielgerichtete Secure Coding Schulungen finden Sie im SEC4YOU Online Shop.
Lassen Sie uns die Welt ein Stückchen sicherer machen! Wir helfen gerne einen SDLC in Ihrem Team einzuführen und die Sicherheitsqualität ihrer Software zu verbessern.
Passende Produkte aus dem Online Shop
Vorlage Secure Coding Manual gemäß ISO 27001 und VDA ISA / TISAX®
ISMS Richtlinien und Vorlagen, Secure Codingexkl. MwSt.
€ 960,00
Secure Coding / Secure Design Schulung für Entwickler/innen
Awareness Schulungen, Secure Codingexkl. MwSt.
€ 2.350,00 – € 3.875,00