5.3.3. Aanvullende informatie over de maatregelen (ontwikkeling en gebruik van toepassingen)

5.3.3.1. De stappen in de Software Development Lifecycle

In dit overzicht schetsen we kort de 7 stappen in de Software Development Lifecycle: planning, behoefteanalyse, design, ontwikkeling, testing, uitrol en onderhoud.

1) Planning

Dit deel van de levenscyclus bevat de praktische aspecten van de te plannen taken:

• Welke resources heb je nodig (mensen en materiaal)?

• Wat is de geraamde kost?

• Binnen welke timing wil ik live zijn?

• Etc.

2) Behoefteanalyse

Je moet tot een volledig beeld komen van alle behoeftes. Deze kunnen zowel functioneel als nietfunctioneel zijn. Hiervoor ga je te raden bij alle relevante partijen bij de business- en de ICT-diensten, en bij experts in de materie.

In deze fase analyseer je ook de behoeftes rond privacy en informatieveiligheid om deze zo vroeg mogelijk te kennen en hun impact te kunnen inschatten. Dit noemen we ook wel security by design en privacy by design (zie ook later in het document voor meer details).

Hier is het van belang dat je goed inschat welke informatieklasse de behandelde informatie in jouw toepassing/proces heeft. Deze is namelijk bepalend voor welke controles je kunt, of moet implementeren en hoe. Ook al zijn de meeste van deze requirements niet-functioneel, ze hebben ook een invloed op hoe de toepassing werkt en op de exploitatiekost.

Je komt tot een geconsolideerde en uniform geaccepteerde lijst van behoeftes (requirements) die je gaat implementeren. Afhankelijk van je ontwikkelmethode (bv. Waterfall of Agile), kan deze lijst een andere vorm aannemen.

3) Design

Een keer dat de behoeftes duidelijk zijn uitgelijnd, werk je het ontwerp uit. Hoe vertaal je die behoeftes concreet zodat je ze kunt inpassen in een operationele context? Hoe maak je maximaal gebruik van bestaande componenten?

De output is een ontwerp van de beoogde oplossing.

4) Ontwikkeling

In deze fase ga je effectief over tot de concrete ontwikkeling van de software. Dit kan op verschillende manieren gebeuren: ofwel in kleine stukken (Agile), ofwel in één keer (Waterfall). 

Hierbij is het belangrijk om regelmatig af te stemmen met de personen die behoeftes hebben geformuleerd, zodat je zeker bent dat je een antwoord biedt op hun behoeftes.

5) Testing

De testfase is van belang om je ervan te vergewissen dat alles werkt zoals het hoort. Er zijn allerlei soorten tests die je best onderneemt om de juiste werking van je software te testen, zowel als programma op zichzelf als binnen de context waar de software terecht komt. Hierbij kan het gaan om (geen exhaustieve lijst):

• De kwaliteit van de code

• Unit testen

• Integratietesten

• Performantietesten

• Security testen

Een groot deel van deze testen kun je automatiseren. Dit vermindert de werklast en verlaagt ook de kans op fouten in de testen.
Ook in deze fase test je de geïmplementeerde controles die je in de analysefase hebt geïdentificeerd. Dit gaat om zowel puur procedurele controles als om de verificatie van de security en privacy by design-principes.

Deze testen laat je aftekenen door de toepassingseigenaar zodat je er zeker van bent dat de geplande implementatie de beoogde resultaten haalt.

6) Uitrol

De uitrol van de software is een proces op zich en gebeurt liefst zo automatisch mogelijk. Het controleniveau hiervoor staat beschreven in op de pagina 4.7. Minimale maatregelen - Release- en deploymentbeheer .

Als de uitrol van een software functionele of proceswijzigingen bevat, moet je de eindgebruikers hiervan op de hoogte stellen en, indien nodig, opleiden.

7) Onderhoud

De levenscyclus stopt niet bij het opleveren en in productie zetten van de software. Eenmaal live, moet je continu monitoren dat de software naar behoren werkt. Als er problemen ontstaan of als er bugs voorkomen, moet je deze aanpakken en oplossen. 

Dit geldt ook voor het up-to-date houden van de controles voor security en privacy. De evoluties in de gebruikte technieken en controles zelf moet je volgen. Het ICR evolueert ook: nieuwe controles kunnen er bijkomen en verwachtingen rond bestaande controles kunnen veranderen. Deze communiceert het Security Office uiteraard wel via de geijkte governance kanalen. Door het eigenlijk gebruik van de software kunnen er ook nieuwe behoeftes naar boven komen. Deze kunnen dienen als input voor verdere verbeteringen.

Een uiteindelijke stap in het Onderhouds-proces is het afvoeren van een toepassing. Hierbij moet je analyseren in welke mate je de business of technische data nog nodig hebt. Denk hierbij aan wettelijke termijnen van opslag, bijvoorbeeld.

Als je toepassing een deel van een proces ondersteunt, moet je er zeker van zijn dat het proces in zijn geheel kan blijven werken zonder jouw toepassing. Dit kan door een vervangende toepassing, of met work arounds.

5.3.3.2. Het beheer van informatierisico en -veiligheid in deze cyclus

5.3.3.2.1. Security/ Privacy by Design

Je betrekt de security en privacy teams zo snel mogelijk in de uitwerking van je software. Hoe vroeger je dit doet, hoe makkelijker je dit kunt integreren in het design of het ontwerp.

Hoe vroeger je dit doet, hoe goedkoper ook. Volgens een Gartner-rapport is “de kost om een security kwetsbaarheid in productie te verwijderen 30 tot 60 keer duurder is dan de kwetsbaarheid te verwijderen tijdens de ontwerpfase” (eigen vertaling). Kostenefficiënte ontwikkeling houdt dus zo snel mogelijk rekening met security vereisten.

Hetzelfde geldt voor het privacy-aspect. Hoe sneller je een concreet zicht hebt op welke behoeften je moet beantwoorden, hoe makkelijker je ze kunt integreren. Ook hier geldt het kostenbesparend aspect.

Norea (NOREA | Privacy) heeft in hun Privacy Control Framework specifiek voor het privacy by design-aspect adviezen gepubliceerd, waarin ze enkele principes aanbevelen om dit mogelijk te maken.

Security en Privacy by Design helpen er ook voor zorgen dat gebruikers en beheerders de functionele eigenschappen van een toepassing op een veilige manier kunnen gebruiken. Het combineert én de functionaliteit, de privacy én de veiligheid.

5.3.3.2.2. Informatieclassificatie

Bij het ontwikkelen van (nieuwe) software, moet je nagaan in welke Informatieklasse je informatie valt. Dit is een oefening die je kunt doen aan de hand van de pagina’s 1.3. Beschrijving van het ICR . Er staan ook andere tools ter beschikking op pagina 8. Tools en via de website http://vlaanderen.be/informatieveiligheid .

Het resultaat van deze oefening valideer je samen met de Veiligheidsconsulent en/of Data Protection Officer binnen jouw entiteit.

Belangrijk hierbij is om te kijken naar de verschillende kwaliteitskenmerken van je toepassing: vertrouwelijkheid, integriteit en beschikbaarheid. De eisen en controles die je verwacht voor elk van deze kenmerken kunnen heel anders zijn. Alle controles die hierbij noodzakelijk zijn, staan beschreven in het ICR. Ook over deze lijst met controles kun je advies vragen aan de persoon die binnen jouw entiteit verantwoordelijk is voor Informatieveiligheid en Privacy. 

5.3.3.2.3. Risicoanalyse

Bij het releasen van (nieuwe) software, is het niet de bedoeling om nodeloze risico’s te introduceren. Om een volledig beeld van je risicolandschap te krijgen, voer je een risicoanalyse uit. Dit doe je in samenspraak met alle belanghebbenden, inclusief een Veiligheidsconsulent en een Data Protection Officer. Verandert het risicolandschap? Valideer dit met je leidend ambtenaar of hun gedelegeerde.

5.3.3.3. Security per processtap

Planning

Tijdens de planningsfase is het vooral van belang dat je de kosten van en voor security in je budget meetelt. Dit zowel voor het ontwikkelen van of aansluiten op bestaande security bouwstenen, als het integreren van security in de business werking van je toepassing. Als je hiervoor geen budget voorziet vanaf het begin, kun je later in het proces in de problemen komen qua oplevertermijn of voorzien budget.
Hierbij hou je rekening met de verschillende kwaliteitskenmerken: vertrouwelijkheid, integriteit en beschikbaarheid. Elk kenmerk heeft specifieke noden waaraan je moet voldoen en die een invloed hebben op oplevertermijnen en budget.

Behoefteanalyse

Nadat je de inschatting gemaakt hebt van je informatieklasse, kun je op basis van de klasse zien welke controles je effectief moet implementeren. Het hoe hiervan hangt uiteraard af van de context en technische invulling van je toepassing. Het is belangrijk dat je deze controles in je analyse opneemt als niet-functionele behoeftes en deze in de scope van je ontwikkeling opneemt.

Je verzamelt ook alle behoeften rond het naleven van de kwaliteitseisen rond vertrouwelijkheid en integriteit van de verantwoordelijke voor het proces en/of de toepassing. Deze behoeften vertalen zich dan naar controles die je implementeert, onder andere op basis van het ICR.

Controles die je kunt overwegen afhankelijk van het proces waarin de toepassing tussenkomt:

• Betrouwbaarheid van de informatiebronnen

• Hoe hoger de informatieklasse rond Integriteit, hoe hoger de noodzaak om een betrouwbare informatiebron te hebben. De betrouwbaarheid van een leverancier heeft een grote invloed op de waarde die deze data heeft.

• Vanaf Integriteit klasse 3 moet de betrouwbaarheid van de informatiebron gegarandeerd kunnen zijn.

• Integriteit van de aangeleverde data/input

• De verschillende methodes om input te genereren zijn: automatisch en manueel.

• Voor manuele input van data moet je bepaalde controles implementeren afhankelijk van de context van de toepassing

  • Het kan gaan om data input validatie van bepaalde velden (alfanumeriek, grenswaarden, preselectie van waarden, etc.)

    • Dit is relevant vanaf klasse 2

  • Bij automatische input van data definieer je welke data je nodig hebt en welk formaat deze moeten hebben. Als de bronformaten anders zijn dan de inputformaten die jouw toepassing nodig heeft, voorzie je een mechanisme om fouten te detecteren en remediëren

    • Dit is relevant vanaf klasse 2

• Validatie van de output van het proces

• Data kan statisch of niet-statisch zijn in een proces

• Statische data moet aantoonbaar niet-gewijzigd zijn door het proces. Dit kun je aantonen met:

  • Een audit trail

  • Checks op de data zelf, die verifieert dat de data inderdaad niet gewijzigd is

  • Business tracking, waarbij je een staal neemt van de data om manueel/automatisch te verifiëren dat er geen wijzigingen gebeurd zijn

  • Meta-validaties, bijvoorbeeld via hash-functies, total counts op tabellen, etc.

    • Dit is relevant vanaf klasse 2

• Voor niet-statische data moet aantoonbaar zijn dat de wijzigingen legitiem zijn. Dit doe je door:

  • Een audit trail

  • Een validatie van het ontvangende proces dat de datakwaliteit aan de verwachtingen voldoet

  • Business tracking, waarbij je een staal neemt van de data om manueel/automatisch te verifiëren dat de gebeurde wijziging aan de verwachtingen voldoen

    • Dit is relevant vanaf klasse 2

• Operationele controles op de wijzigingen van de data

• Om fouten te vermijden, bouw je controles in om te verifiëren dat gebeurde wijzigingen correct zijn. Dit kan gaan om:

  • Controles op de inputvelden – denk hierbij aan het verifiëren van de data requirements (logische checks op naam, adres, rijksregisternummer, etc.)

    • Dit is relevant vanaf klasse 2

  • Controles op de invoer van data – denk hierbij bijvoorbeeld aan een “4-ogen principe” en dan bij voorkeur een “blind 4-ogen principe”, waarbij twee personen dezelfde input moeten ingeven, los van elkaar en er een automatische controle gebeurt op de juistheid ervan. Is er een verschil tussen beide inputs, gebeurt er een aparte controle

    • Dit is relevant vanaf klasse

• Technische controles de wijzigingen van de data

  •  Je bepaalt vooraf welke data kan wijzigen en hoe. Als er een afwijking van deze normen gebeurt, stel je een waarschuwing in om verder te onderzoeken. De afhandeling gebeurt bijvoorbeeld volgens het incidentproces

    • Dit is relevant vanaf klasse 3

  • Je kunt dit ook verifiëren met de toepassingen/processen die jouw output nodig hebben en laten nakijken of jouw output aan de verwachte kwaliteitseisen voldoet. Als dit aanpassingen in een andere toepassing vergt, moet je dit uiteraard in overleg met de toepassingseigenaar implementeren

    • Dit is relevant vanaf klasse 3

Dit zijn uiteraard enkel voorbeelden. Er zijn ook andere controles die de integriteit van data kunnen garanderen. Afhankelijk van je specifieke context, moet je andere controles implementeren. 

Het objectief is wel altijd om tot een aanvaardbaar risiconiveau te komen. Als er controles gedefinieerd zijn in het ICR die geen risicovermindering opleveren, of die net risico toevoegen, breng je dit in kaart en valideer je dit met een Veiligheidsconsulent en/of Data Protection Officer. Zijn er bepaalde controles die je niet opportuun zijn om in te voeren, dan moet je kijken in welke mate dit een risicoverhoging inhoudt en dit afchecken met een Veiligheidsconsulent en/of Data Protection Officer. Mogelijks moet de leidend ambtenaar of hun gedelegeerde dit ook goedkeuren.  

Het gebruik van authentieke bronnen

Bij het gebruik van authentieke bronnen, moet je er als ontvangende toepassing van uitgaan dat de ontvangen informatie correct is. Blijkt uit objectieve feiten, waarnemingen of stukken dat de aangereikte informatie niet juist is, kun je deze in de toepassing wijzigen.
Zorg er wel voor dat je de bewijzen hiervoor opslaat, zodat je de gemaakte wijziging kunt staven. Voorzie ook een feedback richting authentieke bron, waarbij de te corrigeren informatie vermeldt en de bewijzen meelevert die aantonen dat de geleverde data foutief is.
Als de authentieke bron zijn gegevens niet aanpast, zul je de manuele correctie in jouw toepassingen moeten blijven herhalen. Het is aan te raden deze fout telkens opnieuw te melden aan de authentieke bron.

Design

Tijdens de design-fase maak je de afweging tussen business functionaliteit en mogelijke risico’s. Hierbij hou je ook rekening met de controles die je moet implementeren (zoals hierboven beschreven) en hoe je deze integreert in je toepassing en het daaraan verbonden proces.

Dit kan leiden tot verschillende uitkomsten:

• De functionaliteit kan primeren en je introduceert een risico. Dit moet je dan inschatten en aanvaarden in samenspraak met een Veiligheidsconsulent, een Data Protection Officer en/of een leidend ambtenaar of hun gedelegeerde;

• Security primeert en je wijzigt de functionaliteit. Hiervoor moet je uiteraard een akkoord krijgen van de belanghebbenden;

• Je vindt een evenwicht tussen beiden met een wijziging in functionaliteit en een vermindering in security. Hiervoor spreek je alle belanghebbenden aan, inclusief een Veiligheidsconsulent, Data Protection Officer en de leidend ambtenaar of hun gedelegeerde

Dit is gelinkt aan het proces Risicobeheer (zie 5.5. Minimale maatregelen - proces risicobeheer ). Het proces en de tools om hiermee aan de slag te kunnen staan hier beschreven.

Ontwikkeling

Tijdens de ontwikkeling, specifiek tijdens het schrijven van de code, hou je rekening met gangbare praktijken van secure coding. Specifiek kijk je naar de OWASP-top 10 en verzeker je je ervan dat je geen van deze kwetsbaarheden introduceert in code. Gebruik hiervoor automatische tools. Behalve de puur security aspecten, kijk je ook naar de uitwerking van de controles die je bepaald hebt.
De vertrouwelijkheid en integriteit van de informatie die je behandelt, moet doorheen het hele proces gegarandeerd zijn. Het is enkel zo dat de input aan de verwachte kwaliteitseisen kan voldoen. De exacte implementatie hiervan verschilt per toepassing en hangt uiteraard sterk af van de informatieklasse voor deze kwaliteitskenmerken.

Voor de specifieke eisen rond het testen van de veiligheid van een toepassing tijdens de ontwikkeling ervan, raadpleeg je de pagina 5.6. Minimale maatregelen - Veiligheidtesten. Hierin zit ook een rechtstreekse link met de informatieclassificatie van een toepassing. Hoe hoger de klasse, hoe strenger het controleniveau. 

Testing

Tijdens het testen, test je ook de veiligheid van je toepassing in de specifieke context waarbinnen die zal functioneren. Dit kun je doen in de Test&Integratie-omgeving en in de Acceptatie-omgeving. Dit soort oefening kijkt naar hoe de processen binnen de toepassing werken en hoe iemand binnen deze processen veiligheidslekken kan uitbuiten. Hiervoor gebruik je ook automatische tools.

Tegelijkertijd moet je in deze fase er zeker van zijn dat de toepassing geschikt en inzetbaar is. 

Meer details hierover staan beschreven in het document "Life Cycle Management".

Uitrol

Specifieke controles die je binnen deze processtap moet uitvoeren, staan uitgelegd op pagina 4.7. Minimale maatregelen - Release- en deploymentbeheer.

Onderhoud

Veiligheidstesten

Van zodra je toepassing in productie staat, moet je de veiligheid ervan blijven borgen. Dit kan op verschillende manieren:

• Via security monitoring: je definieert welke evenementen je wilt loggen en monitoren. Meer details hierover vind je op pagina 5.2. Minimale maatregelen - logging en monitoring (SIEM);

• Via penetratietests: je bepaalt de scope van de test en laat die regelmatig uitvoeren op je productie-omgeving;

• Via bug bounty of responsible disclosure programma’s: je nodigt zogenaamde white hat hackers uit om kwetsbaarheden op je toepassingen te melden en beloont hen hiervoor.

Dit staat beschreven op pagina 5.6. Minimale maatregelen - Veiligheidtesten.

(Extended) support 

Eenmaal een toepassing in productie staat, moet je als beheerder ervoor zorgen dat je deze voldoende kunt ondersteunen. Dit geldt voor de gebruikers en voor de infrastructuur – en zeker ook voor de diensten die afhangen van leveranciers. Het is aan de beheerder van de toepassing om ervoor te zorgen dat de toepassing altijd een gepaste ondersteuning geniet.