Excerpt | ||
---|---|---|
| ||
Het beleid van veilig ontwerpen en ontwikkelen bevat de maatregelen om op een veilige manier producten en interne toepassing te 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:
|
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.
Risico binnen projectmanagement
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelInformatieveiligheid moet worden geïntegreerd in projectmanagement om ervoor te zorgen dat Informatieveiligheidsrisico's in het kader van projectmanagement worden aangepakt. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelNaast het beleid voor Risicobeheer MOETEN de volgende maatregelen worden gevolgd tijdens het projectmanagement:
|
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelInformatieveiligheidseisen inzake de naleving van intellectuele - eigendomsrechten (Zie zie Leveranciersrelaties) MOETEN in de vroege stadia van projecten worden aangepakt. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelDe passendheid gepastheid van de informatieveiligheidsoverwegingen en -activiteiten MOET in vooraf bepaalde stadia worden gecontroleerd door geschikte personen of governance- instanties, zoals bijv. de projectstuurgroep. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelVerantwoordelijkheden en bevoegdheden voor Informatieveiligheid informatieveiligheid relevant voor het project MOETEN worden gedefinieerd en worden toegewezen aan gespecificeerde rollen. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelInformatieveiligheidseisen voor de door het project te leveren producten of diensten MOETEN worden vastgesteld met gebruikmaking van verschillende methoden zoals het afleiden van nalevingseisen uit informatieveiligheidsbeleid, onderwerpspecifieke onderwerp-specifieke beleidsregels en regelgeving. Verdere informatieveiligheidseisen kunnen 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 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelInformatieveiligheidseisen 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:
|
Toegangsbeveiliging op de broncode
panelIconId | atlassian-info |
---|---|
panelIcon | :info: |
bgColor | #FFFFFF |
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.
Broncode wordt beheerd binnen het GIT versiebeheer systeem. Dit maakt het mogelijk voor meerdere ontwikkelaars om gelijktijdig aan projecten samen te werken.
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelBroncode MOET gecontroleerd centraal worden opgeslagen in een versiebeheersysteem voor code (GIT). |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelLees- en schrijftoegang tot broncode MOET afgestemd worden conform Toegangsbeveiliging. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Implementatiemaatregel#### TOT HIER NAGEKEKENOm de impact van niet-geautoriseerde wijzigingen en het lekken van vertrouwelijke informatie via broncode te minimaliseren, MOETEN de broncodebibliotheken afgeschermd worden. Voor deze beveiliging MOETEN volgende richtlijnen worden gehanteerd:
|
Beveiligen tijdens de ontwikkelcyclus
Panel | ||||||
---|---|---|---|---|---|---|
| ||||||
Bewerkstelligen dat Informatieveiligheid 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.
De ontwikkelcyclus 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.
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Panel | ||||||||
panelIconId | 9e6f15e6-c999-4552-ImplementatiemaatregelBeveiligingseisen MOETEN worden gespecificeerd en geïntegreerd tijdens de specificatie- en ontwerpfase. 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. |
Ontwikkel-, test-, acceptatie-, en productieomgevingen MOETEN gescheiden worden. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelMet de volgende aspecten MOET rekening te worden gehoudenBij het opzetten van ontwikkel-, test-, acceptatie-, en productieomgevingen MOETEN moeten de volgende maatregelen worden geïmplementeerd:
passende milieu-identificatielabels in menu's tonen om het risico op fouten te beperken;
| ||||||||
Panel | ||||||||
| ||||||||
ImplementatiemaatregelIn alle gevallen MOETEN de ontwikkel- en testomgevingen te worden beschermd, waarbij het volgende in aanmerking behoort te worden genomen: het patchen en
monitoren van veranderingen aan de omgeving en de daarin opgeslagen codes; beveiligde monitoring van de omgevingen;
|
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelHet MOET niet MAG NIET mogelijk te zijn dat éen één persoon zonder voorafgaande beoordeling en goedkeuring veranderingen aan zowel de ontwikkeling ontwikkel- als de productie-omgeving 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 realtime monitoring te worden geimplementeerd geïmplementeerd om veranderingen door onbevoegden te detecteren en er actie op te ondernemen. |
Toepassingsbeveiligingseisen
TestenAlgemene beveiligingseisen
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 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelBeveiliging 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 |
Beveiligingseisen voor toepassingen MOETEN worden geïdentificeerd en gespecificeerd aan de hand van een risicobeoordeling. De eisen moeten met ondersteuning van informatieveiligheidsspecialisten worden ontwikkeld. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelBeveiligingseisen MOETEN worden gespecificeerd en geïntegreerd tijdens de specificatie- en ontwerpfase. De implementatie maatregelen uit het informatieveiligheidsbeleid MOETEN in het software ontwerp worden vermeld in zoverre van toepassing. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelToepassingsbeveiligingseisen MOETEN het volgende te omvatten, al naargelang de situatie:
|
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.
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
In aanvulling op de algemene beveiligingseisen, MOETEN voor transactie-systemen, de volgende informatieveiligheidseisen worden in acht genomen:
|
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 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelBeveiligingseisen voor toepassingen MOETEN worden geïdentificeerd en gespecificeerd aan de hand van een risicobeoordeling (zie Proces - Informatieveiligheid risicobeheer ). De eisen moeten met ondersteuning van Informatieveiligheidsspecialisten 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. |
In aanvulling hierop MOET het volgende in aanmerking te worden genomen voor toepassingen waarbij er sprake is van elektronisch bestellen en betalen:
|
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.
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelBeveiliging MOET deel uitmaken van het ontwerp bij alle architectuurlagen (bedrijf, gegevens, toepassingen en technologie). |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Implementatiemaatregel |
In 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 Informatieveiligheidseisen:
de mate van vertrouwen die beide partijen eisen van elkaars beweerde identiteit;
de vereiste mate van vertrouwen in de integriteit van informatie die wordt uitgewisseld of verwerkt en de mechanismen voor het identificeren van integriteitsgebreken (bijv. Cyclische redundantiecontrole, hashing, digitale handtekeningen);
autorisatieprocedures voor wie de inhoud van belangrijke transactiedocumenten kan goedkeuren, belangrijke transactiedocumenten in circulatie kan brengen of kan ondertekenen;
vertrouwelijkheid, integriteit, bewijs van verzending en ontvangst van belangrijke documenten en de onweerlegbaarheid (bijv. contracten in samenhang met inschrijvings- en contractprocedures);
de vertrouwelijkheid en integriteit van transacties (bijv. orders, gegevens betreffende afleveringsadressen en ontvangstbevestigingen);
eisen ten aanzien van hoelang een transactie vertrouwelijk moet blijven;
verzekerings- en andere contractuele eisen.
Nieuwe technologie MOET worden geanalyseerd op veiligheidsrisico’s en het ontwerp MOET worden beoordeeld aan de hand van bekende aanvalspatronen. De volgende aspecten MOETEN worden in acht genomen:
|
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
|
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 | |
---|---|
panelIconId | Implementatiemaatregel |
Toepassingen 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:
eisen om de vertrouwelijkheid en integriteit van orderinformatie in stand te houden;
de mate van verificatie die passend is voor controle van betalingsinformatie die door een klant is verstrekt:
verlies of vermenigvuldiging van transactie-informatie vermijden;
transactiegegevens buiten een publiek toegankelijke omgeving opslaan (bijv. op een opslagplatform op het intranet van de organisatie, in plaats van deze te bewaren en te tonen op direct vanuit internet toegankelijke elektronische opslagmedia);
als een vertrouwde instantie word gebruikt (bijv. voor het uitgeven en onderhouden van digitale handtekeningen of digitale certificaten), beveiliging integreren en inbedden in het gehele beheerproces van certificaten of handtekeningen.
Het ontwerp van een systeem MOET een analyse omvatten van:
|
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Panel | ||||||||
panelIconId | 9e6f15e6-c999-4552-9c6b-2582a2016b24 | panelIcon | :icon_beleidslijnenImplementatiemaatregelBeveiliging 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 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 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.
Het ontwerp van een systeem MOET gepaard gaan met:
|
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelDe organisatie MOET ‘zero trust’-beginselen overwegen zoals:
|
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelUitgangspunten De vastgestelde uitgangspunten voor het ontwerpen van beveiligde systemen en systeemarchitecturen MOETEN een analyse omvatten van:
|
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 |
het gebruik van uitgangspunten voor beveiligingsarchitectuur zoals ‘security by design’ (beveiliging door ontwerp), ‘defence in depth’, ‘security by default’, ‘default deny’ (standaard weigeren), ‘fail securely’, ‘distrust input from external applications’ (input van externe toepassingen wantrouwen), ‘security in deployment’ (beveiliging tijdens implementatie), ‘assume breach’ (uitgaan van inbreuk), ‘least privilege’ (mininimaal benodigde rechten), ‘usability and manageability’ (bruikbaarheid en beheerbaarheid) en ‘least functionality’ (minimale benodigde functionaliteit);
een beveiligingsgerichte beoordeling van het ontwerp om kwetsbaarheden op het gebied van Informatieveiligheid te helpen detecteren, ervoor te zorgen dat beveiligingsbeheersmaatregelen zijn gespecificeerd en aan de beveiligingseisen te voldoen;
documentatie en formele erkenning van beveiligingsbeheersmaatregelen die niet volledig aan de eisen voldoen (bijv. vanwege dwingende veiligheidseisen);
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Implementatiemaatregel |
Het ontwerp van beveiligde systemen MOET gepaard gaan met:
Voor 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 MOETEN er testrapporten als attestatie worden aangeleverd. |
Veilig coderen
Deze paragraaf behandelt de waarborgen dat veilige software wordt geschreven waardoor het aantal potentiële Informatieveiligheidskwetsbaarheden in de software wordt beperkt.
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelDe organisatie MOET organisatie-brede processen op stellen om te voorzien in goede governance voor veilig coderen. Er MOET een nullijn wat betreft beveiliging te worden vastgesteld en toegepast. In aanvulling hierop MOETEN dergelijke processen en governance worden uitgebreid naar softwarecomponenten van derden en opensource software. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelDe organisatie MOET 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 te sturen door middel van continue verbetering en voortdurend leren. |
Planning en voorafgaand aan het coderen
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelDe organisatie MOET |
ervan uitgaan dat er al sprake is van een inbreuk op de informatiesystemen van de organisatie en er daarom niet alleen kan worden vertrouwd op beveiliging van de buitengrenzen van netwerken;
een benadering van ‘nooit vertrouwen, altijd verifiëren’ hanteren voor toegang tot informatiesystemen;
bewerkstelligen dat verzoeken aan informatiesystemen van begin tot eind versleuteld zijn;
elk verzoek aan een informatiesysteem controleren alsof dit afkomstig is van een open, extern netwerk, zelfs als deze verzoeken intern uit de organisatie afkomstig zijn (d.w.z. niets binnen of buiten de buitengrenzen van de organisatie automatisch vertrouwen);
gebruikmaken van ‘least privilege’ (minste rechten) en dynamische toegangsbeveiligingstechnieken (zie [beleid voor toegangsbeveiliging]). Dit omvat het authenticeren en autoriseren van verzoeken om informatie of aan systemen op basis van contextuele informatie zoals authenticatie-informatie, gebruikersidentiteiten, gegevens over het ‘endpoint device’ van de gebruiker, en gegevensclassificatie (zie [Beleid voor toegangsbeveiliging] en [Beleid voor informatiebescherming]).
personen die verzoeken indienen altijd authenticeren en autorisatieverzoeken aan informatiesystemen altijd valideren op basis van informatie, waaronder authenticatie-informatie en gebruikersidentiteiten, gegevens over het ‘endpoint device’ van de gebruiker, en gegevensclassificatie, bijvoorbeeld krachtige authenticatie afdwingen (zie [Beleid voor toegangsbeveiliging] en [Beleid voor informatiebescherming]).
principes voor veilig coderen zowel voor nieuwe ontwikkelingen als bij hergebruik (nieuwe features / versies) toepassen. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelDe planning en voorbereiding voor het ontwikkelen MOET de volgende elementen omvatten:
|
Tijdens het coderen
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelDe |
Veilig coderen
Panel | ||||||
---|---|---|---|---|---|---|
| ||||||
Waarborgen dat veilige software wordt geschreven waardoor het aantal potentiële Informatieveiligheidskwetsbaarheden in de software wordt beperktorganisatie MOET veilige coderingspraktijken die specifiek zijn voor de programmeertalen en -technieken, gebruiken. Specifiek MOETEN de volgende regels worden gehanteerd:
|
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.
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. 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.
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
|
Planning en voorafgaand aan het coderen
Panel | ||||||
---|---|---|---|---|---|---|
| ||||||
Implementatiemaatregel |
De 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.
Onder operationele systemen worden alle systemen die voor eindgebruikers bereikbaar zijn.Alvorens de toepassing operationeel te maken, MOET de software conform dit en ander informatieveiligheidsbeleid te zijn ontwikkeld en geconfigureerd, in het bijzonder;
|
Beoordeling en onderhoud
Panel | |||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
| ||||||||||||
ImplementatiemaatregelNadat de code operationeel is gemaakt MOETEN:
|
Panel | ||||
---|---|---|---|---|
|
Implementatiemaatregel
De planning en voorbereiding voor het ontwikkelen dient de volgende elementen te omvatten:
organisatiespecifieke verwachtingen en goedgekeurde principes voor veilig coderen die zowel voor interne als voor uitbestede codeontwikkelingen behoren te worden gebruikt;
gebruikelijke en historische codeerpraktijken en -gebreken die tot kwetsbaarheden in de Informatieveiligheid leiden;
ontwikkelinstrumenten, zoals geïntegreerde ontwikkelomgevingen (IDE's), configureren om het maken van veilige code af te dwingen waar mogelijk:
automatische tests voor kritieke features;
richtlijnen volgen die door de aanbieders van ontwikkelinstrumenten en uitvoeringsomgevingen worden gegeven, al naargelang de situatie;
onderhoud en gebruik van actuele ontwikkelinstrumenten (bijv. compilers);
de kwalificatie van ontwikkelaars voor het schrijven van veilige code;
veilig ontwerp en veilige architectuur, met inbegrip van het opstellen van dreigingsmodellen;
normen voor veilig coderen en waar relevant het gebruik ervan verplicht stellen;
het gebruik van beheerste omgevingen voor ontwikkeling.
Tijdens het coderen
Panel | ||||||
---|---|---|---|---|---|---|
| ||||||
| ||||||
ImplementatiemaatregelAls er gebruikgemaakt wordt van externe instrumenten en bibliotheken, MOET de organisatie nadenken over:
|
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelDe 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
Als het nodig is om een softwarepakket te wijzigen, MOETEN de volgende punten in overweging te worden genomen:
|
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.
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelEr MOET tijdens en na het ontwikkelen worden getest. |
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. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelAlvorens 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 | ||||||
---|---|---|---|---|---|---|
| ||||||
Waarborgen dat veilige software wordt geschreven waardoor het aantal potentiële Informatieveiligheidskwetsbaarheden in de software wordt beperkt. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelNadat de code operationeel is gemaakt MOET: updates op beveiligde wijze te worden verpakt en ingezet; behoren gemelde kwetsbaarheden in de Informatieveiligheid 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). 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:
|
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:
|
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
Als er gebruikgemaakt wordt van externe instrumenten en bibliotheken, MOET de organisatie na te denken over:
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;
het op voldoende lange termijn beschikbaar zijn van ontwikkelmiddelen en artefacten.
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelAls 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 Informatieveiligheidseisen wordt voldaan wanneer toepassingen of code in de productieomgeving worden uitgerold. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
| ||||||||
ImplementatiemaatregelDe organisatie kan geautomatiseerde instrumenten inzetten zoals instrumenten om codes te analyseren of om op kwetsbaarheden te scannen, en MOETEN het herstel van informatieveiligheid-gerelateerde tekortkomingen te verifiëren deze diensten vallen onder software die geëvalueerd moet worden voor gebruik. |
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.
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 Toegangsbeveiliging), toegangsbeperking (zie Toegangsbeveiliging) en het gebruik van cryptografie (zie Cryptografie) veilig coderen; Het testen van de systemen en de beveiliging, zoals regressietests, codescans en penetratietests MOET worden uitgevoerd. |
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:
|
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.
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 Informatieveiligheid in projectmanagement). Het volgende behoort te worden overwogen:
|
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelTests MOETEN worden uitgevoerd in een testomgeving die zo nauwkeurig mogelijk overeenkomt met de doel-productieomgeving 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
Deze paragraaf beschrijft de maatregelen die dienen om de informatieveiligheid te behouden tijdens het uitvoeren van wijzigingen.
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 gebruik. |
De volgende tooling word ingezet om code kwaliteit en veiligheid automatisch te beoordelen:
Sigrid
Nieuwe 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 MOETEN worden vastgelegd om afdoende beheersing van alle veranderingen te waarborgen. |
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelVoor 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 Informatieveiligheid 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; Procedures voor wijzigingsbeheer MOETEN worden gedocumenteerd en gehandhaafd om de beschikbaarheid, integriteit en vertrouwelijkheid 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 worden geïntegreerd. |
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 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelTests 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 Informatieveiligheid behouden tijdens het uitvoeren van wijzigingen De procedures voor wijzigingsbeheer MOETEN het volgende te omvatten:
|
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. Bij wijzigingen MOET versiebeheer worden gebruikt. Elk gebruikt versiebeheer MOET volgens volgende regels opgesteld worden:
Bovenstaande versie-bouwstenen MOETEN samengevoegd worden tot het formaat: <MAJOR.MINOR.PATCH> Aanvullende labels voor prerelease (TNI, BETA, DEV) en build-metadata MOETEN toegevoegd 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. |
Personeel
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
ImplementatiemaatregelDe procedures voor wijzigingsbeheer MOETEN het volgende te omvatten: het plannen en beoordelen van de potentiële impact van wijzigingen, waarbij alle afhankelijkheden in aanmerking worden genomen; autorisatie van veranderingen; veranderingen aan relevante belanghebbenden communiceren; tests en de aanvaarding van tests voor de veranderingen (zie Testen van de beveiliging tijdens ontwikkeling en acceptatie); implementatie van veranderingen met inbegrip van inzetplannen; nood- en voorzorgsoverwegingen, met inbegrip van vangnetprocedures; registraties onderhouden van veranderingen waarin alle bovenstaande punten worden opgenomen; waarborgen dat bedienings documentatie en gebruikersprocedures indien nodig worden gewijzigd om ze toepasbaar te houden; 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. |
Regelgeving en standaarden (L1)
ISO 27001:2022 (Annex A)
Page Properties Report | ||||||||
---|---|---|---|---|---|---|---|---|
|
Informatieveiligheidsstrategie van de Vlaamse overheid (L2)
Zie voor meer informatie.
Uitvoering van het beleid
Processen
Oplossingen
Titel | Auteur | Datum | Versie | Opmerkingen |
---|---|---|---|---|
Beleid voor veilig ontwerpen en ontwikkelen | Guido Calomme | 31/05/2024 | 1.0 |
Page Properties | ||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||
Document status (Metadata)Onderstaande gegevens worden gebruikt voor rapporteringsdoeleinden in documentregister
status opties:
status eveneens aanpassen bovenaan deze pagina |