| Note |
|---|
Om review makkelijker te maken werden de wijzigingen tegenover ICRv2 als volgt in de tekst duidelijk gemaakt:
|
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 niet functioneel zijn. Hiervoor ga je te raden bij alle relevante partijen bij de business- en de ICT-diensten, en bij experts in de materie.
...
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):
...
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 3.0 .
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.
...
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.
...
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. 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 CISO en een Data Protection Officer. Verandert het risicolandschap? Valideer dit met je leidend ambtenaar of hun gedelegeerde.
| Info |
|---|
Opmerking |
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.
...
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 CISO 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 CISO 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.
...
De functionaliteit kan primeren en je introduceert een risico. Dit moet je dan inschatten en aanvaarden in samenspraak met een CISO, 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 CISO, Data Protection Officer en de leidend ambtenaar of hun gedelegeerde
Dit is gelinkt aan het proces Risicobeheer (zie 5.5. Minimale maatregelen - proces risicobeheer 3.0 ). 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.
...
Tegelijkertijd moet je in deze fase er zeker van zijn dat de toepassing geschikt en inzetbaar is.
Uitrol
Specifieke controles die je binnen deze processtap moet uitvoeren, staan uitgelegd op pagina 4.7. Minimale maatregelen - Release- en deploymentbeheer 3.0 .
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) 3.0 ;
Via penetratietests: je bepaalt de scope van de test en laat die regelmatig uitvoeren op je productie-omgeving;
Via responsible disclosure programma’s: je nodigt zogenaamde white hat hackers uit om kwetsbaarheden op je toepassingen te melden en beloont hen hiervoor.
(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.