Ver-agile-ing goed voor informatiebeveiliging?

Eind 2010 schreef ik een artikel waarin ik stel dat Agile software ontwikkeling de kans op technologische (en/of functionele) imperfecties in software niet vergroot, maar juist kansen biedt door hier periodiek bij stil te staan. Hiermee zeg ik eigenlijk ook dat een ontwikkelmethodiek nooit verantwoordelijk kan zijn voor inhoudelijke ontwikkelkeuzes. Dit is namelijk een gedeelde verantwoordelijkheid van het ontwikkelteam en de opdrachtgever. De opdrachtgever die de uiteindelijke besluiten neemt, en het ontwikkelteam dat de opdrachtgever informeert over zaken die van belang zijn bij het prioriteren.

Het zijn de mensen in het proces die ervoor moeten zorgen dat de  ontwikkelde software niet alleen aan de eisen van vandaag, maar ook aan de eisen van morgen voldoet. En dan doel ik niet alleen op primaire functionaliteiten of variabelen die hardcoded of configureerbaar zijn geïmplementeerd, maar op allerlei kwaliteitsverbeterende aspecten zoals monitoring, het valideren van input, of het kunnen terugdraaien van transacties. Alleen door ook bij dit soort (voor de business vaak secundaire) zaken expliciet stil te staan, kan betrouwbare software worden ontwikkeld.

Een goede informatiebeveiliging is óók op deze manier te realiseren. Om de principes achter Agile nog maar eens aan te halen: “Continuous attention to technical excellence and good design enhances agility.” Zorg er dus voor dat de teams er naar streven om na elke iteratie een getest product op te leveren dat voldoet aan alle kwaliteitskenmerken. Dus inclusief de eisen ten aanzien van informatiebeveiliging. Omdat dit niet altijd lukt, en het implementeren van maatregelen soms meer werk is, is het aan te bevelen om een aantal iteraties te budgetteren voor het implementeren van risicomitigerende maatregelen.

Scrum

Een bekende ontwikkelmethodiek die is gebaseerd op de principes van Agile, en die ik in mijn omgeving veel tegenkom, is Scrum. Scrum kent een specifiek proces waarbinnen rollen (Product Owner, Team, Scrum Master) en hulpmiddelen (Product Backlog, Sprint Backlog, etc) zijn gedefinieerd, waarmee softwareontwikkeltrajecten gemanaged kunnen worden. Met andere woorden: Scrum is eigenlijk een implementatie van het Agile gedachtengoed, en benadert hierdoor de gang van zaken op de werkvloer een stuk nauwkeuriger. Daardoor is het interessant om ook eens door een informatiebeveiligingsbril naar Scrum te kijken.

Eigenlijk geldt voor Scrum exact hetzelfde als voor Agile. De methodiek biedt de mogelijkheden, maar het is aan het Scrumteam om samen de prioriteiten juist te krijgen door ook naar risico’s te kijken. Op internet zijn verschillende artikelen te vinden over wijzen waarop je binnen een Scrum context (beter) met informatiebeveiligingszaken om kunt gaan. Zo zegt de een dat het voor Agile-achtige methodieken belangrijk is om informatiebeveiligingseisen proactief in een vroegtijdig stadium te adresseren, terwijl de ander de tekortkomingen van Scrum op het gebied van risicomanagement aanvult met zaken uit de PRINCE2 projectmanagement methodiek. Genoeg goede ideeën dus om ervoor te zorgen dat Scrum niet zomaar voorbij gaat aan het belang van een goede informatiebeveiliging.

De ver-agile-ing

Toch blijft het moeilijk om voldoende aandacht voor informatiebeveiliging te hebben en te houden. Dit heeft onder andere te maken met het feit dat de meeste IT organisaties kampen met een tekort aan resources (FTE en/of budget). Hierdoor is er bijna continu sprake van complexe prioriteringsvraagstukken. Mijns inziens wordt de situatie versterkt door de volgende zaken:

1. De business is onvoldoende doordrongen van het belang van informatiebeveiliging. Regelmatig komt het voor dat men “niet begrijpt waarom die maatregelen allemaal nodig zijn”, en leeft de perceptie dat “zelfs banken minder goed beveiligd zijn”. Het is dus belangrijk om goed uit te blijven leggen wanneer het nemen van maatregelen belangrijk is. Het risico moet goed uitgelegd worden, inclusief de gevolgen als het misgaat. Als lage risico’s niet altijd een optie zijn, is een bewust geaccepteerd risico nog altijd beter dan een onbewust geaccepteerd risico.
2. De nadruk ligt vaak op projecten, omdat deze per direct waarde toevoegen en dit het beste is voor de klanttevredenheid op de korte termijn. Voor beheerwerkzaamheden, waar ook de informatieveiligheid van het bestaande ICT landschap onder valt, blijft er weinig tot geen tijd over.
3. De aansturing vanuit de business is niet professioneel ingericht. De verschillende businesses sturen primair vanuit hun eigen belang en spreken weinig met elkaar over prioriteiten, terwijl ze wel de resources van de IT organisatie met elkaar delen. En doordat prioriteringsvraagstukken niet op de juiste plek in de organisatie worden geadresseerd, sijpelen deze beslissingen ‘naar beneden’ en belanden ze uiteindelijk op het bordje van de IT organisatie.

Ergens is het dan niet vreemd dat nieuwe modellen zoals Agile met twee handen worden aangegrepen in de hoop dat daarna alles beter gaat. Maar het expliciteren van het prioriteringsproces richting alle relevante stakeholders, is niet automatisch een garantie voor succes. Wanneer Agile/Scrum binnen een andere context dan softwareontwikkeling wordt toegepast, vraagt dat een andere mindset van de mensen die participeren in het proces. Out-of-the-box werkt dit namelijk niet.

Agile niet plug-and-play

Neem bijvoorbeeld de rol Product Owner. Op papier vertegenwoordigt deze het belang van de business en kan hij of zij zelfstandig beslissingen nemen over prioriteiten. De praktijk is echter anders. Er zijn verschillende PO’s die een beroep doen op de resources van dezelfde ontwikkel- en beheerteams, waardoor er dus (nog steeds) geen sprake is van eenduidige aansturing. Daar komt bij dat de PO’s eigenlijk niet dé business zijn, maar zijn afgevaardigd om de business te vertegenwoordigen. Dit is op zich geen probleem, maar dat wordt het wel wanneer de PO’s op hun beurt ook weer door verschillende stakeholders en op verschillende wijzen vanuit de business worden aangestuurd. En bij het uitblijven van concrete resultaten en oplopende druk vanuit de business, worden er ook door PO’s verkeerde prioriteiten gesteld. Op de korte termijn merk je dat wellicht niet, maar op de lange termijn ga je hier de gevolgen van ervaren, omdat dit vaak regelrecht ten koste gaat van de kwaliteitskenmerken van een omgeving. En dat uit zich in verstoringen met als gevolg een lagere klanttevredenheid.

In plaats van het Agile inrichten van de primaire prioriteringsprocessen in de IT organisatie, is er alleen maar een extra tussenlaag gecreëerd die prioritering complexer in plaats van eenvoudiger maakt. Onduidelijkheid en meningsverschillen omtrent verantwoordelijkheden vergroten de inefficiëntie en resulteren continu in onnodige discussies. Het enige wat er dan van Agile overblijft, is een gezamenlijke to-do lijst; de backlog. En helaas is het hebben van een backlog niet hetgene dat prioriteringsvraagstukken gaat oplossen.

Blijkt maar weer eens dat dit soort zaken alleen maar “vanzelf gaan vliegen” in professionele organisaties. Zolang daar slechts in beperkte mate sprake van is (grote én professionele organisaties zijn zeldzaam), is het belangrijk dat het management erop toe ziet dat de juiste mensen de juiste dingen doen. En zo lang de Information Security Officer de enige is die zich realiseert dat zijn lijst met informatiebeveiligingsissues eigenlijk een overzicht is met problemen van anderen, is er werk aan de winkel…

Afbeelding door: uni-t.be.