Het Security team van cibit academy | inspearit hanteert als motto “Sturen op vertrouwen, bouwen aan vertrouwen”. Die nadruk op vertrouwen, dat klinkt vreemd voor een team dat zich met security bezig houdt. Geldt op dat terrein juist niet de uitspraak van de Russische leider Lenin, uit 1921: “Vertrouwen is goed, controle is beter”? Wij denken van niet! Of, beter gezegd, wij brengen de juiste nuance aan in deze uitspraak. In een vijftal blogs leggen we uit waarom en hoe.
In deze blog gaat Michiel Broekhuijsen in hoe beveiliging en agile ontwikkeling hand in hand kunnen gaan en daarmee het vertrouwen geven dat producten naast functionaliteit, ook veiligheid kunnen bieden.
Op het eerste gezicht gaat het niet samen: agile ontwikkeling en degelijke beveiliging. Beveiligen vraagt immers om doordachte maatregelen die ‘de waan van de dag’ ontstijgen. Toch is het mogelijk om het vertrouwen te vergroten dat beveiliging binnen agile voldoende aandacht krijgt.
IT-organisaties kiezen er steeds meer voor om projecten op een agile manier aan te pakken, om sneller en goedkoper betere systemen te realiseren, waarbij scrum een veel gekozen methode is (daarom wordt de term agile/scrum in deze blog gebruikt). Een keuze die noodzakelijk is om als organisatie te kunnen blijven overleven in een snel digitaliserende en veranderende wereld. Tegelijk moeten organisaties ook de beveiliging van hun IT-systemen en informatie op orde hebben, om geen onacceptabele risico’s te lopen en/of te blijven voldoen aan wet – en regelgevingen. Beveiliging en agile lijken op gespannen voet met elkaar te staan. Toch hebben beide werelden het zelfde doel: waarde creëren en behouden voor de organisatie en haar stakeholders.
Contrast
Wie het over agile/scrum heeft, denkt vaak aan snelheid, zelfsturende teams, flexibiliteit en gericht op het creëren van oplossingen en mogelijkheden. Wie het over beveiligen van informatie en systemen heeft, denkt vaak aan regels, beperkingen, boetes en andere negatieve zaken. Een groter contrast tussen beide werelden bestaat bijna niet, zou je zeggen.
Beveiliging wordt meestal in een strak waterval-achtig proces geborgd, waarin op een vast aantal punten controles vereist worden. Denk maar eens aan het opstellen van requirements, ontwerp, bouw, testen en het in productie brengen. Vaak een sequentieel proces, waarbij er pas kan worden begonnen met de volgende fase als de vorige fase is gecontroleerd, gedocumenteerd en goedgekeurd.
Agile/scrum projecten werken op een compleet andere manier. Zo worden er geen grote en gedetailleerde ontwerpen vooraf gemaakt en vinden testen plaats tijdens het ontwikkelen en niet daarna. Agile/scrum werkt vanuit het principe dat de ontwikkelaars zich bezig houden met de “hoe” vraag en de business (product owner) zich richt op de “wat” vraag. Bij agile/scrum projecten zijn het de ontwikkelaars die bepalen hoe de oplossing het beste tot stand kan komen (en ook wanneer). De business geeft de richting en prioriteit aan, de ontwikkelaars geven hier vervolgens vorm aan. Een agile/scrum team bestaat daarom uit diverse professionals en experts die in staat zijn zelf richting en sturing te geven aan het ontwikkelen van een oplossing. Het agile/scrum team staat of valt met het kunnen vertrouwen op elkaars kunde en betrokkenheid om gezamenlijk tot werkbare oplossingen te komen.
Vier aanknopingspunten
De grote vrees die security professionals hebben met agile/scrum, is dat beveiliging een ondergeschoven kindje wordt omdat het agile/scrum-team hier onvoldoende oog voor heeft. Een logische reactie hierop is proberen om tijdens het agile proces allerlei controles en andere barrières op te werpen. Hiermee dreigen de voordelen van agile/scrum teniet te worden gedaan, waardoor organisaties mogelijk hun concurrentievoordelen kwijt raken.
Deze reactie is het gevolg van de misvatting dat agile/scrum een vrijbrief is voor “vrijheid blijheid”, waarin iedereen maar doet waar hij/zij op dat moment zin in heeft. De spelregels binnen agile/scrum zijn beperkt, maar dienen met grote discipline te worden opgevolgd. Ook het aantal rollen is beperkt (zoals product owner, scrum master en developer), maar die rollen vergen wel grote professionaliteit, kunde en discipline van het agile/scrum-team.
In deze blog besteden we daarom aandacht aan hoe het vertrouwen tussen beiden werelden vergroot kan worden. Hiervoor zullen de volgende aanknopingspunten besproken worden:
- Opstellen van user stories
- Definition of done
- Threat-modeling
- Geautomatiseerde testen
1. Opstellen van user stories
User stories zijn binnen agile korte cases die beschrijven wat de gewenste functionaliteit is die gebouwd moet worden. Ze zijn in de vorm geschreven van “ik als , wil , om ” en worden opgesteld door meerdere stakeholders. Het is daarbij van belang om niet alleen te kijken naar gewenste functionaliteit, maar ook ongewenste effecten. Het is de rol van de security officer/architect om er zorg voor te dragen dat user stories ook rekening houden met ongewenste situaties. Dit kan door user stories explicieter te maken of door additionele vragen te stellen tijdens het opstellen hiervan.
Voorbeeld van het explicieter maken van een user story: “Ik als gebruiker wil een bestelling kunnen plaatsen.” Additionele vragen kunnen zijn in de vorm van: “wil je dat iedereen erbij kan?”, “moet dit altijd kunnen?”, “vanuit elke plek?”. Het resultaat zou de volgende aangepaste user story kunnen zijn: “ik als geautoriseerde gebruiker wil een bestelling kunnen plaatsen.”
Een andere manier is het opstellen van een user story vanuit het perspectief van de security officer/architect als stakeholder: “Ik als security officer, wil dat gevoelige geclassificeerde informatie te allen tijde versleuteld opgeslagen wordt, zodat wij voldoen aan wetgeving XX.YYY”. Voorbeelden van deze “Security Stories” zijn te vinden op de site van SafeCode.org: Practical Security Stories and Tasks for Agile Environments (PDF). Het is aan de product owner om er voor zorgen dat de user stories de juiste prioriteit krijgen. De security officer/architect zal de product owner kunnen ondersteunen bij het in kaart brengen van de mogelijke risico’s en bijhorende prioriteiten.
2. Definition of done
Binnen agile worden producten pas als gereed beschouwd als deze aan bepaalde criteria voldaan hebben. Deze criteria worden bepaald door de product owner in de “Definition of Done” (DoD). Deze DoD kan bestaan uit functionele criteria als “er moet aangetoond worden dat een bestelling correct is afgerekend”. Echter, er kunnen ook beveiliging gerelateerde criteria worden opgenomen, zoals het voldoen aan bepaalde regels in het beveiligingsbeleid.
Het is de verantwoordelijkheid van het gehele agile/scrum-team om zich bewust te zijn van de mogelijke beveiligingsrisico’s en voorwaarden en er voor te zorgen dat deze worden opgenomen in de DoD. Uiteraard kan de security officer/architect het team helpen om de juiste DoD criteria op te stellen.
3. Threat-modeling
Tijdens de planning sessies kan Threat-modeling als hulpmiddel worden gebruikt om er voor te zorgen dat de user stories helder en compleet zijn vanuit security perspectief. Bij Threat-modeling wordt er gekeken aan welke mogelijke dreigingen het te ontwikkelen systeem bloot gesteld kan worden en hoe erg dit is. Dit kan het beste worden gedaan aan de hand van een globaal diagram (bijvoorbeeld gezamenlijk getekend op een whiteboard), waarbij duidelijk wordt hoe de data zich verplaatst door het beoogde systeem. Het door Microsoft ontwikkelde “Elevation of privilege” spel, is hiervoor een bruikbare methode. Hierbij moeten deelnemers in de vorm van een kaartspel mogelijke dreigingen benoemen en beargumenteren. De gevonden dreigingen worden vervolgens vastgelegd en tegelijk wordt ook bepaald welke activiteiten nodig zijn om deze het hoofd te bieden. De dreigingen kunnen worden vastgelegd in additionele abuse(r) stories: een user story vanuit het perspectief van een aanvaller (zoals een hacker).
De threat-modeling activiteiten kunnen worden begeleid door de security officer/architect die er tevens voor kan zorgen dat de beveiligingskennis en -bewustzijn van het gehele agile/scrum team vergroot wordt. De uitkomst kan zijn dat user stories aangepast dienen te worden, of dat er extra ruimte moet worden ingepland om spikes uit te voeren. Spikes zijn activiteiten die moeten leiden tot het beter begrijpen van requirements zodat technische risico’s verminderd kunnen worden en betere planning schattingen afgegeven kunnen worden.
4. Geautomatiseerde testen
Een belangrijk onderdeel van agile is dat er geen aparte testfasen zijn. Bouwen en testen vinden plaats als onderdeel van de sprint. Met andere woorden, er wordt alleen software opgeleverd die een foutloze werking heeft. Het beschikken over goede tools om geautomatiseerde testen uit te voeren, is van essentieel belang om de snelheid in de sprint te houden.
Het gebruik van geautomatiseerde testtools voor het uitvoeren van secure code reviews, pentesten, fuzz-testing, etc. kan bijdragen aan het ontwikkelen van veilige en robuuste oplossingen. Van belang is dat deze testen als onderdeel van de sprints worden uitgevoerd en niet als activiteit aan het einde van het project. Door security integraal op te nemen in de testen, wordt het vertrouwen vergroot dat het uiteindelijke product niet alleen waarde oplevert, maar ook blijft behouden.
Werelden dichterbij elkaar brengen
In deze blog hebben we een aantal mogelijkheden besproken om de agile/scrum en security werelden dichter bij elkaar te brengen. Op het eerste gezicht lijken ze elkaar te bijten, maar als je verder kijkt dan zijn ze twee kanten van dezelfde medaille: beiden werelden hebben als doel waarde te creëren en te behouden.
Deze toenadering vergt echter wel de nodige cultuurverandering. Zo zal de rol van de security officer/architect veranderen van een directieve naar een meer coachende en faciliterende rol richting het agile/scrum-team: van “nee, tenzij” naar “ja, mits”.
Iedereen binnen een agile/scrum-team zal ook kennis en vaardigheden moeten ontwikkelen op het gebied van security, zodat veilige software ontworpen, gebouwd en onderhouden kan worden. Hierbij is een proactieve houding van brengen en halen essentieel. Het bouwen aan vertrouwen is hierbij van essentieel belang. Vertrouwen dat het team over de juiste kennis en vaardigheden beschikt, maar ook de juiste houding heeft waarbij security waarde toevoegt aan de organisatie.
Al deze veranderingen zijn nodig zodat we niet alleen mooie, snelle en functionele auto’s kunnen bouwen, maar dat deze ook nog van goede remmen en airbags zijn voorzien.
Ook interessant
Bekijk hier ons uitgebreide opleidingenaanbod op het gebied van Agile en lees hier meer Agile gerelateerde blogs.