Secure Software Development – Die ISO 27034 im Überblick – 2 von 7 (Serie)

Der Lebenszyklus der Anwendungssicherheit oder „Applikations-Entwicklungs-Lebenszyklus“ (AEL)

Nachdem wir uns im ersten Teil des Blogs einen Überblick über Anwendungssicherheit verschafft haben, gehen wir im zweiten Teil auf die Spezialitäten des Lebenszyklus einer Anwendung ein. Der Vorteil ist, dass diese Vorgehensweise generisch und unabhängig von der Entwicklungsmethode ist. Generisch bedeutet in diesem Fall ein geschlossener Kreislauf an Abläufen und Prozessen im Gegensatz zum klassichen Input/Output-Prozessmodell. Durch den ganzheitlichen Ansatz können auch moderne Entwicklungsmethoden wie Agiles Projektmanagement oder Kanban unterstützt werden.     

Dadurch können auch moderne Methoden wie Agile Entwicklung oder Hybrid-Technologien berücksichtigt werden. Welche Inhalte haben die einzelnen Phasen in einem „Application Security LifeCycle“?    

Was ist der „Application Security Lifecycle“?

Der „Application Security Lifecycle“ besteht aus fünf Phasen, mit einzelnen Prozessen (Aktivitäten) und zehn Meilensteinen. Die Meilensteine stellen die WBS „Work Breakdown Structure“ des Projektablaufs in der Anwendungsentwicklung dar. Hier zeigt sich bereits im Vorfeld der Nutzen einer sauberen Planung und Architektur, denn Fehler in den Anfangsphasen, werden in der späteren Qualitätssicherung ein Vielfaches an Aufwand bedeuten. 

  1. Design & Concept
  2. Software Development
  3. Quality Assurance
  4. Operation and Maintenance
  5. End of Life 

Die ISO/IEC 27034 wendet hier einen risikobasierten Ansatz an.  

Der Leitfaden und die optional unterstützenden Werkzeuge (tools) ergänzen die Bestimmung der Risikostufen und die Bestimmung einer geeigneten Kontrolle (audit-based) während des Lebenszyklus. 

Ziel ist hier die Anwendungssicherheit sicherzustellen.

Die einzelnen Werkzeuge für die Phasen lauten:

PhaseBezeichnung der Werkzeuge
Design und
Konzept
Application Risk Assessment (semi-auto)
Application Security Controls (semi-auto)
Software-Entwicklung Application Security Architecture (semi-auto)
Quell-Code Analyse (automatisiert)
QualitätssicherungApplication Security Controls (semi-auto)
Betrieb und WartungApplication Security Controls (semi-auto)
Rückbau Application Security Controls (semi-auto)

Es stehen insgesamt ca. 140 Controls im gesamten Lebenszyklus zur Verfügung. Die Controls sind für das Projektmanagement, die Archtekten, die Entwickler, die Tester und die Auditoren gleichermaßen anwendbar. Die einzelnen Prozesse und Aktivitäten stellen sich wie folgt dar:

Es ist zu beachten, dass einige Informationssicherheitsaktivitäten regelmäßig wiederkehrend oder bei wesentlichen Änderungen an der Anwendung erneut durchgeführt werden sollen. 

Dazu zählen:

  • Durchführen der Risikobewertung;
    • Vorgaben zu dem sicheren Erstellen von Quellcode
    • Durchführen der Schwachstellenbewertung

Welche Werkzeuge werden i.d.R. eingesetzt?

Das „Application Risk Assessment“, eine Risikobewertung der Anwendung, dient zur Ermittlung der Risikostufe für die Anwendung, um davon abgeleitet, die relevanten Sicherheitskontrollen („controls“) zu bestimmen.

Die „Application Architecture Security Controls“, d.h. die Sicherheitskontrollen der Anwendungsarchitektur. Hier wird die Mindestanzahl an Sicherheitskontrollen definiert, die bei der Konzeption und Entwicklung der Anwendung erfüllt werden müssen.

Die ASL-Sicherheitskontrollen als eine Zusammenfassung der definierten Mindestanzahl an Sicherheitskontrollen in Abhängigkeit von der Risikostufe der Anwendung gegeben.

Die „Source Code Analysis“, auch als externer Service in Form von Penetrationstests oder Schwachstellenanalysebezeichnet. Dieses „Tool“ bewertet den zur Verfügung gestellten Quellcode im Hinblick auf allgemeine Sicherheitsschwachstellen und die damit verbundene Verwundbarkeit der Anwendung.

Die Leitfäden „Application Security Lifecycle“ und „Secure Coding Requirements“ enthalten die Hinweise auf Nutzung, Anforderungen und Vermeidung allgemeiner Sicherheitsprobleme bei der Entwicklung von Anwendungen.

Welche vordefinierten Grundsätze oder Prinzipien der sicheren Softwareentwicklung existieren? 

  1. Minimieren der Angriffsflächen
  2. Sichere Standardwerte oder -einstellungen festlegen
  3. Prinzip der geringsten Nutzerrechte bzw. Privilegs
  4. Prinzip der Tiefenverteidigung (mehrere Kontrollen aufeinander)
  5. Sicheres Versagen der Anwendung (abgesicherter Ausfall)
  6. Kein blindes Vertrauen in IT-Komponenten
  7. Trennen von Aufgaben und Berechtigungen
  8. Vermeiden von Unklarheiten oder Unübersichtlichkeit 
  9. Anwendungssicherheit sollte einfach gehalten werden
  10. Sicherheitsprobleme ordnungsgemäß beheben 

Die Liste erhebt keinen Anspruch auf Vollständigkeit und dient nur initial zum Verständnis der Grundsätze und Prinzipien.

Diese sollten, wie in Teil 1 referenziert, zwischen den Verantwortlichen aus den verschiedenen Einheiten (Projekt, Anwendung, Entwickler, Geschäftsbereich) in der „Design & Concept“ – Phase abgestimmt werden. 

Wozu dient die Risikobewertung der Anwendung?

Die Bestimmung der Anwendungsrisikostufe (z.B. niedrig – mittel – hoch) ist für alle Anwendungen obligatorisch. Die ermittelte Risikostufe definiert die erforderlichen Mindestanzahl an Sicherheitskontrollen für die Anwendung. Der Projektleiter der Anwendungsentwicklung ist für das Durchführen der Risikobewertung verantwortlich. Der Verantwortliche für die Anwendung (ggf. der spätere Betriebsverantwortliche) soll die Risikobewertung in der Betriebsphase erneut durchführen, sofern sich wesentliche Änderungen ergeben haben.

Die Risikobewertung muss mindestens die folgenden Sicherheitsaspekte berücksichtigen:

  • Zugänglichkeit der Anwendung auf Netzwerkebene;
    • Beabsichtigte Benutzergruppe;
    • Verfahren zur Benutzerauthentifizierung;
    • Kritische Informationen;
    • Komplexität der Anwendung;
    • Geschäftskritikalität;

Das unterstützende Tool „Application Risk Assessment“ sollte zur Ermittlung der Risikostufe verwendet werden. Die Risikobewertung soll vom Auftraggeber abgezeichnet werden.

Im Falle eines „hohen“ oder „sehr hohen“ Risikoniveaus sollen die entsprechenden Beauftragten (Datenschutz, Informationssicherheit, Compliance) die Risikobewertung überprüfen und abzeichnen.

Welche Sicherheitsanforderungen bestehen darüber hinaus?

Für alle Risikostufen soll der Projektleiter sicherstellen, dass die Sicherheitsanforderungen der Komplexität der Anwendung und der ermittelten Risikostufe angemessen sind. Dazu sollte er mit den „Sicherheitsarchitekten“ bei der Definition und Dokumentation der Anforderungen zusammenarbeiteten. 

Die Sicherheitsanforderungen müssen mindestens die folgenden Sicherheitsbereiche abdecken, um die Hauptrisikender Anwendungssicherheit zu vermeiden:

  • Sicherheitsarchitektur;
    • Authentifizierung;
    • Sitzungsverwaltung;
    • Zugriffskontrolle;
    • Eingabevalidierung;
    • Ausgangskodierung;
    • Kryptographie;
    • Fehlerbehandlung und Protokollierung;
    • Datensicherheit;
    • Kommunikationssicherheit;
    • HTTP-Sicherheit;
    • Sicherheitskonfiguration;
    • Vermeiden von bösartigem Code;
    • Interne Sicherheit.

Der Projektleiter soll die Vorgaben des Tools „Application Architecture Security“ verwenden, um entsprechend der Risikostufe die Sicherheitskontrollen der Anwendungsarchitektur abzuleiten. Weitere Sicherheitsanforderungen können von den Anspruchsgruppen (Geschäfts-/Fachbereich, Kunde, Auftraggeber, Gesetzgeber) definiert werden. Die abgeleiteten Sicherheitsanforderungen sollen von den Verantwortlichen freigegeben werden. 

Wie geht es dazu weiter?

Im nächsten Blog werden wir uns der Phase 2 Software-Entwicklung widmen. Dabei spielt die Analyse des Quell-Codes, der Leitfaden der sicheren Anwendungsentwicklung und die ausgelagerte Entwicklung eine Rolle. 

Dr. Gerd Grimberger, 15. März 2023
Rechtsinformatiker

Weitere Beiträge

Markenanmeldung einfach erklärt

Sie haben ein Produkt und jeder soll wissen, dass es zu Ihrer Firma gehört. Um einen Wiedererkennungswert zu schaffen, denken Sie sich einen passenden Namen für das Produkt aus. Sie betreiben ein kostenintensives Marketing und investieren in die Qualität des

Mehr lesen »

AÜG für die IT 2024 Teil II

III. Abgrenzbares/ dem Auftragnehmer als eigene Leistung zurechenbarer Auftrag Wie sollen die Einzelverträge /SOWs/ Aufträge formuliert sein? 1.) Abgrenzbares Werk Nach der Rechtsprechung soll es entscheidend sein, ob ein abgrenzbares, dem Auftragnehmer als eigene Leistung zurechenbares Werk, vertraglich vereinbart ist

Mehr lesen »

Markenschutzfähigkeit bejaht für #darferdas

Die Entscheidung des BGH ist bereits vom 30.01.2020 (Az. I ZB 61/17 (pdf)). Sie zeigt aber, wie schwierig es sein kann, eine Marke anzumelden, die nicht aus reinen Phantasie-Wörtern oder Begriffen besteht und vielleicht auch nicht besonders originell ist. Angemeldet wurde die Marke

Mehr lesen »
Nach oben scrollen