Partnerpagina Capgemini

- - - - -

Security testen, je kunt er niet vroeg genoeg mee beginnen

door: Sanne Kuijpers

artikelen, 8 november 2017

Security staat steeds hoger op de agenda van overheidsorganisaties en bedrijven. Door de digitale transformatie en het groeiend aantal security incidenten, wordt adequate beveiliging steeds belangrijker. De SSD testtoolkit biedt uitkomst.

Capgemini

Beeld: Dreamstime

Organisaties zien steeds meer het belang – en de uitdaging – in van veilige applicaties; applicaties waarbij de gebruikte soft- ware en het ontwikkelproces voldoen aan algemeen aanvaarde beveiligingsvereisten.

Met het oog op de digitale transformatie en hiermee gepaard gaande directe klantinteractie en data neemt dit belang alleen maar toe. Om deze reden heeft het Centrum voor Informatiebeveiliging en Privacybescherming (CIP) het Secure Software Development (SSD)-normenkader ontwikkeld waaraan organisaties de veiligheid van hun applicaties kunnen toetsen. Om vast te stellen of applicaties aan dit SSD-normenkader voldoen heeft Capgemini de SSD testtoolkit ontwikkeld. Met als doel om op een gestructureerde manier inzichtelijk te maken in hoeverre een applicatie aan de security eisen voldoet.

Voor veel organisaties zijn veilige applicaties waarbij de software en het ontwikkelproces voldoen aan algemeen aanvaardbare beveiligingseisen, een uitdaging. Vaak zijn de eisen redelijk abstract, terwijl organisaties juist behoefte hebben aan een concrete checklist waaraan zij hun applicaties kunnen toetsen. Daarnaast krijgen leveranciers van klanten regelmatig een bepaalde security baseline opgelegd, of een richtlijn waaraan zij moeten voldoen, zoals OWASP of ASVS.

Veel overheidsinstanties gebruiken de SSD-normen van het CIP als baseline. Maar hoe toont een organisatie aan dat haar software, applicatie/systemen en (ontwikkel)processen aan deze richtlijnen voldoen? Hiervoor is meestal geen integrale security oplossing voorhanden. Deze vraag speelt ook bij klanten van Capgemini waar het principe van ‘continuous improvement’ wordt gehanteerd. Organisaties die volgens dit principe werken zijn zich bewust van security als onderdeel van de kwaliteitsstrategie, maar stoeien met de vraag hoe ze het beste inzicht krijgen in de kwaliteit van de veiligheid van de applicatie(s) die ze ontwikkelen. En hoe kan security worden meegenomen in het hele ontwikkel- en sprintproces?

Met deze vragen in het achterhoofd biedt Capgemini een on site pilot aan met de SSD testtoolkit die al in de praktijk is beproefd. Belangrijke aandachtspunten zijn dat de te ontwikkelen eindproducten inpasbaar moeten zijn in het gehanteerde AGILE/SAFE voortbrengingsproces, en dat de producten zo goed mogelijk moeten aansluiten bij de in gebruik zijnde tooling. Relevante aandachtspunten voor iedere organisatie.

Uitvoering

Wat zijn de belangrijkste aandachtspunten bij uitvoering van de SSD testtoolkit? Allereerst wordt de scope van het project vastgesteld. Welke applicaties worden bijvoorbeeld uitgelicht en waarom wordt voor deze applicaties gekozen? Ook moet worden gekeken naar de testafspraken binnen de organisatie: worden de geldende generieke afspraken als uitgangspunt genomen of de testafspraken uit de SSD toolkit?

Na het bepalen van de scope kan de risicoanalyse worden uitgevoerd per onderdeel van de gedefinieerde applicatie(s). Daarop worden de fysieke testgevallen bepaald, op basis van een vooraf door Capgemini gemaakte matrix met logische testgevallen (de SSD toolkit) gekoppeld aan alle 31 SSD-normen uit het normenkader van het CIP. Dit zijn niet alleen testen in de testfase, maar testen & reviewactiviteiten die alle fasen van het ontwikkelproces raken. Zoals het checken van normalisatie in de requirements (SSD norm 19), het uitvoeren van een codere- view met een developer op codering van dynamische onderde- len of commentaarregels (SSD norm 20 en 28), een sql injectie proberen uit te voeren (SSD norm 21) of om sessie versleuteling testen (SSD norm 4). Hieruit volgt een eindrapportage met bevindingen en adviezen en een ontwikkelde basisaanpak voor het testen van de security van de applicatie, afgestemd op het voortbrengingsproces en de specifieke applicatie.

Dit proces wordt uitgevoerd voor bestaande onderdelen van de applicatie, maar kan ook worden opgepakt per story en per sprint. Een story wordt uitgewerkt in een refinement sessie, waarin stap 1 en 2 worden genomen. Daarna wordt de applicatie gebouwd en getest, waarbij, naast functionele testen, ook security testen worden meegenomen in stap 3 en 4. De stap rapporteren zit verweven in het testproces en er wordt direct geschakeld binnen het team (analyse, development en productowner). Bij stap 4 worden alle testen die geautomatiseerd kunnen worden direct geautomatiseerd. Zo wordt, naast een handmatige testset, ook een geautomatiseerde testset opgebouwd, die standaard mee kan draaien in de regressie.

Wat levert de tookkit op?

De SSD testtoolkit komt tegemoet aan de behoefte om ont- wikkelteams tijdens het volgen van de Agile Scrum werkwijze te voorzien van feedback, zodat eventuele securitybevindingen zo vroeg mogelijk worden opgemerkt en al tijdens de sprint kunnen worden verholpen. Het doel van de toolkit is om op een gestructureerde manier inzichtelijk te maken in hoeverre de applicatie aan de security requirements voldoet. De focus ligt tijdens het hele ontwikkelproces op secure software development. Hierdoor ontstaat meer inzicht in de beveiliging in het hele proces en is er meer aandacht en bewustzijn voor dit onderwerp in en rondom de teams.

De kracht van de SSD testtoolkit is dat securitytesten in het hele ontwikkelproces kunnen worden verweven. Hierdoor worden bevindingen eerder opgemerkt en neemt de aandacht voor security zowel binnen als buiten de ontwikkelteams beduidend toe. Bovendien worden de teams direct voorzien van feedback, niet alleen functioneel, maar ook op security aspecten van het nieuwe onderdeel van de applicatie. Dus waarom pas starten met securitytesten aan het einde van een proces? Je kunt niet vroeg genoeg beginnen!

Sanne Kuijpers is senior security test consultant

tags:

- - - - -

De met een * gemarkeerde velden zijn verplicht. U ziet eerst een voorbeeld en daarna kunt u uw bijdrage definitief plaatsen. Uw e-mailadres wordt niet op de site getoond. Reacties zonder achternaam worden verwijderd. Anoniem reageren alleen in uitzonderlijke gevallen in overleg met de redactie.