LU03f - Sicherheitsanforderungen

Merke! Eine Applikation kann nur so sicher sein, wie das Umfeld, in dem sie betrieben wird. Dies gilt für die Infrastruktur genauso, wie für die Architektur und die Implementierung.

Die Anforderungen an die Sicherheit einer Applikation (Programm) sollen bereits zu Beginn der Entwicklung ermittelt und abgestimmt werden. Eine nachträgliche Implementierung von Sicherheitsmassnahmen ist bedeutend teurer und bietet im Allgemeinen weniger Schutz als Sicherheit, die von Beginn an in den Systementwicklungsprozess oder in den Auswahlprozess für ein Produkt integriert wurde.

Abbildung: Sicherheitsanforderungen können nur greifen, wenn diese im gesamten SW-Entwicklungszyklus berücksichtigt werden

Sicherheit sollte daher integrierter Bestandteil des gesamten Lebenszyklus einer Applikation (SDLC) bzw. Produktes sein. Eine Applikation (Programm) besitzt ein Umfeld, in welchem sie betrieben wird. Ein sich ereignender Systemprozess (Geschäftsprozess) stösst eine Applikation zur Bearbeitung an (Anfrage). Diese erfüllt die angeforderte Dienstleistung und gibt ein erarbeitetes und erwartetes Ergebnis (Resultat) zurück. Dabei greifen die Funktionen einer Applikation über ein logisches und physisches Datenmodell auf die Daten zu. In diesem Verfahren gibt es verschiedene Bereiche, die kontrolliert ablaufen müssen. Nebst der Qualität der Applikationsfunktionen (korrekte Abläufe, Berechnungen, etc.) sind die Sicherheitsbelangen auf allen Ebenen.

Die folgenden Prinzipien sollten in jedem Projekt von Anfang an berücksichtigt werden:

Security by Design: Sicherheit ist kein nachträgliches Feature, sondern muss in Architektur und Design integriert sein.
Least Privilege: Jeder Code-Abschnitt, jede Komponente, jeder Benutzer bekommt nur so viel Rechte wie absolut nötig.
Fail Secure: Im Fehlerfall muss das System in einen sicheren Zustand übergehen.
Defense in Depth: Mehrstufige Sicherheitsmaßnahmen bieten auch dann Schutz, wenn eine Ebene versagt.
Minimierung der Angriffsfläche: Weniger exponierte Funktionen bedeuten weniger potenzielle Angriffsvektoren.

Unterstützung starker Authentifizierungsmechanismen (z. B. OAuth2, MFA)
Rollenkonzepte zur feingranularen Rechtevergabe
Session-Management mit begrenzter Lebensdauer

Verschlüsselung sensibler Daten (ruhend und in Übertragung)
Einsatz von TLS 1.2 oder höher
Keine sensiblen Daten im Klartext loggen oder speichern

Validierung aller Benutzereingaben (Client- & Server-seitig)
Schutz gegen SQL-Injection, Cross-Site Scripting (XSS), CSRF etc.
Whitelisting statt Blacklisting

Fehlermeldungen dürfen keine internen Informationen preisgeben
Logging sicherheitsrelevanter Ereignisse mit Integritätsschutz
Protokollrotation und -archivierung

Nur verifizierte, regelmäßig gepflegte Bibliotheken verwenden
Schwachstellenprüfung mit Tools wie OWASP Dependency-Check
Automatisiertes Patch- und Update-Management

Alle Entwickler müssen regelmäßig in Secure Coding geschult werden
Awareness für aktuelle Bedrohungen (z. B. OWASP Top 10)

Statische und dynamische Codeanalyse verpflichtend
Security Unit-Tests und Penetrationstests
Regelmäßige Code-Reviews mit Fokus auf Sicherheitsaspekte

Integration von Sicherheit in die CI/CD-Pipeline
Automatisierte Schwachstellenprüfungen bei jedem Build
Secrets-Management (z. B. HashiCorp Vault)

Sicherheitsanforderungen müssen dokumentiert und versioniert sein
Architekturentscheidungen im Hinblick auf Sicherheit müssen nachvollziehbar sein
Änderungsmanagement mit Sicherheitsbewertung

Einhaltung relevanter Standards (z. B. ISO 27001, BSI-Grundschutz, GDPR/DSGVO)
Umsetzung branchenspezifischer Vorgaben (z. B. KRITIS, PCI-DSS)
Auditierbarkeit und Nachweisführung über implementierte Sicherheitsmaßnahmen

Zusammenfassend kann gesagt werden, dass Sicherheitsanforderungen kein lästiger Ballast, sondern ein integraler Bestandteil professioneller Softwareentwicklung, sind. Wer hier spart, zahlt später – sei es mit Datenschutzpannen, Imageschäden oder rechtlichen Konsequenzen.