Eigenschap:Beschrijving
Naar navigatie springen
Naar zoeken springen
Type eigenschap
:
Tekst
Geldige waarden
:
Meerdere waarden toegestaan
:
Nee
Weergave op formulieren
:
Tekstvak
Initiële waarde
:
Verplicht veld
:
Nee
Toelichting op formulier
:
Deze elementeigenschap kan gebruikt worden om een element te voorzien van een beschrijving.
Subeigenschap van
:
Formatteerfunctie externe URI
:
Klik op de button om een nieuwe eigenschap te maken:
A
==Objectdefinitie==
Omvat de aanpak en de middelen om gebruikers fysieke en logische toegang te kunnen verlenen.
==Objecttoelichting==
Om autorisatiebeheer efficiënt en effectief te kunnen inrichten, zijn technische autorisatievoorzieningen, zoals een personeelsregistratiesysteem, een autorisatiebeheersysteem en autorisatiefaciliteiten noodzakelijk. +
B
Authentieke bron voor basisgegevens van adressen en gebouwen in Nederland. +
BAG Compact is een XML-bestand met alle BAG-adressen op basis van een vaste peildatum van heel Nederland. Behalve adressen bevat het bestand ook adresgerelateerde elementen uit de LV BAG.
[http://www.kadaster.nl/web/Themas/Registraties/BAG/BAG-product/BAG-Compact.htm BAG Compact] op website Kadaster. +
Abonnementenservice om realtime een bericht te ontvangen bij een wijziging in de LV BAG.
[http://www.kadaster.nl/web/Themas/Registraties/BAG/BAG-product/BAG-Digilevering.htm BAG Digilevering] op website Kadaster. +
Levering van een totaalstand van alle BAG-gegevens voor het gevraagde gebied (volledige levenscyclus of op peildatum). Mogelijk om te selecteren op gemeente, meerder gemeenten of geheel Nederland.
Een bestand van heel Nederland is permanent beschikbaar met een vertraging van maximaal één maand.
Bij een abonnement bestaan twee varianten: óf periodieke (maandelijks/dagelijks) levering van de wijzigingen ten opzichte van de voorgaande levering óf maandelijks een levering van de een totaalstand.
[http://www.kadaster.nl/web/Themas/Registraties/BAG/BAG-product/BAG-Extract.htm BAG Extract] op website Kadaster. +
Bij een abonnement bestaan twee varianten: óf periodieke (maandelijks/dagelijks) levering van de wijzigingen ten opzichte van de voorgaande levering óf maandelijks een levering van de totaalstand. +
Biedt BAG gegevens van een in de vraag gespecificeerde geografische contour, hetzij als ‘plaatje’ (WMS) hetzij als data, welke door de afnemer gevisualiseerd, opgeslagen en bewerkt kunnen worden. De WFS service is vooralsnog gemaximeerd op 15000 objecten.
*[https://www.pdok.nl/nl/service/wms-bag BAG WMS] op website PDOK.
*[https://www.pdok.nl/nl/service/wfs-bag BAG WFS] op website PDOK +
Webservice voor het geautomatiseerd bevragen van de LV-BAG met behulp van software van de afnemer.
BAG Bevragen kan de volledige levenscyclus van een object opvragen.
[http://www.kadaster.nl/web/Themas/Registraties/BAG/BAG-product/BAG-Bevragen.htm BAG bevragen] op website Kadaster. +
Website waar een BAG-kaart getoond wordt. Klikken op panden toont de onderliggende pand- en verblijfsobjectgegevens. Viewer toont actuele en historische gegevens.
[https://bagviewer.kadaster.nl/lvbag/bag-viewer/index.html BAG viewer op website Kadaster]. +
Authentieke bron voor geo-informatie in Nederland: een uniform topografisch basisbestand met objecten (dingen die in het terrein fysiek aanwezig zijn) in heel Nederland, op een schaal van 1:500 tot 1:5.000. +
De BGT vormt de kern (verplichtende deel) van het informatiemodel geografie (IMGeo). De verdiepingsslag van de BGT die in IMGeo is vastgelegd als het optionele deel, is bedoeld voor het opslaan en uitwisselen van beheer- en plustopografie. IMGeo zorgt ervoor dat wie de optionele informatie wil beheren en/of uitwisselen, dit volgens een landelijke standaard kan doen. IMGeo biedt ook voor 3D uitwisseling van grootschalige topografie een optionele standaard en baseert zich hiervoor op de internationale standaard CityGML. +
Gemeenschappelijk normenkader en verplichte maatregelen voor de beveiliging van de informatie(systemen) van de overheid. +
Objecten voor applicatieontwikkeling worden gerelateerd aan de ontwikkelfasen en geïdentificeerd met onderzoeksvragen en risicogebieden. De objecten zijn afgeleid vanuit de optiek van de kwaliteitscriteria: Beschikbaarheid, Integriteit, Vertrouwelijkheid en Controleerbaarheid (BIVC), die vervolgens zijn ingedeeld in het beleids-, uitvoerings- en control-domein.
De vragen die hierbij een rol spelen, zijn:
# Welke randvoorwaardelijke elementen spelen vanuit de optiek van BIVC een rol bij applicatieontwikkeling en wat is de consequentie bij afwezigheid hiervan?
# Welke elementen spelen vanuit de optiek van BIVC een rol bij applicatieontwikkeling en wat is de consequentie bij afwezigheid hiervan?
# Welke elementen spelen vanuit de optiek van BIVC een rol bij de beheersing van applicatieontwikkeling en wat is de consequentie bij afwezigheid hiervan?
==Organisatie van applicatieontwikkelingsobjecten==
Zoals in [[BIO Thema Applicatieontwikkeling/Inleiding#Ontwikkelcyclus van applicatieontwikkeling|Ontwikkelcyclus van applicatieontwikkeling]] is aangegeven, worden de geïdentificeerde applicatieontwikkelingsobjecten met het beleids-, uitvoerings- en control-domein georganiseerd. Hiermee worden deze aspecten in de juiste contextuele samenhang gepositioneerd. De betekenis die aan elk domein wordt toegekend, zijn:
*Beleid, Binnen dit domein bevinden zich conditionele elementen over de applicatieontwikkeling. Hier zijn eisen opgenomen over ‘geboden’ en ‘verboden’, zoals het applicatiebeveiligingsbeleid, de te hanteren wet- en regelgeving en andere vormen van reguleringen en beperkingen.
*Uitvoering, Binnen dit domein bevinden zich:
**elementen die gerelateerd zijn aan operationele activiteiten over het ontwikkelen van applicaties;
**elementen die aangeven hoe deze activiteiten georganiseerd moeten zijn;
**elementen die gerelateerd zijn aan beveiligingsaspecten die bij de activiteiten in acht moeten worden genomen.
*Control, Binnen dit domein bevinden zich elementen die zorgdragen voor de beheersing van het ontwikkelproces en/of het in standhouden van activiteiten die wel naar wens verlopen.
==Observatie bij objectidentificatie==
Er is gebleken dat bij het identificeren van objecten uit de [[BIO (Baseline Informatiebeveiliging Overheid)|BIO (Baseline Informatiebeveiliging Overheid)]] en de [[NEN-EN-ISO/IEC 27002:2017 (Praktijkrichtlijn met beheersmaatregelen op het gebied van informatiebeveiliging)|ISO 27002]] weinig controls te vinden zijn die direct gerelateerd zijn aan de ontwikkelfases: analyseren, specificeren, ontwerpen en ontwikkelen. Dit komt doordat binnen deze ISO-standaard niet is uitgegaan van de ontwikkelfasen van systeemontwikkeling en wellicht ook doordat de activiteiten binnen deze fasen gerelateerd zijn aan specifieke methoden en/of programmeertalen. In de ISO 27002 zijn wel beveiligingscontrols en bijbehorende maatregelen aangetroffen die indirect te maken hebben met de ontwikkelfasen.
==Objecten geprojecteerd op domein en gesorteerd naar invalshoek==
[[BIO Thema Applicatieontwikkeling/Geïdentificeerde objecten ingedeeld naar IFGS|De pagina Objecten ingedeeld naar invalshoeken]] geeft een overzicht van de applicatieontwikkelingsobjecten die in het [[ISOR:BIO Thema Applicatieontwikkeling Beleid|Beleidsdomein]], [[ISOR:BIO Thema Applicatieontwikkeling Uitvoering|Uitvoeringsdomein]] en [[ISOR:BIO Thema Applicatieontwikkeling Control|Control-domein]] zijn uitgewerkt. Vanuit een baseline-gebaseerde benadering is een lijst gemaakt van relevante objecten uit verschillende baselines. Los van de baselines zijn enkele objecten als relevant voor dit thema aangegeven. Ervan bewust zijnde dat deze zogenaamde baseline-gebaseerde benadering tot selectie van objecten leidt die niet allemaal in de huidig wereld van systeemontwikkelingsaanpak thuishoren. Er is gekozen om een baseline-benadering toe te passen om zo de overgang naar de Agile-benadering beter te kunnen maken.
Uit de inhoudelijke bestudering van de objecten vanuit de baseline-gebaseerde benadering komt naar voren dat er doublures in de objecten zijn. Met andere woorden het aantreffen van twee verschillende objecten die dezelfde inhoud kennen. Sommige objecten zijn vooralsnog bewust achterwege gelaten vanwege het geringe belang van deze objecten in relatie tot de totale scope.
Opgemerkt wordt dat er verschillende termen gehanteerd worden voor hetzelfde, zoals: informatiesysteem, applicatie, systeem en toepassing. Voor de consistentie is gekozen om de term ‘systeem’ in de betiteling van de betreffende controls (dus de objecten) aan te passen naar applicatieontwikkeling.
Het belang en de risico’s die de organisatie aan het bedrijfs- of beheerproces stelt, bepalen inherent de eisen die gesteld moeten worden aan de applicatie(s) die het betreffende proces ondersteunen. De risicobeoordeling van de functionaliteit, gevoeligheid van de gegevens, belang van de applicatie voor de organisatie bepalen of en welke normen van toepassing zijn.
==Context applicatieontwikkeling==
Alle [[BIO Thema Applicatieontwikkeling|pagina's van applicatieontwikkeling]] bevatten de uitwerking van de BIO Thema-uitwerking Applicatieontwikkeling. Een applicatie kan worden verworven door interne ontwikkeling, uitbesteding of inkoop van een commercieel product. Dit kan ook door een combinatie van interne ontwikkeling en uitbesteding (zie onderstaande afbeelding). Hierbij kan het voortraject (het specificeren) door de klant zelf worden verricht, terwijl het technische deel (het ontwikkelen) door de externe partij wordt uitgevoerd. Hierbij zullen extra afspraken over de beveiligingsaspecten gemaakt moeten worden.
[[Afbeelding:Thema Applicatieontwikkeling - Overzicht van type applicaties.png|thumb|none|500px|Overzicht typen applicaties|alt=”Overzicht van typen applicaties”]]
Gedurende de ontwikkelcyclus van de applicatie moet voldaan worden aan functionele en beveiligingseisen. Ook moeten bij de ontwikkeling het informatiebeveiligingsbeleid, wet- en regelgeving (onder andere de [[BIO (Baseline Informatiebeveiliging Overheid)|Baseline Informatiebeveiliging Overheid (BIO)]] en de [[AVG (Algemene Verordening Gegevensbescherming)|Algemene Verordening Gegevensbescherming (AVG))]] en eisen van de technische omgeving worden betrokken.
In deze BIO Thema-uitwerking zullen de beveiligingseisen voor applicatieontwikkeling worden samengesteld. Het uitgangspunt hierbij is de noodzakelijke beveiligingseisen, in de vorm van controls en onderliggende maatregelen uit de BIO en [[NEN-EN-ISO/IEC 27002:2017 (Praktijkrichtlijn met beheersmaatregelen op het gebied van informatiebeveiliging)|NEN-EN-ISO/IEC 27002:2017 (in deze thema-uitwerking genoemd ISO 27002)]], in een samenhangende context te plaatsen en waar nodig deze aan te vullen met controls uit andere ISO-standaarden, [[NIST (National Institute of Standards and Technology)|National Institute of Standards and Technology (NIST)]] en de [[The Standard of Good Practice for Information Security 2018|The Standard of Good Practice (SoGP) 2018]] e.d.
Eerst wordt een algemene ontwikkelcyclus beschreven om een beter beeld te krijgen over de te hanteren fases voordat de controls die gerelateerd zijn aan objecten worden geïdentificeerd. Deze exercitie is ook zinvol om geïdentificeerde objecten uit de BIO en overige best practices beter contextueel in samenhang te plaatsen. De beschrijving van de fases vindt plaats in [[BIO Thema Applicatieontwikkeling/Inleiding#Ontwikkelcyclus van applicatieontwikkeling|Ontwikkelcyclus van applicatieontwikkeling]].
==Doel applicatieontwikkeling==
Deze BIO Thema-uitwerking is opgesteld voor de interne en externe leverancier als instrument gericht op de implementatie van applicaties in de technische omgeving van de leverancier of van de klant zelf.
De thema-uitwerking geeft hiermee inzicht in de kwaliteitszorg die de leverancier dient toe te passen en wat de klant kan verwachten bij het opleveren van nieuwe software. Het geeft tegelijkertijd de verplichte activiteiten weer van de klant. Hiernaast kan het als instrument dienen voor het geven van inzicht in het beveiligings- en beheersingsniveau van de ontwikkel- en onderhoudsorganisatie van de leverancier.
==Scope en begrenzing applicatieontwikkeling==
In deze BIO Thema-uitwerking wordt voornamelijk gericht op conditionele beveiligings- en beheersingsaspecten die gerelateerd zijn aan het ontwikkelen van applicaties. Geen aandacht wordt besteed aan:
* de activiteiten die gerelateerd zijn aan onderhoud van applicaties, webapplicaties en Enterprise Resource Planning (ERP)-pakketten (zie onderstaande afbeelding);
* de typen gebruikers en bedrijfseisen omdat deze eisen organisatieafhankelijk zijn;
* de toegangsbeveiligingsaspecten omdat deze aspecten in het thema ‘Toegangsbeveiliging’ geadresseerd zijn.
De begrenzing van deze BIO Thema-uitwerking is in onderstaande afbeelding weergegeven.
[[Bestand:APO Relatie BIO Thema-uitwerking Applicatieontwikkeling met aanpalende documenten.png|thumb|none|500px|Relatie BIO Thema-uitwerking Applicatieontwikkeling met aanpalende documenten|alt=”Overzicht van type applicaties”]]
==Ontwikkelcyclus applicatieontwikkeling==
Een applicatie (software) wordt ontwikkeld om een (bedrijfs)proces effectief te ondersteunen. Hiervoor dient eerst een contextanalyse te worden gemaakt om de juiste functionele vereisten te identificeren. De applicatie moet voldoen aan de behoeften van gebruikers en stakeholders in de vorm van wet- en regelgeving, eisen en requirements, of te wel een programma van eisen (PvE). Het PvE wordt ontwikkeld in samenwerking met informatieanalisten, softwareontwikkelaars en -gebruikers.
De kwaliteit (succes) van een applicatie wordt onder andere bepaald door:
* hoe goed het PvE de gebruikerseisen en -wensen weerspiegelt;
* hoe goed de gebruikerseisen en -wensen de reële situatie (daadwerkelijke noodzakelijkheden) weerspiegelt;
* hoe goed de applicatie het vastgestelde PvE weerspiegelt.
Slechte kwaliteit van het PvE wordt onder andere veroorzaakt door onjuistheden, verkeerde aannames, inconsistenties, taalgebruik en ontoereikendheid. Bij applicatieontwikkeling is een goede inrichting van projectmanagement en de te hanteren systeem-ontwikkelmethode (System Development Life Cycle) essentieel.
Het applicatieontwikkelingsproces wordt verdeeld in activiteiten die niet noodzakelijk als sequentiële stappen doorlopen worden<sup class="reference smartref" id="cite_ref-Applicatieontwikkelingsstappen_1-0">[[BIO Thema Applicatieontwikkeling/Inleiding#cite_note-Applicatieontwikkelingsstappen-1|1]]</sup> (zie ook [[BIO Thema Applicatieontwikkeling/Inleiding#Ontwikkelmethoden|Ontwikkelmethoden]]). De onderkende activiteiten zijn: analyseren, specificeren, ontwerpen, ontwikkelen, valideren, gebruiken en beheren. Onderstaande afbeelding geeft een schematische weergave van een ontwikkelproces in de vorm van het V-model. De activiteiten uit dit model worden in de volgende paragrafen toegelicht. Ze verschaffen mogelijkheden om de geïdentificeerde operationele objecten uit de BIO en overige best practices te rubriceren.
[[Afbeelding:Thema Applicatieontwikkeling - De ontwikkelactiviteiten van software en indeling van essentiële elementen in drie domeinen.png|thumb|none|500px|Software-ontwikkelactiviteiten en indeling essentiële elementen in domeinen|alt=”De ontwikkelactiviteiten van software en indeling van essentiële elementen in drie domeinen”]]
Hiernaast spelen ook essentiële randvoorwaardelijke en beheersingselementen een rol bij ontwikkel- en onderhoudsactiviteiten. De randvoorwaardelijke, operationele en beheersingselementen voor applicatieontwikkeling zijn daarom ingedeeld in het beleids-, uitvoerings- en control-domein. Ook deze indeling wordt in bovenstaande afbeelding weergegeven.
===Perspectieven===
De linkerkant van het bovenstaande V-model beschrijft het ontwikkelperspectief en de rechterkant het gebruikersperspectief. Als applicatieontwikkeling plaatsvindt bij een externe organisatie of een aparte businessunit zijn deze op perspectieven gescheiden. Afhankelijk van de afspraken tussen de klant en leverancier wordt bij uitbesteding de rechterkant aangeduid als het leveranciersperspectief en de linkerkant als het klantperspectief. Hierover maken de klant en leverancier heldere afspraken. De afspraken zijn gericht op:
* het uitwisselen van kennis, specifiek over de overdracht van proceskennis van de (gebruiks)organisatie naar de ontwikkelorganisatie;
* het tijdens het ontwikkelproces niet verstoren van het primaire proces;
* het toezien op de bescherming van intellectuele eigendommen en van gevoelige informatie.
De verantwoordelijken binnen het ontwikkelproces moeten verantwoording kunnen afleggen over de kwaliteit van het geleverde product. Om een goede beheersing te waarborgen, is het vanuit best practices noodzakelijk de verschillende fases van de levenscyclus te isoleren in een eigen omgeving zodat gegarandeerd kan worden dat het primaire proces niet wordt verstoord. Daarbij vindt een expliciete afsluiting van een fase plaats zodat een gecontroleerde overgang mogelijk wordt. Dit concept wordt een OTAP-straat genoemd. OTAP staat voor Ontwikkel, Test, Acceptatie en Productie.
===Analyseren===
In deze fase wordt de context van het bedrijfsproces, dat door de te ontwikkelen applicatie ondersteund moet worden, geanalyseerd. Hierbij worden de noodzakelijke requirements, waaronder de bedrijfsfuncties, gegevens en veranderwensen vanuit de bedrijfsprocessen geïdentificeerd en vastgelegd. De focus ligt op de ‘waarom’-aspecten. Onder andere de volgende activiteiten worden uitgevoerd:
* onderzoeken en brainstormen over de te ontwikkelen software om duidelijkheid te krijgen wat het doel is van de software;
* analyseren van eisen en wensen van gebruikers, beheerders en partners over functionele en niet-functionele aspecten.
===Specificeren===
Deze activiteit richt zich op de ‘wat’-aspecten. De business-, gebruikers-, stakeholders- (non)functionele en data-requirements worden gespecificeerd. Ook worden de noodzakelijke business rules en de noodzakelijke beperkingen in de vorm van constraints vastgelegd in een functioneel ontwerp.
===Ontwerpen===
Bij deze activiteit vindt de tijdens in de eerdere fase gedetailleerde en vastgestelde uitwerking van informatie en modellen plaats. Deze fase richt zich op de relaties en afhankelijkheden tussen de te bouwen componenten. Hierbij worden de bedrijfs- en procesvereisten gemodelleerd in een ontwerp (architectuur) voor het te bouwen informatie(deel)systeem. Aandacht dient besteed te worden aan de kwaliteitseisen gerelateerd aan gebruikers, functionaliteit en beveiliging.
===Ontwikkelen (implementeren)===
In deze fase worden de softwarecomponenten geconstrueerd (gecodeerd). De relaties en afhankelijkheden van de te automatiseren processen en modules worden vastgelegd in een software-architectuur. Uiteindelijk zullen de programma’s geschreven worden met deze (applicatie-/software-)architectuur. Hierbij moet ook rekening worden gehouden met enkele ontwikkeleisen, zoals:
* Reproduceerbaarheid van code
* Effectieve testbaarheid
* Toepassing van externe programmabibliotheek
* Toepassing van tools en gebruik van licenties
* Toepassing van gestandaardiseerde vocabulaire (zie de [[NEN-ISO/IEC 25010:2011 (Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models)|NEN-ISO/IEC 25010 Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models)]]
* Inzicht in relaties en afhankelijkheden tussen software-objecten
* Software-features (eisen: interfaces, koppelingen en Application Programming Interfaces (API’s))
* Richten op aantoonbaar veilig programmeren
===Valideren===
In deze fase worden de ontwikkelde modules/programma’s getest en uiteindelijk geaccepteerd. Gecontroleerd wordt of de software volgens de ontwerprichtlijnen is gebouwd. Ook kunnen fouten, gemaakt in eerdere stadia, boven water komen. Er wordt aandacht besteed aan eisen, zoals:
* De applicatie biedt slechts die functionaliteit die in de specificaties/het ontwerp zijn opgenomen (anders gezegd, geen functionaliteit buiten de specificaties/het ontwerp).
* Er is conformiteit aan de gespecificeerde functionaliteit (gebruikers)/het ontwerp (security by design) en de AVG).
===Gebruiken===
Als de software voltooid en getest is, zal het in gebruik worden genomen volgens een standaardprocedure van de OTAP-straat.
===Onderhouden en beheren===
Tenslotte wordt de software periodiek onderhouden en (weer) in beheer genomen. Nieuwe functionele eisen zijn uitgewerkt en/of voorkomende fouten worden hersteld.
==Ontwikkelmethoden==
Er zijn verschillende modellen voor het ontwikkelen van applicaties, zoals de:
* Lineaire methode, Het meest bekende voorbeeld is de Watervalmethode (zie [[BIO Thema Applicatieontwikkeling/Inleiding#Ontwikkelcyclus van applicatieontwikkeling|Ontwikkelcyclus van applicatieontwikkeling]]). In deze ontwikkelmethode wordt het eindproduct (software-product) in een aantal fases opgeleverd. In elke fase wordt een concreet gedefinieerd deelproduct uitgevoerd. De requirements zijn duidelijk en vooraf vastgelegd. Kennisoverdracht en monitoring vinden plaats met specifieke documenten en formats.
* Iteratieve methode, De iteratieve ontwikkeling is een methode waarbij het eindproduct niet in één keer wordt opgeleverd, maar gefaseerd tot stand komt, waarbij fases herhaaldelijk worden doorlopen. Na elke zogenaamde iteratie wordt het proces geëvalueerd en zo nodig aangepast. In de praktijk worden de iteratieve en lineaire ontwikkelmethode met elkaar gecombineerd.
* Agile-methode, De Agile-methode wordt gekenmerkt door korte, in tijd gelimiteerde sprints. De inhoud van een sprint wordt bij de start ervan bepaald. De gevolgde werkwijze kan (dagelijks) worden aangepast al naar gelang de wensen van de zelfsturende teams. Er wordt gebruik gemaakt van een geordende lijst van productfeatures die gedurende het gehele project wordt bijgewerkt op basis van de behoefte van de klant. Daarmee worden in feite de productspecificaties opgebouwd. De nadruk ligt op samenwerking en mondelinge kennisoverdracht. De prioriteit ligt bij het opleveren van sprints en producten met de op dat moment hoogste toegevoegde waarde. De sprints worden gedaan door zelfsturende teams met multidisciplinaire teamleden en zonder vastgelegde taken, rollen en verantwoordelijkheden. Onderstaande afbeelding geeft een schematische weergave van een iteratie/Agile-ontwikkelproces met het V-model.
[[Afbeelding:Thema Applicatieontwikkeling - Schematische weergave van een iteratie agile ontwikkelproces in de vorm van het V-Model.png|none|thumb|500px|Schematische weergave iteratie/Agile-ontwikkelproces met het V-model|alt=”Schematische weergave van een iteratie/Agile ontwikkelproces in de vorm van het V-model”]]
==Applicatieobjecten in relatie tot ontwikkelmethode==
Bij de selectie van applicatieobjecten uit de BIO en overige best practices is in eerste instantie uitgegaan van de lineaire/iteratieve aanpak van applicatieontwikkeling. Na de totstandkoming van dit thema kan met de definitieve versie een versie worden gemaakt die gerelateerd is aan applicatieonderhoud en een versie die gerelateerd is aan de Agile-methode. Dit zullen aparte documenten zijn die overeenkomsten zullen hebben met dit document, maar vanuit de optiek van onderhoud of Agile-aanpak kunnen objecten aangepast en/of toegevoegd worden.
In de onderstaande afbeelding zijn de invalshoeken: intentie, functie, gedrag en structuur gekoppeld aan het V-model.
[[Afbeelding:Thema Applicatieontwikkeling - IFGS gekoppeld aan het V-model.png|thumb|600px|none|Invalshoeken gekoppeld aan het V-model|alt=”IFGS gekoppeld aan het V-model”]]
: → [[ISOR:BIO Thema Applicatieontwikkeling Uitvoering|Ga terug naar Applicatieontwikkeling Uitvoering]] +
Onderstaande afbeelding geeft een overzicht van ingedeelde objecten naar de invalshoeken.
[[Afbeelding:Thema Applicatieontwikkeling - Geïdentificeerde objecten ingedeeld naar IFGS.png|thumb|650px|none|Applicatieontwikkelingsobjecten ingedeeld naar invalshoeken|alt=”Geïdentificeerde objecten ingedeeld naar IFGS”]]
: → [[BIO Thema Applicatieontwikkeling/Identificatie applicatieontwikkeling objecten|Ga terug naar Beveiligingsobjecten applicatieontwikkeling]] +
De Beslisboom in afbeelding 'Beslisboom voor risicobeoordeling' ondersteunt stakeholders voor cloud-services bij het nemen van verantwoorde beslissingen voor het onderbrengen van gegevens en/of bedrijfsprocessen in de publieke cloud, private cloud, als uitbestede IT of in het eigen rekencentrum ‘on premise’. De beslisboom is uitgewerkt in relatie tot de risicoafweging.
[[Afbeelding:BIO Thema Clouddiensten - Procesflow voor de risicoanalyse.png|thumb|none|500px|Beslisboom voor risicobeoordeling|alt=”Beslisboom voor risicobeoordeling”]]
Belangrijk daarbij is om de context van de overheid in de overweging mee te nemen. Overheden worden geacht om verantwoord om te gaan met gevoelige gegevens van burgers en bedrijven, maar ook met gegevens van eigen medewerkers. Zie voor de vraag die in stap 1 gesteld wordt over gegevens [[BIO Thema Clouddiensten/Standpunt AIVD en beleidsverkenning BZK]].
De beslisboom wordt gebruikt als zelf-assessment en toetst achtereenvolgens op:
# Afhankelijkheid en kwetsbaarheid, Gaat het om een primair bedrijfsproces met gevoelige gegevens van burgers en/of bedrijven, waarbij (bijzondere) persoonsgegevens vanwege de [[AVG (Algemene Verordening Gegevensbescherming)|Algemene Verordening Gegevensbescherming (AVG)]] extra zwaar wegen, zeker als het de persoonlijke veiligheid/privacy van eigen medewerkers betreft?
# Te Beschermen Belangen, Gaat het om zogenaamde cruciale belangen die van primair belang zijn voor het voortbestaan van de organisatie, waarbij het vertrouwen van de burger en het bedrijf in de betrouwbare overheid op het spel komt te staan indien die bescherming onvoldoende geborgd is?
# Betrouwbaarheid van producten en diensten, De betrouwbaarheid van de levering van producten en diensten is essentieel voor de organisatie. De Cloud Service Provider (CSP) vervuld daarin als belangrijkste actor een cruciale rol. Daarom is een passende dienstverlening nodig, waarbij het karakter van de te verwerken gegevens/processen daarvoor geschikt moet zijn.
Afhankelijk van de situationele context, zal het tevens gaan om bedrijfsgegevens die vallen in één van de hieronder geschetste domeinen uit afbeelding 'Schematische weergave soorten gegevens' en die de daarbij behorende passende maatregelen vergen.
[[Afbeelding:BIO Thema Clouddiensten - Situationele context van gegevens.png|thumb|none|500px|Schematische weergave soorten gegevens|alt=”Situationele context van gegevens”]]
'''Afhankelijkheid en kwetsbaarheid'''
Vraag 1: Gaat het om persoonsgegevens en/of (zeer) vertrouwelijke bedrijfsgegevens?
NB Onder persoonsgegevens verstaat de AVG alle informatie over een geïdentificeerde of identificeerbare natuurlijke persoon (‘de betrokkene’), die direct of indirect kan worden geïdentificeerd. Bijvoorbeeld aan de hand van naam, identificatienummer (BSN), locatiegegevens of via elementen die kenmerkend zijn voor de fysieke, fysiologische, genetische, psychische, economische, culturele of sociale identiteit van die natuurlijke persoon.
* Direct identificeerbaar: Gegevens die naar hun aard rechtstreeks betrekking hebben op een persoon, zoals iemands naam.
* Indirect identificeerbaar: Gegevens die naar hun aard mede bepalend zijn voor de wijze waarop de betrokken persoon in het maatschappelijk verkeer wordt beoordeeld of behandeld.
Voorbeelden van indirect zijn het type huis of auto van een betrokkene, omdat dit iets zegt over het inkomen en vermogen van de betrokkene. Ook gegevens die in combinatie met andere gegevens tot identificeerbaarheid kunnen leiden worden aangemerkt als persoonsgegeven.
NB Vertrouwelijke bedrijfsgegevens, zoals bijvoorbeeld (nog vertrouwelijke) financiële, technische of juridische informatie, budgetten, beleidsvoornemens, aanbestedingen, beursgevoelige informatie; kortom alle informatie die (nog) niet voor derden is bestemd.
Zo ja, dan is een meer gedetailleerde risicoanalyse noodzakelijk (pre-DPIA, DPIA en/of risicobeoordeling).
NB Die gedetailleerde risicoanalyse zal in het geval van:
* Privacy gevoelige gegevens bestaan uit een zogenaamde pre-DPIA (risico inschatting op basis van 9 vragen), afhankelijk van de uitkomst gevolgd door een formele DPIA.
* vertrouwelijke informatie zal classificatie plaatsvinden door de Betrouwbaarheidseisen te toetsen (= gewenste niveau van beschikbaarheid, integriteit en vertrouwelijkheid).
Zo nee, ga naar vraag 2.
'''Te beschermen belangen'''
Vraag 2: Gaat het om één van de volgende typen processen (is het karakter van de processen)?
2a) Gaat het om de verwerking van gegevens en/of geldstromen in een of meerdere processen van onze organisatie die niet in de handen mogen vallen van de criminaliteit, omdat dat het vertrouwen dat burger en bedrijf stellen in ons als betrouwbare overheid ernstig zou kunnen schaden?
2b) Gaat het om een primair proces of processen van onze organisatie, waarbij geldt dat wanneer deze processen op enig moment worden belemmerd of gestopt, in dit voorbeeld de schade voor onze organisatie groot zal zijn (zowel in financiële zin als ook in termen van imago-schade)?
Zo nee, ga dan naar vraag 3.
Zo ja, dan is een meer gedetailleerde risicoanalyse noodzakelijk (betrouwbaarheidseisen toetsen, en zo nodig meer en/of zwaardere beveiligingsmaatregelen overeenkomen, inclusief risicobeoordeling).
'''Betrouwbaarheid van producten en diensten'''
Vraag 3: Biedt de leverancier een acceptabel niveau van dienstverlening?
3a) Is de leverancier van de toepassing/applicatie [[NEN-ISO/IEC 27001]] gecertificeerd?
3b) Indien er sprake is van opslag van data bij een extern datacenter is dat datacenter ISO 27001 gecertificeerd of anderszins gecertificeerd (ISAE3402 of SOC2)?
3c) Waar worden eventuele (bron)gegevens van de provincie opgeslagen die gebruikt worden bij het werken met de toepassing/applicatie in verband met ongewenste opslag buiten Europa?
3d) Is de leverancier bereid tot een externe (onafhankelijke) audit op compliance met wet- en regelgeving?
Als één van deze 4 sub-vragen uit vraag 3 negatief wordt beantwoord, dan geldt dat er een alternatieve oplossing gezocht moet worden voor public clouddiensten, zoals een private cloud-omgeving, nu of in de toekomst geleverd vanuit de overheid, zoals Rijkscloud, of IT-outsourcing, of on-premise in een eigen rekencentrum.
: → [[BIO Thema Clouddiensten/Inleiding#Context van de relatie tussen de CSC en de CSP|Ga terug naar Context van de relatie tussen de CSC en de CSP]]
Onderstaande lijst met brondocumenten verwijst naar voor clouddiensten relevante documenten. Hiervoor geldt:
* Een deel van de documenten kan via Rijksweb, interne overheidswebsites en/of publieke zoekmachines gevonden worden.
* Op NEN-ISO/IEC documenten rusten licentierechten. Voor de overheid zijn die afgekocht. Log hiervoor in via [https://connect.nen.nl/account/logon/ NEN-connect].
* De [[ISF (Information Security Forum)|ISF]]-documenten, zoals onder andere de [[The Standard of Good Practice for Information Security 2018|SoGP]] zijn beschikbaar voor leden van het Information Security Forum (ISF). De gebruikersorganisatie moet lid zijn van het ISF.
* De [[BSI (Bundesamt für Sicherheit in der Informationstechnik)|Duitse BSI]] IT-Grundschutz-, State of the art in IT security-, NORA-, [[NIST (National Institute of Standards and Technology)|NIST]]- en [[CSA (Cloud Security Alliance)|CSA]]-documenten zijn vrij beschikbaar via internet.
==Nationale kaders en practices==
<table class="wikitable">
<tr>
<th>Eigenaar</th>
<th>Documentnaam</th>
<th>Referentie</th>
<th>Versie</th>
</tr>
<tr>
<td>Algemene Inlichtingen en Veiligheids Dienst</td>
<td>Publieke clouddiensten en gerubriceerde gegevens</td>
<td>9 sep 2019</td>
<td>-</td>
</tr>
<tr>
<td>Ministerie van BzK</td>
<td>Verkenning Cloudbeleid voor de Nederlandse Rijksdienst<br>=Concept voor brede discussie=</td>
<td>16 sep 2019</td>
<td>-</td>
</tr>
<tr>
<td>Informatie Beveiligings Dienst (IBD)</td>
<td>Handreiking Cloudcomputing in Privacy</td>
<td>IBD 2019</td>
<td>2.0</td>
</tr>
<tr>
<td>Informatie Beveiligings Dienst (IBD)</td>
<td>Handreiking Impact Cloudcomputing</td>
<td>IBD 2019</td>
<td>2.0</td>
</tr>
<tr>
<td>Informatie Beveiligings Dienst (IBD)</td>
<td>Handreiking Inkoop Clouddiensten</td>
<td>IBD 2019</td>
<td>2.0</td>
</tr>
<caption align="bottom">Overzicht Nationale kaders en practices</caption></table>
==Nationale standaarden==
<table class="wikitable">
<tr>
<th>Eigenaar</th>
<th>Documentnaam</th>
<th>Referentie</th>
<th>Versie</th>
</tr>
<tr>
<td>NCSC<br>Nationaal Cyber Security Centrum (Ministerie van Justitie en Veiligheid) [https://www.ncsc.nl/ www.ncsc.nl]</td>
<td>Meerdere documenten, zoals de NCSC Webrichtlijnen [https://www.ncsc.nl/documenten/ www.ncsc.nl/documenten]</td>
<td>NCSC</td>
<td></td>
</tr>
<tr>
<td>NEN Normalisatie En Normen [https://www.nen.nl/ www.nen.nl]</td>
<td>NEN-EN-ISO/IEC 27040:2016 en Information technology - Security techniques - Storage security [https://www.nen.nl/NEN-Shop-2/Standard/NENENISOIEC-270402016-en.htm/ www.nen.nl/NEN-Shop-2/Standard/NENENISOIEC-270402016-en.htm]</td>
<td>ISO27040</td>
<td>2016</td>
</tr>
<tr>
<td>ICTU [http://www.ictu.nl/ www.ictu.nl]</td>
<td>NORA Nederlandse Overheids Referentie Architectuur [[NORA online]] NORA beveiligingspatronen [[Beveiliging/index| Beveiligingspatronen]]</td>
<td>NORA</td>
<td> </td>
</tr>
<tr>
<td>W.N.B. Tewarie, M.M.V.E. Ter Meer, E.R. Nieuwland</td>
<td>SIVA, SIVA - Methodiek voor de ontwikkeling van Auditreferentiekaders, VU University Press, ISBN978 90 8659 670 6</td>
<td></td>
<td>2014</td>
</tr>
<tr>
<caption align="bottom">Overzicht nationale standaarden</caption></table>
==Internationale standaarden==
<table class="wikitable">
<tr>
<th>Eigenaar</th>
<th>Documentnaam</th>
<th>Referentie</th>
<th>Versie</th>
</tr>
<tr>
<td rowspan="2">BSI<br>Bundesamt für Sicherheit in der Informationstechnik [https://www.bsi.bund.de/DE/Home/home_node.html/ www.bsi.bund.de/DE/Home/home_node.html]</td>
<td>Cloud ComputingCompliance Controls Catalogue (C5)<br>Criteria to assess the information security of cloud services<br> [https://www.bsi.bund.de/C5/ www.bsi.bund.de/C5]</td>
<td>BSI C5</td>
<td>Feb. 2016</td>
</tr>
<tr>
<td>IT-Grundschutz<br>BSI Standard 200-1 Information Security management System (ISMS)<br>BSI Standard 200-2 IT Grundschutz Methodology<br>BSI-Standard 200-3 Risk Analysis based on IT-Grundschutz<br>BSI Standard 200-4 Business Continuity Management (BCM)<br>[http://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/itgrundschutzkataloge_node.html/ www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/itgrundschutzkataloge_node.html]</td>
<td>BSI ITG</td>
<td>2013</td>
</tr>
<tr>
<td>CSA<br>Cloud Security Alliance<br> [https://cloudsecurityalliance.org/ https://cloudsecurityalliance.org]</td>
<td>Cloud Controls Matrix (CCM)<br>NB: laatste versie is 3.0.1</td>
<td>CSA CCM</td>
<td>1.01<br>Okt. 2010</td>
</tr>
<tr>
<td>ISA<br>International Society of Automation<br> [https://www.isa.org/ www.isa.org]</td>
<td>ISA-62443-2-1-2009<br>Security for Industrial Automation and Control Systems: Establishing anIndustrial Automation and Control Systems Security Program<br> [https://www.isa.org/templates/one-column.aspx?pageid=111294&productId=116731/ www.isa.org/templates/one-column.aspx?pageid=111294&productId=116731]</td>
<td>ISA-62443-2-1</td>
<td>2009</td>
</tr>
<tr>
<td rowspan="11">ISO<br>International Organization for Standardization<br> [http://www.iso.org/home.html/ www.iso.org/home.html]</td>
<td>ISO/IEC 17788:2014<br>Information technology - Cloud computing - Overview and vocabulary<br> [https://www.iso.org/standard/60544.html/ www.iso.org/standard/60544.html]</td>
<td>ISO17788</td>
<td>2014</td>
</tr>
<tr>
<td>ISO/IEC 17789:2014<br>Information technology - Cloud computing - Reference architecture<br> [https://www.iso.org/standard/60545.html/ www.iso.org/standard/60545.html]</td>
<td>ISO17789</td>
<td>2014</td>
</tr>
<tr>
<td>ISO/IEC 17826:2016<br>Information technology - Cloud Data Management Interface (CDMI)<br> [https://www.iso.org/standard/70226.htm/ www.iso.org/standard/70226.html]</td>
<td>ISO17826</td>
<td>2016</td>
</tr>
<tr>
<td>ISO/IEC 18033-1:2015<br>Information technology - Security techniques - Encryption algorithms - Part 1: General<br>[https://www.iso.org/standard/54530.html/ www.iso.org/standard/54530.html]</td>
<td>ISO18033-1</td>
<td>2015</td>
</tr>
<tr>
<td>ISO/IEC 18033-2:2006<br>Information technology - Security techniques - Encryption algorithms - Part 2: Asymmetric ciphers<br> [https://www.iso.org/standard/37971.html/ www.iso.org/standard/37971.html]</td>
<td>ISO18033-2</td>
<td>2006</td>
</tr>
<tr>
<td>ISO/IEC 19941:2017<br>Information technology - Cloud computing - Interoperability and portability<br> [https://www.iso.org/standard/66639.html/ www.iso.org/standard/66639.html]</td>
<td>ISO19941</td>
<td>2017</td>
</tr>
<tr>
<td>ISO/IEC 27003:2017<br>Information technology - Security techniques - Information securitymanagement systems – Guidance<br>[https://www.iso.org/standard/63417.html/ www.iso.org/standard/63417.html]</td>
<td>ISO27003</td>
<td>2017</td>
</tr>
<tr>
<td>ISO/IEC 27005:2018<br>Information technology - Security techniques - Information security riskmanagement<br> [https://www.iso.org/standard/75281.html/ www.iso.org/standard/75281.html]</td>
<td>ISO27005</td>
<td>2011</td>
</tr>
<tr>
<td>ISO/IEC 27017:2015<br>Information technology - Security techniques - Code of practice forinformation security controls based on ISO/IEC 27002 for cloud services<br> [https://www.iso.org/standard/43757.html/ www.iso.org/standard/43757.html]</td>
<td>ISO27017</td>
<td>2015</td>
</tr>
<tr>
<td>ISO/IEC 27018:2019<br>Information technology — Security techniques - Code of practice forprotection of personally identifiable information (PII) in public cloud sacting as PII processors<br> [https://www.iso.org/standard/76559.html/ www.iso.org/standard/76559.html]</td>
<td>ISO27018</td>
<td>2019</td>
</tr>
<tr>
<td>ISO/IEC27036-1:2014<br>Information technology - Security techniques - Information security forsupplier relationships - Part 1: Overview and concepts<br> [https://www.iso.org/standard/59648.html/ www.iso.org/standard/59648.html]</td>
<td>ISO27036-1</td>
<td>2014</td>
</tr>
<tr>
<td>ISF<br>Information Security Forum<br> [http://www.securityforum.org/ www.securityforum.org]</td>
<td>Standard of GoodPractice<br>Standard of Good Practice for Information Security 2018<br> [https://www.securityforum.org/uploads/2016/07/SoGP-2016-Exec-Summary-FINAL-260716.pdf/ www.securityforum.org/uploads/2016/07/SoGP-2016-Exec-Summary-FINAL-260716.pdf]</td>
<td>SoGP</td>
<td>2017</td>
</tr>
<tr>
<td>itSMF<br> [https://itsmfuk.site-ym.com/ https://itsmfuk.site-ym.com]</td>
<td>ITIL 3<br>ITIL 3 Foundation Handbook (print version - pack of 10)<br> [https://itsmfuk.site-ym.com/store/ViewProduct.aspx?id=13263525/ https://itsmfuk.site-ym.com/store/ViewProduct.aspx?id=13263525]</td>
<td>ITIL 3</td>
<td>3</td>
</tr>
<tr>
<td>ITU<br>International Telecommunication Union<br> [https://www.itu.in/ www.itu.in]</td>
<td>ITU-T FG-Cloud TR<br>Focus Group on Cloud Computing (FG Cloud Technical Report)<br>Part 1: Introduction to the cloud ecosystem: definitions, taxonomies, usecases and highlevel requirement<br> [https://www.itu.int/dms_pub/itu-t/opb/fg/T-FG-CLOUD-2012-P1-PDF-E.pdf/ www.itu.int/dms_pub/itu-t/opb/fg/T-FG-CLOUD-2012-P1-PDF-E.pdf]<br>Part 2: Functional requirements and referencearchitecture<br> [https://www.itu.int/dms_pub/itu-t/opb/fg/T-FG-CLOUD-2012-P2-PDF-E.pdf/ www.itu.int/dms_pub/itu-t/opb/fg/T-FG-CLOUD-2012-P2-PDF-E.pdf]<br>Part 3: Requirements and framework architecture ofcloud infrastructure<br> [https://www.itu.int/dms_pub/itu-t/opb/fg/T-FG-CLOUD-2012-P3-PDF-E.pdf/ www.itu.int/dms_pub/itu-t/opb/fg/T-FG-CLOUD-2012-P3-PDF-E.pdf]<br>Part 4: Cloud Resource Management Gap Analysis<br> [https://www.itu.int/dms_pub/itu-t/opb/fg/T-FG-CLOUD-2012-P4-PDF-E.pdf www.itu.int/dms_pub/itu-t/opb/fg/T-FG-CLOUD-2012-P4-PDF-E.pdf]<br>Part 5: Cloud security<br> [https://www.itu.int/dms_pub/itu-t/opb/fg/T-FG-CLOUD-2012-P5-PDF-E.pdf/ www.itu.int/dms_pub/itu-t/opb/fg/T-FG-CLOUD-2012-P5-PDF-E.pdf]<br>Part 6: Overview of SDOs involved in cloud computing<br> [https://www.itu.int/dms_pub/itu-t/opb/fg/T-FG-CLOUD-2012-P6-PDF-E.pdf/ www.itu.int/dms_pub/itu-t/opb/fg/T-FG-CLOUD-2012-P6-PDF-E.pdf]<br>Part 7: Cloud computing benefits fromtelecommunication and ICT perspective<br> [https://www.itu.int/dms_pub/itu-t/opb/fg/T-FG-CLOUD-2012-P7-PDF-E.pdf/ www.itu.int/dms_pub/itu-t/opb/fg/T-FG-CLOUD-2012-P7-PDF-E.pdf]</td>
<td>ITU-T FG Cloud Px</td>
<td>1.0<br>2012</td>
</tr>
<tr>
<td>NIST<br>National Institute of Standards and Technology (U.S. Department of Commerce)<br> [https://www.nist.gov/ www.nist.gov]</td>
<td>Meerdere standards<br> [https://www.nist.gov/services-resources/standards-and-measurements/ www.nist.gov/services-resources/standards-and-measurements]</td>
<td>NIST</td>
<td> </td>
</tr>
<tr>
<td>Teletrust<br>(Bundesverband IT-Sicherheit e.V)<br> [https://www.teletrust.de/ www.teletrust.de]</td>
<td>Richtlijn State of the art in IT Security (Stand der Technik in der IT-Sicherheit)<br> [https://www.teletrust.de/fileadmin/docs/fachgruppen/2019-06_TeleTrusT_Richtlijn_State_of_the_art_in_IT_security_NLD.pdf/ https://www.teletrust.de/fileadmin/docs/fachgruppen/2019-06_TeleTrusT_Richtlijn_State_of_the_art_in_IT_security_NLD.pdf]</td>
<td>SotA</td>
<td>2019</td>
</tr>
<caption align="bottom">Overzicht internationale standaarden</caption></table>
==Toelichting control-domein==
Hieronder volgt per invalshoek een toelichting op het control-domein:
*[[IFGS Intentie|Intentie]], De organisatie heeft haar beleid voor clouddiensten vertaald naar een servicemanagementbeleid en evaluatierichtlijnen voor het inrichten, evalueren en bewaken van het functioneren en van de bescherming van de clouddiensten en activiteiten uitvoeren voor het monitoren en reviewen van de risico’s.
*[[IFGS Functie|Functie]], De organisatie heeft beheersingsprocessen ingericht en verricht voor beveiligingscontroles en kwetsbaarheden van de clouddiensten.
*[[IFGS Gedrag|Gedrag]], De organisatie verricht in haar processen activiteiten voor het monitoren van clouddiensten en technische kwetsbaarheden.
*[[IFGS Structuur|Structuur]], De organisatie heeft voor de clouddiensten een beheersingsorganisatie ingericht.
Afbeelding 'Dreigingen/kwetsbaarheden van control-objecten' toont de dreigingen/kwetsbaarheden van de genoemde [[ISOR:BIO Thema Clouddiensten Control|control-objecten]].
[[Afbeelding:BIO Thema Clouddiensten - De dreigingen en kwetsbaarheden van de benoemde Control objecten.png|thumb|none|650px|Dreigingen/kwetsbaarheden van control-objecten|alt=”De dreigingen en kwetsbaarheden van de control-objecten”]]
==Dreigingen/kwetsbaarheden cloudcontrol-objecten==
Het control-domein is op dezelfde wijze geanalyseerd als vermeld bij het [[BIO Thema Clouddiensten/Cloudbeveiligingsprincipes binnen het beleidsaspect|beleidsdomein]]. Ook hier zijn de vermelde dreigingen/kwetsbaarheden en risico’s zijn niet uitputtend benoemd. De relevante objecten binnen het control-domein worden weergegeven in afbeelding 'Control-objecten gestructureerd met de SIVA-methodiek'.
[[Bestand:CLD Control-objecten gestructureerd met de SIVA-metodiek.png|thumb|none|800px|Control-objecten gestructureerd met de SIVA-methodiek|alt=”De dreigingen en kwetsbaarheden van de control-objecten”]]
: → [[BIO Thema Clouddiensten/Risico's in relatie met clouddiensten#Dreigingen en/of kwetsbaarheden|Ga terug naar Dreigingen en/of kwetsbaarheden]]
De toepassing van cloud-computing<sup class="reference smartref" id="cite_ref-cloud-computing_1-0">[[BIO Thema Clouddiensten/Inleiding#cite_note-cloud-computing-1|1]]</sup>-diensten, kortweg clouddiensten, is een methode voor het leveren van de ICT. Cloud-computing is een term die staat voor de omgeving waarbinnen Cloud Service Providers (CSP’s) functionaliteit of diensten in de vorm van een technologische black-box aanbieden. Dit betekent dat clouddiensten gekozen worden met een vooraf vastgestelde ‘dienstenmenukaart’. De Cloud Service Consumer (CSC) kan als aanvullende eis stellen dat het effectieve beveiligingsniveau voor de betrokken CSC geen invloed ondervindt van onderhoud- en releasewerkzaamheden voor andere CSC's.
In het algemeen zijn er 3 soorten IT-clouds te onderscheiden:
# Private (met een dedicated infrastructuur), De IT-voorzieningen zijn ingericht voor één CSC en opgezet met de standaarden van de CSP.
# Private/shared (met een geheel of gedeeltelijk gedeelde infrastructuur), De IT-voorzieningen zijn toegankelijk voor één CSC en zij delen, om kosten te besparen, de onderliggende infrastructuur met andere CSC’s (bijvoorbeeld de opslag en het netwerk).
# Publiek, De IT-voorzieningen zijn toegankelijk via het Internet. De voorzieningen worden meestal gedeeld met andere CSC’s.
De meest bekende clouddiensten zijn:
* Software as a Service (SaaS), Bij SaaS staat de applicatie volledig onder controle van de dienstverlener.
* Platform as a Service (PaaS), Bij PaaS worden de platformen en de infrastructuur beheerd door de CSP en niet de applicaties.
* Infrastructure as a Service (IaaS), Bij IaaS wordt alleen de infrastructuur beheerd door de CSP en niet de applicaties en de platformen.
De toepassing van clouddiensten past in de verschuiving van maatwerkoplossingen naar standaard oplossingen. Sommige overheidsorganisatie maken al gebruik van bepaalde type clouddiensten. Andere organisaties overwegen nog om gebruik te maken van clouddiensten. Ook hebben sommigen hiervoor een eigen cloud-beleid ontwikkeld. Bij veel overheidsorganisatie heerst er echter onzekerheid over:
* het verwerven van clouddiensten, omdat heel veel activiteiten buiten hun zicht plaatsvinden;
* het opslaan van data bij een derde partij.
Een ander belangrijk aandachtspunt bij de overheidsorganisatie is dat bij een toename van het aantal diensten en dienstverleners (CSP’s) de regie-inspanning voor de afnemer (CSC) verder kan toenemen. Vooral wanneer CSP’s andere CSP’s inschakelen voor de te leveren diensten.
Ondanks het feit dat voor clouddiensten verschillende baselines bestaan, vragen organisaties zich af op welke onderwerpen<sup class="reference smartref" id="cite_ref-Te focussen clouddiensten onderwerpen_2-0">[[BIO Thema Clouddiensten/Inleiding#cite_note-Te focussen clouddiensten onderwerpen-2|2]]</sup> zij zich dienen te focussen.
Overheden die IT-diensten willen aanbesteden, dienen zich vanuit hun bijzondere verantwoordelijkheid de vraag te stellen, welke data van medewerkers, burgers en bedrijven, opgeslagen kan worden in de (publieke) cloud en welke data binnen de bescherming van de rekencentra van de overheid moet blijven. Leidend daarbij zijn de antwoorden<sup class="reference smartref" id="cite_ref-Antwoorden Plasterk_3-0">[[BIO Thema Clouddiensten/Inleiding#cite_note-Antwoorden Plasterk-3|3]]</sup> van minister Plasterk op vragen vanuit de [[Tweede Kamer der Staten-Generaal|Tweede Kamer]], mei 2014. De standpunten van de [[AIVD (Algemene Inlichtingen- en Veiligheidsdienst)|AIVD]] en de verkenning Cloudbeleid Rijksdienst en de [[IBD (Informatiebeveiligingsdienst)|IBD]]-handreikingen voor clouddiensten zijn tevens richtinggevend bij de risicoanalyse, zoals verderop in deze thema-uitwerking is uitgewerkt.
==Doelstelling==
Het doel van deze BIO Thema-uitwerking is overheidsorganisaties een systematisch beeld te geven van de voornaamste objecten van clouddiensten, waarmee zij ondersteund worden bij een goed afgewogen inzet van clouddiensten en het onderkennen van de aspecten die van belang zijn bij het aangaan van een clouddienst. De focus van deze thema-uitwerking ligt op beschikbaarheid, integriteit, vertrouwelijkheid en controleerbaarheid van de data en de betrouwbaarheid van de bedrijfsprocessen.
De uitwerking van de [[BIO Thema Clouddiensten|BIO Thema Clouddiensten]] dient als handreiking bij inkoop van clouddiensten. De keuze van de objecten dient plaats te vinden met de context van de organisatie en risicoanalyse.
==Opzet BIO Thema-uitwerking==
De BIO Thema-uitwerking Clouddiensten wordt uitgewerkt langs twee lijnen: structuur en objecten. De structuur van de BIO Thema-uitwerking Clouddiensten bestaat uit een indeling van [[ISOR:BIO Thema Clouddiensten Beleid|beleid]], [[ISOR:BIO Thema Clouddiensten Uitvoering|uitvoering]] en [[ISOR:BIO Thema Clouddiensten Control|control]]. De beveiligingsobjecten vormen de inhoudelijke onderwerpen die, vanuit de optiek van de CSC, van belang zijn. Door eerst op de objecten te focussen, wordt inzicht verkregen in en de relatie tussen de noodzakelijke objecten. Na het verkregen inzicht worden per object controls en onderliggende criteria voor maatregelen gedefinieerd. De objecten en de bijbehorende criteria voor maatregelen worden gestructureerd via het beleids-, uitvoerings- of controldomein.
Er wordt een standaard opzet voor [[Alle normenkaders|BIO Thema-uitwerkingen]] gevolgd. Vanwege het bijzondere karakter van deze thema-uitwerking zijn voor betere begripsvorming enkele onderwerpen toegevoegd. Deze thema-uitwerking volgt de volgende opzet:
* Context van de relatie tussen de CSC en CSP (zie [[BIO Thema Clouddiensten/Inleiding#Context relatie tussen CSC en CSP|Context relatie tussen CSC en CSP]])
* Context en globale structuur van deze thema-uitwerking (zie [[BIO Thema Clouddiensten/Inleiding#Context en globale structuur clouddiensten|Context en globale structuur clouddiensten]])
* Scope en begrenzing van de thema-uitwerking (zie [[BIO Thema Clouddiensten/Inleiding#Scope en begrenzing clouddiensten|Scope en begrenzing clouddiensten]])
* Aanleiding om gebruik te maken van clouddiensten (zie [[BIO Thema Clouddiensten/Inleiding#Aanleiding om gebruik te maken van clouddiensten|Aanleiding om gebruik te maken van clouddiensten]])
* Dreigingen/kwetsbaarheden (zie [[BIO Thema Clouddiensten/Risico's in relatie met clouddiensten#Dreigingen/kwetsbaarheden|Dreigingen/kwetsbaarheden]])
* CSC-georiënteerde aandachtspunten (zie [[BIO Thema Clouddiensten/Risico's in relatie met clouddiensten#CSC-georiënteerde aandachtspunten|CSC-georiënteerde aandachtspunten]])
* Beveiligingsobjecten voor clouddiensten in het beleids-, uitvoerings- en control-domein (zie [[BIO Thema Clouddiensten/Risico's in relatie met clouddiensten#Beveiligingsobjecten voor clouddiensten|Beveiligingsobjecten voor clouddiensten]]) gerelateerd aan basiselementen (zie [[ISOR:BIO Thema Clouddiensten Beleid|Clouddiensten Beleid]], [[ISOR:BIO Thema Clouddiensten Uitvoering|Clouddiensten Uitvoering]] en [[ISOR:BIO Thema Clouddiensten Control|Clouddiensten Control]])
==Context relatie tussen CSC en CSP==
In de verhouding tussen de CSC en de CSP zijn drie issues waar organisaties steeds op focussen. Vanuit de CSC beredeneerd zijn dit:
# On-going, Krijgt de CSC qua prestaties op dagelijkse basis de juiste diensten geleverd? Anders gezegd, voldoen de geleverde diensten aan prijs, kwaliteit, veiligheid- en continuïteitseisen? Dus hoe het gesteld is met de performance?
# Continuous monitoring (near real time), Krijgt de CSC de zekerheid dat hij regulier, conform contracten, bedrijfseisen en beveiligingseisen, de juiste diensten ontvangt? Dus hoe het gesteld is met de beoogde conformiteit?
# Compliancy (periodieke metingen en evaluaties), Krijgt de CSC de zekerheid dat hij in de afgelopen periode, conform wet- en regelgeving, contracten, bedrijfseisen en beveiligingseisen de juiste diensten heeft ontvangen? Dus hoe het gesteld is met de beoogde de compliance?
Bij de inkoop van clouddiensten levert de CSP niet alleen de gecontracteerde clouddiensten (ICT- servicelevering), maar ook de noodzakelijke continuous monitoring-, compliancy- en assurance-rapportages, zoals dit in afbeelding 'Twee deliverables van een CSP' wordt geschetst.
[[Afbeelding:Thema Clouddiensten - Twee deliverables van een CSP.png|thumb|none|500px|Twee deliverables van een CSP|alt=”Twee deliverables van een CSP”]]
Afbeelding 'Twee deliverables van een CSP' is verder uitgewerkt in afbeelding 'Twee CSP-deliverables en CSC-eisen/wensen'.
[[Afbeelding:Thema Clouddiensten - Twee deliverables van een CSP en de eisen en wensen aan de vraag en levering kant.png|thumb|none|500px|Twee CSP-deliverables ven CSC-eisen/wensen|alt=”Twee deliverables van een CSP en de eisen en wensen aan de vraag en levering kant”]]
ICT-servicelevering
Dit betreft de daadwerkelijk door de CSC gevraagde publieke of private clouddiensten, die aan bepaalde functionele en beveiligingseisen moeten voldoen. De levering gaat vergezeld van prestatiemetingen over de geleverde diensten en de noodzakelijke verbetermaatregelen voor leveringen en beveiliging.
Assurance
Dit betreft een jaarlijkse rapportage gebaseerd op een onderzoek uitgevoerd door een derde partij. Met de assurance-rapportage geeft de CSP zekerheid aan de CSC dat de geleverde diensten aan de contractuele eisen hebben voldaan. De assurance-rapportage komt tot stand met een onderzoekstraject waarin een referentiekader als toetsingsmiddel wordt gehanteerd.
Trust
De inkoop van clouddiensten gaat gepaard met een gedragen en haalbaar ICT-servicecontract. Echter er zullen altijd aspecten zijn die bij de contractvorming over het hoofd worden gezien. Voor een duurzame relatie is daarom een vertrouwensrelatie tussen de CSC en de CSP vereist, anders lopen zij steeds het risico in een juridische strijd verwikkeld te raken.
Zowel aan de CSC-kant als aan de kant van de CSP spelen verschillende aspecten een rol. In de relatie tussen de CSC en CSP heeft iedere partij haar eigen rol. De relevante aspecten zijn hieronder beschreven.
CSC (vraagzijde)
Initieel stelt de CSC een Programma van Eisen en Wensen (PvEeW) vast voor de te verwerven clouddiensten en communiceert dit met de potentiële CSP’s. Wanneer de CSC en de gekozen CSP overeenstemming bereiken, worden clouddiensten geleverd. Een belangrijke vraag voor overheidsdienstverlening is hierbij: ‘Is de toepassing van Clouddienst, gelet op de, door de Tweede Kamer geaccepteerde risico’s toegestaan?'<sup class="reference smartref" id="cite_ref-Mail Kuijpers_4-0">[[BIO Thema Clouddiensten/Inleiding#cite_note-Mail Kuijpers-4|4]]</sup> In [[BIO_Thema_Clouddiensten/Beslisbomen_voor_risicobeoordeling_IV-diensten]] zijn instrumenten, in de vorm van beslisbomen, opgenomen waarmee organisaties kunnen besluiten al dan niet gebruik te maken van clouddiensten.
CSP (leveringszijde)
De CSP maakt met het PvEeW een functioneel en technisch ontwerp. Vervolgens wordt de dienst gebouwd, getest en in productie genomen.
Deze geleverde diensten dienen altijd te voldoen aan de, in de vorm van wettelijke en business eisen, gestelde condities. Hiernaast komen de partijen overeen dat de geleverde diensten:
* meetbaar en voorspelbaar moeten zijn;
* compliant moeten zijn aan wet- en regelgeving, business- en beveiligingseisen van de CSC;
* beveiligd en beheerst moeten zijn.
Geleverde diensten
Deze diensten dienen altijd te voldoen aan de, in de vorm van wettelijke en business eisen, gestelde condities. Hiernaast komen de partijen overeen dat de geleverde diensten:
* meetbaar en voorspelbaar moeten zijn;
* compliant moeten zijn aan wet- en regelgeving, business- en beveiligingseisen van de CSC;
* beveiligd en beheerst moeten zijn.
==Context en globale structuur clouddiensten==
Afbeelding 'Twee deliverables van een CSP en de eisen/wensen aan de CSC-kant' kan samengevat worden met het [[ISOR:BIO Thema Clouddiensten Beleid|beleids-]], [[ISOR:BIO Thema Clouddiensten Uitvoering|uitvoerings-]] en [[ISOR:BIO Thema Clouddiensten Control|control-domein]]. Dit wordt in afbeelding 'Context CSC- en CSP-relatie bij clouddienstenverwerving' geïllustreerd.
[[Afbeelding:Thema Clouddiensten - Context CSC en CSP relatie bij verwerven van clouddiensten.png|thumb|none|500px|Context CSC- en CSP-relatie bij clouddienstenverwerving|alt=”Context CSC en CSP relatie bij verwerven van clouddiensten”]]
===Beleidsdomein===
De CSC stelt een PvE(eW) op, dat als randvoorwaarde geldt. Voor zowel de CSC als de CSP is het PvE(eW) een toetsinstrument. Zij kunnen de volgende vragen stellen:
* CSC: heb ik de juiste dienst(en) geleverd gekregen?
* CSP: hoe kan ik aantonen dat ik de juiste diensten heb geleverd?
===Uitvoeringsdomein===
Binnen dit domein gaat het om de operationele levering van clouddiensten. Aan beide zijden moet transparantie zijn over de gevraagde en daadwerkelijke leveringen.
===Control-domein===
Binnen dit domein zijn de beheersingsprocessen ingericht. Voor de beoogde dienstverlening moeten de beheersingsprocessen aan de kant van de CSC en de CSP op elkaar zijn afgestemd.
==Scope en begrenzing clouddiensten==
De scope van de BIO Thema-uitwerking Clouddiensten is de set van specifieke onderwerpen (objecten) waar organisaties aandacht aan moeten besteden bij het inkopen van clouddiensten. Deze thema-uitwerking richt zich hoofdzakelijk op het ‘wat’-aspect.
Het is ook van belang om te weten langs welke route organisaties naar de cloud kunnen. Hieraan liggen migratiestrategieën ten grondslag. De migratiestrategieën zullen niet worden beschreven. Het zogeheten ‘hoe’-aspect wordt in deze thema-uitwerking niet uitgewerkt. In de praktijk zijn daarvoor verschillende baselines beschikbaar.
De algemene eisen uit de [[BIO (Baseline Informatiebeveiliging Overheid)|Baseline Informatiebeveiliging Overheid (BIO)]] en [[NEN-ISO/IEC 27001|ISO 27001]] en [[NEN-ISO/IEC 27002|ISO 27002]] blijven onverminderd van kracht. Het gaat in deze thema-uitwerking om specifieke additionele objecten die gerelateerd zijn aan clouddiensten. De maatregelen die gerelateerd zijn aan deze objecten moeten realistisch en implementeerbaar zijn voor een CSP.
Privacy-aspecten: Data Protection Impact Assessments (DPIA’s) worden niet expliciet in dit thema opgenomen, omdat DPIA’s vanuit de [[AVG (Algemene Verordening Gegevensbescherming)|Algemene Verordening Gegevensbescherming (AVG)]] generiek bij elk project uitgevoerd dienen te worden.
De begrenzing van deze BIO Thema-uitwerking is in onderstaande afbeelding weergegeven.
[[Bestand:CLD Relatie BIO Thema-uitwerking met aanpalende documenten.png|thumb|none|500px|Relatie BIO Thema-uitwerking met aanpalende documenten|alt=”Relatie BIO Thema-uitwerking Clouddiensten met aanpalende documenten”]]
==Aanleiding om gebruik te maken van clouddiensten==
Enkele belangrijke argumenten van overheden om gebruik te maken van clouddiensten zijn:
* de focus op kerntaken;
* een efficiënte bedrijfsvoering en het verlagen van de totale kosten;
* het binnen een kort tijdsbestek kunnen beschikken over nieuwe IT-functionaliteit en daarmee de dienstverlening aan burger en bedrijf sneller aan kunnen passen aan de (veranderende) behoefte;
* de zekerheid over gekwalificeerd personeel;
* het verlagen van IT-complexiteit in specifieke situaties;
* het verbeteren van beveiliging/beschikbaarheid;
* een herziene bedrijfsstrategie en vereiste specifieke beveiligingseisen voor processen en data.
Hiernaast kunnen organisaties met externe factoren overwegen om gebruik te maken van clouddiensten, zoals:
* Vigerende wet- en regelgeving voor:
** een betrouwbare dienstverlening en het veilig omgaan met data van burgers en bedrijven;
** het overheidsbeleid inzake data in de cloud en de invloed van internationale verdragen;
** de noodzaak voor een weerbare overheid tegen cybercriminaliteit en statelijke actoren;
* Technologische ontwikkelingen, Hierbij wil de CSC kunnen inspelen op innovaties, die kunnen leiden tot een efficiëntere bedrijfsvoering en verlaging van de totale kosten.
==Toepassing BIO Thema-uitwerking==
Deze BIO Thema-uitwerking is een hulpmiddel bij het kiezen van een aantal te adresseren cloud-objecten bij het verwerven van clouddiensten. Bij de opzet van deze thema-uiterking is het onderwerp cloud functioneel benaderd en niet uitgewerkt op de technische gelaagdheid van SaaS, PaaS en IaaS. Bij het verwerven van clouddiensten kan de [[ISOR (Information Security Object Repository)]] als hulpmiddel dienen. Dit impliceert de volgende stappen:
* Bepaal als eerste de context van de case en het type dienst dat verworven moet worden.
* Identificeer vervolgens de operationele beveiligingsobjecten. Raadpleeg hierbij de objecten in het uitvoeringsdomein (zie [[ISOR:BIO Thema Clouddiensten Uitvoering|Uitvoeringsdomein]]).
* Identificeer daarna de conditionele objecten. Raadpleeg hierbij de objecten in het beleidsdomein (zie [[ISOR:BIO Thema Clouddiensten Beleid|Beleidsdomein]]).
* Identificeer tenslotte de beheersingsobjecten. Raadpleeg hierbij de objecten in het control- domein (zie [[ISOR:BIO Thema Clouddiensten Control|Control-domein]]).
* Neem de beveiligingsobjecten op in het PvEeW voor de clouddienst, zodat deze objecten door de CSP kunnen worden gerelateerd aan de specificaties van bestaande ‘standaard diensten’ of worden vertaald in maatregelen voor de aangeboden specifieke dienstverlening.
Relevante risico’s verbonden aan clouddiensten kunnen ondergebracht worden in 2 risicogroepen:
# Data, Gegevens van de burger of de Cloud Service Consumer (CSC) zijn verloren geraakt of misbruikt.
# IT-dienstverlening, De betrouwbare dienstverlening aan de burger en CSC is in gevaar.
Risico’s worden bepaald door dreigingen en kwetsbaarheden en de kans dat daardoor schade ontstaat. Zowel dreigingen als kwetsbaarheden zijn hieronder concreet gemaakt. De factor ‘kans’ is niet berekenbaar voor clouddiensten, maar kan ingeschat worden door onderzoek vanuit de eigen context van de CSC en de zich ontwikkelende markt van Cloud Service Providers (CSP's).
==Dreigingen/kwetsbaarheden==
NB Aandachtspunten voor consequenties is overgenomen van Weolcan: [https://blog.weolcan.eu/wat-is-een-cloud-exit-strategie-precies-en-hoe-voer-je-het-uit/ https://blog.weolcan.eu/wat-is-een-cloud-exit-strategie-precies-en-hoe-voer-je-het-uit]
De vakliteratuur noemt verschillende dreigingen/kwetsbaarheden waarmee een CSC rekening dient te houden bij het verwerven van clouddiensten. Na de verwerving kan de CSC geconfronteerd worden met issues over contracten en prestaties van de clouddienst en over ondersteuning door en de relatie met de CSP. Bij het identificeren van objecten voor clouddiensten zijn beide hiervoor genoemde risicogroepen als invalshoek gebruikt. Onderstaande tabel en afbeelding geven een overzicht van de belangrijkste kwetsbaarheden en voorkomende consequenties. [[BIO Thema Clouddiensten/Cloudbeveiligingsprincipes binnen het beleidsaspect|Toelichting objecten in het beleidsdomein]], [[BIO Thema Clouddiensten/Cloudbeveiligingsprincipes binnen het uitvoeringsaspect|Toelichting objecten in het uitvoeringsdomein]] en [[BIO Thema Clouddiensten/Cloudbeveiligingsprincipes binnen het control-aspect|Toelichting objecten in het control-domein]] bevatten detailuitwerkingen van de dreigingen. De tabel en afbeelding zijn beperkt tot de set van [[CSA (Cloud Security Alliance)|Cloud Security Alliance (CSA)]] en Greer and Jackson.
<table class="wikitable">
<tr>
<th>Nr.</th>
<th colspan="3">Cloud Computing Vulnerabilities CSA en Greerand Jackson, 2017</th>
</tr>
<tr>
<td>1</td>
<td rowspan="2">Data</td>
<td>Data breaches</td>
<td>Dataverstoringen</td>
</tr>
<tr>
<td>2</td>
<td>Data Loss or data leakage</td>
<td>Dataverlies of datalekken</td>
</tr>
<tr>
<td>3</td>
<td rowspan="13">Clouddiensten</td>
<td>Account or service traffic hijacking</td>
<td>Kapen van account of serviceverkeer</td>
</tr>
<tr>
<td>4</td>
<td>Denial of Service</td>
<td>Denial of Service</td>
</tr>
<tr>
<td>5</td>
<td>Malicious insiders</td>
<td>Kwaadwillende insiders</td>
</tr>
<tr>
<td>6</td>
<td>Abuse of nefarious use of cloud computing</td>
<td>Misbruik of misdadig gebruik van cloudcomputing</td>
</tr>
<tr>
<td>7</td>
<td>Insufficient due diligence</td>
<td>Onvoldoende due diligence</td>
</tr>
<tr>
<td>8</td>
<td>Shared technology vulnerabilities</td>
<td>Gedeelde technologiekwetsbaarheden</td>
</tr>
<tr>
<td>9</td>
<td>Insecure interfaces and API’s</td>
<td>Onveilige interfaces en API’s</td>
</tr>
<tr>
<td>10</td>
<td>Unknown risk profile</td>
<td>Onbekend risicoprofiel</td>
</tr>
<tr>
<td>11</td>
<td>Hardware failure</td>
<td>Hardware falen</td>
</tr>
<tr>
<td>12</td>
<td>Nature disasters</td>
<td>Natuurlijke rampen</td>
</tr>
<tr>
<td>13</td>
<td>Closure of cloud service</td>
<td>Afsluiten van de cloud dienst</td>
</tr>
<tr>
<td>14</td>
<td>Cloud related malware</td>
<td>Cloud gerelateerde malware</td>
</tr>
<tr>
<td>15</td>
<td>Inadequate infrastructure design and planning</td>
<td>Inadequateinfrastructuur ontwerp en planning</td>
</tr>
<caption align="bottom">Cloud Computing Vulnerabilities CSA en Greer and Jackson, 2017</caption></table>
[[Afbeelding:BIO Thema Clouddiensten - Cloud gerelateerde dreigingen en kwetsbaarheden.png|thumb|none|800px|Cloud gerelateerde dreigingen en kwetsbaarheden|alt=”Cloud gerelateerde dreigingen en kwetsbaarheden”]]
==CSC-georiënteerde aandachtspunten==
De schrijfgroep heeft over clouddiensten diverse gesprekken gevoerd met CSC’s en CSP’s. Ook heeft de schrijfgroep verschillende beleidsdocumenten ontvangen van CSC’s. Bij de besprekingen en het bestuderen van de documenten staan 2 vragen centraal:
# Welke issues voor clouddiensten spelen een rol bij de CSC’s?
# Waar maken CSC’s zich de meeste zorgen over bij het verwerven van clouddiensten?
De geïdentificeerde issues zijn globaal onderverdeeld in een aantal generieke onderwerpen: beleid en strategie, processen/functies (technische en organisatorische), interacties, infrastructuur en structuur (architectuur en organisatiestructuur). Onderstaande afbeelding geeft een overzicht van de ingedeelde onderwerpen.
[[Afbeelding:Thema Clouddiensten - CSC georiënteerde aandachtspunten.png|thumb|none|800px|CSC georiënteerde aandachtspunten|alt=”CSC georiënteerde aandachtspunten”]]
==Beveiligingsobjecten voor clouddiensten==
Objecten worden geïdentificeerd met onderzoeksvragen en risicogebieden. De objecten hebben tot doel risico’s te mitigeren en zijn afgeleid van de algemene beveiligingseisen: beschikbaarheid, integriteit, vertrouwelijkheid en controleerbaarheid die vervolgens zijn ingedeeld in het beleids-, uitvoerings- en control-domein. De vragen die vanuit optiek van deze domein hierbij spelen zijn:
* Welke randvoorwaardelijke elementen spelen een rol bij de inrichting van de clouddiensten en wat is de consequentie van het ontbreken van een of meer van deze elementen?
* Welke elementen spelen een rol bij de inrichting van de clouddiensten en wat is de consequentie van het ontbreken van één of meer van deze elementen?
* Welke elementen spelen een rol bij de beheersing van de clouddiensten en wat is de consequentie van het ontbreken van één of meer van deze elementen?
Uit de contextuele analyse blijkt dat verschillende onderwerpen niet in de [[BIO (Baseline Informatiebeveiliging Overheid)|Baseline Informatiebeveiliging Overheid (BIO)]] voorkomen. Voor de onderwerpen, waarvoor de BIO geen control heeft geformuleerd, zijn controls uit andere baselines geadopteerd.
In 2019 is de [[AIVD (Algemene Inlichtingen- en Veiligheidsdienst)|Algemene Inlichtingen- en Veiligheidsdienst (AIVD)]] om een standpunt gevraagd over het gebruik van publieke clouddiensten voor gerubriceerde gegevens of vitale overheidsprocessen, waarvoor weerstand tegen statelijke actoren noodzakelijk is. Tevens heeft het [[BZK (Ministerie van Binnenlandse Zaken en Koninkrijksrelaties)|Ministerie van Binnenlandse Zaken en Koninkrijkrelaties (BZK)]] een beleidsverkenning gedaan. De AIVD maakt overigens in haar standpunt geen onderscheid tussen Rijksdiensten en de andere overheden.
Hieronder volgen enkele citaten die de kern van het AIVD-standpunt weergeven, waarop ook de beleidsverkenning van BZK is gebaseerd.
==NBV-standpunt Publieke Clouddiensten (citaten uit de brief AIVD, 09/09/2019)==
Publieke clouddiensten bieden in de huidige situatie, geen controleerbaar afdoende weerstand tegen statelijke actoren omdat er nu nog onvoldoende zekerheid kan worden verkregen:
* dat de overheidsgegevens en -processen technisch en procedureel voldoende zijn afgeschermd tegen de clouddienstverlener, zijn onderaannemers en zijn medewerkers;
* dat de clouddienstverlener spionage-en sabotage-aanvallen van statelijke actoren betrouwbaar preventief kan afweren;
* dat de clouddienstverlener spionage en sabotage aanvallen van statelijke actoren betrouwbaar kan detecteren én hierop adequaat zal reageren;
* dat voldoende controle en toezicht mogelijk is op publieke clouddienstverleners.
Daarbij gebruiken publieke clouddiensten vaak het internet, zodat de toegang en beschikbaarheid extra zorg vragen. Kortom, op dit moment is er onvoldoende zekerheid dat publieke clouddienstverleners kunnen voldoen aan het [[Besluit voorschrift informatiebeveiliging rijksdienst bijzondere informatie 2013 (VIRBI)|Voorschrift Informatiebeveiliging Rijksdienst Bijzondere Informatie (VIR-BI)]] en de [[BIO (Baseline Informatiebeveiliging Overheid)|Baseline Informatiebeveiliging Overheid (BIO)]]. Dit [[AIVD (Algemene Inlichtingen- en Veiligheidsdienst)#Businessunit Nationaal Bureau Verbindingsbeveiliging (NBV)|Nationaal Bureau Verbindingsbeveiliging (NBV)]]-standpunt is gebaseerd op de huidige stand van cloudtechnologie, statelijke cyberdreiging, nationale en internationale regelgeving en contractmogelijkheden. De ontwikkelingen op dit gebied gaan snel en het zal nodig zijn om dit standpunt periodiek, bijvoorbeeld jaarlijks, te heroverwegen.
'''Conclusie'''
In de huidige situatie is gebruik van publieke clouddiensten daarom niet geschikt voor gerubriceerde nationale informatie (Dep.V tot en met Stg.ZG), gerubriceerde EU- en [[NAVO (Noord-Atlantische Verdragsorganisatie)|NAVO]]-informatie en voor vitale overheidsprocessen waarvoor betrouwbare weerstand tegen statelijke actoren nodig is. Het gebruik van publieke clouddiensten is daarom ook ongeschikt voor Dep.V gerubriceerde informatie waarvoor betrouwbare detectie van statelijke actoren nodig is.
Als via risicoanalyse is vastgesteld dat geen weerstand tegen en geen detectie van statelijke actoren nodig is, dan kunnen publieke clouddiensten gebruikt worden. (Einde citaten uit de AIVD-brief.)
==Verkenning Cloudbeleid voor Nederlandse Rijksdiensten (citaten uit brief aan CIO-Rijk, 16/09/2019)==
Concept voor brede discussie
Dit document bevat een verkenning voor Cloudbeleid van de Nederlandse Rijksdienst. Doel van deze verkenning is om richting te geven aan het gebruik en verdere ontwikkeling van clouddiensten door departementen, en om ambities te formuleren, waarbij rekening wordt gehouden inzichten van de AIVD voor het omgaan met dreigingen door Advanced Persistent Threats (APT’s) zoals statelijke actoren. Uitgangspunt is dat clouddiensten moeten voldoen aan de voorwaarden van het algemeen beleid. Deze voorwaarden zijn in grote lijnen beschreven in de strategische i‐agenda voor de Rijksdienst 2019 ‐2021.
'''Overwegingen en beleidsvoornemen'''
Het cloudbeleid dient duidelijkheid te scheppen hoe veilig gebruik gemaakt kan worden van Private, Hybride en Public Clouddiensten door overheidspartijen. Omdat de [[BIR (Baseline Informatiebeveiliging Rijksdienst)|Baseline Informatiebeveiliging Rijksdienst (BIR)]] inmiddels, formeel, in de [[BIO (Baseline Informatiebeveiliging Overheid)|Baseline Informatiebeveiliging Overheid (BIO)]] is overgegaan, wordt in het vervolg van dit document gesproken over BIO-BBN niveaus terwijl de focus van dit document (thans) de Rijkdienst betreft.
In dit hoofdstuk zijn in het kader van risicomanagement de mogelijke beleidslijnen uitgewerkt rond het toepassen van ‘Basis Beveiligingsniveau’ (BBN) 1, 2 en 3 voor diverse Cloudimplementatie-scenario’s. De BIR/BIO bepaalt op basis van eisen voor vertrouwelijkheid. Het onderscheid in drie BBN’s voorkomt dat voor eenvoudige systemen zonder vertrouwelijke informatie of zonder eigen voor hoge beschikbaarheid teveel administratieve last wordt opgeroepen. Terwijl de BIO zich met name richt op vertrouwelijkheid van gegevens, wordt in Nederland, gedreven door internationale ontwikkelingen, ook meer aandacht gevraagd voor de beschikbaarheid van ‘vitale systemen en processen’. In beide toepassingen is risicomanagement met een proportionele set aan maatregelen een logische aanpak.
Risicomanagement betreft het inzichtelijk en systematisch inventariseren, beoordelen en – door het treffen van maatregelen – beheersbaar maken van risico’s en kansen, die het bereiken van de doelstellingen van de organisatie bedreigen dan wel bevorderen, op een zodanige wijze dat verantwoording kan worden afgelegd over de gemaakte keuzes.
'''Uitgangspunten'''
Voor alle toepassingen geldt, dat zal moeten zijn voldaan aan geldende kaders.
Versie 1 okt 2019, geeft aan dat aanpassingen worden meegenomen, zodra nieuwe inzichten daar aanleiding toe geven. Het streven is om deze jaarlijks te herzien, of zoveel eerder als ontwikkelingen daar aanleiding toe geven.
Met de voorgaande overwegingen en de input van veiligheidsexperts zijn de volgende beleidsvoornemens tot stand gekomen: Voor alle niveaus (zoals in de matrix geschetst) geldt de voorwaarde: er is een samenhangende risicoanalyse uitgevoerd, waarin rekening is gehouden met eisen voor vitale en kritieke processen en gevoelige data, en deze is opgevolgd. De restrisico’s zijn of gemitigeerd of zijn geaccepteerd door de eigenaar.
Conclusie: One Cloud doesn’t fit All.
[[Bestand:CLD Matrix voorgenomen cloudbeleid per classificatie.png|thumb|none|500px|Voorgenomen Cloudbeleid 1 oktober 2019 in matrix-overzicht]]
Betekenis van de nummers 1, 2, 3 en 4 in de matrix:
# Er is voldaan aan:
## Er moet een samenhangende risicoanalyse voor vitale en kritieke processen en gevoelige data zijn uitgevoerd en de resultaten daarvan zijn opgevolgd.
## De uitkomsten zijn vastgelegd en (auditeerbaar) gecommuniceerd.
## De restrisico’s zijn door de systeem‐ of proces‐eigenaar geaccepteerd:
### Voor departementale processen: met input van de Chief Information Security Officer (CISO).
### Voor interdepartementale processen: met input van de CISO‐Rijk
# Er dienen passende voorzieningen beschikbaar te zijn om activiteiten van APT's zoals statelijke actoren te kunnen signaleren en daarop in te grijpen. Dit betreft een set aan detectie voorzieningen en maatregelen, waarvan expert diensten (AIVD, [[MIVD (Militaire Inlichtingen- en Veiligheidsdienst)|Militaire Inlichtingen- en Veiligheidsdienst (MIVD)]] of [[NCSC (Nationaal Cyber Security Centrum)|Nationaal Cyber Security Centrum (NCSC)]]) hebben aangegeven dat deze zinvol zijn te opzicht van het risico dat het departement met de voorziening of proces loopt.
# De verwerking van de (Dep.V) gerubriceerde BIO‐BBN2 gegevens is vóóraf door de Secretaris Generaal (SG) goedgekeurd.
# Voor de goedkeuring van de SG, dient het expert advies van de AIVD over Clouddiensten (zie hierboven) expliciet te worden meegewogen. Daarin staat vermeld (citaat) “Het gebruik van publieke clouddiensten is daarom ook ongeschikt voor Dep.V gerubriceerde informatie waarvoor betrouwbare detectie van statelijke actoren nodig is” (einde citaten)
Er wordt een toelichting gegeven van de [[SIVA-methodiek|Structuur, Inhoud, Vorm, Analysevolgorde (SIVA)]]-basiselementen met behulp van het Management Control System (MCS). Hiermee wordt de validiteit van de basiselementen binnen de IFGS (Intentie, Functie, Gedrag en Structuur) kolommen aangegeven. De basiselementen worden verder binnen de Beleid, Uitvoering en Control (BUC)-aspecten toegepast om de relaties tussen de geïdentificeerde cloud-principes uit te drukken.
De dynamische omgeving van een organisatie kan (volgens Leavitt, 1965 en COBIT) met behulp van vier componenten worden uitgedrukt, te weten: functie/processen, mensen, technologie en structuur. Als input geldt een ontwikkelde strategie en als output de performance, die het resultaat is van de samenwerking van de genoemde vier componenten. In de literatuur wordt het MCS bezien als een ‘Framework voor de implementatie van Strategie’, zoals in onderstaande afbeelding wordt afgebeeld.
[[Afbeelding:BIO Thema Clouddiensten Weergave van de componenten van MCS.png|thumb|none|500px|Weergave van de componenten van MCS|alt=”Weergave van de componenten van het MCS”]]
MCS- en SIVA-basiselementen - Aan de componenten van het MCS-framework kunnen vanuit de invalshoeken: Intentie, Functie, Gedrag en Structuur (IFGS) verschillende basiselementen worden gekoppeld. Deze basiselementen zijn weergegeven in onderstaande afbeelding. De zes componenten en de hieraan gerelateerde basiselementen vormen unieke set elementen om de geïdentificeerde set cloud-principes te labelen. Door het labelen van de geïdentificeerde set cloud-principes met de basiselementen krijgen de cloud-principes een unieke plek in de matrix, hierbij wordt tevens rekening gehouden met de typen functionarissen die actief zijn op de BUC-lagen. Zo kan een samenhangend beeld van de geïdentificeerde cloud-principes worden weergegeven.
[[Afbeelding:BIO Thema Clouddiensten - Weergave van de samenhang van de basiselementen binnen het MCS.png|thumb|none|500px|Weergave van de samenhang van de basiselementen binnen het MCS|alt=”Weergave van de samenhang van de basiselementen binnen het MCS”]]
Hieronder volgt per [[Alle invalshoeken|invalshoek]] een toelichting op het [[ISOR:BIO Thema Clouddiensten Beleid|beleidsdomein]]:
*[[IFGS Intentie|Intentie]], Een organisatie heeft bij het verwerven van clouddiensten doelstellingen geformuleerd, zoals: een efficiënte bedrijfsvoering en een schaalbare en flexibele dienstverlening. Hiervoor ontwikkelt zij beleid en strategie. Omdat dit met onzekere informatie wordt ontwikkeld, laten stakeholders risicoanalyse(s) uitvoeren. Voor het uitvoeren van risicoanalyses is een te hanteren risicoaanpak (methode) vastgesteld (risicomanagement).
*[[IFGS Functie|Functie]], Om aan de doelstellingen te kunnen voldoen, kan de organisatie besluiten functionele eisen vast te stellen. Zij moeten de IT-functionaliteiten en gerelateerde processen en beveiligingsfuncties beschrijven.
*[[IFGS Gedrag|Gedrag]], De IT-functionaliteiten worden gerealiseerd door actoren (human resources) en IT-objecten (technische resources). Human resources refereert aan mensen waaraan eisen worden gesteld, zoals educatie, competentie/vaardigheid. IT-resources zijn ‘Data’ en IT-objecten (applicaties, servers en infrastructuur).
*[[IFGS Structuur|Structuur]], De inzet van de actoren dienen goed georganiseerd te worden door een organisatiestructuur en de benodigde IT-objecten een architectuur.
Afbeelding 'Dreigingen/kwetsbaarheden van beleidsobjecten' toont dreigingen/kwetsbaarheden van de genoemde [[ISOR:BIO Thema Clouddiensten Beleid|beleidsobjecten]].
[[Afbeelding:Kwetsbaarheden_van_de_beleidsprincipes.png|thumb|none|650px|Dreigingen/kwetsbaarheden van beleidsobjecten|alt=”De dreigingen/kwetsbaarheden van de beleidsobjecten”]]
==Dreigingen/kwetsbaarheden cloud-beleidsobjecten==
Afbeelding 'Beleidsobjecten gestructureerd met de SIVA-methodiek' geeft voor het beleidsdomein en dankzijde vermelde dreigingen/kwetsbaarheden en risico’s de geïdentificeerde beveiligingsobjecten voor clouddiensten weer. Deze dreigingen/kwetsbaarheden en risico’s zijn niet uitputtend en illustreert de wijze waarop de schrijfgroep tot relevante beleidsobjecten is gekomen: eerst een longlist en vervolgens een shortlist. De objecten uit de shortlist zijn vervolgens gestructureerd met de [[SIVA-methodiek|SIVA-methodiek]]. SIVA staat voor Structuur, Inhoud, Vorm en Analysevolgorde. Ze zijn ingedeeld in de 3 domeinen: [[Beveiligingsaspect Beleid|beleid]], [[Beveiligingsaspect Uitvoering |uitvoering]] en [[Beveiligingsaspect Control|control]] en [[Alle invalshoeken|4 invalshoeken: intentie, functie, gedrag en structuur]].
[[Afbeelding:BIO Thema Clouddiensten - De Beleid objecten gestructureerd conform het SIVA raamwerk.png|thumb|none|800px|Beleidsobjecten gestructureerd met de SIVA-methodiek|alt=”De Beleidsobjecten gestructureerd met de SIVA-methodiek”]]
: → [[BIO Thema Clouddiensten/Risico's in relatie met clouddiensten#Dreigingen en/of kwetsbaarheden|Ga terug naar Dreigingen en/of kwetsbaarheden]]
Hieronder volgt [[Alle invalshoeken|per invalshoek]] een toelichting op het [[ISOR:BIO Thema Clouddiensten Uitvoering|uitvoeringsdomein]]:
* [[IFGS Intentie|Intentie]], In het uitvoeringsdomein zal de organisatie onder andere haar beleid vertalen naar richtlijnen voor het uitvoeren van een risicoanalyse en de implementatie vertalen naar procedures.
*[[IFGS Functie|Functie]], In dit domein worden voor clouddiensten organisatorische en technisch georiënteerde maatregelen getroffen.
*[[IFGS Gedrag|Gedrag]], De clouddiensten kennen een aantal specifieke elementen, zoals toegang en technisch georiënteerde componenten.
*[[IFGS Structuur|Structuur]], De clouddiensten moeten een goed overzicht bieden via een architectuur.
Afbeelding 'Dreigingen/kwetsbaarheden van uitvoeringsobjecten' toont de dreigingen/kwetsbaarheden van de genoemde [[ISOR:BIO Thema Clouddiensten Uitvoering|uitvoeringsobjecten]].
[[Afbeelding:BIO Thema Clouddiensten - De dreigingen en kwetsbaarheden van de benoemde Uitvoering objecten.png|thumb|none|650px|Dreigingen/kwetsbaarheden van uitvoeringsobjecten|alt=”De dreigingen en kwetsbaarheden van de uitvoeringsprincipes”]]
==Dreigingen/kwetsbaarheden cloud-uitvoeringsobjecten==
Het uitvoeringsdomein is op dezelfde wijze geanalyseerd als vermeld bij het [[BIO Thema Clouddiensten/Cloudbeveiligingsprincipes binnen het beleidsaspect|Cloudbeveiligingsobjecten binnen het beleidsdomein]]. Ook hier zijn de vermelde dreigingen/kwetsbaarheden en risico’s niet uitputtend benoemd. Afbeelding 'Uitvoeringsobjecten gestructureerd met de SIVA-methodiek' geeft voor het uitvoeringdomein en dankzijde vermelde dreigingen/kwetsbaarheden en risico’s de geïdentificeerde beveiligingsobjecten voor clouddiensten weer.
[[Afbeelding:BIO Thema Clouddiensten - De Uitvoering objecten gestructureerd conform het SIVA raamwerk.png|thumb|none|800px|Uitvoeringsobjecten gestructureerd met de SIVA-methodiek|alt=”De Uitvoeringsobjecten gestructureerd conform het SIVA-raamwerk”]]
: → [[BIO Thema Clouddiensten/Risico's in relatie met clouddiensten#Dreigingen en/of kwetsbaarheden|Ga terug naar Dreigingen en/of kwetsbaarheden]]