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
Een beschrijving van een complex geheel, en van de principes die van toepassing zijn op de ontwikkeling van het geheel en zijn onderdelen. +
Architectuur Board stelt doorontwikkeling in op drie katernen +
Architectuur Digitale Overheid 2030 vastgesteld +
Processchema met tussenliggende architectuurproducten en de flow daartussen +
Schema van relaties tussen views en viewspoints met hun omgeving +
Een normatieve uitspraak die richting geeft aan het in samenhang ontwerpen en realiseren van overheidsdiensten voor burgers en bedrijven. +
Normatieve en descriptieve documenten die huidige/toekomstige architectuur van een organisatie/domein schetsen. +
De Artificial Intelligence Act (Verordening Kunstmatige Intelligentie, AI Act, AIA) is een voorstel voor een Europese verordening van de Europese Commissie die tot doel heeft een gemeenschappelijk regelgevend en juridisch kader voor kunstmatige intelligentie in te voeren. +
Een eigenschap, kenmerk of kwaliteit van een natuurlijke of rechtspersoon of een entiteit, in elektronisch formaat. +
De mate waarin bij gegevensobjecten waarden aanwezig zijn voor een attribuut. +
Defensie zoekt een partner die ruime ervaring heeft met leveren, implementeren, beheren en onderhouden van audio en videoapparatuur bedoeld voor opname en terugkijken en –luisteren inclusief software. +
De RvA wil door het digitaliseren van zijn primaire proces 'Beoordelen en rapporteren auditbevindingen' zijn klanten (extern) en medewerkers (intern) beter en efficiënter bedienen. Hiertoe wordt
op de korte termijn een Audit-rapportagetool, een Normentool en bijbehorend Toegangsbeheer (Identity and Access management) ingericht. +
De voorbereiding en inrichting van de uitvoering moet aantoonbaar voldoen aan inhoudelijke en procedurele eisen. Dit geldt in het algemeen, onafhankelijk van of het om het beheer van gegevens, van processen of van regels gaat.
Bij regelbeheer bestaan de inhoudelijke controles uit review, verificatie en validatie; standaard-onderdelen van elk voortbrengingsproces voor regelbeheer.
In het voortbrengingsproces voor regelbeheer zijn de procedurele eisen aan regelbeheer neergelegd. Het gaat dan bijvoorbeeld om spelregels als: ‘Een regel moet gevalideerd zijn voordat deze in productie kan worden genomen’. Controleerbaar moet zijn of het voortbrengingsproces is ingericht conform deze procedurele eisen en of het proces juist is gevolgd. +
Het aantonen dat degene die zich identificeert ook daadwerkelijk degene is die zich als zodanig voorgeeft: ben je het ook echt? Authenticatie noemt men ook wel verificatie van de identiteit. +
==Objectdefinitie==
Betreft de controle of een gebruiker van een softwarepakket daadwerkelijk is wie hij beweert te zijn.
==Objecttoelichting==
Toegang tot softwarepakketten door gebruikers wordt gereguleerd door het toegangsmechanisme gebruikersidentificatie (zoals een gebruikersaccount) en authenticatie (zoals een wachtwoord). Het softwarepakket stelt specifieke eisen aan de authenticatie van gebruikers. Het authenticatiemechanisme moet voldoen aan vooraf vastgestelde beveiligingseisen. Voor het verlenen van toegang tot softwarepakketten ontvangen gebruikers authenticatie-informatie. De gebruikers behoren hier vertrouwelijk mee om te gaan.
NB Dit object en de set van maatregelen is voor softwarepakketten relevant als de onderliggende infrastructuur geen toereikende set van maatregelen bevat, waarmee aan de control kan worden voldaan.
==Schaalgrootte==
Elke schaalgrootte.
==Voor wie==
Leverancier. +
Partij die op basis van een identificatiemiddel een authenticatieverklaring afgeeft. +
Een factor waarvan is bevestigd dat deze gebonden is aan een bepaalde persoon en die onder een van de drie volgende categorieën valt:
# Op bezit gebaseerde authenticatiefactor: een authenticatiefactor waarvan de betrokkene moet aantonen dat deze in zijn bezit is.
# Op kennis gebaseerde authenticatiefactor: een authenticatiefactor waarvan de betrokkene moet aantonen dat hij ervan kennis draagt.
# Inherente authenticatiefactor: een authenticatiefactor die op een fysiek kenmerk van een natuurlijke persoon is gebaseerd en waarbij de betrokkene moet aantonen dat hij dat fysieke kenmerk bezit. +
Authenticatie namens een persoon zonder diens toestemming. +
Het middel waarmee een persoon zijn of haar identiteit kan aantonen c.q. laten verifiëren. +
Een Verklaring waaruit het bestaan en de juistheid kan worden opgemaakt van een authenticatie die heeft plaatsgevonden in de context van een bepaalde handeling of dienst. +
==Beschrijving==
Het ervoor kunnen zorgen dat personen hun digitale identificatiemiddelen kunnen gebruiken om hun identiteit digitaal op een passend betrouwbaarheidsniveau aan te tonen.
==Voorbeelden==
Voorbeelden van bestaande oplossingen voor authenticatie zijn de authenticatievoorzieningen van DigiD, eHerkenning, iDIN, en de UZI-pas.
==Rationale==
De overheid moet voorwaarden scheppen zodat burgers en bedrijven veilig, persoonlijk en gebruiksvriendelijk digitale diensten af kunnen nemen. Een noodzakelijke voorwaarde daarvoor is zorgen dat ze hun digitale identificatiemiddelen kunnen gebruiken om toegang te krijgen tot publieke diensten en ook tot diensten buiten het publieke domein.
Verdere rationale voor deze generieke functie is te vinden in:
* Wettelijk kaders A, B, C, D, E, G, H, K, L, M (paragraaf 4.1)
* Beleidskader N (paragraaf 4.2)
Maatschappelijke en technische ontwikkelingen die van invloed zijn op deze generieke functie zijn: O, P, Q, R, S, T, U (paragraaf 4.3).
==Implicaties==
<ol style="list-style-type:lower-alpha">
<li>De dienstverlener moet de handelend persoon in staat stellen zijn toegelaten identificatiemiddelen te gebruiken en moet deze ook accepteren.</li>
<li>De dienstverlener moet in staat worden gesteld om het identificatiemiddel te (laten) verifiëren. Deze verificatie kent de volgende stappen: verificatie van de echtheid van het middel, de geldigheid van het middel, het betrouwbaarheidsniveau van het middel en de identiteit van de gebruiker. Dit zijn generiek ook de stappen die bij cryptografie gedaan worden.</li>
<li>Dienstverleners moeten het voor hun dienstverlening benodigde betrouwbaarheidsniveau van authenticatie vaststellen en aangeven/toepassen bij het verlenen van toegang. </li>
<li>Authenticatie gaat gepaard met identificatie; er moeten duidelijke afspraken komen welke gegevens -- onder voorwaarden -- voor identificatie beschikbaar (kunnen) worden gesteld bij een authenticatie.</li>
<li>Authenticatie dient als basis geschikt te zijn en gebruikt te worden voor de overige beoordelingen bij het verlenen van toegang, zoals het beoordelen van de bevoegdheden van de handelend persoon.</li>
</ol>
==Documentatie==
* [[Bestand:GA Identificatie en authenticatie.pdf|GA Identificatie en authenticatie]]
==Kaders==
Deze kaders zijn bepalend voor Identificatie en authenticatie.
* [[Algemene_Wet_Bestuursrecht|Algemene wet bestuursrecht]]
* [[EIDAS_verordening|eIDAS-verordening]]
* [[Wet_Digitale_Overheid|Wet digitale overheid]]
* [[AVG_(Algemene_Verordening_Gegevensbescherming)|Algemene verordening gegevensbescherming]]
''(Bovenstaande opsomming is een beperkte selectie uit de kaders genoemd in het document)''
==Toelichting relaties==
De bestaande GDI-voorzieningen die hieronder zijn opgenomen onder ‘Gerealiseerd door' realiseren delen van de generieke functies van het GA-domein. Deze bestaande voorzieningen kunnen afwijken van de keuzes die voor het GA-domein zijn gemaakt.
Een kwaliteitsattribuut van een informatieobject. Het toont aan dat het informatieobject is wat het beweert te zijn, dat het is gemaakt of verzonden door de persoon of organisatie die beweert het te hebben gemaakt of verzonden en dat het is gemaakt en verzonden op het tijdstip als aangegeven bij het informatieobject. +
De mate waarin de identiteit van de bron van de gegevens aantoonbaar is. +
In een basisregistratie opgenomen gegeven dat bij wettelijk voorschrift als authentiek is aangemerkt +
Een register of systeem, onder de verantwoordelijkheid van een publiekrechtelijk orgaan of particuliere entiteit, dat attributen omtrent een natuurlijke of rechtspersoon bevat en als de primaire bron van die informatie wordt beschouwd of krachtens nationaal recht als authentiek wordt erkend. +
In het BRM-referentieproces is veel nadruk gelegd op borging van de interpretatie wet- en regelgeving conform deze wet- en regelgeving . Hiervoor zijn processtappen, overdrachtsmomenten, reviews, verificaties en validaties van alle bedrijfsregels nodig. Een zwaar proces, met als doel om bedrijfsregels de status van authentieke interpretatie te verschaffen. Uit deze status vloeit voort dat geen andere analyses en interpretaties van wet- en regelgeving nodig of wenselijk zijn.
In het model van de arm en [[Leidraad Regelbeheer Van wet naar loket#De_hand_met_de_vijf_vingers|de hand met de vijf vingers]] komt dit uitgangspunt terug: Acties van de hand zijn gebaseerd op de arm waarmee bedrijfsregels en gegevensdefinities met authentieke interpretatie ten uitvoer worden gebracht. +, In het BRM-referentieproces is veel nadruk gelegd op borging van de interpretatie wet- en regelgeving conform deze wet- en regelgeving. Hiervoor zijn processtappen, overdrachtsmomenten, reviews, verificaties en validaties van alle bedrijfsregels nodig. Een zwaar proces, met als doel om bedrijfsregels de status van authentieke interpretatie te verschaffen. Uit deze status vloeit voort dat geen andere analyses en interpretaties van wet- en regelgeving nodig of wenselijk zijn.
In het model van de arm en [[Leidraad Regelbeheer Van wet naar loket#De hand met de vijf vingers|de hand met de vijf vingers]] komt dit uitgangspunt terug: Acties van de hand zijn gebaseerd op de arm waarmee bedrijfsregels en gegevensdefinities met authentieke interpretatie ten uitvoer worden gebracht. +
Het proces van het toekennen van rechten voor de toegang tot geautomatiseerde functies en/of gegevens in ICT voorzieningen +
==Objectdefinitie==
Betreft het proces voor het toekennen van rechten aan gebruikers.
==Objecttoelichting==
Gekozen is voor het object ‘Autorisatie’, omdat dit object beter aansluit op de toegangsmechanismen (identificatie, authenticatie en autorisatie) dan de BIO-titel ‘Beperking toegang tot informatie’.
Na het identificatie- en authenticatieproces krijgen gebruikers en beheerders (verdere) specifieke toegang tot informatiesystemen voor gebruik respectievelijk beheerdoeleinden. Toegangsbeperking wordt gecreëerd met rollen en toegangsprofielen die voortkomen uit het toegangsbeleid. +
==Objectdefinitie==
Betreft een instandhoudingsproces voor de toegangsverlening tot softwarepakketten.
==Objecttoelichting==
De toegang tot gebruikersfunctionaliteiten worden georganiseerd met autorisatiebeheer en de toewijzing van een gebruikersaccount. Het softwarepakket moet technische invoermogelijkheden bieden om via gebruikersrechten de toegang tot functionaliteiten te kunnen organiseren. Dit houdt in dat toegangsrechten tot functionaliteiten met gebruikersprofielen vanuit autorisatiebeheer toegekend dan wel ingetrokken kunnen worden.
==Schaalgrootte==
Groot.
==Voor wie==
Klant en leverancier. +
==Objectdefinitie==
Betreft een vastgelegde manier van handelen voor het toekennen van toegangsrechten.
==Objecttoelichting==
De [[BIO (Baseline Informatiebeveiliging Overheid)|Baseline Informatiebeveiliging Overheid (BIO)]]-control 9.2.6 ‘Toegangsrechten intrekken of aanpassen’ stelt eisen aan een autorisatieproces, dat bestaat uit enkele sub-processen zoals: toekennen (of verlenen), verwerken, intrekken, blokkeren, archiveren en controleren. Dit autorisatieproces zorgt ervoor dat autorisaties gestructureerd plaatsvinden. Deze sub-processen zijn gerelateerd aan de fasen: instroom, doorstroom en uitstroom en worden verder beschreven in [[BIO Thema Toegangsbeveiliging/Een scenario voor Toegangsbeveiliging|Een scenario voor Toegangsbeveiliging]]. +
Autorisatieproces onwerkbaar, hoge beheerlast en complexiteit door te hoge granulariteit. +
==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]]