ORDINA BLOGT

Agile security requirements

De veiligheid van systemen en gegevens wordt steeds belangrijker. Mensen willen dat hun gegevens veilig worden opgeslagen, zodat deze niet toegankelijk zijn voor onbevoegden. En boeven gaan niet alleen meer op stap met een koevoet, maar doen ook aan het Nieuwe Werken en gaan digitaal vanuit huis op pad om gegevens te stelen.

  • Linda Haak – van der Spek
  • 18 februari 2014

De requirements engineer moet daarom meer dan ooit achterhalen aan welke veiligheidseisen een systeem moet voldoen. Van oudsher worden dit soort requirements als non-functionele requirements opgeschreven, daar zijn mooie standaarden voor zoals de ISO 9126. Maar hoe gaat dat in Agile omgevingen? Gebruik je dan ook de non-functionals?
Dat is natuurlijk mogelijk, maar dat sluit niet helemaal aan bij de veel gebruikte Agile requirements vorm ‘user stories’. Maar een user story kan ook een beveiligingsdoel omvatten, bijvoorbeeld:

Als gebruiker van de website wil ik dat mijn gegevens veilig worden opgeslagen, zodat ongeautoriseerde gebruikers geen toegang hebben tot mijn gegevens.

User stories schrijven m.b.t. beveiliging is soms lastig, want elke user story moet waarde genereren voor de gebruiker. Maar welke gebruiker kies je dan? De architect? Maar dat is geen gebruiker. Dat maakt het soms lastig om goede user stories te schrijven als het om veiligheid gaat.
Er is ook een tegenhanger van user stories, namelijk: abuser stories, ook wel Evil User stories genoemd. Met abuser stories beschrijf je wat voor kwaads iemand wil doen met het systeem en/of de gegevens. Het is aan de architecten en ontwikkelaars om ervoor te zorgen dat deze abuser story niet uitgevoerd kan worden. Bijvoorbeeld:

Als een hacker wil ik de creditcard gegevens stelen zodat ik deze voor frauduleuze aankopen kan gebruiken.
Acceptatie criteria: Het is niet te achterhalen wie ik ben.

Abuser stories kunnen goed gebruikt te worden om alternatieve en foutscenario’s te beschrijven die voorkomen moeten worden. Foutscenario’s zijn meestal niet de eerste zaken waar de focus op ligt bij een Requirements Engineer, maar zijn juist erg waardevol om te beschrijven als het om veiligheid gaat.

Een andere mogelijkheid, indien Scrum gehanteerd wordt, is om eisen m.b.t. beveiliging mee te nemen in de Definition of Done. Bijvoorbeeld:

Elke functionaliteit moet de Security test (uitgevoerd door de afdeling Security) succesvol doorstaan.

Hier zie je dat het requirement m.b.t. beveiliging op een hoger niveau is beschreven dan de voorgaande voorbeelden. Maar dit requirement is ook erg waardevol. Het beschrijven van veiligheidseisen in de Definition of Done is een mooie aanvulling op de andere requirements beschreven in user stories en abuser stories.

Concluderend kun je zeggen dat er verschillende manieren zijn om beveiligingswensen en -eisen vast te leggen in een Agile project. Persoonlijk ben ik fan van abuser stories, omdat je op het gebied van beveiliging als gebruiker vaak beter kunt beschrijven wat je wilt voorkomen dan wat voor beveiliging je wilt. Al maakt dat de specificatie ook niet volledig, omdat wij vaak denken aan dingen die al eerder mis zijn gegaan en niet goed weten wat er allemaal nog meer mis kan gaan. Gelukkig zijn er experts op het gebied van beveiliging die je het beste kunnen adviseren over wat voor beveiliging het beste aansluit bij jouw behoefte en de hedendaagse risico’s!