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

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 Leveranciersrelaties) MOETEN in de vroege stadia van projecten worden aangepakt. 

Implementatiemaatregel

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

Implementatiemaatregel

Verantwoordelijkheden en bevoegdheden voor 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, onderwerp-specifieke beleidsregels en regelgeving.

Verdere informatieveiligheidseisen 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 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 (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 en de 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: 

• De toegang tot broncodebibliotheken MOET beperkt worden tot bevoegde personen en het beleid voor toegangsbeveiliging Toegangsbeveiliging volgen;

• Procedures voor wijzigingsbeheer MOETEN worden toegepast op het bijwerken van broncode en het verlenen van toegang tot broncode, en MOETEN de passende autorisatie ontvangen; 

• Het MOET vermeden worden om vertrouwelijke informatie op te slaan in de broncode (bijv. 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 waar lees- en schrijftoegang op passende wijze worden beheerd en toegewezen; 

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

Implementatiemaatregel

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

Implementatiemaatregel

Bij het opzetten van ontwikkel-, test-, acceptatie-, en productieomgevingen MOETEN moeten de volgende maatregelen worden geïmplementeerd: 

• Er MOETEN regels en autorisaties worden opgezet en gedocumenteerd voor het transporteren van systeem componenten vanuit de ontwikkel- naar de productieomgeving; 

• Veranderingen aan systemen in productie MOETEN in een testomgeving worden getest voordat ze in productie worden geïmplementeerd;

• Er MAG NIET worden getest in productieomgevingen behalve in gedefinieerde en goedgekeurde omstandigheden; 

• Compilers, editors en andere ontwikkelinstrumenten of systeemhulpmiddelen MOGEN NIET, indien ze niet nodig zijn, toegankelijk zijn vanuit productiesystemen; 

• Er MAG GEEN gevoelige informatie naar de ontwikkel- en testsysteemomgevingen worden gekopieerd tenzij er wordt voorzien in gelijkwaardige beheersmaatregelen voor de ontwikkel- en testsystemen en er geen mogelijkheid is om met een testdataset te werken;

• Het patchen en bijwerken van alle ontwikkelings-, integratie- en test software met inbegrip van builders, integratie-instrumenten, compilers, configuratiesystemen en bibliotheken MOET worden uitgevoerd volgens de instructies van de leveranciers;

• Veranderingen aan de omgeving en de daarin opgeslagen codes MOET worden geregistreerd;

• Configuratie van systemen en software MOET gebeuren conform het beleid IT Service management /wiki/spaces/ISMS/pages/6330876011; 

• Toegangsbeveiliging voor de omgevingen MOET worden opgezet conform conform het beleid Toegangsbeveiliging; 

• Er MOETEN back-ups worden gemaakt van de omgevingen conform het beleid ICT-continuïteit.

Implementatiemaatregel

Het MAG NIET mogelijk zijn dat één persoon zonder voorafgaande beoordeling en goedkeuring veranderingen aan zowel de 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 realtime monitoring te worden geïmplementeerd om veranderingen door onbevoegden te detecteren en er actie op te ondernemen.

Implementatiemaatregel

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

Implementatiemaatregel

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

Implementatiemaatregel

Toepassingsbeveiligingseisen MOETEN het volgende te omvatten, al naargelang de situatie:  

• het niveau van vertrouwen in de identiteit van entiteiten (bijv. via authenticatie);  

• het identificeren van het door de toepassing te verwerken soort informatie en het classificatieniveau ervan;  

• de noodzaak van segmentatie van toegang en het niveau van toegang tot gegevens en functies in de toepassing;  

• weerstand tegen kwaadaardige aanvallen of onbedoelde verstoringen (bijv. bescherming tegen bufferoverflow of SQL-injecties];  

• wettelijke, statutaire en regelgevende eisen in het rechtsgebied waar de transactie wordt gegenereerd, verwerkt, voltooid of opgeslagen;  

• de noodzaak van privacy met betrekking tot alle betrokken partijen;  

• de eisen ten aanzien van bescherming van vertrouwelijke informatie;  

• bescherming van gegevens tijdens de verwerking, tijdens het transport en in rust; 

• de noodzaak om communicatie tussen alle betrokken partijen op beveiligde wijze te versleutelen;  

• inputbeheersmaatregelen, waaronder integriteitscontroles en validatie van de invoer;  

• geautomatiseerde beheersmaatregelen (bijv. goedkeuringslimieten of dubbele goedkeuring);  

• outputbeheersmaatregelen, waarbij ook wordt nagedacht over wie er toegang kan hebben tot output en de autorisatie ervoor;  

• beperkingen met betrekking tot de inhoud van vrije tekst-velden aangezien deze kunnen leiden tot ongecontroleerde opslag van vertrouwelijke gegevens (bijv. persoonsgegevens);  

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

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

• het afhandelen van foutmeldingen.

Implementatiemaatregel

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. 

Implementatiemaatregel

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. 

Implementatiemaatregel

Beveiliging MOET deel uitmaken van het ontwerp bij alle architectuurlagen (bedrijf, gegevens, toepassingen en technologie). 

Implementatiemaatregel

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.

Implementatiemaatregel

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. 

Implementatiemaatregel

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. 

Implementatiemaatregel

De organisatie MOET ‘zero trust’-beginselen overwegen zoals: 

• 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 Toegangsbeveiliging en Informatiebescherming).

Implementatiemaatregel

De 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

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

Implementatiemaatregel

De organisatie MOET organisatie-brede processen op stellen om te voorzien in goede governance voor veilig coderen. In aanvulling hierop MOETEN dergelijke processen en governance worden uitgebreid naar softwarecomponenten van derden en opensource software.  

Implementatiemaatregel

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

Implementatiemaatregel

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

Implementatiemaatregel

De planning en voorbereiding voor het ontwikkelen MOET de volgende elementen omvatten: 

• organisatie-specifieke 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.

Implementatiemaatregel

De organisatie 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 ieder- geval een dekking van geautomatiseerde testen voor alle kritieke capabiliteiten van de software (code coverage);

• het gebruik van gestructureerde programmeertechnieken;

• verbod op het gebruik van onveilige ontwerptechnieken (bijvoorbeeld het gebruik van hardgecodeerde wachtwoorden, niet-goedgekeurde codesamples en niet-geauthenticeerde webdiensten).

De organisatie KAN van de volgende standaarden gebruik maken:

• OWASP Secure Coding Practices;

• NIST Secure Software Development Framework.

Implementatiemaatregel

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.

Implementatiemaatregel

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

Als er gebruikgemaakt wordt van externe instrumenten en bibliotheken, MOET de organisatie nadenken 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. 

Implementatiemaatregel

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

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

Implementatiemaatregel

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

• beveiligingsfuncties [bijv. authenticatie van gebruikers (zie Toegangsbeveiliging), toegangsbeperking (zie Toegangsbeveiliging) en het gebruik van cryptografie (zie Cryptografie) 

• veilig coderen; 

• beveiligde configuraties (zie IT Service management /wiki/spaces/ISMS/pages/6330876011 (configuratiebeheer), Infrastructuurbeveiliging ) waaronder die van besturingssystemen, firewalls en andere beveiligingscomponenten. 

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 

Implementatiemaatregel

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

Implementatiemaatregel

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

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: 

• 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

Tests 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).

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

Implementatiemaatregel

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

Waar mogelijk MOETEN de procedures voor wijzigingsbeheer voor ICT-infrastructuur en -software worden geïntegreerd. 

Implementatiemaatregel

De procedures voor wijzigingsbeheer MOETEN het volgende te omvatten: 

1. het plannen en beoordelen van de potentiële impact van wijzigingen, waarbij alle afhankelijkheden in aanmerking worden genomen; 

2. autorisatie van veranderingen; 

3. veranderingen aan relevante belanghebbenden communiceren; 

4. tests en de aanvaarding van tests voor de veranderingen (zie paragraaf Testen van de beveiliging tijdens ontwikkeling en acceptatie); 

5. implementatie van veranderingen met inbegrip van inzetplannen; 

6. nood- en voorzorgsoverwegingen, met inbegrip van vangnetprocedures; 

7. registraties onderhouden van veranderingen waarin alle bovenstaande punten worden opgenomen; 

8. waarborgen dat bedieningsdocumentatie en gebruikersprocedures indien nodig worden gewijzigd om ze toepasbaar te houden; 

9. bewerkstelligen dat de plannen voor ICT-continuiteit en de respons- en herstelprocedures (zie ICT-continuïteit) worden gewijzigd naarmate nodig is om passend te blijven. 

Implementatiemaatregel

Bij wijzigingen MOET versiebeheer worden gebruikt.

Elk gebruikt versiebeheer MOET volgens volgende regels opgesteld worden:  

• Een versie nummer voor een ontwikkeling MOET 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 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:  

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

Implementatiemaatregel

Medewerkers MOETEN conform Personeelsbeveiliging /wiki/spaces/ISMS/pages/6330811457 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 

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. 

Document status (Metadata)

Onderstaande gegevens worden gebruikt voor rapporteringsdoeleinden in documentregister

status opties: