B-Sec 1: Über den erfolgreichen Umgang mit Compliance relevanten NFRs in Scaled Agile Environments

Wir werden sie einfach nicht los, gewisse nicht-funktionalen Anforderungen (NFR – bzw. nach IREB: Qualitätsanforderungen). Ob in Wasserfall-Umgebungen oder in der agilen Entwicklung – gewisse NFR sind übergreifend, integral und ganzheitlich zu erfüllen. Wir haben uns mit diesen Anforderungen zu beschäftigen. Genau das will diese Blog Serie. Für Neugierige: die Norm ISO/IEC 25010:2011 «Systems and Software Quality Requirements and Evaluation (SQuaRE)» bietet eine gute Klassifizierung an, welche Anforderungen als Qualitätsanforderungen angesehen werden.

Unter diese Anforderungen fallen zum Beispiel Security-Anforderungen (Norm ISO/IEC 27001), EU Data Protection Rules (GDPR), domänen- und firmenspezifische Compliancy-Anforderungen (SOX, Sarbanes Oxley Act) aber auch weitere industriespezifische Compliance- und Regulation-Frameworks von Organisationen wie FINMA, FDA, die EN50155 (Bahn Norm), aber auch allgemeine Anforderungen an Performance, Customer Centricity oder Corporate Design.

Das besondere an vielen dieser NFR (Qualitätsanforderungen) ist,

• Sie müssen vollständig sein, also 100% erfüllt sein, um compliant zu sein. Ein Erfüllungsgrad von 95% genügt nicht.
• Viele dieser Anforderungen verlangen, dass die Erfüllung (Test und Verifizierung) nachvollziehbar nachgewiesen wird im Rahmen eines Audits, eines Zertifikats oder eines offiziellen Regulators.
• für das Erfüllen einer einzigen dieser (grobgranularen) NFR ist typisch ein ganzes Set an abgeleiteten Detailanforderungen zu erfüllen. Diese beziehen sich wiederum auf verschiedene Aspekte wie organisatorische Prozessschritte, (Software) Architekturbausteine, Entwicklungsrichtlinien oder -aktivitäten.

Als Beispiele in dieser Blog Serie beziehe ich mich auf NR aus den Bereichen Cyber-Security und GDPR, alleine weil diese Themen gerade in aller Munde sind. Das Konzept ist jedoch identisch anwendbar für sämtliche zu auditierenden Anforderungen der oben gennannten Bereiche.

So steht etwa in den offiziellen GDPR Regulatorien[4] sinngemäss das NFR „Enrcrypt, pseudonymize, or anonymize personal data wherever possible“. Um diese Anforderung in einem Unternehmen zu realisieren, bedarf es unter anderem

• eines Konzepts für Identity- and Access-Management, auch IAM-Konzept genannt
• der Implementierung des Konzeptes – in der Organisation als auch in der Software, unabhängig ob es sich um Standardsoftware (z.B. SAP) handelt oder um Eigenentwicklung
• eines Test- und Validierungskonzepts
• der Implementierung des Test- und Validierungskonzepts
• ein Prozess zum Erstellen der geforderten Dokumentation zum Nachweis der Konformität mit der Anforderung für einen Auditor oder eine Zertifizierungsstelle

Um das alles zu adressieren, sind eine Menge Abteilungen und Teams beteiligt, die ihre Arbeit aufeinander abstimmen müssen. Typische Beteiligte sind der Chief Information Security Officer (CISO = Compliance and Information Security Office), System-Architektur, Entwicklung, Test und natürlich der Betrieb. Auch wenn ein Unternehmen klein sein sollte, bietet es Produkte und Services im regulierten Umfeld an, so sind diese Verantwortungen auf irgendeine Art zu besetzen. Wenn wir davon ausgehen, dass im Unternehmen ein CISO existiert, dann ist dieses verantwortlich die für das Unternehmen relevanten Normen und Regulatorien zu kennen und diese im Kontext der Firma aufzuarbeiten. Das präsentiert sich auf abstrakter Ebene wie in Abbildung 1.

In einem klassischen Vorgehensmodell etwa nach V-Modell XT [1] oder Hermes[2] war es „einfach“ die Anforderung zu erfüllen und den Nachweis der Konformität zu erbringen – zumindest aus Prozess-Sicht. Einfach deshalb, weil es klare Quality-Gates in der Entwicklung gab (z.B. Grobkonzept, Feinkonzept, Design, Implementierung, Test, Abnahme, Betrieb). Immer bei einem Übergang von einem Quality-Gate zum nächsten gab es vom CISO definierte Validierungen, deren erfolgreiche Durchführung vom CISO überwacht und dokumentiert wurde. Ob die Validierungen selbst „einfach“ durchzuführen waren, ist ein anderes Kapitel. Zumindest waren die Validierungspunkte und der Scope der Validierung an jedem dieser Punkte klar festgelegt und die Durchführung nachvollziehbar.

Bei einem agilen Vorgehen ist es nicht mehr so einfach. Nehmen wir als Beispiel ein grosses Unternehmen, welches einen Teil der Software nach dem Scaled Agile Framework SAFe[3] selbst entwickelt. Ein Entwicklerteam (eines von vielleicht 50 Teams im Unternehmen) implementiert Software für die Angebotserstellung und deployed alle zwei Wochen eine neue Version der Software. Um das NFR GDPR-Anforderung „Enrcrypt, pseudonymize, or anonymize personal data wherever possible“ vollständig zu erfüllen, müssen mit jedem Deployment alle Teilanforderungen des NFR (Vollständigkeit der Anforderung ist gefordert für jedes Deployment!) erfüllt sein. Teilanforderungen sind: ein IAM Konzept existiert, eine Software-Architektur (eventuell in der Cloud), welche Security Anforderung erfüllt, eine Abnahme Test-Suite, welche den dokumentierten Nachweis erbringt, dass alle Änderungen an der Software nach wie vor die GDPR-Anforderung erfüllen, ein Prozess, welcher die Dokumentation erstellt für den Nachweis, dass alle Teilanforderungen mit einem Deployment erfüllt sind.

Die spannende Frage ist: Wie synchronisieren wir diese Tätigkeiten, die auf verschiedenen Abstraktionsebenen im Unternehmen stattfinden, unterschiedliches Know-how in unterschiedlichen Teams bedarf und die zu unterschiedlichen Zeiten stattfinden?

Ist das eine Mission Impossible?

Die kommenden Blogs dieser Serie stellen ein Konzept vor, das in Zusammenarbeit mit einem grossen Schweizer Unternehmen aufgebaut und umgesetzt wurde, einschliesslich eines konkreten Implementierungsvorschlages für dieses Konzept, basierend auf dem Scaled Agile Framework (SAFe) als Prozess Framework in der Entwicklung.

[1] Siehe: Informationssicherheits-Navigator, „Best Practice“-Ansätze zur Entwicklung sicherer Software, V-Modell XT Bund (Version: 2.3)

[2] Siehe: https://www.hermes.admin.ch/de/startseite.html

[3] Siehe: https://www.scaledagileframework.com/

[4] EU-Regulations: Chapter IV, Section 2, Article 32, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679&from=EN#d1e3383-1-1