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.
- Design & Concept
- Software Development
- Quality Assurance
- Operation and Maintenance
- 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:
| Phase | Bezeichnung 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ätssicherung | Application Security Controls (semi-auto) |
| Betrieb und Wartung | Application 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?
- Minimieren der Angriffsflächen
- Sichere Standardwerte oder -einstellungen festlegen
- Prinzip der geringsten Nutzerrechte bzw. Privilegs
- Prinzip der Tiefenverteidigung (mehrere Kontrollen aufeinander)
- Sicheres Versagen der Anwendung (abgesicherter Ausfall)
- Kein blindes Vertrauen in IT-Komponenten
- Trennen von Aufgaben und Berechtigungen
- Vermeiden von Unklarheiten oder Unübersichtlichkeit
- Anwendungssicherheit sollte einfach gehalten werden
- 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
