Sicherheitsanforderungen

• die Liste ist bewusst kurz gehalten, damit man sie in Agile/Scrum im Sinne eines Ready und Done-Kriterium nutzen kann. Wenn ich bei einem Backlogitem nicht sofort erkennen kann, wie ich diese Anforderungen umsetzen kann, dann ist mindestens eine Diskussion im Refinement angesagt.
• es gibt immer mal Gründe anders zu entscheiden, sowohl bei den dos als auch den don´ts. Vielleicht hat man aus historischen Gründen eine eigene Benutzerverwaltung. Benutzerverwaltung ist meiner Meinung nach heute Commodity. Ist gar keine geeignete verfügbar, installiert man halt z.B. ein Active Directory, aber die Anforderungen an eine Benutzerverwaltung allen Anwendungen aufzuzählen macht keinen Sinn. Für so spezielle Anwendungen darf man woanders suchen.
• je nach Umfeld kann es weitere Anforderungen mit Bezug zu Sicherheit geben. Z.B. wird man beim Einsatz von Email auch auf DomainKeys Identified Mail (DKIM) achten. Das muss man dann als funktionale Anforderung aufnehmen. Und auch wenn viele der Anforderungen sich auch aus dem Datenschutz (insbesondere Artikel 32 DSGVO) ableiten – um Datenschutz richtig umzusetzen muss man auch noch u.a. über Aufbewahrungsdauern und Löschen, Auskunft, Einwilligungen oder Pseudonyme nachdenken – das geht ganz tief in die Funktionen der Anwendung.
• das gleiche gilt auch für die im Datenschutz oder Information Security Management System (ISMS) geforderte Verfügbarkeit. Um Verfügbarkeit in verteilten Systemen sicherzustellen – ich unterrichte Verteilte Systeme an der Dualen Hochschule – muss man sich mit dem CAP-Theorem befassen und seine Anwendung und Datenablage geeignet schneiden – das kann man nicht einfach nachrüsten.
• in konkreten Kundenprojekten gibt es zu jeder Anforderungen Details – die hängen meistens vom konkret implementierten Information Security Management System (ISMS) ab. Viele der Anforderungen kann man auch aus dem IT-Grundschutz ableiten – nur leider oft über mehrere Bausteine verteilt. Grundschutzkonform ist diese Liste von Sicherheitsanforderungen übrigens auch, sie adressiert APP.6 A2/APP.7 A4 sowie wesentliche Teile von APP.6 A3/APP.7 A3. Anscheinend ist auch dem Bundesamt für Sicherheit in der Informationstechnik (BSI) bewusst, dass alle Bausteine zusammen von keinem Entwickler gelesen und konsistent interpretiert werden.
• die Umsetzung vieler Anforderungen gelingt am besten, wenn es dafür eine Musterlösung oder Reuse-Komponente gibt. Das ist insbesondere auch bei don´ts wichtig – nicht speziell in Sicherheit geschulte Entwickler werden an Verschlüsselung oder XML Validierung scheitern – mehrfach in der Praxis erlebt.
• gibt es Gründe abzuweichen, dann gehören die Gründe und die alternative Lösung dokumentiert, idealerweise spricht man mit einem Sicherheitsexperten und macht Bedrohungsmodellierung aka Threat-Modeling. Und natürlich setzt ernsthafte Bedrohungsmodellierung voraus, dass man Sicherheitsanforderungen definiert hat. Letztendlich kann man aus nicht-erfüllten Anforderungen sofort auf die Risken schließen.

Authentifizierung, Berechtigungen, Auditlogs (Authentication, Authorisation, Auditing)

• Verwende Single-Sign-On-Mechanismen zur Authentifizierung von Benutzern (do)
• Verwende X.509 Zertifikate oder Kerberos zur Authentifizierung von Systemen oder Services (Server und Client) (do)
• Implementiere keinen eigenen Authentifizierungsmechanismus (don´t)
• Verwende ein für den Prozess (das Verfahren) geeignetes Berechtigungskonzept (do)
• Verwende ein Audit/Protokollierungs-Konzept passend zum Prozess (dem Verfahren) und passend zu Compliance-Anforderungen (insbesondere zu Protokollierungsanforderungen im Datenschutz) (do)

Verschlüsselung (Encryption)

• Verwende nur https, TLS, oder (notfalls) ssh um Daten zu übertragen (do)
• Verwende (transparente) Verschlüsselung für gespeicherte Daten (z.B. Festplattenverschlüsselung) (do)
• Implementiere keine Verschlüsselungsverfahren oder digitale Signatur selbst (don´t)
• Implementiere keine Ende-zu-Ende-Verschlüsselung (don´t)

Eingabevalidierung und Ausgabeaufbereitung (Input Validation and Output Encoding)

• Implementiere sinnvolle Eingabevalidierungen für den Prozess (das Verfahren) – Eingabevalidierungen für den Prozess sind fast immer schärfer als Validierungen nur für Sicherheit und verbessern damit auch die Usability (do)
• Vermeide XML und andere Containerformate (don´t)
• Verwende geeignete Ausgabeaufbereitungsmethoden (do)
• Verwende ein geeignetes Sessionkonzept (do). Implementiere kein eigenes Sessionmanagement (don´t)

Sichere Konfiguration und Ausnahmebehandlung (Secure Configuration and Exception Handling)

• Clean Code, DRY, YAGNI, KISS (do)
• automatische Updates Up- und Downstream (do)

Testautomatisierung (Test Automation)

• alle Sicherheitsanforderungen (außer den don´ts) können und sollen automatisch getestet werden (do)