Veilig ontwerpen en ontwikkelen

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

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.

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

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

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

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.

Het is aangewezen om verdere informatieveiligheidseisen te ontlenen 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. 

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;

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

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

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;

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

Bij het opzetten van ontwikkel-, test-, acceptatie-, en productieomgevingen 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; 

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.

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

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.

Toepassingsbeveiligingseisen MOETEN het volgende omvatten, al naargelang de situatie:  

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

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; 

In aanvulling hierop MOET het volgende in aanmerking 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; 

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

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:

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

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

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; 

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.

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.

De organisatie MOET organisatie-brede processen opstellen 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.  

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.

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

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;

De organisatie MOET veilige coderingspraktijken die specifiek zijn voor de programmeertalen en -technieken, gebruiken.

Specifiek MOETEN de volgende regels worden gehanteerd: