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.

Implementatiemaatregel

Informatieveiligheid moet worden geïntegreerd in projectmanagement om ervoor te zorgen dat Informatieveiligheidsrisico's in het kader van projectmanagement worden aangepakt. 

Implementatiemaatregel

Naast het beleid voor Risicobeheer MOETEN de volgende maatregelen worden gevolgd tijdens het projectmanagement:

• Informatieveiligheidsrisico’s moeten tijdens een vroeg stadium en periodiek gedurende de volledige levenscyclus van het project als onderdeel van de projectrisico's worden beoordeeld en behandeld.

• Informatieveiligheidsrisico’s in verband met de uitvoering van projecten, zoals de beveiliging van interne en externe communicatieaspecten, moeten gedurende de gehele levenscyclus van het project in aanmerking worden genomen en behandeld.

•  De vorderingen met betrekking tot de behandeling van Informatieveiligheidsrisico’s moeten worden beoordeeld en de doeltreffendheid van de behandeling wordt beoordeeld en beproefd. 

Implementatiemaatregel

Informatieveiligheidseisen inzake de naleving van intellectuele - eigendomsrechten (Zie zie Leveranciersrelaties) MOETEN in de vroege stadia van projecten worden aangepakt. 

Implementatiemaatregel

De passendheid gepastheid van de informatieveiligheidsoverwegingen en -activiteiten MOET in vooraf bepaalde stadia worden gecontroleerd door geschikte personen of governance- instanties, zoals bijv. de projectstuurgroep.  

Implementatiemaatregel

Verantwoordelijkheden en bevoegdheden voor Informatieveiligheid informatieveiligheid relevant voor het project MOETEN worden gedefinieerd en worden toegewezen aan gespecificeerde rollen. 

Implementatiemaatregel

Informatieveiligheidseisen 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. 

Implementatiemaatregel

Informatieveiligheidseisen 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:

• welke informatie het betreft, wat de bijbehorende Informatieveiligheidsbehoeften informatieveiligheidsbehoeften zijn (classificatie) en de mogelijke negatieve bedrijfsimpact die het gevolg kan zijn van ontoereikende beveiliging;

• de noodzaak om de desbetreffende informatie en andere gerelateerde bedrijfsmiddelen te beschermen, met name wat betreft vertrouwelijkheid, integriteit en beschikbaarheid; 

• de vereiste mate van betrouwbaarheid of zekerheid ten opzichte van de beweerde identiteit van entiteiten om de authenticatie-eisen af te leiden;

• processen voor het verlenen van toegang en autorisatie, voor klanten en andere zakelijke gebruikers en voor bevoorrechte of technische gebruikers, zoals relevante projectleden, mogelijk operationeel personeel of externe leveranciers;

• het informeren van gebruikers over hun plichten en verantwoordelijkheden;

• eisen die zijn afgeleid van bedrijfsprocessen, zoals registreren en monitoren van transacties, eisen voor onweerlegbaarheid;

• eisen die verplicht zijn gesteld door andere beheersmaatregelen met betrekking tot Informatieveiligheid informatieveiligheid (bijv. interfaces voor het registreren en monitoren of systemen voor het detecteren van lekken van gegevens);

• naleving van de wettelijke, statutaire, regelgevende en contractuele omgeving waarin de organisatie actief is;

• het vereiste niveau van vertrouwen of zekerheid dat derden zullen voldoen aan het Informatieveiligheidsbeleid informatieveiligheidsbeleid en de onderwerpspecifieke onderwerp-specifieke beleidsregels van de organisatie, met inbegrip van relevante beveiligingsclausules in overeenkomsten of contracten. 

Implementatiemaatregel

Broncode MOET gecontroleerd centraal worden opgeslagen in een versiebeheersysteem voor code (GIT). 

Implementatiemaatregel

Lees- en schrijftoegang tot broncode MOET afgestemd worden conform Toegangsbeveiliging.

Implementatiemaatregel

Om 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: 

• Broncodebibliotheken zijn privé en het publiek maken van broncode MOET het beleid voor toegangsbeveiliging Toegangsbeveiliging volgen;

• Elke broncodebibliotheek is een bedrijfsmiddel en MOET het beleid beheer bedrijfsmiddelen volgen;

• Procedures voor wijzigingsbeheer MOETEN worden toegepast op het bijwerken van broncode en gerelateerde zaken en het verlenen van toegang tot broncode en dit pas uitvoeren nadat de passende autorisatie is ontvangen; 

• Vermijden Het MOET vermeden worden om vertrouwelijke informatie op te slaan in de broncode of commit messages, bvb. Door het gebruik van development configuratie bestanden. Voorbeelden van vertrouwelijke informatie : 

• Activiteiten kunnen altijd aan een natuurlijke persoon worden gekoppeld of een proces waar een verantwoordelijke natuurlijk persoon aan is toegewezen

• (interne) IP adressen of DNS entries 

• Configuratiedetails (bvb. IaC, Database modellen) 

• Persoonsgegevens vanaf klasse 3 

• Controle houden op broncode wijzigingen

• Pull requests / Broncode reviews 

• Development / test / acceptatie en release branches wanneer toepasbaar 

• Commits signen 

• Ontwikkelaars mogen geen zijn IP adressen, DNS entries of persoonsgegevens vanaf klasse 3;

• Ontwikkelaars MOGEN GEEN rechtstreekse toegang tot de broncodebibliotheek krijgen, maar via ontwikkelinstrumenten die activiteiten en autorisaties met betrekking tot de broncode beheersen; 

• Lijsten van programma's MOETEN bewaard worden in een beveiligde omgeving bewaren waar lees- en schrijftoegang op passende wijze behoort te worden beheerd en toegewezen; 

• Er MOET een auditlogbestand bijhouden logboekregistratie zijn van alle toegangsinstanties toegang tot en van alle wijzigingen aan de broncode. 

Ontwikkel-, test-, acceptatie-, en productieomgevingen MOETEN gescheiden worden. 

Implementatiemaatregel

Het 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. 

Implementatiemaatregel

Het testen van de systemen en de beveiliging, zoals regressietests, codescans en penetratietests MOETEN worden uitgevoerd. 

Beveiligingseisen voor toepassingen MOETEN worden geïdentificeerd en gespecificeerd aan de hand van een risicobeoordeling. De eisen moeten met ondersteuning van informatieveiligheidsspecialisten worden ontwikkeld.  

In aanvulling op de algemene beveiligingseisen, MOETEN voor transactie-systemen, de volgende informatieveiligheidseisen worden in acht genomen: 

• 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, of 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. 

In aanvulling hierop MOET het volgende in aanmerking te worden genomen voor toepassingen waarbij er sprake is van elektronisch bestellen en betalen: 

1. eisen om de vertrouwelijkheid en integriteit van orderinformatie in stand te houden; 

2. de mate van verificatie die passend is voor controle van betalingsinformatie die door een klant is verstrekt: 

3. verlies of vermenigvuldiging van transactie-informatie vermijden; 

4. 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); 

5. 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. 

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:

• 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 gekende 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 risicobeheersproces uit.

Het ontwerp van een systeem MOET een analyse omvatten van: 

• het volledige spectrum van beheersmaatregelen voor beveiliging dat vereist is om het systeem tegen geïdentificeerde dreigingen te beschermen, gebaseerd op de geïdentificeerde kwetsbaarheden binnen risicobeheer (zie Risicobeheer); 

• de capaciteit van beveiligingsbeheersmaatregelen om beveiligingsgebeurtenissen te voorkomen, te detecteren of erop te reageren; 

• specifieke beveiligingsbeheersmaatregelen die worden vereist door bepaalde bedrijfsprocessen (bijv. het versleutelen van gevoelige informatie, integriteit-controle en digitale ondertekening van informatie); 

• waar en hoe beveiligingsbeheersmaatregelen behoren te worden toegepast (bijv. door ze te integreren met een beveiligingsarchitectuur en de technische infrastructuur); 

• hoe individuele beveiligingsbeheersmaatregelen (handmatige en geautomatiseerde) samenwerken om een geïntegreerde verzameling beheersmaatregelen tot stand te brengen. 

Het ontwerp van een systeem MOET gepaard gaan met: 

• 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); 

• hardening van systemen waarbij ieder geval gebruik gemaakt word van een hardening management beoefening waarbij leveranciers beveiligings adviezen worden nageleefd. 

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

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. 

principes voor veilig coderen zowel voor nieuwe ontwikkelingen als bij hergebruik (nieuwe features / versies) toepassen. 

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.  Er MOET tijdens en na het ontwikkelen worden getest.

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;

• het aanvalsoppervlak en het beginsel van het ‘least privilege’ (minste voorrechten) MOET zijn toegepast; 

• een verificatie om te verifieren dat in het verleden gemaakte fouten binnen de organisatie bij het ontwikkelen van toepassingen niet aanwezig zijn MOET zijn uitgevoerd.

Implementatiemaatregel

Nadat de code operationeel is gemaakt MOETEN:

• updates op beveiligde wijze te worden verpakt en ingezet;

• gemelde kwetsbaarheden in de informatieveiligheid worden opgepakt;

• logbestanden van fouten en vermeende aanvallen worden bijgehouden en regelmatig beoordeeld om de code zo nodig aan te passen;

• bibliotheken met broncode worden beschermd tegen toegang en manipulatie door onbevoegden (bijv. door gebruik te maken van configuratiebeheerinstrumenten die meestal functies als toegangsbeveiliging en versiebeheer bieden).

Implementatiemaatregel

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;

Als het nodig is om 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. 

Implementatiemaatregel

Er 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. 

Implementatiemaatregel

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;

• het aanvalsoppervlak en het beginsel van het ‘least privilege’ (minste voorrechten) MOET zijn toegepast; 

• een verificatie om te verifieren dat in het verleden gemaakte fouten binnen de organisatie bij het ontwikkelen van toepassingen niet aanwezig zijn MOET zijn uitgevoerd.

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: 

Het testen van de systemen en de beveiliging, zoals regressietests, codescans en penetratietests MOET worden uitgevoerd. 

Implementatiemaatregel

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

• een gedetailleerd schema van de activiteiten en tests; 

• input en verwachte output onder allerlei omstandigheden; 

• criteria om de resultaten te evalueren;  

• een besluit over verdere acties naarmate nodig is 

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: 

• 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 

Implementatiemaatregel

De 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. 

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. 

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 Informatieveiligheid in projectmanagement). Het volgende behoort te worden overwogen: 

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. 

Implementatiemaatregel

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 dienen er testrapporten als attestatie te worden aangeleverd. 

Implementatiemaatregel

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 behoren te worden vastgelegd om afdoende beheersing van alle veranderingen te waarborgen. 

Implementatiemaatregel

De procedures voor wijzigingsbeheer MOETEN het volgende te omvatten: 

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 

Document status (Metadata)

Onderstaande gegevens worden gebruikt voor rapporteringsdoeleinden in documentregister

status opties: