Meteen naar de inhoud

Shift Left Security

Eerder nadenken over informatiebeveiliging is een mooi streven. Het voorkomt dat het werk achteraf opnieuw moet worden gedaan. Binnen softwareontwikkeling heeft dit de naam ‘Shift Left Security‘, omdat zo aan het begin van een proces (links) security aan bod komt.

Overigens hoeft het niet per se een technische discussie te zijn: belanghebbenden uit de business kunnen zelf ook een shift left maken door security op te nemen in beleid, acceptatiecriteria en checklists. Vanuit de Avg zijn privacy by design & default inmiddels bekende hieraan gerelateerde onderwerpen.

Starten met informatiebeveiliging

Beginnen met het verbeteren van de informatiebeveiliging kan een lastige opdracht zijn. Een hulpmiddel is het uitvoeren van een risicoanalyse. Deze doorloopt globaal gezien altijd de volgende fasen: (1) bepaal de belangrijkste informatiesystemen/stromen, (2) koppel de dreigingen en kwetsbaarheden, en (3) selecteer en pas de juiste maatregelen toe. Herhaal dit proces jaarlijks of bij veranderingen.

Het is gelukkig niet nodig om alles zelf te bedenken: gebruik bijvoorbeeld ‘SPARK‘ als model, ‘MAPGOOD‘ voor de dreigingen of ‘RAVIB‘ als complete tool voor een risicoanalyse.

Business analyse

Een business analyse zorgt ervoor dat de doelen van een organisatie worden vertaald in specifieke acties, om deze doelen te kunnen behalen. Over het algemeen is een business analyse mogelijk op drie niveaus:

  • Strategische analyse – wat zijn onze sterke punten?
  • Procesanalyse – hoe werken processen en systemen optimaal samen?
  • Productanalyse – welke (IT)-oplossing sluit het beste aan bij onze wensen?

Veranderingen in de informatievoorziening en/of het aanschaffen, dan wel bouwen, van informatiesystemen hebben baat bij een business analyse vooraf.

Kijk voor meer informatie eens op bptrendsassociates.com.

Functioneel ontwerp

Een veelgebruikte aanpak om werkzaamheden in de IV/IT te beschrijven is het maken van een ‘functioneel ontwerp’. In een functioneel ontwerp beschrijf je de functionaliteiten die nodig zijn als uitwerking van de wensen van de klant of gebruiker.

Praktisch gezien wordt hiervoor vaak gekozen voor het format van ‘User Story’. Een User Story schrijf je vanuit de vraagsteller: als [rol] wil ik [functionaliteit] zodat ik [x] kan bereiken met [x] randvoorwaarden.

Het stukje randvoorwaarden vind ik een goede toevoeging om te zorgen dat de User Stories specifiek genoeg worden opgeschreven. Daarbij raad ik aan om: A. altijd de ‘non-functionals’ (bijv. performance) en B. een referentie naar het grotere plaatje (bijv. een stroomschema, wireframe of architectuur) op te nemen.

Scoping van een project

Voor een project binnen de informatievoorziening of IT is het verstandig vooraf te bepalen wat er wordt gedaan en wat niet. Met andere woorden: wat is in scope en wat is out of scope.

Hanteer bijvoorbeeld de volgende stappen:

  1. Begin met het in kaart brengen van de belanghebbenden
  2. Achterhaal de ‘wens achter de vraag’ via de voice of the customer of voice of the business
  3. Werk dit uit door te bepalen wat de succesfactoren zijn: critical to quality
  4. Plot deze factoren met het zgn. KANO-model om de volgorde (lees: prioriteit) vast te stellen

De uitkomst kan als input dienen voor de inhoud van een projectvoorstel of projectplan – afhankelijk van hoe uitgebreid de stappen worden doorlopen – en is aan te vullen met een risico-analyse, begroting, etc.

Succes!