Das Thema IT-Sicherheit ist äußerst komplex. Außerdem ist Sicherheit kein Feature, das am Ende eines Projektes – egal ob ein Softwareentwicklungs- oder ein Infrastrukturprojekt – „drangeklebt“ werden kann. Sicherheit ist eine Eigenschaft eines Systems und sollte daher über die gesamte Dauer eines Projektes berücksichtigt werden: Von der initialen Design- und Konzeptphase über die Entwicklungsphase bis zum Produktivbetrieb und darüber hinaus.

Das Feld des Security Engineering beschäftigt sich damit, wie Sicherheit bei der Entwicklung von Software und Systemen gebührend berücksichtigt werden kann. Sogenannte Secure Development Lifecycle-Modelle geben dabei einen Rahmen vor, welche Aktivitäten in welcher Projektphase üblicherweise durchgeführt werden sollten, um ein gutes Sicherheitsniveau für das fertige System zu erreichen.

In diesem Blogpost gehen wir darauf ein, welche Aktivitäten in der jeweiligen Phase üblicherweise durchgeführt werden sollten. Wir streben hierbei keine Vollständigkeit an, sondern möchten nur einen groben Überblick geben. Danach listen wir verschiedene Secure Development Lifecycle-Modelle auf.

Wie stellt man Sicherheit in verschiedenen Phasen eines Projekts sicher?

Planungs- und Anforderungsphase

Während der Planungs- und Anforderungsphase sollten vor allem Sicherheitsanforderungen ermittelt werden. Diesen Prozess nennt man auch Security Requirements Elicitation. Hierzu gehören Fragen wie:

  • Wie hoch ist der Schutzbedarf des zu entwickelnden Systems bzw. der zu entwickelnden Anwendung?
  • Welche Daten soll die Anwendung oder das System speichern?
  • Mit welchen anderen Systemen wird die Anwendung oder das System interagieren?
  • Welche Vertrauensbeziehungen bestehen mit anderen Anwendungen und Systemen?
  • Wer soll das System oder die Anwendung nutzen?
  • Welche Fähigkeiten soll das System oder die Anwendung haben, d.h. was sind seine Use Cases?
  • Was sollen Nutzer oder Angreifer nicht können (Angriffs-, Bedrohungs- und Risikoszenariendefinition)?
  • Welche Bedrohungen und Risiken ergeben sich normalerweise bei Entwicklung oder Betrieb eines solchen Systems oder einer solchen Anwendung?

Aus diesen und vielen weiteren detaillierteren Fragen werden system- bzw. anwendungsspezifische Sicherheitsanforderungen abgeleitet. Auch werden Sicherheitsanforderungen, die sich aus unternehmensweiten Richtlinien ergeben, mit in die projektbezogenen Anforderungen übernommen.

Die Sicherheitsanforderungskataloge werden oft als Listen mit KANN/SOLL/MUSS-Einträgen definiert, z.B. wie folgt:

ID Anforderung Verbindlichkeit
1 Nur berechtigte Nutzer dürfen auf ihnen freigegebene Daten zugreifen MUSS
2 Die Anwendung muss 2-Faktor-Authentifizierung unterstützen SOLL

Wichtig ist, dass die Definition von Sicherheitsanforderungen nicht vergessen oder vernachlässigt wird, denn sie ist die Basis für alle späteren Bemühungen.

Design- und Architekturphase

Die in der vorherigen Phase definierten Sicherheitsanforderungen werden hier in konkrete Pläne umgesetzt: Wie sollen diese erreicht werden? Wie werden sie in Design und Architektur berücksichtigt? Welche technischen Lösungen und Konzepte sollen den Unterbau des zu entwickelnden Systems bzw. Anwendung darstellen?

Auch werden generelle Prinzipien, die durch die Implementierer zu berücksichtigen sind, festgelegt. Hierzu gehören Ansätze wie z.B. folgende:

  • Principle of Least Privilege
  • Annotation-based Security
  • Kerckhoff’sches Prinzip
  • Annotation-based Security für Autorisierung
  • Single Point of Control-Pattern
  • u.v.m.

In dieser Phase werden somit die konkreten Pläne, wie die Sicherheitsanforderungen umgesetzt werden, festgelegt und diese in der gesamten System- bzw. Anwendungsarchitektur berücksichtigt.

Implementierungsphase

In der Implementierungsphase werden die Vorgaben aus der Design- und Architekturphase in Bezug auf Sicherheit umgesetzt. Zusätzlich ist auch sehr wichtig, dass Praktiken der sicheren Software- oder Systementwicklung berücksichtigt werden. Hierzu gehören z.B. folgende:

Softwareentwicklung Systementwicklung
– Eingabedatenvalidierung und Säuberung (Input Data Validation and Sanitization) – Zugriffsrechte nach Principle of Least Privilege und Need to Know implementieren
– Output Encoding – Configuration Management einführen
– Prepared Statements – Patch-Management-Prozesse einführen
– Kontinuierliche Überprüfung des Quelltexts durch Tools wie SAST – u.v.m.
– u.v.m.

Testphase

Teil einer jeden Testphase sollten auch Sicherheitstests sein. Hier sind insbesondere Penetrationstests zu nennen. Bei diesen wird das entwickelte System bzw. die Anwendung umfassend auf Sicherheitslücken überprüft. NSIDE ATTACK LOGIC ist auf Penetrationstests spezialisiert – kontaktieren Sie uns gerne!

Laufender Betrieb (Post-Launch-Phase)

Auch nach der Inbetriebnahme eines/einer Systems/Anwendung ist Sicherheit nicht zu vernachlässigen: Aktualisierungen müssen zeitnah (bei entwickelten Anwendungen) zur Verfügung gestellt oder (bei entwickelten Systemen) eingespielt, Änderungen auf Sicherheitsprobleme überprüft, Change Management betrieben werden und vieles mehr. Heutzutage ist es auch üblich, Systeme und Anwendungen nach dem ersten Launch beständig weiterzuentwickeln. Die bereits beschriebenen Tätigkeiten müssen bei jeder Iteration ebenfalls berücksichtigt werden.

Wie stellt man Sicherheit in agilen Prozessen her?

Bei agilen Prozessen verhält es sich ähnlich, nur auf anderer zeitlicher Skala: Auch bei agilen Entwicklungen sollte eine Grundarchitektur bestehen, die Sicherheitsaspekte gebührend berücksichtigt. Ebenfalls sollten projektweite Sicherheitsanforderungen bestehen. Zusätzlich sollten aber pro Sprint bzw. pro neuem Feature Set (Epic oder User Story) die Sicherheitsanforderungen definiert werden und die oben beschriebenen Prozesse für die Iterationen bzw. für die Stories und Epics durchlaufen werden.

Bei agilen Prozessen ergeben sich außerdem besondere Anforderungen an Sicherheitstests. Diese hatten wir bereits in einem vergangenen Artikel (LINK HIER EINFÜGEN) beschrieben.

Welche Secure Development Lifecycle Models gibt es?

In den obigen Abschnitten haben wir nur einen ganz groben Überblick über einige Tätigkeiten gegeben, die im Rahmen des Security Engineerings anfallen. Es gibt verschiedene Modelle, die weitaus detaillierter sind und sogar konkrete Prozesse und Methoden vorschlagen. Hierzu gehören unter anderem:

  • Microsoft SDL – Microsoft Security Development Lifecycle
  • OpenSAMM – von der OWASP ins Leben gerufenes Modell und Aktivitätensammlung; OpenSAMM steht für Open Software Assurance Maturity Model
  • BSIMM – Building Security In Maturity Model

Abschluss und Literaturtipp

Wie man Sicherheit in Entwicklungsprozesse, egal ob von Software oder Systemen, integrieren kann, ist keine triviale Fragestellung. Wir hoffen, dass wir mit diesem Post einen sehr groben Überblick geben konnten. Abgesehen von den genannten Tätigkeiten gibt es in jeder Phase noch viele weitere, die üblicherweise durchgeführt werden sollten. Anschließend sei noch das Buch „Security Engineering“ von Ross Anderson empfohlen – es gibt einen guten Einblick in viele technische Einzelmaßnahmen, d.h. Themen, mit denen man sich in der Implementierungsphase beschäftigen sollte.

Haben Sie noch Fragen oder wünschen Sie Unterstützung? Wir freuen uns auf Ihre Nachricht!