Column


IT-jurist Peter van Schelven over...

Agile & security: een lastig duo

Toen ik in de eerste helft van de jaren ’80 van de vorige eeuw mijn werk als jurist in de IT-sector begon, was security onder de makers van software een ondergeschoven kindje. De aandacht van softwareproducenten lag vooral bij de primaire systeemfunctionaliteit en niet of veel minder bij vragen die gerelateerd waren aan beveiliging. Security werd bij softwareontwikkeling vaak veronachtzaamd of uitgesteld. Zelden was security voorwerp van voortdurende aandacht bij het ontwerpen van software.

De tijden zijn inmiddels veranderd. Algemeen gesproken zie je dat de makers van software er tegenwoordig niet aan ontkomen om volop aandacht te geven aan de beveiliging van hun producten. Men spreekt dan ook van ‘secure software development’ en ‘security by design’. Terecht, want de zorgplichten van de makers van software gaan inmiddels veel verder. De betrokken belangen op het vlak van de beschikbaarheid, integriteit en vertrouwelijkheid van IT-systemen en data zijn in de huidige tijd vele malen groter. Het is een open deur om te zeggen dat security steeds vaker wordt ingebed in de ontwerpprocessen.

Agile als boosdoener?
Toch kan ik mij niet aan de indruk onttrekken dat oude tijden tegenwoordig soms herleven. Agile is daarvan de boosdoener. Het is, zoals bekend, hip en eigentijds om software te bouwen via ‘agile’ principes, bijvoorbeeld in de vorm van Scrum, Lean Software Development of Extreme Programming (XP).

Op zich valt er voor een ‘agile’ aanpak van softwareontwikkeling best veel te zeggen. De voordelen van een flexibele aanpak ten opzichte van het gebruik van in beton gegoten ontwerpen, zijn inmiddels alom bekend. Centraal in een ‘agile’ aanpak staat om in een aantal relatief korte, overzichtelijke sprints van bijvoorbeeld twee weken of een maand waardevolle werkende software op te leveren.

Een van de principes van de agile aanpak is dat werkende software de belangrijkste maat voor de voortgang – in jargon: de ‘velocity’ – van het ontwikkelproject is. Van een Scrum-team wordt verwacht dat het in een vroeg stadium van het project die delen van de software oplevert die de hoogste ‘business value’ voor de gebruiker vertegenwoordigen. In agile contracten tussen ontwikkelaars en de toekomstige gebruikers van de software vormen ‘velocity-afspraken’ dikwijls kernbepalingen van de afsprakenset.

Lean and mean
Er zijn meerdere verklaringen waarom de aandacht voor security in agile projecten soms ondergesneeuwd raakt. Een daarvan is dat bij de ontwikkeling van software eenvoud voorop dient te staan. Dat is een leidende gedachte. Essentieel voor de makers is dan ook de kunst van het maximaliseren van het werk dat niet gedaan hoeft te worden. ‘Lean and mean’ is het uitgangspunt van een agile projectaanpak.

Ik heb meer dan eens gezien dat in zo’n setting de primaire systeemfunctionaliteit van de te maken software aanzienlijk meer aandacht krijgt dan allerlei secundaire functionaliteit en ‘non functionals’ zoals betrouwbaarheid en onderhoudbaarheid. Het is de taak van ontwikkelaars om vroegtijdig en voortdurend werkende software af te leveren. Security verliest het dan al snel van andere functionaliteit.

Prioritering
Een tweede verklaring hangt samen met het uitgangspunt dat tijdens een agile softwareproject continu prioriteringen moeten worden gemaakt. Het doel is dat het werk met de hoogste ‘business value’ in het ontwikkelwerk voorrang krijgt. De daarvoor benodigde afwegingen moeten gedurende het gehele ontwikkelproject worden gemaakt. De ene functionaliteit is zakelijk gezien nou eenmaal belangrijker dan de andere en dus moet, aldus het gedachtegoed van Agile, die afweging continu gemaakt worden. In de praktijk ligt die verantwoordelijkheid in de regel bij de ‘product owner’.

Hier wreekt zich dat het dikwijls niet eenvoudig is om praktisch een concrete ‘business value’ aan security toe te kennen. Uiteraard kunnen daartoe pogingen worden gedaan, maar die komen naar mijn indruk geregeld niet veel verder dan ‘nattevingerwerk’. Ook dat is niet bevorderlijk om binnen agile projecten stevig aan security te werken. Functionaliteit waarmee echt geld verdiend kan worden, kosten worden bespaard of de productinnovatie kan worden versneld, heeft dan al snel een streepje voor.

Agile contracten
Hoewel er zonder twijfel heel veel agile projecten bestaan waarin security een eigen en volwaardige plek binnen de softwareontwikkeling krijgt, vrees ik dat het dikwijls ook anders is. Dat zou anders moeten. Scrumteams en ‘product owners’ zouden daarom meer expliciete aandacht dienen te geven aan ‘non functionals’ en security.

Maar ook mijn eigen vakgenoten – de IT-juristen – roep ik op een bescheiden bijdrage te leveren. Ook bij het maken van agile contracten tussen ontwikkelaars en toekomstige gebruikers kan hierover het nodige worden gewaarborgd. Dat gebeurt nog te weinig.

Wij willen bij softwareontwikkeling toch niet terug naar het begin van de jaren ’80?

 

IT-jurist Mr. Peter van Schelven, BIJ PETER – Wet & Recht, laat wekelijks zijn licht schijnen over een opmerkelijke uitspraak of wetgeving binnen het IT-recht. Heeft u een concrete vraag voor Peter? Dan kunt u mailen naar peter.van.schelven@gmail.com.

Kijk hier voor de eerdere bijdragen van Peter van Schelven.

Verder lezen?

Log in en lees verder of maak hier uw persoonlijk profiel aan en ontvang als eerste het laatste securitynieuws. Speciaal voor u geselecteerd!

Dit veld is verplicht
Vul een geldige e-mailadres in
Dit veld is verplicht