De noodzaak tot herijken van informatie beveiliging voor agile projecten

Meer en meer systeemontwikkeling vindt plaats op basis van agile methodieken. Het voordeel van agile is dat snel nieuwe functionaliteit toegevoegd kan worden en het risico van complexe wijzigingen sterk wordt gereduceerd door deze op te knippen in kleinere brokken. Klassieke informatiebeveiliging heeft echter moeite met deze agile aanpak. Wat zijn de oorzaken van dit falen en hoe kan een acceptabel beveiligingsniveau in agile ontwikkelomgevingen dan wél worden bereikt?

De mismatch tussen traditioneel securitymanagement en agile ontwikkeling wordt onder meer veroorzaakt door de gebruikelijke manier van werken binnen securitymanagement. Veelal worden hier standaarden en raamwerken toegepast die een top-down benadering kennen: eerst moet er beleid komen en een organisatie worden ingericht, daarna moeten de procedures worden opgesteld en tenslotte wordt er een verzameling van generieke technische maatregelen bedacht. En pas als dat allemaal ‘geregeld’ is kunnen projecten gebruik maken van de diensten van securitymanagement.

Deze raamwerken zijn essentieel voor een goed gebalanceerde en beheersbare beveiliging binnen een organisatie. Ze passen echter niet goed bij een agile traject waar een ontwikkelaar op detailniveau wil weten welke maatregelen geïmplementeerd moeten worden. Daarnaast sluit de beschrijving van de maatregelen niet aan bij de taal en cultuur van ontwikkelaars. Veel ontwikkelaars zien beveiliging als een hindernis (de ‘paarse krokodil’) binnen een agile project die een snelle levering van nieuwe functionaliteit onmogelijk maakt. De snelle ontwikkelmethoden staan haaks op het gebruik van compliance checklists die niet met hun tijd zijn meegegaan.

Hoe kunnen we dat veranderen? Dit artikel onderzoekt een aantal mogelijkheden om informatiebeveiliging op de juiste wijze te integreren in agile. Door bij de basis van securitymanagement te beginnen en op die basis een nieuwe manier van werken te ontwikkelen kan binnen agile het uiteindelijke doel worden bereikt: een snelle en beheersbare ontwikkeling waarbij ook de beveiligingsrisico’s op de juiste en acceptabele wijze zijn geadresseerd.

Het beveiligingsperspectief op agile ontwikkeling

Het doel van de agile aanpak is om zo snel mogelijk nieuwe functionaliteit te implementeren door middel van een continue release van kleine stappen. De agile aanpak probeert niet in één keer de gedetailleerde scope voor het gehele project te definiëren en in detail de producten te beschrijven. Bij agile wordt het project opgeknipt in kleinere, overzichtelijke, stappen (sprints) die beheersbaar en bestuurbaar zijn. De besturing van deze sprints is zodanig dat ontwikkelaars gedwongen zijn keuzes te maken welke functionaliteit wel en niet in een sprint wordt gebouwd. Alle ‘feature requests’ worden verzameld in een backlog, en voor elke sprint wordt een selectie van deze features gemaakt op basis van gewenste functionaliteit, urgentie, beschikbare middelen, verwachte inspanning en andere criteria. Als een feature request te groot of complex is, wordt deze opgeknipt in kleinere onderdelen die afzonderlijk kunnen worden geïmplementeerd, al dan niet in een aantal sprints achter elkaar. Test resultaten en bevindingen uit vorige sprints worden als input gebruikt voor nieuwe sprints om zo direct de bevindingen te kunnen oplossen.

De traditionele aanpak van beveiliging is veel meer gericht op het traditionele watervalmodel waarbij beveiliging vaak als eerste en als laatste in de keten aan bod komt. Aan het begin wordt beveiliging ingeschakeld om de eisen en wensen op te stellen, en aan het einde van het traject om te controleren of deze op de juiste wijze zijn geïmplementeerd. Dit model werkt niet meer in agile.

In dit artikel wordt een aantal van de belangrijke aspecten van agile ontwikkeling uitgewerkt die gerelateerd zijn aan de manier waarop een organisatie haar beveiliging heeft ingericht. Deze aspecten zijn:

  1. Keuzes: In elke sprint moeten ontwikkelaars continue keuzes maken, wordt een bouwsteen wel of niet gebouwd. Op basis van de gewenste functionaliteit, project risico, bijdrage aan het eindresultaat en beschikbaarheid van mensen en middelen worden deze keuzes gemaakt. Informatiebeveiliging zal op dezelfde wijze vergelijkbare keuzes moeten maken. Deze keuzes zijn gebaseerd op de onderkende beveiligingsrisico’s. Dit houdt in dat er continue risico assessments worden uitgevoerd, op het detailniveau van de sprint en daarin gedefinieerde bouwstenen. De risico assessments dienen ook in uitvoering binnen de planning van de sprint te vallen, het liefst zelfs korter zodat de resultaten al in de sprint kunnen worden meegenomen. Uiteraard zullen de beveiligingsmaatregelen ook binnen de sprint moeten passen. Dit houdt in dat ze op het juiste detailniveau gedefinieerd moeten zijn en zo specifiek mogelijk, zodat zij binnen de schaal en planning van de sprint passen.
  2. Bottom up: Binnen agile worden producten vaak via een bottom-up aanpak ontwikkeld waarbij kleine bouwstenen eerst worden ontwikkeld die vervolgens door andere bouwstenen gebruikt kunnen worden. Het breidt uit van onderaf. In de klassieke waterval methode wordt juist een top-down besturing gevolgd, ieder componentje krijgt een plaats in een van tevoren uitgedacht geheel. De meeste beveiligingsraamwerken zijn op dit model gebaseerd. Om beveiliging aan te laten sluiten bij agile moet ook binnen beveiliging een bottom-up aanpak worden ingevoerd. Beveiligingsbouwstenen en maatregelen moeten aansluiten bij de agile benadering, het juiste detailniveau hebben en passende beveiligingsdiensten bieden.
  3. Snelheid: agile ontwikkeling levert kleine, incrementele stappen in functionaliteit in korte sprint cycli. Deze korte tijd betekent dat securitymanagement niet uitgebreid de tijd heeft om allerlei standaarden en beleid te formuleren, laat staan deze uitgebreid te controleren. Verder betekent deze incrementele oplevering dat er niet een vast gedefinieerd product wordt opgeleverd in een sprint, functionaliteit kan nog ontbreken. Voor beveiliging betekent dit dat er geen uitgebreide (klassieke) beveiligingstesten gedaan kunnen worden uitgevoerd, hiervoor is de tijd niet beschikbaar en het te testen systeem is te veel in beweging. De beveiligingscontroles zullen ook op incrementele wijze moeten worden uitgevoerd en de sprint cycli moeten volgen. Hierbij wordt het bijhouden van een risico register, met de juiste scope en details, van essentieel belang. Dit risico register is de backlog voor beveiliging.
  4. Terugkoppeling: dankzij de korte cyclus tijd van een sprint, is het mogelijk bevindingen van vorige sprints mee te nemen in volgende sprints. Dit model leidt uiteindelijk tot een proces van continue verbetering. In het waterval model was het mogelijk dat securitymanagement een release kon blokkeren vanwege bijvoorbeeld kritieke risico’s. Binnen het waterval model is er immers een duidelijk moment van vrijgave te definiëren. Binnen agile is er niet zo’n duidelijk moment, de incrementele releases volgen elkaar op in een continue stroom. Beveiliging heeft hierdoor wel de mogelijkheid eerder kritieke risico’s te identificeren en deze te laten oplossen in een sprint waardoor de kans op blokkade aan het einde van een project aanzienlijk wordt verminderd. Door in een sprint op de juiste risico’s te toetsen is beveiliging, mits zij aansluit bij agile, in staat de juiste focus te leggen en de juiste risico’s te identificeren.

Waarom wringt ISO27001 binnen agile?

Het securitymanagementproces, met de PDCA-cyclus en ISMS

In veel organisaties wordt ISO27001 (of een afgeleide daarvan) toegepast om richting en sturing te geven aan de informatiebeveiliging en de bijbehorende beheerprocessen. Het ISO27001 raamwerk is gebaseerd op een ISMS en bijbehorende Plan-Do-Check-Act cyclus. (Overigens heeft de nieuwste versie van ISO27001 (de 2013 versie) de PDCA cyclus min of meer losgelaten en is de focus meer op de context van de organisatie komen te liggen). De PDCA-cyclus begint met een risico assessment en gebruikt daarvoor een top-down benadering om de juiste doelstellingen te definiëren. Op basis van de doelstellingen worden maatregelen gekozen die de geïdentificeerde risico’s moeten adresseren. Deze maatregelen bestaan vaak uit een combinatie van maatregelen op organisatorisch, procesmatig en technisch niveau. De effectiviteit van deze maatregelen wordt vervolgens gemeten en op basis daarvan wordt het beveiligingsplan bijgesteld. Dit is heel kort samengevat de PDCA-cyclus die op basis van een top-down benadering beveiliging inricht.

pdca

Figuur 1. De planning en control cyclus binnen securitymanagement

En alhoewel ISO27001 een veel gebruikt raamwerk is dat een organisatie in staat stelt om haar beveiligingsbehoefte te beheren, past ISO27001 niet eenvoudig op een agile ontwikkelproces. De top-down benadering, samen het feit dat veel maatregelen te generiek zijn, zorgt voor een gat tussen het raamwerk en de daadwerkelijke behoefte binnen agile.

Aannames en waar zij falen voor agile

De klassieke raamwerken doen een aantal aannames over de manier waarop securitymanagement integreert met systeemontwikkeling:

  1. Het projectteam is in staat de generieke beveiligingseisen te vertalen naar specifieke beveiligingsmaatregelen;
  2. Het projectteam heeft de tijd, kennis en middelen om deze maatregelen op de juiste wijze te implementeren;
  3. Er is voldoende tijd en budget om in het project een technische beveiligingstest uit te voeren en de bevindingen te verwerken;
  4. Er is voldoende tijd om alle beveiligingsrisico’s te identificeren en op te lossen.

Deze aannames gaan mank in een agile ontwikkeltraject.

  1. Het ontwikkelteam heeft andere prioriteiten en beperkte middelen om alle eisen te vertalen naar maatregelen en deze vervolgens te implementeren. Binnen agile is timemanagement essentieel en moeten continue keuze worden gemaakt. Helaas zijn deze keuzes vaak nadelig voor beveiliging.
  2. Het ontwikkelteam heeft van de kennis en ervaring niet om beveiligingsmaatregelen te ontwikkelen en definiëren. Zij zijn zich niet altijd bewust van de kwetsbaarheden in bouwstenen en hebben vaak geen kennis van methodieken om veilig software te ontwikkelen.
  3. Binnen de ontwikkelcyclus is vaak geen duidelijke testfase aanwezig waarin de functionele en niet-functionele eisen worden getest. Testen vindt veel meer plaats op unit niveau en richt zich primair op functionele testen. Hierdoor blijven testen op beveiliging vaak achterwege, ook omdat er binnen een sprint geen tijd is voor securitymanagement om uitgebreide testen te doen. Bovendien is de focus van een sprint vaak pas bekend bij aanvang van de sprint zelf en heeft securitymanagement niet de tijd en middelen om hierop in te spelen.
  4. Tenslotte zijn er culturele issues. De meeste ontwikkelaars krijgen geen warm gevoel bij informatiebeveiliging. Het beeld is dat beveiliging een hoop overhead creëert omdat verplicht allerlei maatregelen moeten worden geïmplementeerd. Deze maatregelen kosten een hoop tijd, vertragen de ontwikkeling en geven niet direct een aantoonbaar resultaat.

Agile securitymanagement

Het doel van informatiebeveiliging is om de risico’s tot een acceptabel niveau te beperken, zodat de doelstellingen van de bedrijfsprocessen kunnen worden gehaald.

De business of systeem eigenaar wil in control zijn en heeft daarbij securitymanagement nodig. Om dit te bereiken wordt de Plan-Do-Check-Act-cyclus vaak toegepast. Wanneer deze (strategische) PDCA-cyclus wordt toegepast in een agile omgeving, past het agile ontwikkelproces het best in de Do-fase. Dat is waar de maatregelen worden geïmplementeerd. Het securitymanagement-proces zorgt voor inbedding van beveiliging in agile ontwikkeling; door het stellen van eisen (Plan), door het selecteren van de juiste maatregelen (Do), door het monitoren van beveiliging (Check), en het aanpassen naar aanleiding van nieuwe eisen of wijzigingen (Act). Dit is weergegeven in in Figuur 2. Deze positionering van agile in de PDCA-cyclus is het gevolg van de bovengenoemde vier aannames. Iedere fase uit de PDCA-cyclus wordt verder besproken in de volgende paragrafen.

Pascal2

Figuur 2. Agile security model, waarin agile development is geplot op de Plan-Do-Check-Act cyclus.

Plan: Securitystrategie en governance

Security governance in een agile omgeving is gelijk aan traditionele security governance. Deze component zorgt ervoor dat de PDCA-cyclus wordt uitgevoerd. Ten aanzien van requirements-management houdt het bij wat de wettelijke, branche-gebonden en organisatie-specifieke eisen rond security zijn. Tevens houdt het bij welke risico’s zijn geïdentificeerd gedurende het agile ontwikkelproces en of deze in lijn zijn met de security-doelstellingen. In een agile omgeving zorgt security governance door de bestaande audit en GRC-processen in lijn te brengen met agile ontwikkeling, zowel in scope als detail niveau.

Do: Secure agile ontwikkelproces

Het agile ontwikkelproces is waar het rubber het asfalt raakt, met een actieve bijdrage van securitymanagement in de sprints.

Adresseren van aanname 1. Niet in staat om requirements naar security-maatregelen te vertalen.

De eerste aanname was dat het agile projectteam niet in staat is om de security doelstellingen door te vertalen naar securitymaatregelen, door gebrek aan tijd, geld of de juiste mensen.

Dit vereist actieve betrokkenheid van één of meer medewerkers uit het security management domein in het project. Ze zijn deel van het team en ondersteunen het project om de security requirements en functionele requirements tegen elkaar af te wegen indien nodig. De securitymedewerkers dienen kennis te hebben van de verschillende domeinen en technieken. Ze selecteren de juiste beveiligingsmaatregelen die relevant zijn voor de functionaliteit die op dat moment door het ontwikkelteam wordt gerealiseerd. Op deze manier wordt het gat overbrugd tussen het generieke security raamwerk op organisatorisch niveau en de specifieke security-maatregelen die op projectniveau nodig zijn.

De vertaling van security doelstellingen naar beveiligingsmaatregelen kan worden gestandaardiseerd door:

  • De definitie van een security baseline, welke een lijst bevat van alle beveiligingsmaatregelen die dienen te worden geïmplementeerd;
  • De definitie van een security classificatieschema. Wanneer een sprint begint wordt de bouwsteen in kwestie geclassificeerd voor bijvoorbeeld vertrouwelijkheid, privacy en toegankelijkheid. De classificatie leidt tot een set van beveiligingsmaatregelen die het juiste niveau van bescherming bieden. Het classificatieschema zorgt ervoor dat de baseline wordt afgestemd op verschillende beveiligingsniveaus.

Adresseren van aanname 2. Gebrek aan expertise om beveiligingsmaatregelen te implementeren

De tweede aanname was dat het agile ontwikkelteam onvoldoende expertise heeft om de beveiligingsmaatregelen correct te implementeren. De rol van het security-team is daarom om het implementeren van de maatregelen zo eenduidig en eenvoudig mogelijk te maken door ze als kant-en-klare security bouwstenen aan te leveren. Deze kunnen snel worden geïntegreerd in het ontwikkelende systeem.

Security bouwstenen kunnen de vorm hebben van:

  • Operationele securityservices die as-is kunnen worden geïntegreerd in het systeem. Een voorbeeld is een authenticatieservice. De generieke services in de service catalogus beschrijven een authenticatieservice met verschillende beveiligingsniveaus, variërend van wachtwoorden tot twee-factor-authenticatie met certificaten. Alle systemen implementeren minimaal het laagste niveau (met de wachtwoorden). Dit kan fysiek zijn geïmplementeerd door een Active Directory. Voor sterkere authenticatie kan bijvoorbeeld twee-factor authenticatie beschikbaar zijn middels een federated service op basis van SAML. De verwijzing naar de juiste fysieke service wordt gedaan door de service catalogus in combinatie met de security baseline.
  • Security patronen: standaard manieren om standaard issues mee op te lossen. Een voorbeeld is de manier waarop patch management wordt gedaan. Hoewel de frequentie van patch releases en hoe deze toe te passen verschilt per technologieleverancier, kan de generieke procedure voor het toepassen van patches dezelfde zijn voor alle systemen in de organisatie.

​De verzameling van kant-en-klare security bouwstenen kan worden gevonden in de securityservices catalogus. De inhoud van deze catalogus zal voor iedere organisatie verschillend zijn. In het beste geval is het gebaseerd op een praktische catalogus van operationele securityservices, welke zou kunnen worden gegeven door branche-standaarden en platform-specifieke security standaarden. De services in de catalogus zijn geordend naar de laag in de system stack waarin ze opereren, zoals weergegeven in onderstaande diagram.

P3

Figuur 3. Voorbeeld van een baseline met verplichte securityservices op de platform-laag.

Zoals is te zien in het diagram, hebben bepaalde services een preventief karakter, andere juist een detectie of correctief karakter. Welke services deel uitmaken van de baseline hangt af van de context, beschikbaar budget en risk appetite van de organisatie. Het systeem-ontwikkel-project hoeft alleen de witte services uit het diagram te implementeren: de grijze services worden geleverd door securitymanagement.

Check: Continuous security monitoring

Security Monitoring is een breed begrip. Doorgaans wordt hieronder verstaan het monitoren op operationele security events. Met betrekking tot agile systeemontwikkeling gaat het om het monitoren of er veilige systemen worden opgeleverd, het monitoren op events is even buiten scope gehouden. Waar het om gaat is dat als securitymanagement de snelle cycli van agile development niet bij kan houden, het hele idee van synchroniseren van agenda’s moet worden losgelaten. Het onderzoeken van kwetsbaarheden zou volledig onafhankelijk van het ontwikkelproces moeten worden uitgevoerd.

Adresseren van aanname 3. Er is geen tijd voor security tests in de sprint 

De agile aanname is dat er geen tijd voor het plannen en uitvoeren van een kwetsbaarhedenonderzoek voordat de functionaliteit wordt opgeleverd; het nieuwe (deel)systeem wordt hoe dan ook opgeleverd. Als dit het geval is, waarom zouden we er dan niet van uitgaan dat securitymanagement überhaupt niet wordt geïnformeerd van enige nieuwe systeemrelease. Het moet zelf maar uitzoeken welke systemen erbij zijn gekomen, en het moet de veiligheid van deze systemen controleren ongeacht de methode waarmee ze tot stand zijn gekomen. Dat is continuous monitoring in een agile omgeving: bijhouden welke systemen er zijn en de veiligheid checken onafhankelijk van het ontwikkelproces. Het vaststellen van kwetsbaarheden in systemen is dus niet langer planning-gedreven (de releasedatum van het systeem is immers onbekend), maar observering-gedreven (er is een nieuw systeem gedetecteerd, dus direct gaan testen).

In de praktijk begint continuous monitoring met discovery scans op het netwerk. Wanneer een nieuw systeem wordt aangetroffen wordt automatisch een check op kwetsbaarheden gestart. Dit kan op verschillende manieren:

  • Een geautomatiseerd kwetsbaarhedenonderzoek (door de bouwsteen ‘Vulnerability management’);
  • Een penetratietest door een security expert (bouwsteen ‘Penetratie testen’).
  • Een consistentie-check op implementatie van de security baseline (door bouwsteen ‘Security monitoring’): zijn alle verplichte security bouwstenen geïmplementeerd?

Deze laatste behoeft enige toelichting. Het vereist dat er een set security bouwstenen wordt gebruikt in de organisatie, welke in samenhang opereren en die alle loggen naar een centraal logsysteem. Stel je voor dat de baseline in Figuur 3 voorschrijft dat een systeem zowel een NTP (bouwsteen ‘Trusted time’) als Active Directory (specifieke ‘Authenticatie’ bouwsteen) implementeert. Zodra één van de security-bouwstenen over dit nieuwe systeem een logregel wegschrijft, wordt het ontdekt. Nu komt de consistentie-check: als er een logregel komt uit Active Directory, dan moet er ook een NTP-logregel over dit systeem komen. Zo niet, dan is de conclusie dat de baseline niet volledig is geïmplementeerd door het systeem, en dat kan dan weer leiden tot sancties. Voor deze geavanceerde manier van monitoring is het gebruik van een securityservice catalogus vereist, evenals een goed werkende security monitoring functie.

Act: De cirkel sluiten

Het doel van de Act-fase is om de bestaande situatie bij te stellen, zodat risico’s worden gereduceerd tot een acceptabel niveau.

Adresseren van aanname 4. Geen tijd om kwetsbaarheden te herstellen 

De vierde aanname was dat er geen tijd is om de security risico’s te mitigeren die tijdens de tests zijn aangetroffen. Er van uitgaande dat de sprints geen ruimte laten voor herstelwerkzaamheden voordat de functionaliteit wordt opgeleverd, dienen andere routes te worden bewandeld om bij te sturen en de kwetsbaarheden weg te nemen. Bijsturing kan worden bereikt op twee manieren:

  1. Door het informeren van het security governance team welke zich met de Plan-fase bezighoudt. Dit resulteert in een nieuwe securitystrategie en bijbehorend security plan. Dit is de langzame route die leidt tot resultaat op de lange termijn voor een brede groep systemen.
  2. Door het informeren van het agile development-team welke zich met de Do-fase bezighoudt. Dit leidt gericht tot veiligere systemen en vermindering van het operationele risico. Dit is de snelle route, maar de scope van de verbeteringen is beperkt tot het systeem in kwestie. Het vereist dat er wordt ingespeeld op de werkwijze van het agile ontwikkelproces. De testresultaten worden geformuleerd als wijzigingsverzoeken en toegevoegd aan de backlog. Ze zullen dan worden overwogen voor de volgende sprint.

Conclusie

De aannames en randvoorwaarden die golden in een traditioneel systeemontwikkelproces zijn niet langer geldig in een agile ontwikkelomgeving. In een agile ontwikkelomgeving dient de security-benadering daarom ook agile te zijn. De belangrijkste veranderde aannames en hun consequenties voor securitymanagement zijn:

  • Verwacht niet dat het ontwikkelteam de beveiligingsdoelstellingen vertaalt naar de juiste security-maatregelen zonder de juist hulp, ondersteuning en middelen vanuit securitymanagement.
    • Stel een snelle en eenvoudige methode beschikbaar voor het classificeren van het systeem. De classificatie fungeert als een security baseline.
  • Verwacht niet dat er middelen zijn voor het ontwerpen en implementeren van de beveiligingsmaatregelen.
    • Stel operationele security-bouwstenen beschikbaar die klaar voor gebruik zijn. Ze versnellen het ontwikkelproces en zorgen er tegelijkertijd voor dat de maatregelen correct worden geïmplementeerd.
  • Verwacht niet dat veiligheidsonderzoeken kunnen worden gepland binnen de agile ontwikkelcycli
    • Implementeer observatie-gedreven security monitoring, onafhankelijk van het ontwikkelproces: monitor de omgeving continu en controleer de veiligheid van systemen op het moment dat ze zich vertonen.
    • Maak gebruik van een samenhangende set van security bouwstenen. In combinatie met security monitoring kan hieruit worden geconcludeerd of de security baseline correct is geïmplementeerd.
  • Verwacht niet dat er tijd is om kwetsbaarheden weg te nemen voordat het systeem wordt opgeleverd.
    • Participeer in het beheer van de backlog, zodat security-aanpassingen worden geïmplementeerd in de volgende sprint.

 

Auteurs:

Arthur Donkers, 1Secure (arthur@1secure.nl)

Pascal de Koning, Ideas to Interconnect (p.de.koning@i-to-i.nl)

 

Dit artikel is onderdeel van een reeks waarin door beide auteurs wordt verkend hoe informatiebeveiliging kan worden geïntegreerd in agile ontwikkel trajecten. Deze reeks is beschikbaar op http://www.agilesecurity.nl

Deel dit bericht via:Tweet about this on TwitterShare on LinkedInEmail this to someoneShare on FacebookShare on Google+Pin on PinterestPrint this page

Door de site te te blijven gebruiken, gaat u akkoord met het gebruik van cookies. meer informatie

De cookie-instellingen op deze website zijn ingesteld op 'toestaan cookies "om u de beste surfervaring mogelijk. Als u doorgaat met deze website te gebruiken zonder het wijzigen van uw cookie-instellingen of u klikt op "Accepteren" hieronder dan bent u akkoord met deze instellingen.

Sluiten