Excerpt | ||
---|---|---|
| ||
Een veilige toepassing implementeren door vanaf de start bij het ontwerp tot aan de ingebruikname een aantal informatieveiligheidseisen in acht te nemen. |
DOELSTELLINGENHet beleid draagt bij tot de realisatie van volgende informatieveiligheidsdoelstellingen van de organisatie:
|
DREIGINGENHet beleid draagt bij om de volgende dreigingen te verminderen of te voorkomen:
|
Informatiebeveiliging in projectmanagement
Panel | ||||||
---|---|---|---|---|---|---|
| ||||||
Informatiebeveiliging behoort te worden geïntegreerd in projectmanagement om ervoor te zorgen dat informatiebeveiligingsrisico's in het kader van projectmanagement worden aangepakt. Dit kan worden toegepast op elk type project ongeacht de complexiteit, omvang, duur, discipline of het toepassingsgebied (bijv. een project voor een proces voor kernactiviteiten, IT, ‘facility management’ of andere ondersteunende processen). |
Panel | ||||||
---|---|---|---|---|---|---|
| ||||||
Het vroegtijdig nadenken over informatiebeveiligingseisen voor het product of de dienst (bijv. tijdens de plannings- en ontwerpfasen) kan leiden tot doeltreffender en kostenefficiëntere oplossingen voor kwaliteits- en informatiebeveiliging. |
Risico binnen projectmanagement
Risico’s binnenInfo |
---|
Informatieveiligheidsbeleid is van toepassing op alle soorten projecten en dus niet alleen op technische projecten. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelInformatiebeveiliging moet worden geïntegreerd in projectmanagement om ervoor te zorgen dat informatiebeveiligingsrisico's in het kader van projectmanagement worden aangepakt. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelNaast het beleid voor Risicobeheer MOETEN de volgende maatregelen worden gevolgd tijdens het projectmanagent:
|
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelInformatiebeveiligingseisen [bijv. [Beveiligingseisen voor toeppassingen]], eisen inzake de naleving van intellectuele-eigendomsrechten (Zie Leveranciersrelaties) MOETEN in de vroege stadia van projecten worden aangepakt. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelDe passendheid van de informatiebeveiligingsoverwegingen en -activiteiten MOET in vooraf bepaalde stadia worden gecontroleerd door geschikte personen of governance-instanties, zoals de projectstuurgroep. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelVerantwoordelijkheden en bevoegdheden voor informatiebeveiliging relevant voor het project MOETEN worden gedefinieerd en worden toegewezen aan gespecificeerde rollen. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelInformatiebeveiligingseisen voor de door het project te leveren producten of diensten MOETEN worden vastgesteld met gebruikmaking van verschillende methoden zoals het afleiden van nalevingseisen uit informatiebeveiligingsbeleid, onderwerpspecifieke beleidsregels en regelgeving. Verdere informatiebeveiligingseisen kunnen worden ontleend aan activiteiten zoals dreigingsmodellering, beoordelingen van incidenten, het gebruik van kwetsbaarheidsdrempels of het opstellen van noodplannen om zo te bewerkstelligen dat de architectuur en het ontwerp van informatiesystemen worden beschermd tegen bekende dreigingen die gebaseerd zijn op de operationele omgeving. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelInformatiebeveiligingseisen MOETEN worden vastgesteld voor alle soorten projecten, niet alleen voor ICT-ontwikkelprojecten. Bij het vaststellen van deze eisen moet het volgende in aanmerking worden genomen:
|
Toegangsbeveiling op de broncode
Panel | ||||||
---|---|---|---|---|---|---|
| ||||||
Zie de Glossary voor een formele definitie van Broncode. Dit beleid gaat over alle situaties waar broncode is opgeslagen. |
Normaliter word code beheerd binnen GIT versiebeheer systeem.
GIT is een gedistribueerd versiebeheersysteem dat wordt gebruikt om wijzigingen in de broncode bij te houden tijdens softwareontwikkeling. Het maakt het mogelijk voor meerdere ontwikkelaars om gelijktijdig aan projecten samen te werken door revisies, branches en samenvoegingen efficiënt te beheren.
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelBroncode MOET gecontroleerd centraal worden opgeslagen in een versiebeheersysteem voor code (GIT). |
Panel
Pull requests:
Branching: Het afschermen van een main of master tak en het mergen word alleen gedaan door lead developers.
Het beperken van access tot pipelines en andere deployment tooling: Alleen DevOps engineers hebben in principe toegang nodig tot deployment tooling.
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelLees- en schrijftoegang tot broncode MOET afgestemd worden conform Toegangsbeveiliging |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelOm de impact van niet-geautoriseerde wijzigingen en het lekken van vertrouwelijke informatie via broncode te minimaliseren, wordt geadviseerd om de broncodebibliotheken terdege af te schermen. Voor deze beveiliging worden volgende richtlijnen gehanteerd:
|
Beveiligen tijdens de ontwikkelcyclus
Panel | ||||||
---|---|---|---|---|---|---|
| ||||||
Bewerkstelligen dat informatiebeveiliging binnen de veilige ontwikkelcyclus van software en systemen wordt ontworpen en geïmplementeerd. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelOntwikkel-, test-, acceptatie-, en productieomgevingen MOETEN gescheiden worden. |
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.
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelBeveiligingseisen MOETEN worden gespecificeerd en geïntegreerd tijdens de specificatie- en ontwerpfase (zie 1.1). Ook dient een risico assessment te worden uitgevoerd die een sterke nadruk legt op veiligheid. |
Info |
---|
Software architectuur maakt gebruik van requirements engineering, de implementatie maatregelen in het ISMS zover toepasbaar, behoren terug te komen in het software ontwerp. |
Panel | ||||||
---|---|---|---|---|---|---|
| ||||||
De productieomgeving en de gegevens beschermen tegen compromittering door ontwikkel- en testactiviteiten. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Implementatiemaatregel |
Het testen van de systemen en de beveiliging, zoals regressietests, codescans en penetratietests MOETEN worden uitgevoerd.
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.Met de volgende aspecten MOET rekening te worden gehouden:
|
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelIn alle gevallen MOETEN de ontwikkel- en testomgevingen te worden beschermd, waarbij het volgende in aanmerking behoort te worden genomen:
|
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Implementatiemaatregel |
Beveiliging in het versiebeheer:
Elk gebruikt versiebeheer dient volgens volgende regels opgesteld te worden:
Een versie nummer voor een ontwikkeling dient te bestaan uit 3 componenten
MAJOR: wordt verhoogd bij nieuwe features of uitbreidingen die niet compatibel zijn bij de vorige MAJOR-versie
MINOR: wordt verhoogd bij het toevoegen van functionaliteit die compatibel is met de huidige MAJOR-versie
PATCH: wordt verhoogd bij het toevoegen van bugfixes binnen de huidige MINOR.
Bovenstaande versie-bouwstenen dienen samengevoegd te worden tot het formaat: <MAJOR.MINOR.PATCH>
Aanvullende labels voor prerelease (TNI, BETA, DEV) en build-metadata dienen toegevoegd te worden aan het bovenstaande formaat. Voorbeelden van deze aanvullende labels in combinatie met bovenstaand formaat zijn:
1.0.0-alpha
1.2.1-beta.11
3.2.1-rc.1
2.2.1-beta.20042021.1
Als versie raamwerk volgen we het Semantisch Versioning principe, zoals beschreven op http://semver.org
Het MOET niet mogelijk te zijn dat éen persoon zonder voorafgaande beoordeling en goedkeuring veranderingen aan zowel de ontwikkeling als de productie kan doorvoeren. Dit kan bijvoorbeeld worden bereikt door toegangsrechten te scheiden of door middel van regels die worden gemonitord. In uitzonderingssituaties behoren aanvullende maatregelen zoals het bijhouden van gedetailleerde logbestanden en realtimemonitoring te worden geimplementeerd om veranderingen door onbevoegden te detecteren en er actie op te ondernemen. |
Testen
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelHet testen van de systemen en de beveiliging, zoals regressietests, codescans en penetratietests MOETEN worden uitgevoerd. |
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.
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Implementatiemaatregel |
Medewerkers MOETEN conform Personeelsbeveiliging geselecteerd te worden voor ontwikkelrollen. Medewerkers die een rol opnemen in de ontwikkeling van software moeten opgeleid worden in de toepassing van informatieveiligheidsprincipes en het toepassen van veilige coderingstechnieken, waaronder:
· hoe coderingskwetsbaarheden kunnen worden vermeden, en
· begrijpen hoe gevoelige gegevens in het geheugen worden verwerkt
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelDe betrokken Product Owner moet het niveau van beveiligingsvaardigheden en kennis die vereist is voor het ontwikkelingsproces definiëren en stelt de training voor aan HR. HR omvat passende training in het opleidingstraject van de ontwikkelaars. |
Toepassingsbeveiligingseisen
panelIconId | atlassian-info |
---|---|
panelIcon | :info: |
bgColor | #FFFFFF |
Beveiliging in het versiebeheer: Elk gebruikt versiebeheer dient volgens volgende regels opgesteld te worden:
Bovenstaande versie-bouwstenen dienen samengevoegd te worden tot het formaat: <MAJOR.MINOR.PATCH> Aanvullende labels voor prerelease (TNI, BETA, DEV) en build-metadata dienen toegevoegd te worden aan het bovenstaande formaat. Voorbeelden van deze aanvullende labels in combinatie met bovenstaand formaat zijn:
Als versie raamwerk volgen we het Semantisch Versioning principe, zoals beschreven op http://semver.org |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelMedewerkers MOETEN conform Personeelsbeveiliging geselecteerd te worden voor ontwikkelrollen. Medewerkers die een rol opnemen in de ontwikkeling van software moeten opgeleid worden in de toepassing van informatieveiligheidsprincipes en het toepassen van veilige coderingstechnieken, waaronder: · hoe coderingskwetsbaarheden kunnen worden vermeden, en · begrijpen hoe gevoelige gegevens in het geheugen worden verwerkt |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Implementatiemaatregel |
De betrokken Product Owner moet het niveau van beveiligingsvaardigheden en kennis die vereist is voor het ontwikkelingsproces definiëren en stelt de training voor aan HR. HR omvat passende training in het opleidingstraject van de ontwikkelaars. |
Toepassingsbeveiligingseisen
Panel | ||||||
---|---|---|---|---|---|---|
| ||||||
Onder toepassingen verstaan we voornamelijk software applicaties die zijn ontwikkeld maar applicaties die zijn aangekocht zijn ook van toepassing. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Implementatiemaatregel |
Toepassingsbeveiligingseisen MOETEN het volgende te omvatten, al naargelang de situatie:
Beveiligingseisen voor toepassingen MOETEN worden geïdentificeerd en gespecificeerd aan de hand van een risicobeoordeling (zie Proces - Informatieveiligheid risicobeheer ). De eisen moeten met ondersteuning van informatiebeveiligingsspecialisten worden ontwikkeld. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelToepassingsbeveiligingseisen MOETEN het volgende te omvatten, al naargelang de situatie:
|
Transactionele diensten
Panel | ||||||
---|---|---|---|---|---|---|
| ||||||
Transactionele diensten zijn processen 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. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelIn aanvulling hierop behoort voor toepassingen die transactionele diensten tussen de organisatie en een partner aanbieden, het volgende in aanmerking te worden genomen bij het identificeren van informatiebeveiligingseisen:
|
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelToepassingen voor elektronisch bestellen en betalen In aanvulling hierop behoort het volgende in aanmerking te worden genomen voor toepassingen waarbij er sprake is van elektronisch bestellen en betalen:
|
Veilige systeemarchitectuur en technische uitgangspunten
Panel | ||||||
---|---|---|---|---|---|---|
| ||||||
Waarborgen dat informatiesystemen veilig worden ontworpen, geïmplementeerd en beheerd binnen de ontwikkelingslevenscyclus. |
Panel | ||||||
---|---|---|---|---|---|---|
| ||||||
Uitgangspunten voor veilig ontwerpen bieden richtlijnen voor manipulatietechnieken, beheer van beveiligde sessies en gegevensvalidatie en opschoning. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelBeveiliging moet deel uitmaken van het ontwerp bij alle architectuurlagen (bedrijf, gegevens, toepassingen en technologie). |
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 informatiebeveiligingseisen.
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 cloudservices. Deze laag zorgt voor de ondersteuning van alle IT-diensten en -toepassingen. Beveiligingsaspecten omvatten netwerkbeveiliging, fysieke beveiliging, en het beheer van toegangsrechten.
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelNieuwe technologie moet worden geanalyseerd op veiligheidsrisico’s en het ontwerp moet worden beoordeeld aan de hand van bekende aanvalspatronen. |
Voorbereiding en Informatieverzameling: Begin met het verzamelen van gedetailleerde informatie over de nieuwe technologie, inclusief architectuur, functionaliteiten, en interacties met andere systemen.
Aanvalsoppervlak Identificatie: Identificeer het aanvalsoppervlak van de nieuwe technologie.
Analyse van Bekende Aanvalspatronen: Integreer kennis van bekende aanvalspatronen en dreigingen specifiek voor de technologie of vergelijkbare systemen.
Risico-Identificatie en Beoordeling: Combineer de informatie uit de vorige stappen om specifieke risico's te identificeren en voer het risico beheer proces uit.
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelUitgangspunten voor het ontwerpen van beveiligde systemen MOETEN een analyse omvatten van:
|
|
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelHet ontwerp van beveiligde systemen MOET gepaard gaan met:
|
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelDe organisatie MOET ‘zero trust’-beginselen overwegen zoals:
|
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelDe vastgestelde uitgangspunten voor het ontwerpen van beveiligde systemen en systeemarchitecturen MOETEN waar van toepassing worden toegepast op de uitbestede ontwikkeling van informatiesystemen via de contracten en andere bindende overeenkomsten tussen de organisatie en de leverancier aan wie de organisatie uitbesteedt. De organisatie moet ervoor zorgen dat de praktijken van leveranciers voor het ontwerpen van beveiligde systemen aansluiten op de behoeften van de organisatie. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelDe uitgangspunten voor het ontwerpen van beveiligde systemen en de vastgestelde ontwerpprocedures MOETEN regelmatig worden beoordeeld om te waarborgen dat ze doelmatig bijdragen aan verbeterde normen voor beveiliging binnen het ontwerpproces. Ze moeten ook regelmatig worden beoordeeld om ervoor te zorgen dat ze actueel blijven in de zin dat ze nieuwe potentiële dreigingen afwenden en toepasbaar blijven bij verbeteringen die worden toegepast in de technologieën en oplossingen. |
Veilig coderen
Panel | ||||||
---|---|---|---|---|---|---|
| ||||||
Waarborgen dat veilige software wordt geschreven waardoor het aantal potentiële informatiebeveiligingskwetsbaarheden in de software wordt beperkt. |
panelIconId | 9e6f15e6-c999-4552-9c6b-2582a2016b24 |
---|---|
panelIcon | :icon_beleidslijnen: |
panelIconText | :icon_beleidslijnen: |
bgColor | #F4F5F7 |
Implementatiemaatregel
De organisatie dientorganisatiebrede processen op te stellen om te voorzien in gode governance voor veilig coderen. Er behoort een minimale nullijn wat betreft beveiliging te worden vastgesteld en toegepast. In aanvulling hierop behoren dergelijke processen en governance te worden uitgebreid tot softwarecomponenten van derden en opensourcesoftware.
|
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelDe organisatie MOET te monitoren op dreigingen in de echte wereld en actueel advies en actuele informatie over kwetsbaarheden in software als richtlijn om de principes voor veilig coderen van de organisatie door middel van continue verbetering en voorturend leren te sturen. Dit kan bijdragen aan het garanderen dat er doeltreffende praktijken voor veilig coderen worden geimplementeerd als tegenhanger tegen het snel veranderende dreigingslandschap. |
Planning en voorafgaand aan het coderen
Panel | ||||||
---|---|---|---|---|---|---|
| ||||||
Onder operationele systemen worden alle systemen die voor eindgebruikers bereikbaar zijn. |
panelIconId | 9e6f15e6-c999-4552-9c6b-2582a2016b24 |
---|---|
panelIcon | :icon_beleidslijnen: |
panelIconText | :icon_beleidslijnen: |
bgColor | #F4F5F7 |
Implementatiemaatregel
De organisatie MOET principes voor veilig coderen zowel voor nieuwe ontwikkelingen als bij hergebruik (nieuwe features / versies) toe te passen.
| ||
ImplementatiemaatregelDe organisatie MOET ‘zero trust’-beginselen overwegen zoals:
|
Panel | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
|
| |||||
ImplementatiemaatregelDe vastgestelde uitgangspunten voor het ontwerpen van beveiligde systemen en systeemarchitecturen MOETEN waar van toepassing worden toegepast op de uitbestede ontwikkeling van informatiesystemen via de contracten en andere bindende overeenkomsten tussen de organisatie en de leverancier aan wie de organisatie uitbesteedt. De organisatie moet ervoor zorgen dat de praktijken van leveranciers voor het ontwerpen van beveiligde systemen aansluiten op de behoeften van de organisatie. Zie ook Leveranciersrelaties |
Veilig coderen
Panel | ||||||
---|---|---|---|---|---|---|
| ||||||
Waarborgen dat veilige software wordt geschreven waardoor het aantal potentiële informatiebeveiligingskwetsbaarheden in de software wordt beperkt. veilige software wordt geschreven waardoor het aantal potentiële informatiebeveiligingskwetsbaarheden in de software wordt beperkt. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelDe organisatie dientorganisatiebrede processen op te stellen om te voorzien in gode governance voor veilig coderen. Er behoort een minimale nullijn wat betreft beveiliging te worden vastgesteld en toegepast. In aanvulling hierop behoren dergelijke processen en governance te worden uitgebreid tot softwarecomponenten van derden en opensourcesoftware. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelDe |
Specifiek MOETEN de volgende regels worden gehanteerd:
het gebruik van veilige programmeertechnieken zoals ‘pair programming’ (programmeren in duo's) of iedergeval een vorm van het 'four eyes principle' voor kritieke functionaliteit, ‘refactoring’ (code herstructureren), ‘peer review’ (beoordeling door collega's), beveiligingsiteraties en testgestuurde ontwikkeling of in iedergeval een dekking van geautomatiseerde testen voor alle kritieke capabiliteiten van de software (code coverage);
het gebruik van gestructureerde programmeertechnieken;
het gebruik van onveilige ontwerptechnieken (bijvoorbeeld het gebruik van hardgecodeerde wachtwoorden, niet-goedgekeurde codesamples en niet-geauthenticeerde webdiensten) verbieden;organisatie MOET te monitoren op dreigingen in de echte wereld en actueel advies en actuele informatie over kwetsbaarheden in software als richtlijn om de principes voor veilig coderen van de organisatie door middel van continue verbetering en voorturend leren te sturen. Dit kan bijdragen aan het garanderen dat er doeltreffende praktijken voor veilig coderen worden geimplementeerd als tegenhanger tegen het snel veranderende dreigingslandschap. |
Planning en voorafgaand aan het coderen
Panel | ||||||
---|---|---|---|---|---|---|
| ||||||
Onder operationele systemen worden alle systemen die voor eindgebruikers bereikbaar zijn. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Implementatiemaatregel |
De organisatie MOET principes voor veilig coderen zowel voor nieuwe ontwikkelingen als bij hergebruik (nieuwe features / versies) toe te passen. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelAlvorens de toepassing operationeel te maken, behoort de software conform dit en ander beleid in het ISMS te zijn ontwikkeld en geconfigureerd, in het bijzonder;
|
ImplementatiemaatregelDe planning en voorbereiding voor het ontwikkelen dient de volgende elementen te omvatten:
|
Tijdens het coderen
Panel | ||||||
---|---|---|---|---|---|---|
| ||||||
Waarborgen dat veilige software wordt geschreven waardoor het aantal potentiële informatiebeveiligingskwetsbaarheden in de software wordt beperkt. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Implementatiemaatregel |
Nadat de code operationeel is gemaakt MOET:
updates op beveiligde wijze te worden verpakt en ingezet;
behoren gemelde kwetsbaarheden in de informatiebeveiliging te worden opgepakt
behoren logbestanden te worden bijgehouden van fouten en vermeende aanvallen en behoren de logbestanden regelmatig te worden beoordeeld om de code zo nodig aan te passen
behoort de broncode te worden beschermd tegen toegang en manipulatie door onbevoegden (bijv. door gebruik te maken van configuratiebeheerinstrumenten, die meestal functies als toegangsbeveiliging en versiebeheer bieden).
De organistie MOET veilige coderingspraktijken die specifiek zijn voor de programmeertalen en -technieken gebruiken. Specifiek MOETEN de volgende regels worden gehanteerd: het gebruik van veilige programmeertechnieken zoals ‘pair programming’ (programmeren in duo's) of iedergeval een vorm van het 'four eyes principle' voor kritieke functionaliteit, ‘refactoring’ (code herstructureren), ‘peer review’ (beoordeling door collega's), beveiligingsiteraties en testgestuurde ontwikkeling of in iedergeval een dekking van geautomatiseerde testen voor alle kritieke capabiliteiten van de software (code coverage); het gebruik van gestructureerde programmeertechnieken; het gebruik van onveilige ontwerptechnieken (bijvoorbeeld het gebruik van hardgecodeerde wachtwoorden, niet-goedgekeurde codesamples en niet-geauthenticeerde webdiensten) verbieden; |
De organisatie kan van de volgende standaarden gebruik maken:
OWASP Secure Coding Practices
NIST Secure Software Development Framework
Daarnaast zijn er voor gebruikte techniek specifieke standaarden en richtlijnen beschikbaar.
het bewerkstelligen dat externe bibliotheken worden beheerd (bijv. door een inventarislijst bij te houden van bibliotheken die worden gebruikt en de desbetreffende versies) en regelmatig worden bijgewerkt met releasecycli;
het selecteren, autoriseren en hergebruiken van goed gecontroleerde componenten, met name authenticatie- en cryptografische componenten;
de licentie, beveiliging en historie van externe componenten;
het bewerkstelligen dat software kan worden onderhouden, wordt getraceerd en afkomstig is van beproefde, gerenommeerde bronnen;
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Implementatiemaatregel |
Als er gebruikgemaakt wordt van externe instrumenten en bibliotheken, MOET de organisatie na te denken over:
Er MOET tijdens en na het ontwikkelen worden getest. |
Met procedures voor het statisch testen van de beveiliging van toepassingen (SAST) kunnen beveiligingslekken in software worden geïdentificeerd.
Testen van de beveiliging tijdens ontwikkeling en acceptatiePanel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Implementatiemaatregel |
Als het nodig is een softwarepakket te wijzigen, MOETEN de volgende punten in overweging te worden genomen:
het risico dat ingebouwde beheersmaatregelen en integriteitsprocessen gecompromitteerd raken;
of het al dan niet nodig is toestemming van de leverancier te verkrijgen;
de mogelijkheid om de vereiste wijzigingen van de aanbieder als standaard programma-updates te verkrijgen;
de impact als de organisatie verantwoordelijk wordt gehouden voor het toekomstig onderhoud van de software als gevolg van de veranderingen;
compatibiliteit met andere software die in gebruik is.
Alvorens de toepassing operationeel te maken, MOET de software conform dit en ander beleid in het ISMS te zijn ontwikkeld en geconfigureerd, in het bijzonder;
|
Beoordeling en onderhoud
Panel | ||||||
---|---|---|---|---|---|---|
| ||||||
Valideren of aan de informatiebeveiligingseisen wordt voldaan wanneer toepassingen of code in de productieomgeving worden uitgeroldWaarborgen dat veilige software wordt geschreven waardoor het aantal potentiële informatiebeveiligingskwetsbaarheden in de software wordt beperkt. |
Panel | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
|
| ||||||||||
ImplementatiemaatregelNadat de code operationeel is gemaakt MOET:
|
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelHet 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 testen omvatten van: beveiligingsfuncties [bijv. authenticatie van gebruikers (zie [Beleid voor toegangsbeveiliging]), toegangsbeperking (zie [Beleid voor toegangsbeveiliging]) en het gebruik van cryptografie (zie [Beleid cryptografie])];" veilig coderen; Als er gebruikgemaakt wordt van externe instrumenten en bibliotheken, MOET de organisatie na te denken over:
|
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelTestplannen 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:
| ||||||||
Panel | ||||||||
| ||||||||
ImplementatiemaatregelDe organisatie kan geautomatiseerde instrumenten inzetten zoals instrumenten om codes te analyseren of om op kwetsbaarheden te scannen, en MOETEN het herstel van beveiligingsgerelateerde tekortkomingen te verifiëren deze diensten vallen onder software die geevalueerd moet worden voor gebruikAls het nodig is een softwarepakket te wijzigen, MOETEN de volgende punten in overweging te worden genomen:
|
Testen van de beveiliging tijdens ontwikkeling en acceptatie
Panel | ||||||
---|---|---|---|---|---|---|
| ||||||
Valideren of aan de informatiebeveiligingseisen wordt voldaan wanneer toepassingen of code in de productieomgeving worden uitgerold. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Implementatiemaatregel |
Voor interne ontwikkelactiviteiten MOETEN dergelijke tests in eerste instantie te worden uitgevoerd door het ontwikkelteam. Vervolgens behoren onafhankelijke tests te worden uitgevoerd om te bewerkstelligen dat het systeem uitsluitend werkt zoals voorzien (zie Informatiebeveiliging in projectmanagement). Het volgende behoort te worden overwogen:
het uitvoeren van activiteiten om code te beoordelen als relevant element voor het testen op zwakke plekken in de beveiliging, met inbegrip van onvoorziene inputs en omstandigheden;
het scannen op kwetsbaarheden om onveilige configuraties en kwetsbaarheden in systemen te identificeren;
het uitvoeren van penetratietests om onveilige code en ontwerpen te identificeren
Nieuwe informatiesystemen, upgrades en nieuwe versies MOETEN tijdens de ontwikkelingsprocessen grondig te worden getest en geverifieerd. Het testen van de beveiliging behoort een integraal onderdeel te zijn van het testen voor systemen of componenten. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
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 testen omvatten van:
|
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Implementatiemaatregel |
Tests MOETEN worden uitgevoerd in een testomgeving die zo nauwkeurig mogelijk overeenkomt met de doelproductieomgeving om te bewerkstelligen dat het systeem geen kwetsbaarheden introduceert in de omgeving van de organisatie en dat de tests betrouwbaar zijn (zie Scheiding van ontwikkel-, test- en productieomgevingen). In het bijzonder: Test en acceptatieomgevingen dienen ook infrastructuur technisch zover mogelijk productie omgevingen te spiegelen (software, softwareversies, netwerken en beveiliging (onder andere hardening, firewalls en gateways)).
Scheiding van ontwikkel-, test-, en productieomgevingen
Panel | ||||||
---|---|---|---|---|---|---|
| ||||||
De productieomgeving en de gegevens beschermen tegen compromittering door ontwikkel- en testactiviteiten. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelDe organisatie MOET het scheidingsniveau tussen productie-, test- en ontwikkelomgevingen dat nodig is om operationele problemen te voorkomen te identificeren en te implementeren. 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:
|
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.
Panel | ||||
---|---|---|---|---|
|
Implementatiemaatregel
Met de volgende aspecten MOET rekening te worden gehouden:
ontwikkel- en productiesystemen in afdoende mate van elkaar scheiden en ze in verschillende domeinen uitvoeren (bijv. in gescheiden virtuele of fysieke omgevingen);
regels en autorisaties definieren, documenteren en implementeren voor het inzetten van software vanuit de ontwikkel- naar de productiestatus;
veranderingen an productiesystemen en toepassingen in een test- of gefaseerde omgeving testen
voordat ze in productiesystemen worden toegepast (zie Testen van de beveiliging tijdens ontwikkeling en acceptatie);
niet testen in productieomgevingen behalve in gedefinieerde en goedgekeurde omstandigheden;
compilers, editors en andere ontwikkelinstrumenten of systeemhulpmiddelen behoren, indien ze niet nodig zijn, niet toegankelijk te zijn vanuit productiesystemen;
passende milieu-identificatielabels in menu's tonen om het risico op fouten te beperken;
geen gevoelige informatie naar de ontwikkel- en testsysteemomgevingen kopiëren tenzij er wordt
| |||||
ImplementatiemaatregelDe organisatie kan geautomatiseerde instrumenten inzetten zoals instrumenten om codes te analyseren of om op kwetsbaarheden te scannen, en MOETEN het herstel van beveiligingsgerelateerde tekortkomingen te verifiëren deze diensten vallen onder software die geevalueerd moet worden voor gebruik. |
De volgende tooling word ingezet om code kwaliteit en veiligheid automatisch te beoordelen:
Sigrid
Sonarcube
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Implementatiemaatregel |
In alle gevallen MOETEN de ontwikkel- en testomgevingen te worden beschermd, waarbij het volgende
in aanmerking behoort te worden genomen:
het patchen en bijwerken van alle ontwikkelings-, integratie- en testinstrumenten (met inbegrip van builders, integratie-instrumenten, compilers, configuratiesystemen en bibliotheken);
beveiligde configuratie van systemen en software conform [Beleid voor beheer van bedrijfsmiddelen ];
toegangsbeveiliging voor de omgevingen conform [Beleid voor toegangsbeveiliging];
monitoren van veranderingen aan de omgeving en de daarin opgeslagen codes;
beveiligde monitoring van de omgevingen conform [Beleid voor informatiebeveiligingsgebeurtenissen];
Voor interne ontwikkelactiviteiten MOETEN dergelijke tests in eerste instantie te worden uitgevoerd door het ontwikkelteam. Vervolgens behoren onafhankelijke tests te worden uitgevoerd om te bewerkstelligen dat het systeem uitsluitend werkt zoals voorzien (zie Informatiebeveiliging in projectmanagement). Het volgende behoort te worden overwogen:
|
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelVoor uitbestede ontwikkeling en het inkopen van componenten MOET een verwervingsprocedure worden gevolgd. In de contracten met de leverancier moeten de vastgestelde beveiligingseisen zijn opgenomen. Voordat producten en diensten worden gekocht, moeten ze worden geëvalueerd tegen deze criteria. Na ieder ontwikkeltraject dienen er testrapporten als attestatie te worden aangeleverd. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Implementatiemaatregel |
Tests MOETEN worden uitgevoerd in een testomgeving die zo nauwkeurig mogelijk overeenkomt met de doelproductieomgeving om te bewerkstelligen dat het systeem geen kwetsbaarheden introduceert in de omgeving van de organisatie en dat de tests betrouwbaar zijn (zie Scheiding van ontwikkel-, test- en productieomgevingen). |
Wijzigingsbeheer
Panel | ||||||
---|---|---|---|---|---|---|
| ||||||
De informatiebeveiliging behouden tijdens het uitvoeren van wijzigingen. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelNieuwe systemen en belangrijke wijzigingen van bestaande systemen MOETEN volgens overeengekomen regels en een formeel proces van documentatie, specificatie, testen, kwaliteitscontrole en beheerde implementatie te worden |
geïntroduceerd. Verantwoordelijkheden en procedures voor beheer behoren te worden vastgelegd om afdoende beheersing van alle veranderingen te waarborgen. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelProcedures voor wijzigingsbeheer MOETEN te worden gedocumenteerd en gehandhaafd om de vertrouwelijkheid, integriteit en beschikbaarheid van informatie in informatieverwerkende faciliteiten en informatiesystemen te garanderen gedurende de gehele ontwikkelcyclus van systemen, vanaf het begin van de ontwerpfase tot en met alle daaropvolgende onderhoudsinspanningen. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelWaar mogelijk MOETEN de procedures voor wijzigingsbeheer voor ICT-infrastructuur en -software te worden |
geïntegreerd. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelDe procedures voor wijzigingsbeheer MOETEN het volgende te omvatten:
|
Regelgeving en standaarden (L1)
ISO 27001:2022 (Annex A)
Page Properties Report | ||||||||
---|---|---|---|---|---|---|---|---|
|
Informatieveiligheidsstrategie van de Vlaamse overheid (L2)
Zie voor meer informatie.
Processen
Oplossingen
Titel | Auteur | Datum | Versie | Status | Opmerkingen |
---|---|---|---|---|---|
Page Properties | ||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||
Document status (Metadata)Onderstaande gegevens worden gebruikt voor rapporteringsdoeleinden in documentregister
status opties:
status eveneens aanpassen bovenaan deze pagina |