Sandbox:cip

Deze pagina is in opbouw. Kom later terug om het resultaat te zien of neem contact op met nora@ictu.nl als je mee wilt werken aan de eerste concepten.

Alle Beveiligingseisen SSD met relatie 'heeft conformiteitsindicator'

(Dit overzicht zou je kunnen tonen in een overzichtspagina van alle Beveiligingseisen SSD)

Relatie 'heeft conformiteitsindicator' met specifieke Beveiligingseis

(Dit overzicht zou je op de pagina van specifieke Beveiligingseisen kunnen zetten)

Hardeningsbeleid met onderliggende indicatoren (relatie 'is onderdeel van')

(Dit overzicht zou je op de pagina van het trefwoord / hoofd conformiteitsindicator kunnen tonen na de beschrijving en toelichting. Het blijft leeg wanneer er geen onderliggende indicatoren zijn.) Er zijn geen onderliggende indicatoren

Hardeningsrichtlijn met onderliggende indicatoren (relatie 'is onderdeel van')

(Dit overzicht zou je op de pagina van het trefwoord / hoofd conformiteitsindicator kunnen tonen na de beschrijving en toelichting. Het blijft leeg wanneer er geen onderliggende indicatoren zijn.) Er zijn geen onderliggende indicatoren

Procesmatig en procedureel met onderliggende indicatoren (relatie 'is onderdeel van')

(Dit overzicht zou je op de pagina van het trefwoord / hoofd conformiteitsindicator kunnen tonen na de beschrijving en toelichting. Het blijft leeg wanneer er geen onderliggende indicatoren zijn.) Er zijn geen onderliggende indicatoren

Alle conformiteitsindicatoren en Beveiligingseisen SSD op ID met beschrijving, toelichting & context

(Dit overzicht zou je kunnen tonen op een overzichtspagina. Het kan ook nuttig zijn bij het invoeren van de informatie: hier check je snel of alles er goed en consistent instaat.)

Overzicht van alleen context Beleid

ID		Beschrijving	Toelichting
APO_B	Applicatieontwikkeling Beleid	==Objecten, controls en maatregelen== Onderstaande afbeelding toont de objecten die specifiek voor dit domein een rol spelen. Het geeft een overzicht en de ordening van objecten. De geel gemarkeerde objecten komen voor in de Baseline Informatiebeveiliging Overheid (BIO). De wit gemarkeerde objecten zijn betrokken uit andere best practices. Voor de identificatie van de objecten en de ordening is gebruik gemaakt van basiselementen (zie de grijs gemarkeerde tekst). Ze zijn ingedeeld naar de invalshoek: Intentie, Functie, Gedrag of Structuur. Overzicht objecten voor applicatieontwikkeling in het beleidsdomein
APO_B.01	Beleid voor (beveiligd) ontwikkelen	==Objectdefinitie== Betreft het resultaat van een besluitvorming over welke regels en protocollen gehanteerd moeten worden om op een veilige wijze beveiligde applicaties te ontwikkelen. Objecttoelichting De ISO 27002 2017, artikel 14.2.1 formuleert ‘Beveiligd ontwikkelen’ als een eis voor het opbouwen van een beveiligde dienstverlening, architectuur, software en een beveiligd systeem. In deze BIO Thema-uitwerking wordt bij het object ‘Beleid voor (beveiligd) ontwikkelen’ aan applicatieontwikkelingsbeleid gerelateerde specifieke aspecten benadrukt. In zo’n beleid worden onder andere methoden en technieken voor requirementsanalyse en -richtlijnen voor beveiliging in de levenscyclus van softwareontwikkeling besproken.
APO_B.01.01	De gangbare principes rondom Security by Design als uitgangspunt voor softwareontwikkeling
APO_B.01.02	Grip op Secure Software Development' als uitgangspunt voor softwareontwikkeling
APO_B.01.03	Overwegingen bij het beleid voor beveiligd ontwikkelen van software
APO_B.01.04	Technieken voor beveiligd programmeren
APO_B.02	Systeem-ontwikkelmethode	==Objectdefinitie== Betreft een gestructureerde manier van handelen voor het ontwikkelen van applicaties. Objecttoelichting Ontwikkel- en onderhoudsactiviteiten worden uitgevoerd met een systeem-ontwikkelmethode. Hierdoor wordt rekening gehouden met: Vereisten uit wet- en regelgeving Contractuele vereisten Beveiligingsvereisten Projectmatige aanpak
APO_B.02.01	Software wordt ontwikkeld conform een formeel vastgestelde ontwikkelmethodologie
APO_B.02.02	Softwareontwikkelaars zijn getraind om de ontwikkelmethodologie toe te passen
APO_B.02.03	Adoptie van ontwikkelmethodologie wordt gemonitord
APO_B.02.04	Software wordt ontwikkelen conform standaarden en procedures
APO_B.02.05	De systeemontwikkelmethode ondersteunt dat de te ontwikkelen applicaties voldoen aan de vereisten
APO_B.02.06	Het softwareontwikkeling wordt projectmatig aangepakt
APO_B.03	Classificatie van informatie	==Objectdefinitie== Betreft het systematisch indelen in categorieën van de waarde van informatie, om te kunnen bepalen welk niveau van bescherming de te ontwikkelen van applicaties nodig heeft. Objecttoelichting In ISO 27002 2017 is gesteld dat een organisatie haar informatie moet classificeren om ervoor te zorgen dat informatie een passend beschermingsniveau krijgt. Hiervoor moet de organisatie een classificatieschema opstellen en dit schema communiceren binnen de organisatie. Een classificatieschema geeft beveiligingsrichtlijnen voor zowel algemene informatiemiddelen als voor informatie in het ontwikkeltraject. Binnen dit thema moet de projectverantwoordelijke dit classificatieschema als input beschikbaar hebben om binnen deze context van de applicatie omgeving te kunnen toepassen. Het classificatieschema beidt specifieke richtlijnen voor het ontwikkeltraject.
APO_B.03.01	Dataclassificatie als uitgangspunt voor softwareontwikkeling
APO_B.03.02	Informatie in alle informatiesystemen is conform expliciete risicoafweging geclassificeerd
APO_B.03.03	Bij applicatieontwikkeling is informatie beschermd conform de vereisten uit het classificatieschema
APO_B.03.04	Verplichtingen uit wet en regelgeving en organisatorische en technische requirements
APO_B.04	Engineeringsprincipe voor beveiligde systemen	==Objectdefinitie== Betreft een regel, norm of beginsel voor ‘goed gedrag’, specifiek voor het ontwikkelen van applicaties die beveiligd moeten worden. Objecttoelichting Bij het ontwikkelen van applicaties worden engineeringsprincipes in acht genomen. In de Baseline Informatiebeveiliging Overheid (BIO) is het principe security by design expliciet genoemd. In de ISO 27033-2 2012 is het principe defence in depth expliciet genoemd. Hiernaast bestaan nog verschillende andere van belang zijnde (engineerings)principes die in andere baselines zijn opgenomen.
APO_B.04.01	Security by Design als uitgangspunt voor softwareontwikkeling
APO_B.04.02	Principes voor het beveiligen van informatiesystemen
APO_B.04.03	Beveiliging is integraal onderdeel van systeemontwikkeling
APO_B.04.04	Ontwikkelaars zijn getraind om veilige software te ontwikkelen
APO_B.05	Business Impact Analyse (BIA)	==Objectdefinitie== Betreft een methode om de mogelijke bedrijfsimpact te bepalen die een organisatie zou kunnen ervaren door een incident, die de functionaliteit van of de informatie in een applicatie in gevaar brengt. Objecttoelichting Eén van de specifieke activiteiten bij applicatieontwikkeling is het uitvoeren van een BIA. Hierbij wordt vanuit verschillende optieken de doelomgeving geanalyseerd, om op deze manier de juiste requirements voor de te ontwikkelen applicatie te kunnen identificeren en traceren.
APO_B.05.01	Perspectieven bij de Business Impact Analyse
APO_B.05.02	Scenario's voor de Business Impact Analyse
APO_B.05.03	Vaststelling op welke wijze een eventueel compromitteren invloed heeft op de financiën van de organisatie
APO_B.06	Privacy en bescherming persoonsgegevens applicatieontwikkeling	==Objectdefinitie== Privacy betreft de persoonlijke vrijheid, het recht om alleen gelaten te worden. Bescherming persoonsgegevens betreft het proces van de bescherming van deze gegevens. Objecttoelichting Bij applicatieontwikkeling behoort de verantwoordelijke stakeholder rekening te houden met privacy en de bescherming van persoonsgegevens in het kader van de AVG (Algemene Verordening Gegevensbescherming). Privacybescherming betekent een contextanalyse verrichten van de situatie waarin de desbetreffende applicatie ontwikkeld wordt. Hierbij wordt voorkomen dat eventuele inbreuk ontstaat op de persoonlijke levenssfeer van de personen waarvan persoonsgegevens worden verwerkt. Om inbreuk op de privacy vast te stellen, wordt voorafgaand aan het ontwerp van de applicatie een Privacy Impact Assessment (PIA) uitgevoerd voor waarschijnlijk hoog risicoverwerkingen. Deze verplichting komt voort uit de AVG.
APO_B.06.01	GEB om vooraf in het ontwerp de privacy en gegevensbeschermingsmaatregelen mee te nemen
APO_B.06.02	Procesbeschrijving voor uitvoeren GEB's en voor opvolgen uitkomsten
APO_B.06.03	Een tot standaard verheven GEB-toetsmodel wordt toegepast; dit model voldoet aan de in de AVG gestelde eisen
APO_B.06.04	Privacy by Design en GEB als onderdeel van een tot standaard verheven risicomanagement aanpak
APO_B.06.05	Risicomanagement aanpak aantoonbaar toegepast
APO_B.06.06	Op basis van de AVG worden de principes Privacy by Design en Privacy by Default gehanteerd
APO_B.07	Kwaliteitsmanagementsysteem	==Objectdefinitie== Omvat activiteiten waarmee de organisatie haar doelstellingen identificeert en vaststelt welke processen en middelen vereist zijn om gewenste resultaten te behalen (zie NEN-EN-ISO 9000:2015 Kwaliteitsmanagementsysteem - Grondbeginselen en verklarende woordenlijst). Objecttoelichting De doelorganisatie heeft de ontwikkelactiviteiten procesmatig ingericht en voert ook de noodzakelijke kwaliteitscontroles uit.
APO_B.07.01	De doelorganisatie beschikt over een ontwikkel en onderhoudsbeleid
APO_B.07.02	De doelorganisatie beschikt over QA- en KMS-methodiek
APO_B.07.03	De ontwikkel en onderhoudsactiviteiten worden in samenhang georganiseerd en geïmplementeerd
APO_B.07.04	Voor informatie- en communicatie zijn processen ingericht
APO_B.07.05	Op de ontwikkel- en onderhoudsactiviteiten worden kwaliteitsmetingen en inspecties uitgevoerd
APO_B.07.06	Aan het management worden evaluatierapportages verstrekt
APO_B.07.07	Applicatieontwikkeling- en onderhoudsprocessen zijn beschreven en maken onderdeel uit van KMS
APO_B.08	Toegangsbeveiliging op programmacode	==Objectdefinitie== Betreft de geautoriseerde toegang tot gevalideerde broncode (source code) voor het bouwen van applicaties. Objecttoelichting Toegang tot de programmacode en samenhangende elementen, zoals ontwerpen, specificaties, verificatie- en validatieschema’s zijn ingericht om onbevoegde functionaliteit en ongeautoriseerde wijzigingen te voorkomen en om de vertrouwelijkheid van intellectueel eigendom te handhaven. NB De broncode is de gevalideerde en in de broncodebibliotheek opgeslagen programmacode.
APO_B.08.01	Om de toegang tot broncode bibliotheken te beheersen worden richtlijnen in overweging genomen
APO_B.08.02	Aanvullende beheersmaatregelen wanneer programmabroncode wordt gepubliceerd
APO_B.09	Projectorganisatie	==Objectdefinitie== Betreft een doelgerichte bundeling van kennis en vaardigheden tussen personen met taken, verantwoordelijkheden en bevoegdheden voor projectmatige softwareontwikkeling. Objecttoelichting Binnen de (project-)organisatie is een beveiligingsfunctionaris betrokken die verantwoordelijkheid draagt bij het ondersteunen van applicatieontwikkelingen (projecten). Binnen het project heeft hij de specifieke taak gericht op het vervaardigen van beveiligingsvoorschriften. De expliciete taken, verantwoordelijkheden en bevoegdheden van de beveiligingsfunctionaris zijn vooraf expliciet benoemd en vastgesteld. De beveiligingsfunctionaris ziet toe op het naleven van het informatiebeveiligingsbeleid en architectuurvoorschriften. Ook staat vast hoe de rapporteringslijnen zijn uitgestippeld.
APO_B.09.01	Taken van de beveiligingsfunctionaris
APO_B.09.02	Inzicht gegeven door de beveiligingsfunctionaris
CLD_B	Clouddiensten Beleid	==Objecten, controls en maatregelen== De onderwerpen die specifiek voor clouddiensten in het beleidsdomein een rol spelen, zijn in afbeelding 'Overzicht objecten voor clouddiensten in het beleidsdomein' vermeld. Is een objectblok geel gekleurd, dan komt de bijbehorende control voor in de Baseline Informatiebeveiliging Overheid (BIO). Betreft het een wit gemarkeerd objectblok, dan heeft de BIO geen control gedefinieerd, maar is dit object wel noodzakelijk voor deze BIO Thema-uitwerking. Overzicht objecten voor clouddiensten in het beleidsdomein Per specifiek beveiligingsobject worden de control (hoofdnorm) en maatregelen (sub-normen) beschreven (zie Principes uit de BIO Thema Clouddiensten binnen dit aspect en Normen uit de BIO Thema Clouddiensten binnen dit aspect).
CLD_B.01	Wet- en regelgeving Clouddiensten	==Objectdefinitie== Omvat de geldende nationale en internationale wetten en regelgeving die van toepassing is op clouddiensten. Objecttoelichting Nationale en internationale wet- en regelgeving die van toepassing is op clouddiensten, zoals vooral de Algemene Verordening Gegevensbescherming (AVG), heeft betrekking op de te nemen organisatorische en technische maatregelen, zoals bewustwording, mensen en fysieke middelen. De Cloud Service Provider (CSP) zal deze vertalen naar specifieke eisen voor cloud-componenten.
CLD_B.01.01	Informeren welke wet- en regelgeving van toepassing is op clouddiensten
CLD_B.01.02	Selecteren relevante wettelijke eisen ter bescherming van persoonsgegevens
CLD_B.01.03	Identificeren vereisten die van toepassing zijn
CLD_B.01.04	Voorzien zekerheid over van toepassing zijnde wettelijke eisen en contractuele vereisten
CLD_B.01.05	Treffen van maatregelen en benoemen verantwoordelijkheden om te voldoen aan gestelde eisen
CLD_B.01.06	Vaststellen alle van toepassing zijnde wet- en regelgeving
CLD_B.02	Cloudbeveiligingsstrategie	==Objectdefinitie== Omvat het plan van handelen van de CSP waarmee zijn beveiligingsdoelstellingen voor de clouddienstenlevering kunnen worden gerealiseerd. Objecttoelichting Organisaties staan voor de vraag, welke clouddiensten ze moeten verwerven en waar en hoe ze deze veilig kunnen inzetten. Hiervoor moeten de IT-stakeholders van Cloud Service Providers (CSC’s) een beslissingsraamwerk ontwikkelen, waarmee systematisch de mogelijke scenario’s kunnen worden onderzocht. Dit raamwerk richt zich met name op typen applicaties en technische karakteristieken. Een strategie omvat uitspraken over de doelstellingen bij de inzet van de clouddiensten die de organisatie wil nastreven en de wegen waarlangs of de wijze waarop dit moet plaatsvinden. Om CSC’s te kunnen bedienen, heeft de CSP vanuit haar eigen optiek een cloudbeveiligingsstrategie ontwikkeld. Deze strategie geeft de CSC’s voldoende mogelijkheden om hun cloud-strategie te relateren aan de strategie van een specifieke CSP. Dit biedt de CSC de mogelijkheid om haar keuzes bij te stellen dan wel aanvullende eisen aan de CSP te stellen.
CLD_B.02.01	Aangeven hoe cloudbeveiligingsstrategie bedrijfsdoelstellingen ondersteunt
CLD_B.02.02	Aangeven hoe te beschermen tegen bedreigingen en aandacht te besteden aan beveiligingscontext
CLD_B.02.03	Ondersteunen in behalen van bedrijfsdoelen door samenhang van beveiligingsmaatregelen
CLD_B.03	Exit-strategie clouddiensten	==Objectdefinitie== Omvat het plan van handelen, inclusief voorwaarden voor de beëindiging van de dienstverlening bij een bestaande Cloud Service Provider (CSP), plus het kunnen overzetten van data en IT-diensten naar een nieuwe CSP. Objecttoelichting Omdat geen enkel contract voor eeuwig is, moet een Cloud Service Consumer (CSC) op een zeker moment afscheid kunnen nemen van de CSP. Als bij het afsluiten van de clouddienst geen bindende afspraken zijn gemaakt over het afscheid nemen, kan het heel lastig of kostbaar worden om data te migreren naar een andere CSP. De organisatie moet rekening houden met een ‘vendor lock-in’. Het is daarom van belang, nog voor het aangaan van een overeenkomst met een CSP, een exit-strategie te ontwikkelen. De exit-strategie dient de voorwaarden voor mutaties van data te bevatten. Het is ook mogelijk de praktische uitwerking van de exit-strategie op te nemen in een Service Level Agreement (SLA). Om verschillende redenen kan een CSC de dienstverlening van de CSP willen beëindigen. Enerzijds planmatig, zoals bij het einde van de contracttermijn, anderszins vanwege moverende redenen, zoals niet voldoen aan de afspraken, overname van de CSP door een andere organisatie. Het niet planmatig beëindigen is gerelateerd aan de exit-strategie, dat onderdeel is van bedrijfscontinuïteitsmanagement (BCM). Het planmatig beëindigen van de dienstverlening raakt de transitie en is onderdeel van Service Level Management (SLM).
CLD_B.03.01	Vastleggen bepalingen over exit-regeling
CLD_B.03.02	Overgaan tot exit buiten verstrijken contractperiode
CLD_B.04	Clouddienstenbeleid	==Objectdefinitie== Omvat beleidsuitgangspunten en de wijze waarop, in welk tijdbestek en met welke middelen, de beveiligingsdoelstellingen voor clouddiensten bereikt moeten worden. Objecttoelichting Het onderwerp clouddiensten moet een specifiek onderdeel zijn van het informatiebeveiligingsbeleid van de Cloud Service Consumer (CSC). Een CSC kan ook kiezen voor een specifiek clouddienstenbeleid, waarbij in de informatiebeveiligingsparagraaf het algemene informatiebeveiligingsbeleid specifiek voor clouddiensten wordt uitgewerkt of ingevuld. Het beleid zal uitgangspunten moeten bevatten over de wijze waarop, binnen welk tijdsbestek en met welke middelen clouddiensten de doelstellingen moeten bereiken. In dit beleid zal ook aandacht moeten worden besteed aan archiveringsbeleid, cryptografiebeleid, certificering en verklaringen. Om de CSC te kunnen bedienen, zal de Cloud Service Provider (CSP) vanuit haar eigen optiek een cloud-beveiligingsbeleid hebben ontwikkeld. Dit beleid geeft de CSC mogelijkheden om haar cloud-beleid te relateren aan de strategie van de CSP en biedt de CSC de mogelijkheid om de keuzes bij te stellen dan wel aanvullende eisen aan de CSP te stellen.
CLD_B.04.01	Bevatten organisatorisch en technische georiënteerde maatregelen in cloudbeveiligingsbeleid
CLD_B.05	Transparantie	==Objectdefinitie== Omvat de inzichtelijkheid van de relaties en samenhang van organisatie, technologie en contracten daarover tussen Cloud Service Consumer (CSC) en Cloud Service Provider (CSP). Objecttoelichting Een eenduidige communicatie, waarmee de CSP de verantwoordelijke functionarissen binnen de CSC en CSP inzicht geven over de status van de implementatie en het functioneren van de clouddiensten. Transparantie is in de relatie tussen de CSC en CSP een belangrijk item, dat wordt ondersteund door de clouddienstenarchitectuur. Hierin beschrijft de CSP de relaties tussen de componenten van de clouddiensten (hoe deze aan elkaar gekoppeld zijn). Het verschaft inzicht en overzicht over ICT-componenten en hun onderlinge samenhang. Uit de clouddienstenarchitectuur blijkt hoe de componenten de bedrijfsprocessen van de CSC ondersteunen.
CLD_B.05.01	Bevatten diverse aspecten in systeembeschrijving
CLD_B.05.02	SLA/systeembeschrijving bevat specificatie van jurisdictie inzake data-opslag, verwerking en back-up-locatie
CLD_B.05.03	SLA/systeembeschrijving bevat specificatie voor publicatie-vereisten en onderzoeksmogelijkheden
CLD_B.05.04	SLA/systeembeschrijving bevat specificatie met betrekking tot beschikbaar zijn van valide certificaten
... meer resultaten

Overzicht van alleen context Uitvoering

ID		Beschrijving	Toelichting
APO_U	Applicatieontwikkeling Uitvoering	==Objecten, controls en maatregelen== Binnen het uitvoeringsdomein worden specifieke inrichtings- en beveiligingsobjecten voor applicatieontwikkeling beschreven. Per object worden conformiteitsindicatoren en de desbetreffende implementatie-elementen uitgewerkt. De rood gemarkeerde objecten komen voor in de Baseline Informatiebeveiliging Overheid (BIO). De wit gemarkeerde objecten zijn betrokken uit andere best practices, zie onderstaande afbeelding. De objecten zijn ingedeeld naar intentie, functie, gedrag en structuur. In de pagina Invalshoeken gekoppeld aan het V-model zijn de invalshoeken gekoppeld aan het V-model. Overzicht objecten voor applicatieontwikkeling in het uitvoeringsdomein
APO_U.01	Wijzigingsbeheerprocedure voor applicaties en systemen	==Objectdefinitie== Omvat een vastgelegde manier van handelen voor de wijziging en instandhouding van applicaties en systemen. Objecttoelichting Wijzigingsbeheer heeft tot doel om wijzigingen binnen het traject van applicatieontwikkeling op een beheerste en geautoriseerde wijze te laten verlopen, zodat voorkomen wordt dat de doorgevoerde wijzigingen allerlei verstoringen veroorzaken.
APO_U.01.01	Voor het wijzigingsbeheer gelden de algemeen geaccepteerde beheer frameworks
APO_U.01.02	Medewerkers (programmeurs) krijgen de juiste autorisatie om werkzaamheden te kunnen uitvoeren
APO_U.01.03	Nieuwe systemen en belangrijke wijzigingen aan bestaande systemen volgen een formeel wijzigingsproces
APO_U.01.04	Elementen van de procedures voor wijzigingsbeheer
APO_U.02	Beperking software-installatie applicatieontwikkeling	==Objectdefinitie== Betreft systematisch ontwikkelde aanbevelingen, bedoeld om het installeren van programmatuur door eindgebruikers te beperken. Objecttoelichting Het installeren van software kan betrekking hebben op 3 type actoren: Gebruikers, om een bepaald type data-analyse in de business-omgeving te kunnen uitvoeren; Softwareontwikkelaars, voor requirementsspecificatie, het creëren van datamodellen en het genereren van de programmacode; Technische beheerders, voor het beheren van servers en netwerkcomponenten. Deze BIO Thema-uitwerking is gericht op eisen die gerelateerd zijn aan het installeren van software door ontwikkelaars voor het specificeren van gebruikersrequirements. Hierbij kan gedacht worden aan het toekennen van minimale rechten aan ontwikkelaars om additionele hulpsoftware te installeren of het toekennen van rechten die gerelateerd zijn aan de regels: need-to-use, need-to-know, need-to-modify, need-to-delete. Het doel hiervan is om risico’s die gerelateerd zijn aan het onbedoeld wijzigen van kritische assets (zoals informatie, software, applicaties en system security controls) te beperken.
APO_U.02.01	Beleid ten aanzien van het type software dat mag worden geïnstalleerd
APO_U.02.02	Het toekennen van rechten om software te installeren vindt plaats op basis van 'Least Privilege'
APO_U.02.03	De rechten verleend op basis van de rollen van het typen gebruikers en ontwikkelaars
APO_U.03	Richtlijn programmacode	==Objectdefinitie== Betreft systematisch ontwikkelde aanbevelingen voor de broncode van een applicatie. Objecttoelichting De programmacode wordt ontwikkeld door bepaalde typen ontwikkelaars. Het ontwikkelen is geen eenmalige activiteit en vindt plaats langs een cyclisch proces van ontwikkelen, testen en verbeteren. Voor een effectieve inrichting van dit cyclische proces nemen ontwikkelaars regels in acht, waarbij zij gebruik maken van afgesproken best practices. Zonder deze regels en afspraken bestaat het risico dat het voortbrengingsproces van de software/applicatie verstoord wordt, met als consequentie dat het product niet onderhoudbaar is en/of niet efficiënt tot stand komt.
APO_U.03.01	De programmacode voor functionele specificaties is reproduceerbaar
APO_U.03.02	Programmacode wordt aantoonbaar veilig gecreëerd
APO_U.03.03	Programmacode is effectief, veranderbaar en testbaar
APO_U.03.04	Over het gebruik van vocabulaire, applicatieframework en toolkits zijn afspraken gemaakt
APO_U.03.05	Voor het ontwikkelen van programmacode wordt gebruik gemaakt van gestandaardiseerde vocabulaire
APO_U.03.06	Ontwikkelaars hebben kennis van algemene en vastgelegde beveiligingsfouten
APO_U.03.07	Gebruik van programmacode uit externe programmabibliotheken
APO_U.04	Analyse en specificatie informatiesysteem	==Objectdefinitie== Betreft een systematisch onderzoek naar functionele eisen voor een applicatie, bepaald door de business en andere stakeholders. Objecttoelichting Het analyseren en specificeren van requirements is een proces van het traceren en onderkennen van functionele en niet-functionele requirements waar de te ontwikkelen applicatie aan moet voldoen. Ook worden de constraints geïdentificeerd die zullen gelden in de ontwikkel- en de operatiefases. Het ontwikkelen van informatiesystemen wordt tegenwoordig veelal uitgevoerd conform de iteratieve ontwikkelmethode (Agile). Onafhankelijk van de methode (traditioneel, Waterval of Agile) is sprake van een aantal ontwikkelstappen waaraan aandacht wordt besteed: functionele eisen onder andere: functionaliteiten, gegevens, business rules, presentatie, interactie en foutafhandelingen; niet-functionele eisen onder andere: betrouwbaarheid, gebruiksvriendelijkheid, efficiëntie, onderhoudbaarheid, performance en flexibiliteit in overdraagbaarheid. In de NEN-ISO/IEC 27002 wordt rond dit thema alleen focus gelegd op niet-functionele eisen (beveiligingseisen). Daarom is naast het object ‘Analyse en specificatie van informatiebeveiligingseisen’ ook het object ‘Analyse en specificatie van informatiesystemen’ toegevoegd, waarbij de nadruk gelegd wordt op functionele eisen. Deze BIO Thema-uitwerking is baseline gebaseerd en met lineaire volgens het V-modelaanpak uitgewerkt. Aangezien bij Agile niet op deze wijze wordt gewerkt, verdient dit aspect extra aandacht.
APO_U.04.01	Functionele eisen van nieuwe informatiesystemen worden geanalyseerd en in Functioneel Ontwerp vastgelegd
APO_U.04.02	Het Functioneel Ontwerp wordt gereviewd waarna verbeteringen en/of aanvullingen plaatsvinden
APO_U.04.03	Op basis van een goedgekeurd Functioneel Ontwerp wordt een Technisch Ontwerp vervaardigd
APO_U.04.04	Alle vereisten worden gevalideerd door peer review of prototyping
APO_U.04.05	Acceptatie-eisen worden vastgelegd parallel aan het Functioneel Ontwerp en Technisch Ontwerp
APO_U.05	Analyse en specificatie informatiebeveiligingseisen	==Objectdefinitie== Betreft een systematisch onderzoek naar en het vaststellen van informatiebeveiligingseisen voor een applicatie. Objecttoelichting Het object Analyse en specificatie informatiebeveiligingseisen heeft betrekking op niet-functionele eisen, zoals betrouwbaarheid, gebruiksvriendelijkheid, efficiëntie, onderhoudbaarheid, performance en flexibiliteit in overdraagbaarheid.
APO_U.05.01	Een expliciete risicoafweging wordt uitgevoerd ten behoeve van het vaststellen van de beveiligingseisen
APO_U.05.02	De Handreikingen: "Risicoanalysemethode" en "Risicomanagement ISO-27005
APO_U.05.03	Informatiebeveiligingseisen
APO_U.05.04	Overwogen informatiebeveiligingseisen
APO_U.06	Applicatie-ontwerp	==Objectdefinitie== Betreft specificaties vastgelegd in tekst en beeld van een computerprogramma. Objecttoelichting Tijdens de ontwerpfase worden de (niet-)functionele requirements omgezet naar een uitvoerbaar informatiesysteem. Een high level architectuur wordt ontwikkeld om de software te kunnen bouwen. Hierbij wordt onder andere aandacht besteed aan de gebruikte data door het systeem, de functionaliteit die geboden moeten worden, de toegepaste interfaces tussen componenten binnen het systeem en aan koppelingen met andere systemen. Ook worden constraints die voortvloeien uit specifieke beveiligingseisen verder uitgewerkt.
APO_U.06.01	Het ontwerpen van applicaties is gebaseerd op eisen voor verschillende typen informatie
APO_U.06.02	Bij het ontwerp is informatie verkregen uit connecties met de te ontwerpen applicatie
APO_U.06.03	Het ontwerp is mede gebaseerd op een beveiligingsarchitectuur
APO_U.07	Applicatiefunctionaliteit	==Objectdefinitie== Omvat toepassingsfuncties die ondersteuning bieden aan bedrijfsprocessen. Objecttoelichting De functies kunnen worden onderverdeeld in invoer-, verwerking- en uitvoerfuncties. Binnen de functies worden controles en rekenregels ingebouwd om de gewenste acties te kunnen uitvoeren en gewenste resultaten te kunnen leveren. Het totaal aan functionaliteiten moet aan bepaalde eisen voldoen. Zo moeten functionaliteiten: voldoen aan de behoefte van de gebruikers; de gebruikerstaken afdekken; resultaten leveren die nauwkeurig zijn; geschikt zijn om bepaalde taken te kunnen ondersteunen.
APO_U.07.01	Bereikcontroles worden toegepast en gegevens worden gevalideerd
APO_U.07.02	Geprogrammeerde controles worden ondersteund
APO_U.07.03	Het uitvoeren van onopzettelijke mutaties wordt tegengegaan
APO_U.07.04	Voorzieningen voor het genereren van fouten- en uitzonderingsrapportage zijn beschikbaar
APO_U.07.05	Voorzieningen voor het achteraf vaststellen van een betrouwbare verwerking zijn beschikbaar
APO_U.07.06	Opgeleverde en over te dragen gegevens worden gevalideerd
APO_U.07.07	Controle op de juistheid, volledigheid en tijdigheid van input en op de verwerking en output van gegevens
APO_U.07.08	Voorkomen wordt dat gegevens buiten de applicatie om (kunnen) worden benaderd
APO_U.07.09	Gegevens worden conform vastgestelde beveiligingsklasse gevalideerd
APO_U.08	Applicatiebouw	==Objectdefinitie== Betreft het ontwikkelen van een programmacode. Objecttoelichting Na de eerste twee ontwikkelfasen, waarbij de nadruk ligt op de analyse van requirements en op het ontwerp van het product, volgt de derde fase, de applicatiebouw. In deze derde fase wordt de programmacode gecreëerd met good practices, methoden/technieken en bepaalde beveiligingsuitgangspunten.
APO_U.08.01	Voor het bouwen van programmacode worden gedocumenteerde standaarden en procedures beschikbaar gesteld
APO_U.08.02	Veilige methodes ter voorkoming van veranderingen in basis code of in software packages
APO_U.08.03	Voor het creëren van programma code wordt gebruik gemaakt van good practices
APO_U.08.04	Geen gebruik van onveilig programmatechnieken
APO_U.08.05	(Applicatie)code is beschermd tegen ongeautoriseerde wijzigingen
APO_U.08.06	Activiteiten van applicatiebouw worden gereviewd
APO_U.08.07	De ontwikkelaars zijn adequaat opgeleid en in staat de noodzakelijke en gebruikte tools te hanteren
APO_U.09	Testen systeembeveiliging	==Objectdefinitie== Een verzameling van uitgevoerde activiteiten om na te gaan of het systeem voldoet aan de vooraf gestelde beveiligingseisen. Objecttoelichting Bij het object Testen systeembeveiliging gaat het om het testen van het totale informatiesysteem dat ontwikkeld wordt. Tijdens het ontwikkelproces worden in verschillend stadia verschillende tests uitgevoerd. Hierbij worden onder andere onder diverse omstandigheden tests uitgevoerd op input, verwerkingen en verwachte output. Na integratie van het informatiesysteem in de infrastructuur wordt specifiek vanuit beveiligingsoptiek getest.
APO_U.09.01	Functionarissen testen functionele requirements
APO_U.09.02	In de infrastructuur wordt specifiek getest vanuit beveiligingsoptiek
APO_U.10	Systeemacceptatietest	==Objectdefinitie== Betreft de eindtoets van een applicatie of deze al dan niet geaccepteerd kan worden. Objecttoelichting De systeemacceptatietest is zowel in de Waterval- als in de Agile-ontwikkelmethode de afsluitende test. Voor beide methoden gelden een aantal eisen waarmee tijdens de systeemacceptatietest rekening gehouden moet worden. Bij de acceptatietest wordt door gebruikers getoetst of de requirements adequaat in het uiteindelijke product zijn verwerkt. Hierbij gaat het niet alleen om de beveiligingseisen maar ook om de functionele eisen, gebruikerseisen, businesseisen en business rules. De systeemtest wordt in onderstaande afbeelding geïllustreerd voor beide methoden. Systeemtest bij Waterval- en Agile-methode
APO_U.10.01	Voor acceptatietesten van (informatie)systemen worden gestructureerde testmethodieken gebruikt
APO_U.10.02	Van de resultaten van de testen wordt een verslag gemaakt
APO_U.10.03	Testresultaten worden formeel geëvalueerd en beoordeeld
APO_U.10.04	Acceptatietesten worden uitgevoerd in een representatieve acceptatietest omgeving
APO_U.10.05	Vastgestelde acceptatiecriteria en passend uitgevoerde tests voorafgaand aan acceptatieproductie overgang
APO_U.10.06	Tenzij geanonimiseerd worden productiegegevens niet gebruikt als testgegevens
APO_U.10.07	Bij acceptatietest wordt getoetst of het geleverde product overeenkomt met hetgeen is afgesproken
APO_U.11	Beschermen testgegevens	==Objectdefinitie== Betreft het beschermen van gegevens die gebruikt worden om aan te tonen dat een applicatie werkt volgens de vastgestelde eisen en wensen. Objecttoelichting Voor het testen van informatiesystemen wordt gebruik gemaakt van verschillende soorten gegevens. Het gebruik van operationele databases met persoonsgegevens of enige andere vertrouwelijke informatie moet worden vermeden en aangepast. Testgegevens dienen zorgvuldig te worden gekozen, beschermd en gecontroleerd.
APO_U.11.01	Richtlijnen worden toegepast om operationele gegevens die voor testdoeleinden worden gebruikt te beschermen
APO_U.12	Beveiligde ontwikkelomgeving	==Objectdefinitie== Betreft een omgeving die uitsluitend wordt gebruikt om applicaties te creëren of aan te passen. Objecttoelichting Het traject van ontwikkelen van een applicatie en het in productie nemen van de resultaten van dit ontwikkeltraject vindt gefaseerd plaats in specifieke omgevingen. Bij de ontwikkeling worden vier omgevingen onderscheiden: Ontwikkelomgeving, Hierin wordt de programmacode ontwikkeld. Om te voorkomen dat ontwikkelingen het productieproces kunnen beïnvloed is deze omgeving gescheiden van de productie omgeving. Testomgeving, Hierin worden de uit de ontwikkelomgeving afkomstige producten getest door professionele testteams. Aanwezige, in de testomgeving gesignaleerde, onvolkomenheden in de software worden weer via ontwikkelomgeving aangepast. Dit is een iteratief proces totdat uit de test naar voren komt dat het product geschikt is om in productie te nemen; Acceptatieomgeving, Hierin worden de softwareproducten (nog éénmaal grondig) getest en bij positief resultaat door de gebruikers en beheerders geaccepteerd. Bij eventuele onvolkomenheden worden de softwareproducten niet geaccepteerd (no-go) en terug gestuurd naar de testomgeving of ontwikkelomgeving; Productieomgeving, Hierin worden de nieuwe softwareproducten uitgerold. De Productie omgeving is de omgeving waarin de nieuwe softwareproducten functioneel en actief moeten zijn. De in de voorgaande omgevingen uitgevoerde stappen moeten zo veel mogelijk garanderen dat nieuw ontwikkelde software geen fouten bevat die de productiegegevens kunnen corrumperen. In principe zijn alle omgevingen los van elkaar ingericht en vindt behalve via formele overdrachten geen contact plaats tussen de verschillende omgevingen.
APO_U.12.01	Uitgangspunt voor systeemontwikkeling trajecten is een expliciete risicoafweging
APO_U.12.02	Logisch en/of fysiek gescheiden Ontwikkel, Test, Acceptatie en Productie omgevingen
APO_U.12.03	De taken, verantwoordelijkheden en bevoegdheden worden uitgevoerd conform de onderkende rollen
APO_U.12.04	Voor remote werkzaamheden is een werkwijze vastgelegd
APO_U.12.05	Ontwikkelaars hebben geen toegang tot productieomgeving
... meer resultaten

Overzicht van alleen context Control

ID		Beschrijving	Toelichting
APO_C	Applicatieontwikkeling Control	==Objecten, controls en maatregelen== Onderstaande afbeelding toont de objecten die specifiek voor dit domein een rol spelen. Het blauw gemarkeerde object komt voor in de Baseline Informatiebeveiliging Overheid (BIO). De wit gemarkeerde objecten zijn betrokken uit andere best practices. De objecten zijn ingedeeld naar de invalshoek: Intentie, Functie, Gedrag of Structuur. Overzicht objecten voor applicatieontwikkeling in het control-domein
APO_C.01	Richtlijn evaluatie-ontwikkelactiviteiten	==Objectdefinitie== Vooraf bepaalde regels voor het achteraf beoordelen van ontwikkelactiviteiten. Objecttoelichting De ontwikkelorganisatie moet tijdig een softwareproduct realiseren dat aan de gestelde eisen voldoet. Hiervoor verrichten deze organisatie periodiek controle- en reviewactiviteiten op de producten die in de ontwikkelfase tot stand komen, zoals requirements, specificaties, intern ontwikkelde programmacode en delen die uit externe bibliotheken worden verworven. De verantwoordelijke functionarissen moeten daarvoor beschikken over de nodige controlerichtlijnen.
APO_C.01.01	Controle richtlijnen voor de evaluatie van de producten die uit de ontwikkelfasen voorvloeien
APO_C.01.02	Evaluatierichtlijnen voor het evalueren van intern ontwikkelde en extern verworven code
APO_C.01.03	Controle richtlijnen die binnen de relevante beheerprocessen worden toegepast
APO_C.01.04	Het kwaliteitshandboek bevat procedures voor Quality Control en Quality Assurance methodiek en reviewrichtlijnen
APO_C.01.05	De Quality Assurance methodiek wordt conform de richtlijnen nageleefd
APO_C.01.06	Controleactiviteiten en rapportages over de ontwikkelactiviteiten en bijbehorende beheerprocessen
APO_C.01.07	Het applicatieontwikkelproces, de testcyclus en programmacodekwaliteit worden periodiek beoordeeld
APO_C.02	Versiebeheer applicatieontwikkkeling	==Objectdefinitie== Betreft een instandhoudingsproces voor de registratie van verschillende fases van een document, programma of andere informatie. Objecttoelichting Versiebeheer is het beheerproces dat verantwoordelijk is voor het organiseren van versies van applicatie-objecten tijdens het ontwikkel- en onderhoudstraject. Enerzijds heeft versiebeheer te maken met versies van documenten, zoals documenten die functionele eisen en functionele en technische ontwerpen bevatten. Anderzijds heeft versiebeheer te maken met versies van programmacodemanagement in de verschillende fases van het ontwikkel- en onderhoudstraject. Een goed versiebeheerproces zorgt ervoor: dat iedere medewerker de juiste en meest recente versie van de functionele eisen hanteert bij het ontwikkelen van software-specificaties; dat binnen het ontwikkel- en onderhoudsproces de juiste versie van programmacode wordt gebruikt. Hierdoor kunnen releases van applicaties met de juiste code en relevante bestanden worden samengesteld. Vanuit efficiëntie kan versiebeheer geautomatiseerd ondersteund worden.
APO_C.02.01	Versiemanagement is beschreven, vastgesteld en toegekend aan een verantwoordelijke functionaris
APO_C.02.02	Versiemanagement beschrijft welke applicatieobjecten in het ondersteunend tool worden vastgelegd
APO_C.02.03	Versiemanagement wordt ondersteund met procedures en werkinstructies
APO_C.02.04	Ondersteuning vanuit het toegepaste versiebeheertool
APO_C.03	Patchmanagement applicatieontwikkeling	==Objectdefinitie== Betreft een besturingsproces voor het verwerven, testen en installeren van patches op een computersysteem. Objecttoelichting Binnen een projectprogramma wordt bij het ontwikkelen van informatiesystemen programmacode gecreëerd. Soms hebben ontwikkelaars de mogelijkheid om voor bepaalde functionaliteiten code uit een externe bibliotheek te gebruiken. Deze externe code kan fouten in zich dragen. Uit beveiligingsoogpunt is het raadzaam om code uit externe bibliotheken te testen en na te gaan of deze code beveiligd moet worden met door de codeleverancier beschikbaar gestelde patches.
APO_C.03.01	Patchmanagement en noodzakelijke patchmanagement procedures zijn beschreven, vastgesteld en bekendgemaakt
APO_C.03.02	Ontwikkelaars zijn wat betreft patchmanagement bekend met hun formeel vastgelegde verantwoordelijkheden
APO_C.03.03	Het al dan niet uitvoeren van de verworven patches voor programmacode is geregistreerd
APO_C.03.04	Het beheer van technische kwetsbaarheden in code uit externe bibliotheken
APO_C.03.05	Installeren van alle noodzakelijke door de leveranciers beschikbaar patches en fixes
APO_C.03.06	Updates en patches voor kwetsbaarheden waarvan de kans op misbruik en ontstane schade hoog is
APO_C.04	(Software)configuratiebeheer	==Objectdefinitie== Betreft een instandhoudingsproces voor het vastleggen en actueel houden van gegevens van configuratie-items van een computerprogramma. Objecttoelichting Configuratiebeheer is het beheerproces dat onder andere verantwoordelijk is voor het registreren van de softwareconfiguratie-items (SCI’s) en hun specifieke kenmerken, zodat de SCI’s altijd uniek te identificeren zijn en de volledigheid en de juistheid van de in de Configuration Management Database (CMDB) opgenomen items gewaarborgd is. Configuratiemanagement geeft inzicht in de status van de verschillende SCI’s die binnen het ontwikkeltraject worden gebruikt en geeft de relaties weer tussen deze SCI’s. Hierdoor wordt duidelijk welke gevolgen aanpassingen van het ene SCI heeft voor andere SCI’s.
APO_C.04.01	Software configuratiescomponenten worden conform procedures vastgelegd
APO_C.04.02	De configuratie administratie is alleen toegankelijk voor hiertoe geautoriseerd personeel
APO_C.04.03	Wijzigingen in softwareconfiguratie conform gestandaardiseerd proces vastgelegd in de CMDB
APO_C.05	Quality assurance	==Objectdefinitie== Het vakgebied dat zich bezig houdt met het beheersen en verbeteren van processen. Objecttoelichting Om zekerheid te geven dat de juiste producten worden ontwikkeld en opgeleverd, is het van belang dat deze producten worden onderworpen aan een kwaliteitscontrole (quality assurance). Quality assurance betreft ook alle activiteiten gericht op de ontwikkeling van software en richt zich onder andere op het toetsen van deelproducten en van de aanwezige risico’s voor het verwerken van de juiste business requirements en beveiligingseisen in de applicaties. Ook wordt nagegaan in hoeverre in de functionele en technische ontwerpen de beleidseisen en eisen uit wet- en regelgeving zijn meegenomen. Het is daarom van belang dat op bepaalde vastgestelde momenten quality assurance op de ontwikkelde software-producten wordt uitgevoerd.
APO_C.05.01	Het compliance management proces is gedocumenteerd en vastgesteld
APO_C.05.02	De noodzakelijke eisen voor het compliance proces samengevat en vastgelegd
APO_C.05.03	Rapportage van de resultaten uit de QA-onderzoeken aan verbetermaatregelen initiërende verantwoordelijken
APO_C.05.04	Toetsingsafspraken en resultaten zijn beknopt en SMART vastgelegd
APO_C.06	Compliance-management	==Objectdefinitie== Betreft een besturingsproces voor het voldoen aan de geldende wet- en regelgeving, beleid overeenkomsten en andere verplichtingen in de organisatie voor softwareontwikkeling. Objecttoelichting Compliance-management richt zich op het naleven van de verplichtingen die voortkomen uit wet- en regelgeving en door de organisatie overeengekomen beleid, richtlijnen, standaarden en architectuur. Vanuit de optiek van de functionele en technische beveiligingseisen voor software is het van belang om met een compliance-managementproces vast te stellen in welke mate de gerealiseerde software voldoet aan de verplichtingen die voorvloeien uit wet- en regelgeving en uit vooraf overeengekomen beleid, architectuur, standaarden en contracten.
APO_C.06.01	De Quality Assurancemethodiek voor de ontwikkelde software producten wordt nageleefd
APO_C.06.02	Gedurende alle fasen van het ontwikkelcyclus worden Quality Assurance activiteiten uitgevoerd
APO_C.07	Technische beoordeling informatiesystemen	==Objectdefinitie== Omvat de evaluatie van de mate waarin de serveromgeving voldoet aan de vooraf gestelde technische eisen. Objecttoelichting Tijdens de ontwikkelfase tot kort na ingebruikname kunnen om bepaalde redenen veranderingen in het besturingssysteem plaatsvinden. In deze situaties dient de verantwoordelijke stakeholder de noodzakelijke tests uit te voeren om vast te stellen of de applicatie nog de beoogde functionaliteiten biedt en of de beveiliging van deze applicatie aan de daaraan gestelde eisen voldoet.
APO_C.07.01	Testen bij verandering van besturingssystemen
APO_C.08	Beheersorganisatie applicatieontwikkeling	==Objectdefinitie== Betreft een doelgerichte bundeling van kennis en vaardigheden tussen personen die verantwoordelijk zijn voor de beheersing van softwareontwikkeling. Objecttoelichting De projectmanager heeft een (beheers)organisatiestructuur ingericht, waarbij de verantwoordelijkheden voor de beheersprocessen met toereikende bevoegdheden zijn uitgedrukt en op het juiste niveau zijn gepositioneerd.
APO_C.08.01	De samenhang van de beheersprocessen wordt door middel van een processtructuur vastgelegd
APO_C.08.02	De belangrijkste functionarissen en hun onderlinge relaties zijn inzichtelijk
APO_C.08.03	De verantwoordelijkheden zijn aan een specifieke functionaris toegewezen en vastgelegd
APO_C.08.04	De taken, verantwoordelijkheden en bevoegdheden voor de evaluatie- en beheerwerkzaamheden zijn beschreven
CLD_C	Clouddiensten Control	==Objecten, controls en maatregelen== Afbeelding Overzicht objecten voor clouddiensten in het control-domein geeft de onderwerpen weer die specifiek voor het control-domein een rol spelen. Is een objectblok blauw gekleurd, dan komt de bijbehorende control voor in de Baseline Informatiebeveiliging Overheid (BIO). Betreft het een wit gemarkeerd objectblok, dan heeft de BIO geen control gedefinieerd, maar is dit object wel noodzakelijk voor deze BIO Thema-uitwerking. Overzicht objecten voor clouddiensten in het control-domein De objecten, voor clouddiensten, die specifiek binnen het control-domein een rol spelen, zijn in de overeenkomstige controls uitgewerkt (zie de tabel in Principes uit de BIO Thema Clouddiensten binnen dit aspect).
CLD_C.01	Servicemanagementbeleid en evaluatierichtlijn	==Objectdefinitie== Betreft het resultaat van besluitvorming voor het inrichten van beheerprocessen en het systematisch ontwikkelde aanbevelingen voor het evalueren en uitvoeren van controle-activiteiten voor clouddiensten. Objecttoelichting Het servicemanagementbeleid geeft richting aan de wijze waarop de beheerorganisatie voor clouddiensten moet zijn ingericht en de wijze waarop deze moet functioneren. Voor de ondersteuning van de specifieke beheerprocessen bestaan richtlijnen en procedures. De beheerorganisatiestructuur geeft de samenhang van de ingerichte processen weer. Clouddiensten bestaan uit verschillende componenten en verschillende koppelvlakken. Het is van groot belang dat clouddiensten, vanwege risicomanagement, periodiek geëvalueerd worden. De evaluatie-activiteiten dienen ondersteund te worden met evaluatierichtlijnen, procedures en instructies, ter voorkoming van het risico dat de resultaten van de controle-activiteiten niet voldoen aan de gestelde eisen.
CLD_C.01.01	Beschikken over richtlijnen voor inrichting van service-management-organisatie
CLD_C.01.02	Beschrijven en inrichten relevante beheerprocessen
CLD_C.01.03	Richtlijnen voor uitvoeren controle-activiteiten en evalueren van en rapporteren over prestaties
CLD_C.02	Risico-control	==Objectdefinitie== Betreft het beoordelen van continu onderzoek naar dreigingen en kwetsbaarheden en het beoordelen van de beheersing van onderkende risico’s. Objecttoelichting Risico-control is het monitoren en reviewen van activiteiten van de risico-assessment in relatie met risicomanagement. Het monitoren en reviewen van risico’s is noodzakelijk omdat risicofactoren: waarde van assets, impact, dreigingen, zwakheden en kans op voorkomen steeds veranderen. Risico-control kan ondersteund worden door extern verkregen informatie over dreigingen en zwakheden.
CLD_C.02.01	Verifiëren van criteria voor risicometing en vaststelling consistentie van criteria
CLD_C.02.02	Monitoren en evalueren risico’s voor behouden risicobeeld en tijdige vaststelling van veranderingen
CLD_C.02.03	Richten op diverse zaken met betrekking tot monitoren van risico
CLD_C.02.04	Uitvoeren monitoringsactiviteiten en mitigeren risico’s
CLD_C.02.05	Adresseren diverse elementen bij monitoring en reviewen
CLD_C.03	Compliance en assurance	==Objectdefinitie== Betreft de besturing op het voldoen aan de geldende wet- en regelgeving, beleid, richtlijnen en procedures en de onafhankelijke toetsing op de naleving hiervan. Objecttoelichting Met compliance wordt aangeduid dat de Cloud Service Provider (CSP) werkt conform de geldende wet- en regelgeving en het uitgestippeld cloud-beveiligingsbeleid. Aan de Cloud Service Consumer (CSC) wordt zekerheid geboden over het beoogde beveiligingsniveau van de aangeboden clouddienst. Hiervoor zal de CSP een compliance-functie moeten hebben ingericht die het management van de CSP bijstaat bij het in control houden van de CSP-organisatie om te werken volgens de geldende wet- en regelgeving en het overeengekomen beveiligingsbeleid. Assurance is zekerheid geven over de naleving van wet- en regelgeving door een onafhankelijke toetsing. Daarmee wordt aan de CSC zekerheid geboden van het beoogde beveiligingsniveau van de aangeboden clouddienst. Dit vindt plaats met een assurance-rapportage.
CLD_C.03.01	Inrichten compliance-proces voor governance van clouddienstverlening
CLD_C.03.02	Registreren reguliere rapportages in administratie
CLD_C.03.03	Aansluiten compliance-proces op ISMS
CLD_C.03.04	Uit laten voeren onderzoek op inrichting en beheersing van clouddiensten
CLD_C.03.05	Betrekken cloud-omgeving en administratie bij assessment
CLD_C.03.06	Aansluiten uitkomsten uit diverse rapportages e.d.
CLD_C.04	Technische kwetsbaarhedenbeheer clouddiensten	==Objectdefinitie== Betreft een instandhoudingsproces voor het onderzoek naar en het oplossen van technische kwetsbaarheden. Objecttoelichting Het verzamelen en beheren van security-kwetsbaarheden en issues in clouddiensten. Voor wat betreft de services van de Cloud Service Consumer (CSC), het transparant communiceren van kwetsbaarheden van de genomen (of nog te nemen) maatregelen voor IT en organisatie. De CSC wenst op een transparante wijze op de hoogte gesteld te worden van de kwetsbaarheden en issues gerelateerd aan de beveiliging van de clouddiensten. Door technische assessments uit te voeren op de ICT-componenten worden aanwezige kwetsbaarheden zichtbaar en kunnen deze worden weergegeven in een rapportage. Met deze rapportage kan de CSP de afweging maken welke kwetsbaarheden relevant zijn en verholpen moeten worden en welke risico’s ten aanzien van deze kwetsbaarheden geaccepteerd kunnen worden. De frequentie voor het uitvoeren van technische assessments moet zijn vastgesteld met het voor de clouddienst actuele risicoprofiel en actie moet worden ondernomen als geïmplementeerde maatregelen niet voldoen aan de gestelde eisen en/of verwachtingen of als tekortkomingen worden geconstateerd.
CLD_C.04.01	Beschikbaar stellen informatie over beheer van technische kwetsbaarheden
CLD_C.04.02	Definiëren en vaststellen rollen en verantwoordelijkheden
CLD_C.04.03	Installeren patches en treffen mitigerende maatregelen
CLD_C.04.04	Definiëren tijdspad waarbinnen gereageerd moet worden op aankondiging kwetsbaarheid
CLD_C.04.05	Uitvoeren penetratietests op ICT-componenten
CLD_C.04.06	Verhelpen technische zwakheden door patchmanagement
CLD_C.04.07	Registreren en rapporteren evaluaties van technische kwetsbaarheden
CLD_C.04.08	Communiceren verbeteringsvoorstellen uit evaluatierapportages en communiceren met de verantwoordelijken
CLD_C.05	Security-monitoringsrapportage	==Objectdefinitie== Omvat het continu bewaken van security-gebeurtenissen en de rapportage over de geconstateerde afwijking van het overeengekomen beveiligingsniveau. Objecttoelichting Onder security-monitoring wordt voor clouddiensten verstaan, het reviewen, analyseren, signaleren en tijdig rapporteren van zwakheden, onveilige interfaces en ongeautoriseerde toegangspogingen, om misbruik te voorkomen en om met de ernst van de signalering acties te ondernemen. De bewakingsfunctie is voorbehouden aan de daartoe verantwoordelijke functionaris(sen) en vindt mede plaats met geregistreerde gegevens (logging). De loggegevens behoren regelmatig te worden geanalyseerd en de resultaten van deze analyses moeten worden gerapporteerd (alerting). Ook moet de Cloud Service Provider (CSP) regelmatig rapporteren over of en de mate waarin afwijkingen zijn geconstateerd op het overeengekomen beveiligingsniveau.
CLD_C.05.01	Vaststellen en toepassen richtlijnen en afspraken voor monitoren en rapporteren
CLD_C.05.02	Monitoren en rapporteren over informatiebeveiliging is gerelateerd doelen, risico en beveiligingsincidenten
... meer resultaten

Het bekend maken van de identiteit van personen, organisaties of IT-voorzieningen.

Een beschrijving van een complex geheel, en van de principes die van toepassing zijn op de ontwikkeling van het geheel en zijn onderdelen.

Het informatiebeveiligingsbeleid verbindt de bedrijfsdoelstellingen met beveiligingsdoelstellingen. Met de beveiligingsdoelstellingen geeft een organisatie aan op welke wijze – door het treffen van beveiligingsmaatregelen – de bedrijfsdoelstellingen nagestreefd worden.

De mate waarin de organisatie zich voor de informatievoorziening kan verlaten op een informatiesysteem. De betrouwbaarheid van een informatiesysteem is daarmee de verzamelterm voor de begrippen beschikbaarheid, integriteit en vertrouwelijkheid.

De mate waarin de organisatie zich voor de informatievoorziening kan verlaten op een informatiesysteem. De betrouwbaarheid van een informatiesysteem is daarmee de verzamelterm voor de begrippen beschikbaarheid, integriteit en vertrouwelijkheid.

Een samenhangend geheel van gegevensverzamelingen en de daarbij behorende personen, procedures, processen en programmatuur alsmede de voor het informatiesysteem getroffen voorzieningen voor opslag, verwerking en communicatie.

Betekent dat alle procesgebonden informatie is vastgelegd en wordt beheerd die aanwezig zou moeten zijn conform het beheerregime dat voor dat proces is vastgesteld.