Informatieveiligheidsbeleid is van toepassing op alle soorten projecten en dus niet alleen op technische projecten.

Implementatiemaatregel

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

Implementatiemaatregel

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

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

• Informatiebeveiligingsrisico’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 informatiebeveiligingsrisico’s moeten worden beoordeeld en de doeltreffendheid van de behandeling wordt beoordeeld en beproefd. 

Implementatiemaatregel

Informatiebeveiligingseisen [bijv. [Beveiligingseisen voor toeppassingen]], eisen inzake de naleving van intellectuele-eigendomsrechten (Zie Leveranciersrelaties) MOETEN in de vroege stadia van projecten worden aangepakt. 

Implementatiemaatregel

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

Implementatiemaatregel

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

Implementatiemaatregel

Informatiebeveiligingseisen voor de door het project te leveren producten of diensten MOETEN worden vastgesteld met gebruikmaking van verschillende methoden zoals het afleiden van nalevingseisen uit informatiebeveiligingsbeleid, onderwerpspecifieke beleidsregels en regelgeving. Verdere informatiebeveiligingseisen kunnen worden ontleend aan activiteiten zoals dreigingsmodellering, beoordelingen van incidenten, het gebruik van kwetsbaarheidsdrempels of het opstellen van noodplannen om zo te bewerkstelligen dat de architectuur en het ontwerp van informatiesystemen worden beschermd tegen bekende dreigingen die gebaseerd zijn op de operationele omgeving. 

Implementatiemaatregel

Informatiebeveiligingseisen 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 informatiebeveiligingsbehoeften 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 informatiebeveiliging (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 informatiebeveiligingsbeleid en de onderwerpspecifieke beleidsregels van de organisatie, met inbegrip van relevante beveiligingsclausules in overeenkomsten of contracten. 

Zie de Termen en definities voor een formele definitie van Broncode. Dit beleid gaat over alle situaties waar broncode is opgeslagen.

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, wordt geadviseerd om de broncodebibliotheken terdege af te schermen. Voor deze beveiliging worden volgende richtlijnen gehanteerd: 

• broncodebibliotheken zijn privé. Het publiek maken van broncode kan alleen doormiddel door het [Beleid voor toegangsbeveiliging] te volgen. 

• Elke broncodebibliotheek is een bedrijfsmiddel en is daarom onderhevig aan [Beleid beheer bedrijfsmiddelen] 

• Procedures voor wijzigingsbeheer toepassen 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 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 rechtstreekse toegang tot de broncodebibliotheek krijgen, maar via ontwikkelinstrumenten die activiteiten en autorisaties met betrekking tot de broncode beheersen; 

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

• een auditlogbestand bijhouden van alle toegangsinstanties en van alle wijzigingen aan de broncode. 

Bewerkstelligen dat informatiebeveiliging binnen de veilige ontwikkelcyclus van software en systemen wordt ontworpen en geïmplementeerd. 

Implementatiemaatregel

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

Implementatiemaatregel

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

Software architectuur maakt gebruik van requirements engineering, de implementatie maatregelen in het ISMS zover toepasbaar, behoren terug te komen in het software ontwerp.

De productieomgeving en de gegevens beschermen tegen compromittering door ontwikkel- en testactiviteiten. 

Implementatiemaatregel

Met de volgende aspecten MOET rekening te worden gehouden: 

1. regels en autorisaties definieren, documenteren en implementeren voor het inzetten van software vanuit de ontwikkel- naar de productiestatus; 

2. veranderingen an productiesystemen en toepassingen in een test- of gefaseerde omgeving testen voordat ze in productiesystemen worden toegepast (zie Testen van de beveiliging tijdens ontwikkeling en acceptatie); 

3. niet testen in productieomgevingen behalve in gedefinieerde en goedgekeurde omstandigheden; 

4. compilers, editors en andere ontwikkelinstrumenten of systeemhulpmiddelen behoren, indien ze niet nodig zijn, niet toegankelijk te zijn vanuit productiesystemen; 

5. passende milieu-identificatielabels in menu's tonen om het risico op fouten te beperken; 

6. geen gevoelige informatie naar de ontwikkel- en testsysteemomgevingen kopiëren tenzij er wordt voorzien in gelijkwaardige beheersmaatregelen voor de ontwikkel- en testsystemen en er geen mogelijkheid is om met een testdataset te werken. 

Implementatiemaatregel

In alle gevallen MOETEN de ontwikkel- en testomgevingen te worden beschermd, waarbij het volgende 

in aanmerking behoort te worden genomen: 

1. het patchen en bijwerken van alle ontwikkelings-, integratie- en testinstrumenten (met inbegrip van builders, integratie-instrumenten, compilers, configuratiesystemen en bibliotheken); 

2. beveiligde configuratie van systemen en software conform IT Service management; 

3. toegangsbeveiliging voor de omgevingen conform Toegangsbeveiliging; 

4. monitoren van veranderingen aan de omgeving en de daarin opgeslagen codes; 

5. beveiligde monitoring van de omgevingen; 

6. back-ups maken van de omgevingen. 

Implementatiemaatregel

Het MOET niet mogelijk te zijn dat éen persoon zonder voorafgaande beoordeling en goedkeuring veranderingen aan zowel de ontwikkeling als de productie kan doorvoeren. Dit kan bijvoorbeeld worden bereikt door toegangsrechten te scheiden of door middel van regels die worden gemonitord. In uitzonderingssituaties behoren aanvullende maatregelen zoals het bijhouden van gedetailleerde logbestanden en realtimemonitoring te worden geimplementeerd om veranderingen door onbevoegden te detecteren en er actie op te ondernemen. 

Implementatiemaatregel

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

Implementatiemaatregel

Beveiliging in het versiebeheer: 

Elk gebruikt versiebeheer dient volgens volgende regels opgesteld te worden:  

• Een versie nummer voor een ontwikkeling dient te bestaan uit 3 componenten  

• MAJOR: wordt verhoogd bij nieuwe features of uitbreidingen die niet compatibel zijn bij de vorige MAJOR-versie  

• MINOR: wordt verhoogd bij het toevoegen van functionaliteit die compatibel is met de huidige MAJOR-versie  

• PATCH: wordt verhoogd bij het toevoegen van bugfixes binnen de huidige MINOR.  

Bovenstaande versie-bouwstenen dienen samengevoegd te worden tot het formaat: <MAJOR.MINOR.PATCH> 

Aanvullende labels voor prerelease (TNI, BETA, DEV) en build-metadata dienen toegevoegd te worden aan het bovenstaande formaat. Voorbeelden van deze aanvullende labels in combinatie met bovenstaand formaat zijn:  

• 1.0.0-alpha  

• 1.2.1-beta.11  

• 3.2.1-rc.1  

• 2.2.1-beta.20042021.1  

Als versie raamwerk volgen we het Semantisch Versioning principe, zoals beschreven op http://semver.org 

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 

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. 

Onder toepassingen verstaan we voornamelijk software applicaties die zijn ontwikkeld maar applicaties die zijn aangekocht zijn ook van toepassing.

Implementatiemaatregel

Beveiligingseisen voor toepassingen MOETEN worden geïdentificeerd en gespecificeerd aan de hand van een risicobeoordeling (zie Proces - Informatieveiligheid risicobeheer ). De eisen moeten met ondersteuning van informatiebeveiligingsspecialisten worden ontwikkeld.  

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 tekstvelden’, 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 

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.

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

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

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: 

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. 

Waarborgen dat informatiesystemen veilig worden ontworpen, geïmplementeerd en beheerd binnen de ontwikkelingslevenscyclus. 

Uitgangspunten voor veilig ontwerpen bieden richtlijnen voor manipulatietechnieken, beheer van beveiligde sessies en gegevensvalidatie en opschoning.

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. 

Implementatiemaatregel

Uitgangspunten voor het ontwerpen van beveiligde systemen MOETEN een analyse omvatten van: 

• het volledige spectrum van beheersmaatregelen voor beveiliging dat vereist is om informatie en systemen tegen geïdentificeerde dreigingen te beschermen gebasseerd op de geidentificeerde 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, integriteitscontrole 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 beveiligde systemen 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 informatiebeveiliging 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 [Beleid voor toegangsbeveiliging] en [Beleid voor 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

Waarborgen dat veilige software wordt geschreven waardoor het aantal potentiële informatiebeveiligingskwetsbaarheden in de software wordt beperkt.

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.  

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.

Implementatiemaatregel

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

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

Waarborgen dat veilige software wordt geschreven waardoor het aantal potentiële informatiebeveiligingskwetsbaarheden in de software wordt beperkt. 

Implementatiemaatregel

Er MOET tijdens en na het ontwikkelen worden getest.

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.

Waarborgen dat veilige software wordt geschreven waardoor het aantal potentiële informatiebeveiligingskwetsbaarheden in de software wordt beperkt. 

Implementatiemaatregel

Nadat de code operationeel is gemaakt MOET:

• updates op beveiligde wijze te worden verpakt en ingezet;

• behoren gemelde kwetsbaarheden in de informatiebeveiliging te worden opgepakt

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

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

• Gebruikte bibliotheken van derden dienen te worden gescreend en uit een door de organisatie beheerde omgeving te worden geladen geinstalleerd of geladen. Waar mogelijk dienen bibliotheken uit een door de organsiatie beheerde bron geladen te worden. 

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. 

Implementatiemaatregel

Als het nodig is een softwarepakket te wijzigen, MOETEN de volgende punten in overweging te worden genomen: 

• het risico dat ingebouwde beheersmaatregelen en integriteitsprocessen gecompromitteerd raken; 

• of het al dan niet nodig is toestemming van de leverancier te verkrijgen; 

• de mogelijkheid om de vereiste wijzigingen van de aanbieder als standaard programma-updates te verkrijgen; 

• de impact als de organisatie verantwoordelijk wordt gehouden voor het toekomstig onderhoud van de software als gevolg van de veranderingen; 

• compatibiliteit met andere software die in gebruik is. 

Valideren of aan de informatiebeveiligingseisen wordt voldaan wanneer toepassingen of code in de productieomgeving worden uitgerold. 

Implementatiemaatregel

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

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: 

• 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 (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 beveiligingsgerelateerde tekortkomingen te verifiëren deze diensten vallen onder software die geevalueerd moet worden voor gebruik. 

Implementatiemaatregel

Voor interne ontwikkelactiviteiten MOETEN dergelijke tests in eerste instantie te worden uitgevoerd door het ontwikkelteam. Vervolgens behoren onafhankelijke tests te worden uitgevoerd om te bewerkstelligen dat het systeem uitsluitend werkt zoals voorzien (zie Informatiebeveiliging in projectmanagement). Het volgende behoort te worden overwogen: 

• het uitvoeren van activiteiten om code te beoordelen als relevant element voor het testen op zwakke plekken in de beveiliging, met inbegrip van onvoorziene inputs en omstandigheden; 

• het scannen op kwetsbaarheden om onveilige configuraties en kwetsbaarheden in systemen te identificeren; 

• het uitvoeren van penetratietests om onveilige code en ontwerpen te identificeren 

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

Tests MOETEN worden uitgevoerd in een testomgeving die zo nauwkeurig mogelijk overeenkomt met de doelproductieomgeving om te bewerkstelligen dat het systeem geen kwetsbaarheden introduceert in de omgeving van de organisatie en dat de tests betrouwbaar zijn (zie Scheiding van ontwikkel-, test- en productieomgevingen).

De informatiebeveiliging behouden tijdens het uitvoeren van wijzigingen. 

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

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

Implementatiemaatregel

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