B-Sec 2: Compliance NFRs & Agilität: Der konzeptionelle Ansatz

Übergreifende Compliance NFR (IREB[1]: Qualitätskriterien) in einem agilen Setup zu erfüllen ist keine Mission Impossible. Allerdings sind dazu einige zusätzliche Voraussetzungen und Rahmenbedingungen zu erfüllen. Das Konzept achtet darauf diese so leichtgewichtig und praktikabel wie möglich zu implementieren, so dass der agile Mindset nicht durch starre Rahmenbedingungen korrumpiert wird. So ist die Chance gegeben übergreifende und integrale NFR in einer dezentralen skaliert agilen Entwicklungsumgebung zu erfüllen, ohne Rückfall auf klassische Quality-Gates und zentrale Prüforganisationen.

Beteiligte Rollen

Ein wichtiges Element ist, sich bewusst zu sein, welche dezentralen Organisationseinheiten und «Rollen» in diesem Ansatz beteiligt sind und wie diese kooperieren. Der vorgestellte Ansatz erkennt die folgenden Rollen, die in einem agilen Setup kooperieren. Diese Rollen sind, zumindest ab der Grösse eines mittleren KMU, in einem Unternehmen existent. Ist dies nicht der Fall, dann würde ich einem Unternehmen, welches Regulatorien unterliegt, dringend vorschlagen diese zu etablieren. Dies zu unterlassen ist ein leichtfertiger Umgang mit Risiken.

• Das Cyber & Information Security Office (CISO):
  • Besitzt die Verantwortung die Liste der für das Unternehmen relevanten NFR auf der obersten Abstraktionsebene zu identifizieren und zu definieren.
  • Besitzt die Verantwortung zusammen mit Business Ownern zu definieren, welches Subset an Anforderungen für ein spezifisches Entwicklungsvorhaben zu erfüllen ist.
  • Definiert zusammen mit Business- und System-Architektur, welcher Detailanforderungen eines einzelnen NFR organisatorisch, durch die System-Architektur (die Entwicklungsplattform), beziehungsweise in der Entwicklung abgedeckt werden und definiert dazu die entsprechenden Akzeptanzkriterien.
  • Schult spezifische Rollen in der Organisation (Anwender, Software-Architektur, Entwickler) in der Ausführung sicherheitsrelevanter der Tätigkeiten.
• Die operativen Einheiten
  • Werden geschult im Anwenden organisatorischer Massnahmen im Betrieb (Beispiel: Agenturen oder Kundenservice im Opt-in von Kunden) und wenden diese Massnahmen an.
• Die Software-Architektur (auch möglich dezentral organisierte z.B. als Community of Practice)
  • Definiert zusammen mit dem CISO welche Detailanforderungen eines NFR durch die System-Architektur abgedeckt werden (zum Beispiel Identity & Access Management IAM) und stellt die entsprechenden Software-Bausteine etwa in Form einer Entwicklungsplattform oder als zu verwendende Softwarekomponenten bereit.
  • Wird geschult vom CISO, so dass die Software-Architektur das entsprechende NFR Knowhow besitzt, um die Software-Architektur entsprechend zu definieren und zu entwickeln.
• Die Entwicklungsteams
  • Implementieren die Software unter Beachtung des Subset an Teilanforderungen und den dazu gehörigen Akzeptanzkriterien, die auf der Ebene Entwicklerteam verantwortet werden und nicht – was zum Glück oft der Fall ist – bereits organisatorisch bzw. durch die Software-Architektur abgedeckt sind.
• Testing und Validierung (auch möglich als dezentral organisierte Community of Practice)
  • Definition von konkreten Abnahmetest zur Validierung der NFR. Diese Abnahmetests, die vor dem Deployment in die produktive Umgebung zwingend notwendig sind, sind (idealerweise) Bestandteil einer (automatisierten) Test-Suite. Sie validieren diejenigen Teilanforderungen eines NFR, welche durch Architektur und Entwicklung zu erfüllen sind – einschliesslich der zum Nachweis notwendigen Dokumentation.

Es existiert ein charmanter Vorteil bei übergreifenden und integralen NFR – sie verändern sich nur sehr langsam. Wenn ein Unternehmen die NFR einmal initial definiert hat, jedes einzelne NFR in Teilanforderungen zerlegt hat und entschieden hat, welche Teilanforderungen organisatorisch und welche durch die Architektur, beziehungsweise in der Entwicklung zu erfüllen ist, so verändert sich dieses Zusammenspiel über die Zeit nur sehr langsam.

Es kann also optimal mit Templates, Vorlagen und Checklisten gearbeitet werden, welche zum Beispiel Bestandteil einer Definition of Ready (DoR) beziehungsweise einer Definition of Done (DoD) werden. Zusätzlich entsteht mit der Zeit eine Test-Suite wiederverwendbarer Testfälle zur Validierung von Teilanforderungen, sodass auf diese effizient zurückgegriffen werden kann.

Beispielhafte Umsetzung des Konzeptes

Bauen wir das zur Veranschaulichung einmal exemplarisch (und stark vereinfacht) für das Beispiel des GDPR NFR „Enrcrypt, pseudonymize, or anonymize personal data wherever possible“ auf (siehe Abbildung 2)

1. CISO, zusammen mit HR und System-Architektur, definieren ein rollenbasiertes Identity & Access Mgmt (IAM) Konzept, d.h. die Abbildung der Organisation, welche Rolle welche Rechte auf welche Objekte im Unternehmen erhält.
2. Das IAM-Konzept ist organisatorisch zu verankern, d.h. wird festgelegt welche Mitarbeiter*in welche Rolle(n) einnimmt – sowohl in der Entwicklung als auch im operativen Betrieb. Die Mitarbeiter*innen sind eventuell zu schulen.
3. Die System-Architektur entscheidet, welche Software-Bausteine zur Implementierung des IAM Konzepts eingesetzt werden bzw. wie eine Standard-Software entsprechend zu konfigurieren ist.
4. Bei einer Eigenentwicklung von Software im Unternehmen entwickeln die Entwicklungsteams IAM Zugriffsmodule, die Bestandteil der Software-Architektur sind und in der Entwicklung eingesetzt werden, um IAM konforme Zugriffe auf Objekte zu garantieren.
5. Die System-Architektur definiert zusammen mit dem CISO-Akzeptanzkriterien und davon abgeleitete logische Testfälle, welche das Einhalten bestimmter Teilanforderungen des NFR validieren.
6. Die Entwicklungsteams implementieren gemäss der Akzeptanzkriterien und der logischen Testfälle konkrete Testfälle. Dies sind zum einen Abnahmetests, die in eine allgemeine regressionsfähige Test-Suite aufgenommen werden, und zum anderen spezifische Entwicklertests.
7. Die Definition of Ready[2] (DoR) eines zu implementierenden Features umfasst das Validieren, ob das IAM-Konzept die notwendigen Rollen und Zugriffsrechte definiert und diese im IAM implementiert sind.
8. Die Definition of Done[3] (DoD) für das Deployment eines Deliverables eines Teams enthält eine Checkliste mit den folgenden Punkten
   • Ausschliesslich die IAM-Zugriffsmodule der Architektur werden verwendet
   • Die IAM-spezifischen Abnahmetests der regressionsfähigen Test-Suite sind erfolgreich ausgeführt und die notwendige Dokumentation der Tests ist vorhanden.
   • Die IAM-spezifischen Test für das entwickelte Deliverable sind erfolgreich durchgeführt und die notwendige Dokumentation der Tests ist vorhanden.
   • Zusätzlich entwickelte regressionsfähige Tests der Entwicklung sind der regressionsfähigen Test Suite hinzugefügt.
   • Die Anwender der Software sind geschult (wenn notwendig)

Das klingt nun nach unheimlich viel Upfront-Arbeit und wenig Agiliät. Das täuscht jedoch – vorausgesetzt das Unternehmen verfügt über eine gewisse Reife in seinen Prozessen bezüglich agiler Entwicklung.

Die notwendige «agile Reife» des Unternehmens als Voraussetzung dieses Konzept zum Leben zu erwecken, thematisiere ich in meinem nächsten Blog.

[1] International Requirements Engineering Board – www.ireb.org

[2] Eine gute Erklärung der DoR von Ian Mitchell, Scrum.org: https://www.scrum.org/resources/blog/walking-through-definition-ready

[3] Eine gute Erklärung der Definition of Done von Sumeet Madan, Scrum.org: https://www.scrum.org/resources/blog/done-understanding-definition-done