19.08.2019 | Javan Rasokat | comment icon 0 Comment

So sorgen Sie für mehr Sicherheit im Software Development Lifecycle

Dieser Artikel ist auch auf Englisch verfügbar: https://blog.exxeta.com/en/2019/08/19/helpful-aspects-for-securing-the-software-development-lifecycle/

SDLC steht für Software Development Lifecycle (dt. Software-Lebenszyklus). Ein SDLC ist im Wesentlichen eine Reihe von Schritten oder Phasen, die einen Rahmen für die Entwicklung von Software und deren Verwaltung über den gesamten Lebenszyklus bieten. Obwohl es nicht nur eine Technik oder Möglichkeit gibt, Anwendungen und Softwarekomponenten zu entwickeln, gibt es etablierte Methoden, die von Unternehmen verwendet werden und Modelle, um unterschiedliche Herausforderungen und Ziele zu bewältigen. Diese Methoden und Modelle basieren typischerweise auf einer Norm, wie beispielsweise ISO/IEC 12207, die Richtlinien für die Entwicklung, Beschaffung und Konfiguration von Softwaresystemen festlegt.

Um ein qualitativ hochwertiges Softwareprodukt zu entwickeln, das die Anforderungen des Kunden oder des Endverbrauchers erfüllt, müssen Unternehmen den für sie besten Software Development Lifecycle wählen. Es gibt unterschiedliche SDLC’s. Die Wahl des SDLC variiert von Unternehmen zu Unternehmen. Jedes Unternehmen hat seine eigenen Verfahren und Richtlinien, die sich auch in Bezug auf die Anforderungen und die Infrastruktur unterscheiden. Ein Softwareentwicklungsprozess beschreibt eine theoretische und konzeptionelle Darstellung der Softwareentwicklung. Die Softwareentwicklung durchläuft eine Reihe von verschiedenen Phasen wie Anforderungsanalyse, Designspezifikation, Programmierung, Test und Wartung. Mit Hilfe von Entwicklungsprozessen können Unternehmen die Arbeit effizient aufteilen, verschiedene Aktivitäten dem Softwareentwicklungsteam zuordnen, Budgets und Termine oder den Zeitraum schätzen. Um auf dem globalen Markt konkurrenzfähig zu sein, haben in den letzten vier Jahrzehnten die Unternehmen und Organisationen verschiedene Softwareentwicklungsprozesse wie Wasserfall, Spiralmodell, “Rapid Prototyping”, Agilität und weitere praktiziert. (JAGLI & Yeddu, 2017)

Secure SDLC

Ein sicherer SDLC ist für Unternehmen aller Branchen von entscheidender Bedeutung. Schwache oder gar keine Sicherheitspraktiken führen zu unsicherem und verwundbarem Code. Durch die Integration von Aktivitäten, welche die Sicherheitspraktiken beschreiben, kann die Architektur verbessert werden. Synonym für Secure SDLC ist der sichere Software-Lebenszyklus, auch bekannt als S-SDLC. Außerdem gibt es noch das bekannte Secure Development Lifecycle (SDL)-Framework von Microsoft, auf das wir ebenfalls verweisen.

Eine stärkere Fokussierung auf die Anwendungssicherheit ist wirtschaftlich sinnvoll. Dies betrifft nicht nur die nun aufgezeigten, recht hohen Kosten, die ein IT-Sicherheitsvorfall verursacht, sondern hilft auch, den Unternehmenswert zu steigern. Es ist bekannt, dass die erst späte Behebung von Schwachstellen im SDLC zu höheren IT-Ausgaben und Opportunitätskosten führt.

Von verschiedenen Unternehmen wurden mehrere Herausforderungen im Rahmen des SDLC beobachtet. Einige dieser Beobachtungen sind:

  • – Laut eines Sicherheitsberichtes von Microsoft waren etwa 10% der bis Oktober 2016 offenbarten Schwachstellen auf Betriebssysteme (OS) und die anderen 90% auf die Anwendungsebene ausgerichtet.
  • – Der IBM Internet Security Systems X-Force-Bericht 2016 ergab, dass nur 11% aller im Jahr 2008 offenbarten Schwachstellen zu den fünf führenden Softwareanbietern (Microsoft, Oracle, IBM, Apple und Cisco) gehören.
  • – Das National Institute of Standards & Technology (NIST) schätzt, dass Code-Fixes, die nach der Veröffentlichung durchgeführt werden, 30 Mal mehr kosten als die Code-Fixes, die während der Designphase durchgeführt werden.
  • – Das NIST schätzt, dass 92% aller Sicherheitsvorfälle auf Softwareprobleme zurückzuführen sind.
  • – Ein Bericht von Cigitial zeigt, dass die Ursachen für Schwachstellen in der Anwendungssicherheit fast gleichmäßig auf Programmierfehler und Designfehler verteilt sind.

Diese Ergebnisse zeigen, wie stark die Anwendungsebene von Angriffen betroffen ist.

Eine solide SDLC-Strategie bietet qualitativ hochwertige Software, weniger Schwachstellen, sowie besser eingesetzte Zeit und Ressourcen. Eine Strategie hilft bei der Entwicklung und Wartung von Software. Tools ermöglichen die Integration automatisierter Sicherheitstests in den SDLC-Prozess.

Abbildung 1: Die Phasen des SDLC (in Anlehnung an Subramanian & M., 2017)

In der Literatur gibt es unterschiedliche Einteilungen der Phasen des SDLC. Diese unterschiedlichen Einteilungen reichen von vier recht allgemein gefassten Phasen bis zu den in der Abbildung 1 gezeigten sechs Phasen. Das liegt daran, dass oftmals die Phasen vier und fünf als “Test und Wartung” zusammengefasst sind. Auch eine Einteilung in sieben Phasen ist möglich. Da der Software-Lebenszyklus als vollständige Endlosschleife betrachtet wird, sind auch die Aktivitäten nach der Bereitstellung, also während des Betriebs, für ein vollständiges Bild sinnvoll. In dieser Grafik wurde die sechste Phase “Betrieb und Wartung” für den Secure SDLC hinzugefügt, um die Sicherheitsmaßnahmen, die nach dem Bereitstellen (Deployment) auftreten, mit aufzunehmen und ein ganzheitliches Bild des Secure SDLC zu vermitteln.

Ein wesentliches Merkmal, das den Secure SDLC vom herkömmlichen Entwicklungsprozess unterscheidet, ist, dass Tests kontinuierlich und automatisiert im gesamten SDLC stattfinden.

OWASP SAMM

Zur Entwicklung einer ganzheitlichen Sicherheitsstrategie kann das OpenSAMM Projekt eingesetzt werden. Das OWASP Software Assurance Maturity Model (SAMM) unterstützt den gesamten Software-Lebenszyklus, einschließlich Entwicklung und Beschaffung, und ist technologie- und prozessunabhängig. Es ist bewusst so konzipiert, dass es entwicklungsfähig und risikoorientiert ist (Deleersnyder, Win, & Glas, 2017, S. 2). SAMM definiert die einzelnen Sicherheitsmaßnahmen anhand der Unternehmensfunktionen und kann daher bereits zu Beginn in der Planungsphase verwendet werden, um den Prozess zur kontinuierlichen Verbesserung der Sicherheit phasenübergreifend aufzusetzen (Tatlı, 2012, S. 805).

Abbildung 2: Sicherheitsmaßnahmen innerhalb der Unternehmensfunktionen (Deleersnyder u. a., 2017, S. 3)

Abbildung 2 veranschaulicht die Unternehmensfunktionen nach SAMM und die jeweiligen Sicherheitsmaßnahmen. Die vier Geschäftsfunktionen (Governance, Construction, Verification und Operations) befinden sich in der höchsten Ebene. In jeder Geschäftsfunktion sollen bestimmte Sicherheitsmaßnahmen umgesetzt werden, um ein bestimmtes Sicherheitsniveau in dieser Geschäftsfunktion zu erreichen. Unter jeder Geschäftsfunktion gibt es drei „Security Practices“. (Tatlı, 2012, S. 805)

Phasen des Secure SDLC

Dieses Kapitel orientiert sich an den Phasen des Secure Development Lifecycle. In den nun folgenden Unterkapiteln werden die einzelnen Phasen erklärt und jeweils die Maßnahmen zur Integration von Sicherheit erläutert.

Phase 1: Anforderungsanalyse (Requirement Analysis)

Der erste Schritt ist die Abbildung eines Planungsprozesses. Während dieser Phase muss ein Unternehmen das Release-Thema, den Inhalt und die Zeitleiste identifizieren. Dazu gehören typischerweise Aktivitäten wie das Sammeln von Endbenutzeranforderungen, das Bestimmen von User Stories, die in das Release aufgenommen werden sollen, und das Planen von Release-Phasen.

Zu den Schlüsselaspekten in dieser Phase gehört das Sicherstellen, dass eine Anwendung den Geschäftsanforderungen entspricht.

Festlegung der Security & Privacy Anforderungen

Die Notwendigkeit, Sicherheit und Datenschutz zu berücksichtigen, ist ein grundlegender Aspekt bei der Entwicklung sicherer Anwendungen und Systeme. Unabhängig von der verwendeten Entwicklungsmethodik müssen die Sicherheitsanforderungen kontinuierlich aktualisiert werden, um Änderungen der erforderlichen Funktionalität und Änderungen der Bedrohungslandschaft Rechnung zu tragen. Der optimale Zeitpunkt für die Definition der Sicherheitsanforderungen liegt natürlich bereits in der ersten Entwurfs- und Planungsphase, da Entwicklungsteams die Sicherheit so integrieren können, dass Störungen minimiert werden. Zu den Faktoren, die die Sicherheitsanforderungen beeinflussen, gehören die gesetzlichen und branchenspezifischen Anforderungen, Standards wie Verschlüsselungsverfahren, die Überprüfung früherer Vorfälle und bekannte Bedrohungen. (Microsoft, 2019b)

Phase 2: Designspezifikation (Design)

Ganz im Gegensatz zum Prinzip „Security by Design“ wird Sicherheit bei der Entwicklung von Anwendungen häufig vernachlässigt. Dabei können durch die Designphase laut Gartner bis zu 50% der Schwachstellen vermieden werden (Stackpole & Oksendahl, 2010, S. 199).

Während der Designphase werden Architektur und Design der Lösung mit Hilfe von Threat Modeling-Techniken überprüft. Für jede der Komponenten sollten Bedrohungsakteure und mögliche Bedrohungsszenarien aufgezählt werden. Beispielsweise könnte ein Bedrohungsszenario ein mögliches Problem der Datenintegrität sein, da es keine Authentifizierungskontrollen auf dem Gerät gibt. Nach der Aufzählung der Bedrohungen können Gegenmaßnahmen bewertet und empfohlen werden.

Zu den Schlüsselaspekten in dieser Phase gehören:

  • – Das Engagement in der Bedrohungsmodellierung und im Sicherheitsdesign
  • – Die Wahl der Programmiersprachen, Frameworks und der Bibliotheken, die im Entwicklungsprozess verwendet werden sollen

Bedrohungsmodellierung (engl. Threat Modeling)

Threat Modeling ist ein Prozess, mit dem potenzielle Bedrohungen aus der Sicht eines hypothetischen Angreifers identifiziert, aufgezählt und priorisiert werden können. Microsoft bietet als Hilfsmittel kostenfrei das Microsoft Threat Modeling Tool an.

Das Threat Modeling Tool ist ein Kernelement im Microsoft Security Development Lifecycle (SDL). Es ermöglicht Softwarearchitekten, potenzielle Sicherheitslücken früh zu identifizieren und zu entschärfen, wenn sie relativ einfach und kostengünstig gelöst werden können. (Microsoft, 2019a)

Security Design Review (SDR)

Ein SDR ist eine detaillierte Analyse der wichtigsten Systeme mit Blick auf die Gesamtsystemsicherheit. Dazu gehört beispielsweise die Einhaltung von Best Practices. Werden zum Beispiel Authentifizierungsverfahren mit Standards wie OAuth umgesetzt und Schutzmechanismen wie 2-Faktor unterstützt und werden technische Schutzmechanismen, wie die OWASP Proactive Controls, von Beginn an in die Applikationsarchitektur integriert, entstehen in der Implementierungsphase weniger Fehler (Stackpole & Oksendahl, 2010, S. 199).

Phase 3: Implementierung (Development)

Diese Phase umfasst die eigentliche Entwicklung und die Erstellung der Anwendung – bei gleichzeitiger Erfüllung aller in der Planungsphase festgelegten Anforderungen.

Zu den Schlüsselaspekten in dieser Phase gehören:

  • – Die Schulung von Entwicklern in sicherer Programmierung
  • – Das Auffinden und Beheben von Fehlern und Sicherheitsschwachstellen im Code während des Schreibens
  • – Die Open-Source-Komponenten auf sichere Weise nutzen

Statische Codeanalyse

Eine wichtige Sicherheitsmaßnahme ist die statische Codeanalyse. Ziel ist es, den Quellcode nach unsicheren Methoden, wie veralteten Hashing-Algorithmen oder ungeprüften Benutzereingaben, zu untersuchen. Unter anderem mit Hilfe von Pattern Matching können Schwachstellen im Quellcode erkannt werden. Es gibt zahlreiche Tools, die statische Codeanalysen auch vollautomatisch im CI/CD-Build-Prozess durchführen. Bereits in der Entwicklungsumgebung (IDE) können statische Codeanalysetools wie .NET Security Code Scan unterstützen.

Code Review

Beim Code-Review wird ein Programmabschnitt nach oder während der Entwicklung von einem (Peer Review) oder mehreren Gutachtern (Mehr-Augen-Prinzip) Korrektur gelesen, um mögliche Fehler, Vereinfachungen oder Testfälle zu finden. Code Reviews sind ein etabliertes und adäquates Mittel der Softwareentwicklung. Ziel dieser Sicherheitsmaßnahme ist die Einhaltung von Secure Coding Guidelines, die beispielsweise durch Secure Coding Schulungen vermittelt werden, zu überprüfen. Von OWASP gibt es als nützliches Hilfsmittel die OWASP Secure Coding Praktiken und das OWASP Code Review Projekt.

Phase 4: Test (Testing)

Während dieser Phase testet das Team den Code anhand der Anforderungen, um sicherzustellen, dass das Produkt diese erfüllt und wie erwartet funktioniert. Die vierte Phase umfasst die Durchführung aller Arten von Leistungs-, Qualitätssicherungs- und Funktionstests sowie nicht-funktionale Tests, wie z. B. UX-Tests. Während das Testen traditionell nach der Entwicklungsphase stattgefunden hat, gehen Unternehmen, die einen Best-Practice-Ansatz verfolgen, zu kontinuierlichen automatisierten Tests im gesamten SDLC über.

Zu den Schlüsselaspekten in dieser Phase gehören:

  • – Das Testen der Anwendung anhand von Sicherheitsrichtlinien mit verschiedenen Testmethoden, darunter statische, dynamische, Software-Zusammensetzungsanalyse und manuelle Penetrationstests
  • – Die Durchführung eines umfassenden Spektrums von Leistungs-, Funktions-, Einheits- und Integrationstests unter Verwendung der gleichen Sprache und Protokolle der zu testenden Systeme
  • – Das Hinzufügen von Sicherheitstests als Teil der abschließenden Qualitätsprüfungen

Security Test Cases

Zu den Security Test Cases gehört das Prüfen von bestimmten Testfällen, die auch ein Angreifer anwenden würde. Hilreiches Material liefert hierzu der OWASP Testing Guide und die OWASP Cheat Sheets. Damit können per Checkliste häufige Angriffe ausprobiert und abgearbeitet werden. Ein Beispielhafter Testfall wäre die Schwachstelle “Error Handling: Disclosure of sensitive informations”. Diese Schwachstelle tritt dann auf, wenn Fehler in der Applikation provoziert werden. Ein weiterer Testfall ist das Ausspähen von eingesetzten Bibliotheken (auch Footprinting/Banner Grabbing genannt) und die darauf aufbauene Untersuchung nach bereits gemeldeten CVE (Common Vulnerabilities and Exposures) Einträgen.

Dynamische Analysen

Mittels Vulnerability Scanning-Tools und Fuzzing-Angriffen kann automatisiert die Applikation von außen angegriffen werden. Schwachstellenscanner wie OWASP ZAP und w3af können die laufende Anwendung angreifen. Diese Scanner verwenden verschiedene Angriffsvektoren und geben sie als Benutzereingaben ein (Fuzzing), die dann von der Anwendung verarbeitet werden. Mithilfe von Scanning Tools wie der OWASP ZAP API oder dem Netsparker können dynamische Analysen automatisiert in den Entwicklungsprozess eingebaut werden.

Phase 5: Bereitstellung (Deployment)

In der Release-Phase setzt ein Team die Software auf Produktionsservern ein. Dazu gehört das Bündeln, Verwalten und Bereitstellen mehrerer komplexer Releases in verschiedenen Umgebungen, einschließlich privater Rechenzentren und Clouds, sowie Public Cloud-Ressourcen.

Zu den Schlüsselaspekten in dieser Phase gehören:

  • – Die Überwachung des Fortschritts eines Releases und seiner Komponenten
  • – Weg von manuellen Freigabeprozessen hin zu einem automatisierten Prozess, bei dem die Freigabe von Software auf einer Geschäftsentscheidung basiert
  • – Das Erstellen von Sicherheitstests als Teil der abschließenden Qualitätsprüfungen

Final Security Review (FSR)

Da sich das Produkt dem Fertigstellungszeitpunkt nähert, muss eine wichtige Frage beantwortet werden: Ist das Produkt aus Sicherheits- und Datenschutzsicht einsatzbereit? Ziel des Final Security Review (FSR) ist es, diese Frage zu beantworten. Das FSR wird vom zentralen Sicherheitsteam durchgeführt und ist ein kritischer Teil des Secure SDLC. Ein hilfreiches Mittel ist ein unabhängiger Penetration Test, welcher von einem externen Dienstleister ausgeführt werden kann.

Application Security & Monitoring Response Plan

Bestandteil dieser Sicherheitsmaßnahme ist die Erstellung eines Incident Response Plan (IRP) und die Implementierung eines Incident Response and Management System (IRMS). Ein IRP ist eine Reihe von Anweisungen, die das IT-Team bei der Erkennung, Reaktion auf und Wiederherstellung von Sicherheitsvorfällen unterstützen. Die Informationen des Unternehmens, und damit auch seine Reputation, können durch eine Infrastruktur eingedämmt werden, für welche eine Reaktion auf Störungen entwickelt und implementiert wird. Dies kann zum Beispiel durch Pläne, definierte Rollen, Training, Kommunikation erfolgen, um einen Angriff schnell zu entdecken und den Schaden effektiv einzudämmen. So kann die Anwesenheit des Angreifers beseitigt und die Integrität des Netzwerks und der Systeme wiederhergestellt werden. Angegliedert an das Risikomanagement kann ein Incident Response and Management System (IRMS) implementiert werden.

Phase 6: Betrieb und Wartung (Operations and Maintenance)

Während dieser Phase befindet sich ein Produkt in der Produktion und wird von den Kunden genutzt. Die Überwachung der Leistung und der Benutzererfahrung der Anwendung ist entscheidend für die kontinuierliche Verbesserung. Ein Unternehmen stellt sicher, dass Betriebsdaten Entwicklern und Testern zur Verfügung gestellt werden.

Zu den Schlüsselaspekten in dieser Phase gehören:

  • – Die fortlaufende Prüfung und Überwachung von Anwendungen in der Produktion.
  • – Die Neubewertung von Anwendungen hinsichtlich Leistung, Sicherheit und Benutzerfreundlichkeit, sobald diese aktualisiert oder geändert werden.

Incident Forensics

Incident Forensics beinhaltet unter anderem, die Vorgehensweise eines Angreifers Schritt für Schritt zurückzuverfolgen und die forensische Analyse möglicher Sicherheitsverletzungen. Im Falle eines Cyberangriffes geht es darum, Beweismittel gerichtsverwertbar zu sichern und aufzubereiten. Im Ernstfall helfen nicht kompromittierte Logfiles, um den Angreifer aufzugreifen.

Security Monitoring

Beim Security Monitoring geht es darum, die potentiellen Bedrohungen zu erkennen, bevor es zu bedrohlichen Einbrüchen kommt. Dazu werden Ereignisdaten aus unterschiedlichen operativen Ebenen gesammelt und in Echtzeit analysiert. Auf Applikationsebene kann der OWASP AppSensor integriert werden. Dieser Verteidigungsmechanismus wird als Runtime Application Self-Protection (RASP) bezeichnet. RASP ist eine Sicherheitssoftware, die mit in die Anwendung integriert wird oder an die Umgebung geknüpft ist. So können Angriffe auf Anwendungsebene erkannt und direkt blockiert werden. Da RASP auf Anwendungsebene läuft, hat zum Beispiel AppSensor Einblick über die Vorgänge innerhalb der Anwendung. Das Anwendungsverhalten kann genau analysiert werden. Somit wird ermöglicht, dass in Echtzeit reagiert werden kann.

.

Quellen

Deleersnyder, S., Win, B. D., & Glas, B. (2017). SOFTWARE ASSURANCE MATURITY MODEL. A GUIDE TO BUILDING SECURITY INTO SOFTWARE DEVELOPMENT, OWASP Foundation. Abgerufen von https://github.com/OWASP/samm/raw/master/Supporting Resources/v1.5/Final/SAMM_How_To_V1-5_FINAL.pdf

JAGLI, D., & Yeddu, S. (2017). CloudSDLC: Cloud Software Development Life Cycle. International Journal of Computer Applications, 168, 6–10. https://doi.org/10.5120/ijca2017914468

Kesäniemi, A. (2009). Code Analysis. Automatic vs Manual, OWASP Foundation. Abgerufen von https://www.owasp.org/images/5/53/Ari_kesaniemi_nixu_manual-vs-automatic-analysis.pdf

Lobačevski, J., & Arteau, P. (2019). Security Code Scan. Security static code analyzers for .NET. Abgerufen von https://security-codescan.github.io

Microsoft. (2019a). Microsoft Threat Modeling Tool. Abgerufen von https://docs.microsoft.com/de-de/azure/security/azure-security-threat-modeling-tool

Microsoft. (2019b). What are the Microsoft SDL practices? Abgerufen von https://www.microsoft.com/en-us/securityengineering/sdl/practices

Stackpole, B., & Oksendahl, E. (2010). Security Strategy: From Requirements to Reality. CRC Press. Abgerufen von https://books.google.de/books?id=ziGJGMhryA0C

Subramanian, S., & M., B. S. (2017). Security Assurance in the SDLC for the Internet of Things. Secure SDLC Steps to Address Common Coding Flaws and Software Vulnerabilities. Abgerufen von https://www.isaca.org/Journal/archives/2017/Volume-3/Pages/security-assurance-in-the-sdlc-for-the-internet-of-things.aspx

Tatlı, E. İ. (2012). OWASP Anleitungen und Tools für Secure SDLC. Datenschutz und Datensicherheit – DuD, 36(11), 805–809. https://doi.org/10.1007/s11623-012-0276-2

Javan Rasokat

Javan Rasokat

Javan works as an IT security consultant specializing in application-level pentesting. He lectures Secure Coding at the DHBW Karlsruhe and studies M.Sc. IT Security Management at the Aalen University.

Show all posts by Javan Rasokat

Leave a Comment