null


Digitaal Vlaanderen | Team Informatieveiligheid (TIV)

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 20 Current »

Het beleid van veilig ontwerpen en ontwikkelen bevat de maatregelen om op een veilige manier producten en interne toepassingen te implementeren door vanaf de start bij het ontwerp tot aan de ingebruikname een aantal informatieveiligheidseisen in acht te nemen.

Inhoud

Doel

(blue star) DOELSTELLINGEN

Het beleid draagt bij tot de realisatie van volgende informatieveiligheidsdoelstellingen van de organisatie:

  • Page:
    OD.05

    We nemen beveiligingseisen ten harte gedurende de volledige levenscyclus van een product of dienst.

Beleid

Projectmanagement

Informatieveiligheid behoort te worden geïntegreerd in projectmanagement om ervoor te zorgen dat informatieveiligheidsrisico's in alle fases van een project worden aangepakt. Dit kan worden toegepast op elk type project ongeacht de complexiteit, omvang, duur, discipline of het toepassingsgebied (bijvoorbeeld een project voor een proces voor kernactiviteiten, een ICT-project, een facility management project, enz.). 

Het vroegtijdig nadenken over informatieveiligheidseisen voor het product of de dienst (bijv. tijdens de plannings- en ontwerpfasen) kan leiden tot doeltreffender en kostenefficiëntere oplossingen voor informatieveiligheid. 

Toegangsbeveiliging op de broncode

Broncode wordt beheerd binnen het GIT versiebeheer systeem. Dit maakt het mogelijk voor meerdere ontwikkelaars om gelijktijdig aan projecten samen te werken. Zie Termen en definities voor een formele definitie van “broncode”. Dit beleid gaat over alle situaties waar broncode is opgeslagen.

Beveiligen tijdens de ontwikkelcyclus

De ontwikkelcyclus voor systemen zoals producten en interne toepassingen, bestaat uit de zogenaamde OTAP fases, waarbij OTAP staat voor:

  • Ontwikkeling (O): Dit is de fase waarin software wordt ontwikkeld of aangepast. Ontwikkelaars schrijven nieuwe code of passen bestaande code aan om nieuwe functionaliteiten toe te voegen of bugs op te lossen. Deze ontwikkelingen vinden plaats in een gecontroleerde ontwikkelomgeving.

  • Test (T): Nadat de ontwikkeling is voltooid, wordt de software getest in een aparte testomgeving om te controleren of alles naar behoren werkt en of de nieuwe functionaliteiten correct functioneren. Eventuele fouten worden opgespoord en opgelost voordat de software wordt vrijgegeven voor productie.

  • Acceptatie (A): In deze fase wordt de software getest in een omgeving die zo dicht mogelijk bij de uiteindelijke productieomgeving ligt. Dit wordt gedaan om ervoor te zorgen dat de software correct functioneert in een omgeving die vergelijkbaar is met de echte wereld. Het doel is om te verifiëren of de software voldoet aan de vereisten en verwachtingen van de eindgebruikers.

  • Productie (P): Na succesvolle tests en acceptatie wordt de software vrijgegeven voor gebruik in de productieomgeving. Dit is de omgeving waar de software daadwerkelijk wordt ingezet en gebruikt door eindgebruikers.

Toepassingsbeveiligingseisen

Algemene beveiligingseisen

Beveiligingseisen voor transactie-systemen 

Transactie-systemen zijn systemen die betrokken zijn bij het uitvoeren, verwerken, en beheren van transacties, zoals financiële overdrachten, e-commerce, en gegevensuitwisseling. Deze diensten verwerken vaak gevoelige informatie en vereisen daarom sterke beveiligingsmaatregelen om de integriteit, vertrouwelijkheid, en beschikbaarheid van de gegevens te beschermen.

Veilige systeemarchitectuur en technische uitgangspunten

Systemen kunnen beveiligingsmaatregelen implementeren in de verschillende architectuurlagen, met name:

  • Bedrijfslaag: Deze laag richt zich op de organisatorische aspecten, waaronder bedrijfsprocessen, governance en beleid. Het definieert hoe de bedrijfsdoelstellingen worden bereikt en hoe technologie deze doelstellingen ondersteunt. Beveiliging in deze laag zorgt ervoor dat bedrijfsprocessen en besluitvorming rekening houden met Informatieveiligheidseisen.

  • Gegevenslaag: Omvat de structuur, opslag, en het beheer van data binnen de organisatie. Het gaat hierbij om databases, datawarehouses, en de manier waarop data wordt gecategoriseerd, toegankelijk gemaakt, en beschermd. Beveiligingsmaatregelen op deze laag richten zich op data-integriteit, vertrouwelijkheid, en beschikbaarheid.

  • Toepassingslaag: Deze laag bevat de software en applicaties die worden gebruikt door de organisatie. Het gaat om het ontwerp en de ontwikkeling van applicaties met een focus op hoe deze applicaties interageren met de gebruiker en andere systemen. Beveiliging in deze laag richt zich op het beschermen van de applicaties tegen kwetsbaarheden en aanvallen, zoals bijvoorbeeld SQL injectie of cross-site scripting.

  • Technologielaag: Betreft de fysieke en virtuele technologie-infrastructuur, zoals servers, netwerken, en cloud services. Deze laag zorgt voor de ondersteuning van alle IT-diensten en -toepassingen. Beveiligingsaspecten omvatten netwerkbeveiliging, fysieke beveiliging, en het beheer van toegangsrechten.

Veilig coderen

Deze paragraaf behandelt de waarborgen dat veilige software wordt geschreven waardoor het aantal potentiële Informatieveiligheidskwetsbaarheden in de software wordt beperkt.

Planning en voorafgaand aan het coderen 

Tijdens het coderen 

Beoordeling en onderhoud  

Testen van de beveiliging tijdens ontwikkeling en acceptatie

Deze paragraaf beschrijft het valideren van de informatieveiligheidseisen wanneer toepassingen of code in de productieomgeving worden uitgerold.

Implementatiemaatregel

Nieuwe informatiesystemen, upgrades en nieuwe versies MOETEN tijdens de ontwikkelingsprocessen grondig worden getest en geverifieerd. Het testen van de beveiliging MOET een integraal onderdeel te zijn van het testen voor systemen of componenten. 

Implementatiemaatregel

Het testen van de beveiliging MOET worden uitgevoerd aan de hand van een verzameling eisen die als functioneel of niet-functioneel kunnen worden uitgedrukt. Het testen van de beveiliging MOET het volgende omvatten: 

Implementatiemaatregel

Testplannen MOETEN met behulp van een verzameling criteria worden vastgesteld. De omvang van de tests moet in verhouding staan tot het belang, de aard van het systeem en de mogelijke impact van de verandering die wordt ingevoerd. Het testplan moet het volgende omvatten: 

  • een gedetailleerd schema van de activiteiten en tests; 

  • input en verwachte output onder allerlei omstandigheden; 

  • criteria om de resultaten te evalueren;  

  • een besluit over verdere acties naarmate die nodig zijn 

Het is niet nodig om een register te gaan bijhouden van alle tests. Wel is het belangrijk dat er een document bestaat wat als handboek voor het testen van het product gebruik kan worden met:

  • Doelstellingen:

    • Duidelijke vermelding van de doelen van het testen;

    • Wat wordt er verwacht te worden bereikt door middel van de tests;

  • Scope:

    • Welke delen van de software worden getest en welke niet;

    • Inclusief functionaliteiten, platforms, apparaten, enz.;

  • Teststrategie:

    • Beschrijving van de aanpak voor het testen;

    • Inclusief testmethoden (zoals functionele tests, regressietests, prestatietests, etc.) niet uitsluitend geautomatiseerde testplatformen;

    • Prioritering van tests;

    • Gebruikte tools en technologieën;

  • Hoe de verschillende tests uitgevoerd worden.

Men kan de volgende types van testen onderscheiden:

  • Regressietests: Regressietests zijn een type softwaretest die wordt uitgevoerd om te controleren of recente code- of omgevingswijzigingen geen ongewenste effecten hebben op bestaande functionaliteiten. Het doel van regressietests is om te verzekeren dat nieuwe updates, bugfixes of functionaliteiten de bestaande code niet breken of nieuwe fouten introduceren in het systeem. Dit type test is cruciaal in continu ontwikkelende softwareprojecten om te garanderen dat de applicatie stabiel en betrouwbaar blijft door de tijd heen. Regressietests kunnen handmatig of automatisch worden uitgevoerd, waarbij automatische tests vaak de voorkeur hebben voor hun efficiëntie en herhaalbaarheid.

  • Codescans: Codescans, of statische code-analyse, zijn processen waarbij tools worden gebruikt om de broncode van een applicatie te analyseren zonder deze daadwerkelijk uit te voeren. Deze scans zoeken naar patronen in de code die kunnen wijzen op fouten, kwetsbaarheden, stijlfouten of afwijkingen van best practices. Codescans zijn een essentieel onderdeel van de ontwikkelingscyclus om de kwaliteit en veiligheid van de code te verbeteren, risico's te verminderen en de naleving van coderingsstandaarden te waarborgen. Statische code-analyse helpt bij het vroegtijdig identificeren van problemen die in latere stadia van ontwikkeling of na uitrol moeilijker en kostbaarder zijn om op te lossen.

  • Penetratietests: Penetratietests, vaak "pen-tests" genoemd, zijn een methode voor het evalueren van de beveiliging van een IT-infrastructuur of applicatie door actief te proberen deze te exploiteren. Het doel van penetratietests is om kwetsbare punten of beveiligingslekken te identificeren die een aanvaller zou kunnen gebruiken om ongeautoriseerde toegang te krijgen tot systemen of gegevens, of om andere kwaadaardige activiteiten uit te voeren. Tijdens een penetratietest simuleren beveiligingsexperts aanvallen op netwerken, applicaties, en andere systemen op dezelfde manier als een echte aanvaller dat zou doen, maar dan op een gecontroleerde en overeengekomen manier. De resultaten van penetratietests bieden waardevolle inzichten in de effectiviteit van de huidige beveiligingsmaatregelen en waar verbeteringen nodig zijn.

Wijzigingsbeheer

Het waarborgen van informatieveiligheid bij veranderingen is belangrijk bij het uitrollen en in productie brengen van nieuwe versies van informatiesystemen. De implementatiemaatregelen voor wijzigingsbeheer zijn beschreven binnen het beleidsdomein IT service management.

Personeel

Appendix

Relatie van het beleid met andere richtlijnen en standaarden

Regelgeving en standaarden (L1)

ISO 27001:2022 (Annex A)

Document status

Titel

Auteur

Datum

Versie

Opmerkingen

Beleid voor veilig ontwerpen en ontwikkelen

Guido Calomme

31/05/2024

1.0

Wijzigingsbeheer verplaatst naar beleid IT Service Management.

  • No labels