Eigenschap:Beschrijving

Uit NORA Online
Ga naar: navigatie, zoeken
Kennismodel
:
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
:
Geïmporteerd uit
:

Klik op de button om een nieuwe eigenschap te maken:


Showing 250 pages using this property.
&
Sessie van de [[architectuur-community Toezicht Inspectie Opsporing Handhaving (@TIOH)]].  +
'
'Mastering Alliances' published, a whitepaper on cross-organizational collaboration  +
(
Het -binnen de mogelijkheden van de overheid- op de wensen van burgers en bedrijven aangepast houden van de overheidsdiensten. (Digitale) Diensten ontstaan niet zomaar. Ze worden bedacht, ontworpen, gebouwd / gerealiseerd en daarna uitgevoerd, aangepast / verbeterd en tenslotte een keer gestopt c.q. ontmanteld. De [[NORA online|Nederlandse Overheid Referentie Architectuur]] is ons Nationale afsprakenstelsel over hoe de dienstverlening van de overheid is geregeld: nu en in de toekomst. De NORA geeft inzicht in de samenhang van “alles” wat voor de dienstverlening van de overheid nodig is: wet- en regelgeving, processen, mensen, gegevens, systemen e.d. De NORA bevat ook richtinggevende principes en handvatten voor het ontwerp en het aanpassen van de dienstverlening van de overheid. Die diensten lijken in 1e instantie alleen gericht op burgers in Nederland, maar het gaat ook om diensten voor Nederlanders in het Buitenland en voor Buitenlanders die met Nederland te maken hebben. Ook zijn er specifieke ontwerpen voor Europese cross-border-services (diensten binnen de Europese Unie). Het Kabinet heeft op 2 juli 2008 de afspraken over dienstverlening in de NORA vastgesteld als norm voor alle overheden, zie [https://zoek.officielebekendmakingen.nl/kst-26643-128.html De NORA als norm (Kamerstuk)]. De NORA is gepubliceerd op [[NORA online|www.noraonline.nl]] onder [[NORA licentie|Creative Commons licentie]]. Bestuurders, beleidsmedewerkers en projectmanagers kunnen de NORA daardoor gebruiken om te “Navigeren Op Relevante Afspraken:” om veranderingen door te voeren, waarbij rekening wordt gehouden met bestaande afspraken. Naast de NORA is nog een grote [[NORA Familie|Familie]] van andere architecturen beschikbaar voor het ontwerp van diensten binnen specifieke domeinen en ketens. Het her-ontwerp van een dienst kan vanuit 2 impulsen worden geïnitieerd: # Als gevolg van het herstel van (structurele) fouten, zie [[Bieden van correctiemogelijkheden]]; # Vanuit het sturen op kwaliteit of innovatieve verbetering, zie [[Sturen op (verbetering van) de kwaliteit van dienstverlening]]; '''NB.''' Verzoeken van burgers of bedrijven om een dienst aan te passen of nieuwe diensten aan te bieden, worden volgens het Dienstverleningsconcept ingebracht via de 2e impuls, waarin de overheid een pro-actieve rol zal moeten spelen, e.e.a. volgens de stakeholders- en community-gedachte van de NORA en ook wat tegenwoordig via design-thinking wordt gepropageerd. Het (Her)Ontwerpen van een dienst zal leiden tot een aangepast aanbod van diensten van de overheid, zie [[Bieden van een overzicht van de diensten van de overheid]] en tot het aanpassen van (de afspraken over) de bedrijfsvoering van de overheidsorganisaties die betrokken zijn bij het uitvoeren c.q. leveren van die dienst, zie [[Diensten leveren volgens de afspraken]]. Aanvullend op het (Her)Ontwerpen van een dienst, zal de overheid nog moeten overgaan tot het (laten) “Realiseren van een dienst”: het bouwen en implementeren van de dienst, in combinatie met Projectmanagement e.d. En pas daarna kan (weer) sprake zijn van [[Diensten leveren volgens de afspraken]].  
==Definitie== De zorg en verantwoordelijkheid hebben voor het vastleggen en actueel houden van gegevens van alle softwareconfiguratie-items. ==Toelichting== Configuratiebeheer is het beheerproces dat onder andere verantwoordelijk is voor het registreren van de softwareconfiguratie-items (SCI’s) en hun specifieke kenmerken, zodat de SCI’s altijd uniek te identificeren zijn en de volledigheid en de juistheid van de in de Configuration Management Database (CMDB) opgenomen items gewaarborgd is. Configuratiemanagement geeft inzicht in de status van de verschillende SCI’s die binnen het ontwikkeltraject worden gebruikt en geeft de relaties weer tussen deze SCI’s. Hierdoor wordt duidelijk welke gevolgen aanpassingen van het ene SCI heeft voor andere SCI’s.  +
(Ver)sterkte authenticatie. Bij het elektronisch communiceren vanuit een niet vertrouwde omgeving (bijvoorbeeld vanuit de externe zone) kan het noodzakelijk zijn extra zekerheden (boven het basisniveau beveiliging) te verkrijgen over de identiteit van derden. De hiervoor te treffen maatregelen worden afgestemd met het in dit gevoerde beleid en de beschikbare generieke oplossingen.  +
1
10 lessen van datagedreven werken bij EZK en LNV  +
Met een 14+netnummer krijgen gemeenten een herkenbare telefonische ingang. Een 14+netnummer begint met de cijfers 14 en eindigt op het netnummer van de gemeente (zoals 14 010 of 14 0115). Door te bellen met het 14+netnummer komt de burger uit bij zijn gemeente.  +
2
22 januari Linked Data en Knowledge Graphs in Beeld en Geluid  +
4
Verslag en presentaties Symposium Sturen op gegevens beschikbaar  +
7
7 November 2018 Congres Linked Data is FAIR voor Iedereen  +
@
Sessie van de [[architectuur-community Toezicht Inspectie Opsporing Handhaving (@TIOH)]].  +
Sessie van de [[architectuur-community Toezicht Inspectie Opsporing Handhaving (@TIOH)]].  +
Tweede sessie van de [[architectuur-community Toezicht Inspectie Opsporing Handhaving (@TIOH)]]. Op het programma in ieder geval een kijkje in de keuken van DNB Toezicht, met oog voor de digitale ambitie en voorbeelden van innovatief gebruik van data (science) in het toezicht. Andere onderwerpen kunnen nog worden aangemeld, zeker als ze hier bij aansluiten. NB: De [[architectuur-community Toezicht Inspectie Opsporing Handhaving (@TIOH)|community]] heeft een [https://noracommunity.pleio.nl/groups/profile/57979282/tioh besloten Pleio-groep] waarop documenten en verslagen gedeeld worden. Alleen mensen die beschikken over een mailadres van een publieke organisatie in de domeinen Toezicht Inspectie Opsporing en/of Handhaving mogen hiervan lid worden.  +
Sessie van de [[architectuur-community Toezicht Inspectie Opsporing Handhaving (@TIOH)]].  +
Derde sessie van de [[architectuur-community Toezicht Inspectie Opsporing Handhaving (@TIOH)]]. DEZE SESSIE IS AFGELAST I.V.M. CORONA NB: De [[architectuur-community Toezicht Inspectie Opsporing Handhaving (@TIOH)|community]] heeft een [https://noracommunity.pleio.nl/groups/profile/57979282/tioh besloten Pleio-groep] waarop documenten en verslagen gedeeld worden. Alleen mensen die beschikken over een mailadres van een publieke organisatie in de domeinen Toezicht Inspectie Opsporing en/of Handhaving mogen hiervan lid worden.  +
Vierde sessie van de [[architectuur-community Toezicht Inspectie Opsporing Handhaving (@TIOH)]].  +
Derde sessie van de [[architectuur-community Toezicht Inspectie Opsporing Handhaving (@TIOH)]]. Onderwerpen kunnen nog worden aangemeld. NB: De [[architectuur-community Toezicht Inspectie Opsporing Handhaving (@TIOH)|community]] heeft een [https://noracommunity.pleio.nl/groups/profile/57979282/tioh besloten Pleio-groep] waarop documenten en verslagen gedeeld worden. Alleen mensen die beschikken over een mailadres van een publieke organisatie in de domeinen Toezicht Inspectie Opsporing en/of Handhaving mogen hiervan lid worden.  +
Sessie van de [[architectuur-community Toezicht Inspectie Opsporing Handhaving (@TIOH)]].  +
A
ADMS (Asset Description Metadata Schema) is een verbindende standaard die in andere standaarden wordt toegepast waaronder o.a. DCAT (ADMS is het toepassingsprofiel van DCAT). ADMS is een gestandaardiseerd metadata woordenboek om beheerders van standaarden te laten documenteren waar de standaarden over gaan en waar ze kunnen worden gevonden op het web. Oftewel, DCAT beschrijft de datasets en ADMS beschrijft de standaarden en waar ze te vinden zijn. Hiermee zijn deze standaarden een aanvulling op elkaar.  +
De AES-standaard is een versleutelingstechniek voor de bescherming van de vertrouwelijkheid van opgeslagen en verzonden data en is de vervanger van de verouderde DES standaard. AES wordt zowel binnen Nederland als wereldwijd zeer veel en op, op zeer veel verschillende wijzen gebruikt. Voorbeelden van het gebruik zijn: # In programma's zoals WinRAR, WinZip, PowerArchiver, e.d. wordt AES als encryptie aangeboden. # AES wordt toegepast voor beveiliging (WPA2) in draadloze netwerken (Wifi), zie IEEE 802.11i. # AES wordt toegepast voor het versleutelen van gegevens voor verzending over het internet, https verkeer etc. # In hardware voor netwerken wordt veelvuldig gebruikt gemaakt van AES.  +, De AES-standaard is een versleutelingstechniek voor de bescherming van de vertrouwelijkheid van opgeslagen en verzonden data en is de vervanger van de verouderde DES standaard.  +
De AES-standaard is een versleutelingstechniek voor de bescherming van de vertrouwelijkheid van opgeslagen en verzonden data en is de vervanger van de verouderde DES standaard.  +
Verslag eerste bijeenkomst API-community gepubliceerd  +
[[Afbeelding:Presentatie API's Youetta 2.jpg|thumb|rigth|350px|Presentatie API's en de samenwerkende overheid|alt=Presentatie in vergaderzaal over het onderwerp API's en de samenwerkende overheid”|link=API’s en de samenwerkende overheid]] Youetta de Jager (ICTU, senior consultant) neemt de deelnemers mee op reis met de API-strategie van de overheid. Maar wat is eigenlijk zo’n API? Wat kan een API en wat weten we er al over? NORA ondersteunt de community in het ontwikkelen van een strategie en het gebruik van API’s. Waar is behoefte aan bij dit thema? Door [[API|API’s]] (Application Programming Interfaces) kunnen computerprogramma’s communiceren met een ander programma. Het zijn programmeerbare blokjes waarmee een dienst slim samengesteld kan worden. API’s bieden mogelijkheden voor privacy-by-design. Er zijn bijvoorbeeld API’s die alleen ja/nee antwoorden geven. Daarmee kan het gebruik van Self Sovereign Identity worden gerealiseerd. “Tot nu toe is er veel technisch werk verricht. Er liggen bijvoorbeeld standaarden voor API’s”, vertelt Youetta. “Dar gaat nog vooral om de vraag: welke data zitten erin? Als gebruiker wil je weten hoe robuust zo’n dienst gebouwd is. Bijvoorbeeld: deze API is 24/7 beschikbaar. Of: deze API is geschikt voor meer dan 10000 gebruikers.” Ze heeft een [[media:Mindmap API's en de samenwerkende overheid.pdf|Mindmap (PDF, 80 kB)]] gemaakt over API’s en nodigt iedereen uit: “Werk mee, denk mee, vul aan.” ===Waar hebben deelnemers behoefte aan?=== * “Help ons standaarden beter te begrijpen.” * “Vindbaar maken en bieden van standaarden.” * “API’s kunnen plotten op alle architectuurlagen. Structuren.” * “Hoe maken we de transitie naar op API’s gebaseerde diensten?” * “Omschrijvingen van API’s vanuit de behoefte van de eindgebruiker en eisen aan de dienst.” * “Behoefte aan organisatie die API’s publiceert en beheert: een soort API Management Platform.” * “Gemeenten werken samen in de Common Ground. We zijn al met API’s bezig. Eigenlijk wil je dat ook landelijk als overheid. NORA kan een rol hebben in het bij elkaar brengen van die ontwikkelingen.“ ==Voorbeelden== Er zijn voorbeelden beschikbaar, vertelt Youetta. “Uber heeft architectuur met API’s, ook de Belastingdienst heeft voorbeelden. Er zijn mogelijkheden kennis uit te wisselen.” In NORA staan al namen van organisaties die met API’s werken, met contactpersonen erbij. “Wat verwacht je van NORA?”, vraagt Youetta. “Focus op het gemeenschappelijke niveau. Domeinspecifiek hoort bij de domeinreferentie architecturen.” Youetta vertelt wat er al gebeurt: “We maken een verbinding tussen het Kennisplatform API’s en de NORA. Ontwerpvragen als ‘Hoe ontwerp ik een API?’ pakt developer.overheid.nl op. Op dat platform worden ook de API’s gepubliceerd.” Het gedachtengoed van API’s wordt verwerkt in de NORA in de themapagina [[API]]. <div class="inspring pijl">[[media:Mindmap API's en de samenwerkende overheid.pdf|Mindmap API's en de samenwerkende overheid (PDF, 80 kB)]]</div> [[Afbeelding:Presentatie API's Youetta 1.jpg|thumb|none|350px|Presentatie API's en de samenwerkende overheid|alt=Presentatie in vergaderzaal over het onderwerp API's en de samenwerkende overheid”|link=API’s en de samenwerkende overheid]]  
ASN is een standaard manier voor het beschrijven van data die binnen een netwerk verzonden of ontvangen worden. Abstract syntax notation one (ASN.1). ASN.1 wordt veel gebruikt voor het beschrijven van X.509 certificaten en de toepassing ervan. Voorbeeld van een toepassing is RSA public key voor beveiliging van het transactieverkeer in de elektronische handel. Hiernaast beschrijft deze standaard rollen en structuren om data in telecommunicatie en computer netwerken te representeren, te coderen, over te brengen en te decoderen. Hierdoor is het mogelijk grote hoeveelheden gegevens geautomatiseerd te valideren aan de hand van specificaties met behulp van software tools.  +, Abstract syntax notation one (ASN.1) wordt veel gebruikt voor het beschrijven van X.509 certificaten en toepassing daarvan. Voorbeeld van een toepassing is RSA public key voor beveiliging van het transactieverkeer in de elektronische handel. Hiernaast deze standaard een syntax om data in telecommunicatie en computer netwerken te representeren, te coderen, over te brengen en te decoderen.  +
Abstract syntax notation one (ASN.1) wordt veel gebruikt voor het beschrijven van X.509 certificaten en toepassing daarvan. Voorbeeld van een toepassing is RSA public key voor beveiliging van het transactieverkeer in de elektronische handel. Hiernaast deze standaard een syntax om data in telecommunicatie en computer netwerken te representeren, te coderen, over te brengen en te decoderen.  +
Per 25 mei 2018 is de Algemene Verordening Gegevensbescherming (AVG) ([https://autoriteitpersoonsgegevens.nl/sites/default/files/atoms/files/verordening_2016_-_679_definitief.pdf pdf]) van toepassing. Dat betekent dat er vanaf die datum nog maar één privacywet geldt in de hele Europese Unie (EU). De [[Wet Bescherming Persoonsgegevens]] is daarmee komen te vervallen. Nederland heeft de Europese AVG verwerkt in de Nederlandse [[Uitvoeringswet AVG]]. Buiten de overheidssector spreekt men ook in Nederland vaak van de GDPR (voor General Data Protection Regulation) i.p.v. AVG, hiermee wordt dezelfde verordening aangeduid.  +
Het aspect 'aanpassingsvermogen' staat voor het tijdig en adequaat reageren op onverwachte gebeurtenissen; ofwel juist reageren. #Regels zijn op verschillende plaatsen gemodelleerd en daardoor kost het aanpassen relatief veel doorlooptijd. Architectuurprincipe ARB-04: Implementatieonafhankelijk Onder techniek-onafhankelijk modelleren verstaan we dat regels los van de IT–technologie gemodelleerd dient te worden. Het IT-landschap is gestandaardiseerd d.m.v. een applicatie-architectuur waarbij aansluitvoorwaarden en Quality of Service vooraf zijn geformuleerd. '''Hoe bevordert techniek-onafhankelijk modelleren de wendbaarheid?''' Het bouwblok ‘aanpassingsvermogen’ verstevigt de wendbaarheid doordat regels en regelsets los van de technische implementatie worden gemodelleerd. Daardoor is er de vrijheid gecreëerd om de technische architectuur van de oplossing aan te passen over het verloop van tijd zonder de regels daarbij aan te passen: het vergroten van het aanpassingsvermogen. Architectuurprincipe ARB-02: Hergebruik Als de wetgeving wordt aangepast, dient de (bron) van de wet opnieuw geïnterpreteerd te worden en de impact voor de omgeving binnen de uitvoeringsorganisatie te worden bepaald. De wijzigingen worden met behulp van een wijzigingsradar gemonitord en vastgelegd. Indien de kennis van de interpretatie van de wet is vastgelegd in een conceptueel model, dient het model tegen het licht van de nieuwe wetgeving te worden gehouden en zo nodig te worden aangepast. Een impactanalyse kan plaatsvinden op basis van de verschillen tussen het huidige en het nieuwe conceptueel model: in de impactanalyse komen de consequentie(s) van de gewijzigde normen voor de verschillende vingers terug; zie [[Leidraad Regelbeheer Van wet naar loket#De hand met de vijf vingers|de hand met de vijf vingers]]. De geïmplementeerde regels/regelsets voor verschillende toepassingen dienen los van elkaar te worden geïmplementeerd, zodat conform Service-Oriented-Architecture–standaarden regels/regelsets aangeboden kunnen worden aan verschillende afnemers.  
==Doel== Zorgdragen dat de overheid gegevens kan uitwisselen tussen de eigen overheidsorganisaties onderling en met personen en publieke en private organisaties buiten de overheid. ==Scope== De overheid wisselt gegevens uit met burgers, bedrijven en instellingen, zowel nationaal als internationaal. Digitale aansluiting helpt, ondersteunt, de overheid bij de diversiteit aan aansluitingen die daarvoor worden gebruikt. Daardoor kunnen zowel de overheid als de partijen waarmee zij gegevens uitwisselt, zich richten op de gegevens i.p.v. op de (technische belemmeringen van) het aansluiten.<br /> Wij zien verschillende ontwikkelingen op dit moment plaatsvinden m.b.t. het digitaal aansluiten van en met de overheid. Uitwisselstandaarden worden breed ingezet, en met name internationaal zijn nog de nodige ontwikkelingen gaande. Het toepassen van (RESTful) API’s heeft een vlucht genomen. Daarnaast zien wij een belangrijke ontwikkelingen als SSI opkomen. Uitwisselstandaarden: Instituten binnen de overheid hebben te maken met diverse digitale contacten zowel binnen als buiten de overheid, nationaal en internationaal. Het gaat hier om verschillende uitwissel standaarden, denk aan Digikoppeling, eDelivery. Uitwisselstandaarden waarvan de toepassing verplicht is vanuit nationale wetgeving of internationale verordeningen of anderzijds brede toepassingen kennen in de markt. De verschillende standaarden geven ieder haar eigen beheerlast en daarbij behorende kosten. Door deze vanuit digitale aansluiting als onderdeel van de GDI aan te bieden wordt het voor de betrokken instituten eenvoudiger om aan te sluiten. Voor de afnemende partijen is het handig dat zij niet met iedere aangesloten (overheids-)instantie apart een aansluiting moeten inregelen. API: Bij toepassen van API’s spelen hele andere zaken. Een API is een hele eenvoudige interface, zeker t.o.v. de eerdergenoemde uitwisselstandaarden, met vele toepassingen. Zonder een strategie, een set van afspraken en ondersteuning zal dit tot een wildgroei van API’s leiden. Figuur API Ecosysteem Het is van belang dat er voor API’s binnen de GDI, een overheidsbrede omgeving komt die leveranciers en afnemers ondersteunt bij het ontwikkelen en gebruik van de overheids API’s. Hierdoor wordt het bijvoorbeeld voor ontwikkelaars eenvoudiger om de definities van overheids-API’s te vinden en daarop applicaties te bouwen. Bestaande API’s kunnen worden hergebruikt en indien nodig worden gebruikt als basis voor nieuwe API’s. Bij het toepassen van API’s voor het uitwisselen van gevoelige data, zoals persoonsgegevens, is het van belang dat er een éénduidige beveiligingsstrategie wordt opgesteld en daaraan, vanuit digitale aansluiting, ondersteuning wordt gegeven. SSI Een andere ontwikkeling die de komende jaren zijn toepassing binnen en buiten de overheid gaat vinden is Self Sovereign Identity (SSI). Hierbij ligt de nadruk niet langer meer op het halen van data uit een bron maar meer op de herleidbaarheid van de bron van de data. Deze bron zou ook buiten de overheid kunnen liggen. Een belangrijk onderdeel van de SSI infrastructuur is de zogenaamde Identity Trust Fabric (ITF). De laag waarin het publieke deel van digitale identiteiten worden opgeslagen, is in Figuur 3 weergegeven als ‘Layer One: DID Networks’. Tegen deze laag wordt binnen SSI de digitale identiteit van personen, systemen, bronnen, documenten, etc. etc. gecontroleerd. Figuur Architectuurlagen Self Sovereign Identity Met een ITF die openbaar, zowel publiek als privaat, beschikbaar is wordt het ontwikkelen van breed inzetbare SSI applicaties eenvoudiger. Digitale toegang zou de ontwikkeling en ondersteuning van een dergelijke ITF op zich moeten nemen. Implicaties Digitale aansluiting ondersteunt bij het toepassen van de diverse uitwisselstandaarden waar de overheid mee wordt geconfronteerd. Dit vereenvoudigt het werk van de betreffende instituten en maakt het ook voor de afnemers eenvoudiger om met de overheid uit te wisselen. Verder ondersteunt Digitale aansluiting de uitrol van API’s binnen en buiten de overheid. Door het leveren van overheidsbrede ondersteunende diensten zal de ontwikkeling en toepassing van overheids API’s eenvoudiger worden en daardoor versnellen. Denk hierbij het verder uitbouwen van het overheids API register tot een volledige Overheidsbrede API Store en het leveren van een API gateway voor de overheid. Om de ontwikkeling van SSI gerelateerde applicaties te ondersteunen levert digitale aansluiting een Identity Trust Fabric in een publiek private samenwerking om een brede toepassing van deze SSI applicaties mogelijk te maken. Om de aansluiting veilig te laten verlopen zijn certificaten vereist. Uitgifte van en toezicht op certificaten moet goed geregeld zijn. Standaarden: * Digikoppeling * Oauth * OpenID * JRC * ASI² Voorzieningen: * eDelivery * OpenPEPPOL * SDG * Digipoort * X-Road * Common Ground * NLX * uNLock * Hyperledger Indy * Hyperledger Aries ==Voorbeelden== Nog te bepalen. ==Status== Medio 2020 is via een pressure-cooker versnelling aangebracht in de oplevering van GO. Een vijftal werkgroepen heeft in 2 maanden tijd uitwerking gegeven aan: * ‘Why’ van de GDI inclusief bijbehorende visual, * uitgangspunten voor het vastleggen van generieke functies (capability’s), * visies voor de domeinen Interactie, Gegevensuitwisseling, Identificatie en Authenticatie (Toegang), Machtigen en Infrastructuur. Resultaten van de pressure cooker zijn overgedragen om mee te nemen in de Gemeenschappelijke Overheidsarchitectuur (GO). GO brengt samenhang aan, verwijdert dubbelingen en verdiept visies zodanig dat besluitvorming in de PL en (naar beoordeling door PL) in het OBDO mogelijk is. Voor het domein Interactie geldt dat bovendien nog afstemming met de beleidsomgeving moet plaatsvinden. Gegevensuitwisseling heeft nu nog een bredere scope dan GDI en zal daarom binnen de GDI-context in samenhang met andere domeinen uitgewerkt worden. ==Documentatie== De visie uit de pressure cooker GO t.a.v. Infrastructuur is opgenomen in het document van de werkgroep: [[media:GO_Pressure_Cooker_Infrastructuur.pdf|GO_Pressure_Cooker_Infrastructuur.pdf (PDF, 1,79 MB)]]. ==Naamgeving== Het visie document uit de pressure cooker gebruikt voor deze capability de naam '''Digitale aansluiting'''  
Circulaire van de Minister-President, Aanwijzingen waarbij de wetgevingstechniek en de wetgevingskwaliteit centraal staan. Hoofdstuk 5, paragraaf 8 behandelt de Informatievoorziening en Gegevensverwerking. Bevat de aanwijzigingen: Aanwijzing 5.31. Aansluiten bij definities basisregistraties Indien voor de uitvoering van een regeling gegevens van burgers, bedrijven of instellingen nodig zijn, wordt voor de omschrijving van de daaraan ten grondslag liggende begrippen zoveel mogelijk verwezen naar of aangesloten bij de definities uit de wetten inzake de basisregistraties Aanwijzing 5.32. Informatieparagraaf in toelichting Indien voor de uitvoering van een regeling de beschikbaarheid of uitwisseling van informatie tussen overheidsorganisaties van betekenis is, wordt in een aparte informatieparagraaf in de toelichting aandacht besteed aan de wijze waarop de informatievoorziening organisatorisch en technisch is ingericht. Aanwijzing 5.33. Verwerking van persoonsgegevens Bij het opnemen in een regeling van bepalingen over de verwerking van persoonsgegevens bevat de regeling een welbepaalde en uitdrukkelijke omschrijving van de doeleinden van de gegevensverwerking en bevat de toelichting een expliciete afweging van de belangen van verantwoordelijken en betrokkenen in relatie tot die doeleinden. Aanwijzing 5.34. Structurele basis verstrekking persoonsgegevens Indien het noodzakelijk is dat op structurele basis wordt voorzien in de onderlinge verstrekking van persoonsgegevens tussen bestuursorganen of toezichthouders, terwijl geldende geheimhoudingsbepalingen daaraan in de weg staan, wordt op het niveau van de formele wet voorzien in een uitdrukkelijke regeling van de gegevensverstrekking, met inbegrip van de vaststelling van het doel van de gegevensverstrekking.  +
Abonnementservice die een automatisch bericht afgeeft wanneer er iets verandert in de registratie van voor de afnemer van belang zijnde WOZobjecten. Alle wijzigingen worden gebeurtenisgedreven aangeleverd. Een afnemer kan zich abonneren op alle WOZ-objecten of op de gegevens van één of meer waterschappen. Abonnementservice WOZ loopt via Digilevering.  +
De mate waarin gegevens recent genoeg zijn.  +
Geeft persoonsgegevens van alle op een adres ingeschreven personen. Bevragen kan met een adres als ingang of met persoonsgegevens als ingang.  +
Verstrekking van gegevens van een bepaalde ingeschrevene naar aanleiding van een door afnemer gestelde vraag.  +
Elektronische handtekeningen worden gebruikt voor het ondertekenen van digitale berichten. Een elektronische handtekening is voor de ontvanger het bewijs dat een elektronisch bericht inderdaad afkomstig is van de ondertekenaar en dat deze de inhoud van het bericht onderschrijft. Voor het ondertekenen van berichten die een hoger niveau van betrouwbaarheid vereisen, kunnen geavanceerde elektronische handtekeningen of gekwalificeerde elektronische handtekeningen worden gebruikt. De AdES Baseline Profiles zorgen ervoor dat een geavanceerde/gekwalificeerde elektronische handtekening voor de ondertekenaar en ontvanger uitwisselbaar is door eisen te stellen aan de minimale set aan informatie die wordt uitgewisseld. De AdES Baseline Profiles beschrijven de minimale set aan gegevens die uitgewisseld moeten worden om aan de eisen van een geavanceerde elektronische handtekening te voldoen. Een geavanceerde elektronische handtekening voldoet aan vier eisen: # De handtekening is op unieke wijze aan de ondertekenaar verbonden; # De handtekening maakt het mogelijk de ondertekenaar te identificeren; # De handtekening komt tot stand met middelen die de ondertekenaar onder zijn uitsluitende controle kan houden; # De handtekening is op zodanige wijze aan het elektronisch bestand waarop zij betrekking heeft verbonden, dat elke wijziging van de gegevens, na ondertekening, kan worden opgespoord.  +, Een digitale handtekening geeft de ontvanger van een digitaal document of bericht zekerheid dat het afkomstig is van de ondertekenaar en dat deze de inhoud van het bericht onderschrijft. De Advanced Electronic Signature (AdES) standaard voorziet in het digitaal tekenen van documenten met een geavanceerde of gekwalificeerde digitale handtekening.<br /> <br /> Als een verzender een document tekent met een digitale (AdES) handtekening, dan moet de ontvanger die ook kunnen verifiëren.  Dat wordt soms bemoeilijkt doordat AdES verschillende configuraties toestaat, waardoor een verzender opties kan gebruiken die de ontvanger niet kan verifiëren.  De AdES Baseline Profiles voorzien in afspraken zodat verzender en ontvanger dezelfde AdES basisconfiguratie gebruiken.  +
Een digitale handtekening geeft de ontvanger van een digitaal document of bericht zekerheid dat het afkomstig is van de ondertekenaar en dat deze de inhoud van het bericht onderschrijft. De Advanced Electronic Signature (AdES) standaard voorziet in het digitaal tekenen van documenten met een geavanceerde of gekwalificeerde digitale handtekening.<br /> <br /> Als een verzender een document tekent met een digitale (AdES) handtekening, dan moet de ontvanger die ook kunnen verifiëren.  Dat wordt soms bemoeilijkt doordat AdES verschillende configuraties toestaat, waardoor een verzender opties kan gebruiken die de ontvanger niet kan verifiëren.  De AdES Baseline Profiles voorzien in afspraken zodat verzender en ontvanger dezelfde AdES basisconfiguratie gebruiken.  +
Administratieve hygiëne is noodzakelijk om het opstellen, reviewen en valideren van bedrijfsregels met voldoende professionaliteit te kunnen uitvoeren. In dit opzicht is het beheren van bedrijfsregels vergelijkbaar met het beheer van specificaties. Het versioneren van bedrijfsregels of regelsets is een invulling van dit aspect. Daarnaast moeten juridische en gegevensbronnen onder versiebeheer staan om traceerbaarheidsrelaties zuiver te kunnen leggen. Ook het zorgvuldig verzamelen en beheren van alle secundaire documentatie is een noodzakelijk kwaad. Het architectuurprincipe ARB-03 - Traceerbaar kan niet zonder dit aspect worden ingevuld.  +
Eenmalige of maandelijkse levering met adresgegevens van een door de gebruiker gespecificeerde set bedrijven. Filtering is mogelijk op diverse criteria, waaronder gemeente, postcode, SBIcode. Het data-formaat van dit product is niet geheel handelsregister-compliant (afwijkende notatie BAG adressen) en levert geen BAG-IDs. Het product wordt naar verwachting uitgefaseerd.  +
De persoon of organisatie die een dienst in ontvangst neemt. Dit kan een burger, een (medewerker van een) bedrijf of instelling dan wel een collega binnen de eigen of een andere organisatie zijn.  +
Overeenkomst binnen de overheid of een deel (domein of sector) over de inrichting en het toepassen van bepaalde voorzieningen of standaarden.  +
''''Reinvent Government,'''' dagen Steven Gort en Bas Kaptijn (ICTU, Discipl) ons uit. [[Afbeelding:Presentatie Bas en Steven NORA Gebruikersdag 19 november 2019 (2).jpg|thumb|left|350px|Discipl - a global Society Architecture|alt=Presentatie in vergaderzaal Discipl - a global Society Architecture”|link=Discipl - a global Society Architecture]] [[Afbeelding:Impressie sessie Society Architecture.jpg|thumb|right|500px|Impressie van oude en nieuwe werkwijze overheidsdienstverlening|alt=Twee tekeningen onder elkaar met als titels Reinventing Government en Reinvented Government. Beide platen hebben in het midden een viertal poppetjes, zo te zien een gezin, waarbij van een van de volwassenen een denkwolkje omhoog gaat met daarin datzelfde gezin in een huis in Ommen. Die tekstwolk heeft als titel NEED. Beide platen hebben links een weegschaal in een kader met de tekst Wetten, Regels, Subsidies, Toeslag. In de eerste plaat, het heden, gaat hierheen een blauwe pijl vanuit de familie met als tekst 'Ik zoek uit.' Vanuit het kader gaat vervolgens weer een blauwe pijl met de tekst ik vertaal naar twee officiële overheidsdiensten: "Sociale huurwoning" en "huurtoeslag." Vanuit het gezin komt een blauwe pijl naar deze twee diensten met de tekst 'ik vraag aan', die doorloopt naar een groepje gebouwen met verschillende loketten, waaronder staat Uitvoerende organisaties. Vanuit die organisaties loopt een tweezijdige paarse pijl met de tekst 'zij registreren, zij checken' naar een kader met een aantal gekleurde silo's er in en de tekst Datasilo's. Deze silo's zijn met een laatste blauwe pijl vanuit het gezin verbonden met de tekst 'ik vraag op, deel, verzamel, actualiseer. De tweede tekening, reinvented government, bevat een aantal dezelfde elementen: het gezin, het kader met wetten en regels en de uitvoerende organisaties. De laatste zijn echter getransformeerd van verschillend gekleurde loketten in een loket voor mensen met Welkom er boven en een voor IoT met antennes op het dak. De grootste toevoeging in deze tekening is een mobiele telefoon met als tekst 'My public-private servant app.' Vanaf het gezin gaat een blauwe pijl naar de app, met als tekst 'ik uit mijn behoefte.' Vervolgens gaan vanuit de app een aantal pijlen lopen: Naar de datasilo's, die inmiddels meer verspreid staan, met de tekst "app checkt situatie." Naar de het kader met wetten met de tekst "App checkt mogelijkheden." naar het gezin met de tekst "App legt opties voor." En naar het IoT loket met "App vraagt aan." Voor die laatste pijl is er echter nog de pijl van beide volwassen gezinsleden naar de app: wij besluiten.]] Als de bestaande organisaties, silo's en administratieve werkelijkheid er niet zouden zijn en je opnieuw zou beginnen, hoe zou je dan vandaag of morgen publieke dienstverlening inrichten? Voor hen is dit duidelijk: de mens en de behoeften van die mens moeten centraal staan en de rest organiseer je flexibel genoeg om te veranderen als onze behoeften als burgers en samenleving veranderen. Gegevens die nu in silo's van overheden zitten moeten onder regie van de burger komen, bereikbaar vanuit je eigen devices en deelbaar als dat voor jou nuttig is. Wetten, regels, subsidies en toeslagen dienen de mens en moeten dus begrijpelijk worden in je eigen unieke context. Daar kan de techniek een handje bij helpen, als we wetten en regels als open linked data beschikbaar stellen: een persoonlijke app kan jouw gegevens en de wettelijke mogelijkheden voor je uitzoeken en wat in jouw situatie relevant is in heldere taal uitleggen. In hun visie komt de techniek niet in de plaats van contact tussen burger en overheid, maar maakt dit contact juist menselijker: je uit je behoeften in je eigen woorden en zonder dat je zelf hoeft uit te zoeken bij welke overheidsorganisatie je moet zijn: ‘''Ik wil een betaalbaar huis''’ in plaats van ‘''ik schrijf mij in voor een sociale huurwoning bij deze woningcorporatie''’ & ‘''ik vraag huurtoeslag aan bij de belastingdienst.''’ Doordat de techniek veel wetsinterpretatie en rondschuiven met gegevens uit handen neemt heeft de ambtenaar de tijd om echt contact te leggen met de mensen die dat nodig hebben, terwijl het gros van de diensten automatisch verstrekt kan worden. Door de dialoog tussen burger en overheid te versterken en te faciliteren groeit het wederzijds vertrouwen. En de flexibiliteit en ruimte die juristen oorspronkelijk hebben ingebouwd in veel wetten komt weer beschikbaar: niet 'computer says no' maar samen met de burger naar oplossingen zoeken. Hoe willen ze de bestaande organisatie veranderen die hun visie in de weg staat? We lopen als overheid en samenleving tegen bestaande muren op, maar aangezien we die zelf hebben neergezet kunnen we ze ook zelf weer weghalen. Een concrete toepassing van deze visie waar het discipl-team al ervaring mee heeft opgedaan is het opvragen van waardepapieren bij je gemeente, oftewel verifiable credentials. Hierbij hebben ze gelijk rekening gehouden met de W3C standaard en EIDAS, zodat het in de toekomst mogelijk moet zijn om een uittreksel uit het geboorteregister te krijgen dat overal geaccepteerd wordt. Een andere opdracht is de waardewisselaar, waar compliance by design een belangrijke factor is. Lees meer over deze toepassingen op [https://discipl.org discipl.org]. : → [[media:Discipl, a global society architecture.pdf|presentatie (PDF, 6,94 MB)]]  
==Definitie== Het proces van het vaststellen van en vorm en inhoud geven aan informatiebeveiligingseisen. ==Toelichting== Het object Analyse en specificatie informatiebeveiligingseisen heeft betrekking op niet-functionele eisen, zoals betrouwbaarheid, gebruiksvriendelijkheid, efficiëntie, onderhoudbaarheid, performance en flexibiliteit in overdraagbaarheid.  +
==Definitie== Het analyseren en specificeren van functionele eisen, afkomstig van de business en andere stakeholders, waaraan een applicatie moet voldoen. ==Toelichting== Het analyseren en specificeren van requirements is een proces van het traceren en onderkennen van functionele en niet-functionele requirements waar de te ontwikkelen applicatie aan moet voldoen. Ook worden de constraints geïdentificeerd die zullen gelden in de ontwikkel- en de operatiefases. Het ontwikkelen van informatiesystemen wordt tegenwoordig veelal uitgevoerd conform de iteratieve ontwikkelmethode (Agile). Onafhankelijk van de methode (traditioneel, Waterval of Agile) is sprake van een aantal ontwikkelstappen waaraan aandacht wordt besteed: * functionele eisen onder andere: functionaliteiten, gegevens, business rules, presentatie, interactie en foutafhandelingen; * niet-functionele eisen onder andere: betrouwbaarheid, gebruiksvriendelijkheid, efficiëntie, onderhoudbaarheid, performance en flexibiliteit in overdraagbaarheid. In de [[ISO 27002 2017|ISO 27002 2017]] wordt rond dit thema alleen focus gelegd op niet-functionele eisen (beveiligingseisen). Daarom is naast het object ‘Analyse en specificatie van informatiebeveiligingseisen’ ook het object ‘Analyse en specificatie van informatiesystemen’ toegevoegd, waarbij de nadruk gelegd wordt op functionele eisen. Dit thema is baseline gebaseerd en met lineaire volgens het V-modelaanpak uitgewerkt. Aangezien bij Agile niet op deze wijze wordt gewerkt, verdient dit aspect extra aandacht.  +
De website Antwoord voor bedrijven is per 15 september 2014 opgegaan in Ondernemersplein.nl. De website maakt ondernemers wegwijs door de grote hoeveelheid informatie van de overheid. Binnen- en buitenlandse dienstverleners vinden op deze website informatie van de overheid over onder meer wet- en regelgeving, vergunningen en aanvraagprocedures. Daarnaast kunnen zij via dit elektronische kanaal met overheidsorganisaties procedures en formaliteiten afwikkelen, zoals het aanvragen en verkrijgen van vergunningen. Antwoord voor bedrijven voert regelmatig gebruikersonderzoeken met een actief ondernemerspanel uit. Zo houden ze in de gaten of het loket aansluit op de wensen van de gebruikers.  +
==Definitie== Het periodiek volgens een bepaalde procedure onderhouden van apparatuur (machines). ==Toelichting== Apparaten kunnen cruciale data bevatten. Het verwijderen van apparaten moet daarom met vastgestelde procedures plaatsvinden.  +
==Definitie== Het plaatsen en beschermen van apparatuur binnen huisvesting IV voor toepassing van vastlegging, verwerking, opslag, overdracht, vermenigvuldiging en verstrekking van informatie. ==Toelichting== In huisvesting IV bevindt zich verschillende apparatuur. Deze apparatuur dient zo te zijn gepositioneerd en beschermd dat verlies, diefstal en onderbreking van bedrijfsmiddelen wordt voorkomen.  +
==Definitie== Het verwijderen van apparatuur met een geregistreerde procedure. ==Toelichting== Apparaten kunnen cruciale data bevatten. Het verwijderen van apparatuur moet daarom met vastgestelde procedures plaatsvinden.  +
==Definitie== Een modelmatige beschrijving van het applicatielandschap, een blauwdruk. ==Toelichting== De applicatie-architectuur beschrijft de samenhang tussen functionele en beveiligingseisen. Ook wordt aandacht besteed aan de integratie-aspecten met de infrastructuur. Vanuit een eenduidig beeld wordt de applicatie met deze architectuur gerealiseerd. Richtlijnen, instructies, architectuur- en beveiligingsvoorschriften en procedures worden zodanig toegepast dat een samenhangend geheel ontstaat. Op deze manier wordt ook zeker gesteld dat de applicatie aan de vereiste functionele en beveiligingseisen voldoet.  +
==Definitie== Het applicatie-ontwerp is de bouwtekening (in tekst en beeld) van een computerprogramma. ==Toelichting== Tijdens de ontwerpfase worden de (niet-)functionele requirements omgezet naar een uitvoerbaar informatiesysteem. Een high level architectuur wordt ontwikkeld om de software te kunnen bouwen. Hierbij wordt onder andere aandacht besteed aan de gebruikte data door het systeem, de functionaliteit die geboden moeten worden, de toegepaste interfaces tussen componenten binnen het systeem en aan koppelingen met andere systemen. Ook worden constraints die voortvloeien uit specifieke beveiligingseisen verder uitgewerkt.  +
==Definitie== Het ontwikkelen van programmacode, een concrete reeks instructies die een computer kan uitvoeren, in een programmeertaal. ==Toelichting== Na de eerste twee ontwikkelfasen, waarbij de nadruk ligt op de analyse van requirements en op het ontwerp van het product, volgt de derde fase, de applicatiebouw. In deze derde fase wordt de programmacode gecreëerd met good practices, methoden/technieken en bepaalde beveiligingsuitgangspunten.  +
==Definitie== De interne functies binnen een applicatie die ondersteuning bieden aan een of meer bedrijfsprocessen. ==Toelichting== De functies kunnen worden onderverdeeld in invoer-, verwerking- en uitvoerfuncties. Binnen de functies worden controles en rekenregels ingebouwd om de gewenste acties te kunnen uitvoeren en gewenste resultaten te kunnen leveren. Het totaal aan functionaliteiten moet aan bepaalde eisen voldoen. Zo moeten functionaliteiten: * voldoen aan de behoefte van de gebruikers; * de gebruikerstaken afdekken; * resultaten leveren die nauwkeurig zijn; * geschikt zijn om bepaalde taken te kunnen ondersteunen.  +
==Definitie== Een verbinding tussen twee applicaties zodat gegevens of informatie tussen deze applicaties uitgewisseld kan worden. ==Toelichting== Bij het ontwikkelen van applicaties kunnen mogelijk koppelingen tussen de applicatie die in ontwikkeling is en andere applicaties noodzakelijk zijn. Vanuit beveiligingsoogpunt dienen dit soort koppelingen aan bepaalde eisen te voldoen.  +
==Toelichting== Logging is een proces voor het registreren van activiteiten en gebeurtenissen in systemen om achteraf de rechtmatigheid van de resourcebenadering en vroegtijdige ongeautoriseerde toegangspogingen van systemen en netwerken te kunnen signaleren. Voorkomen moet worden dat (te) grote hoeveelheden logdata ontstaan. Logdata dient van hoge kwaliteit te zijn met relevante gebeurtenissen. Logdata bevat doorgaans gevoelige, persoonsgebonden en/of financiële gegevens en moet worden beschermd volgens de lokale privacywetgeving of richtlijnen. ==Schaalgrootte== Middel en groot. ==Voor wie== Klant en leverancier.  +
==Objecten, controls en maatregelen== Onderstaande afbeelding toont de objecten die specifiek door dit domein een rol spelen. Het geeft een overzicht en de ordening van objecten. Voor de identificatie van de objecten en de ordening is gebruik gemaakt van basiselementen (zie de grijs gemarkeerde tekst) ingedeeld naar de invalshoek: Intentie, Functie, Gedrag of Structuur. [[Bestand:APO Overzicht objecten voor applicatieontwikkeling in het beleidsdomein.png|thumb|none|500px|Overzicht applicatieontwikkelingsobjecten in het beleidsdomein|alt=”Onderwerpen die binnen het Beleid domein een rol spelen”]]  +
==Objecten, controls en maatregelen== Onderstaande afbeelding toont de objecten die specifiek voor dit domein een rol spelen. [[Bestand:APO Overzicht objecten voor applicatieontwikkeling in het control-domein.png|thumb|none|500px|Overzicht applicatieontwikkelingsobjecten in het control-domein|alt=”Onderwerpen die binnen het Control domein een rol spelen”]]  +
==Objecten, controls en maatregelen== Binnen het uitvoeringsdomein worden specifieke inrichtings- en beveiligingsobjecten voor applicatieontwikkeling beschreven. Per object worden conformiteitsindicatoren en de desbetreffende implementatie-elementen uitgewerkt. De rood gemarkeerde objecten komen voor in de [[BIO (Baseline Informatiebeveiliging Overheid)|Baseline Informatiebeveiliging Overheid (BIO)]]. De wit gemarkeerde objecten zijn betrokken uit andere best practices. De objecten zijn ingedeeld naar intentie, functie, gedrag en structuur. In de [[BIO Thema Applicatieontwikkeling/IFGS gekoppeld aan het V-model|pagina Invalshoeken gekoppeld aan het V-model zijn de invalshoeken gekoppeld aan het V-model]]. [[Afbeelding:Thema Applicatieontwikkeling - Onderwerpen die binnen het Uitvoeringsdomein een rol spelen.png|thumb|none|500px|Overzicht applicatieontwikkelingsobjecten in het uitvoeringsdomein|alt=”Onderwerpen die binnen het Uitvoering domein een rol spelen”]]  +
== Toelichting == Een API is te beschouwen als een soort digitale stekkerdoos, die externe diensten of personen gecontroleerde toegang kan verschaffen tot interne diensten, algoritmes, apparaten en/of informatiebronnen. De eigenschappen van een API maakt een algoritme, dienst, apparaat of data programmeerbaar en daarmee ook gevoelig voor aanvallen. De maatregelen hieronder zijn beperkt tot generieke eisen. Zie voor specifieke eisen over [[JSON|JavaScript Object Notation (JSON)]], [[XML|Extensible Markup Language (XML)]] of Graph Query Language (GraphQL) en de [[OWASP Application Security Verification Standard 4.0.2|Application Security Verification Standard (ASVS)]] van [[OWASP (Open Source Foundation for Application Security)|Open Source Foundation for Application Security (OWASP)]]. Bij cloud-toepassingen speelt de HyperText Markup Language (HTML)-5 ondersteuning van bepaalde browsers en de versie van die browser een belangrijke rol, onder andere voor de ondersteuning van bepaalde office-versies. ==Schaalgrootte== Elke schaalgrootte. ==Voor wie== Leverancier.  +
Aquo-lex (het ‘waterwoordenboek') bevat circa 7.500 definities voor termen. De fouten die bij gegevensuitwisseling optreden, ontstaan vaak door verschil in betekenis. Door deze ‘standaardtaal' te gebruiken, wordt spraakverwarring tussen mensen en/of informatiesystemen voorkomen. Aquo-lex wordt geïntegreerd in de Aquo Objecten Catalogus (Aquo OC). Deze catalogus bevat relaties tussen de begrippen uit Aquo-lex. De gebruiker ervan kan snel termen vinden en in hun context plaatsen.  +
De Aquo-standaard maakt het mogelijk om op een uniforme manier gegevens van een object met een ruimtelijk kenmerk uit te wisselen tussen partijen die betrokken zijn bij het waterbeheer. Het vormt hiermee de digitale schakel tussen de waterbeheerders Rijkswaterstaat, provincies en waterschappen, maar ook tussen waterbeheerders en derden zoals bedrijven en onderzoeksinstellingen. Door de uniforme manier van uitwisselen zijn landelijke rapportages te maken ten behoeve van de waterkwaliteit. <br /> <br />  <br /> <br /> De Aquo-standaard draagt zodoende bij aan een kwaliteitsverbetering van het waterbeheer. Het eenvoudig en eenduidig delen van informatie levert tijd- en geldwinst op.  +
De Aquo-standaard maakt het mogelijk om op een uniforme manier gegevens van een object met een ruimtelijk kenmerk uit te wisselen tussen partijen die betrokken zijn bij het waterbeheer. Het vormt hiermee de digitale schakel tussen de waterbeheerders Rijkswaterstaat, provincies en waterschappen, maar ook tussen waterbeheerders en derden zoals bedrijven en onderzoeksinstellingen. Door de uniforme manier van uitwisselen zijn landelijke rapportages te maken ten behoeve van de waterkwaliteit. <br /> <br />  <br /> <br /> De Aquo-standaard draagt zodoende bij aan een kwaliteitsverbetering van het waterbeheer. Het eenvoudig en eenduidig delen van informatie levert tijd- en geldwinst op.  +
Een beschrijvingstaal voor enterprise-architecturen.  +
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  +
Een stelling over een gewenste, generieke, kwalitatieve eigenschap waar architectuur invulling aan moet geven in de publieke sector.  +
Normatieve en descriptieve documenten die huidige/toekomstige architectuur van een organisatie/domein schetsen.  +
De mate waarin bij gegevensobjecten waarden aanwezig zijn voor een attribuut.  +
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.  +
==Toelichting== 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.  +
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  +
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  +
==Definitie== Het verlenen van toestemming aan een geauthenticeerde gebruiker om toegang te krijgen tot een bepaalde dienst om een bepaalde actie uit te voeren. ==Toelichting== Gekozen is voor het object ‘Autorisatie’, omdat dit object beter aansluit op de toegangsmechanismen (identificatie, authenticatie en autorisatie) dan de [[BIO (Baseline Informatiebeveiliging Overheid)|Baseline Informatiebeveiliging Overheid (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 door middel van rollen en toegangsprofielen die voortkomen uit het toegangsbeleid.  +
==Toelichting== 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.  +
==Definitie== Een reeks van aan elkaar verbonden taken of activiteiten die een afgerond geheel vormen over het toekennen van toegangsrechten (autorisaties). ==Toelichting== 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.  +
==Definitie== De technische middelen waarmee ontwerpen passend in architectuur kunnen worden vormgegeven en waarmee acties, zoals geautomatiseerde tools en of ondersteunende systemen, effectief kunnen worden ingericht. ==Toelichting== Om autorisatiebeheer efficiënt en effectief te kunnen inrichten, zijn technische autorisatievoorzieningen, zoals een personeelsregistratiesysteem, een autorisatiebeheersysteem en autorisatiefaciliteiten noodzakelijk.  +
B
De Basisregistratie Adressen en Gebouwen (BAG) is de registratie waarin gemeentelijke basisgegevens over alle gebouwen en adressen in Nederland zijn verzameld. De BAG is gebaseerd op de Wet basisregistraties adressen en gebouwen. Gemeenten zijn bronhouder van de gebouw- en adresgegevens. Alle bestuursorganen zijn verplicht om vanaf 1 juli 2011 gebruik te maken van de BAG bij de uitvoering van hun publiekrechtelijke taken.  +
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].  +
De Basisregistratie Grootschalige Topografie (BGT) wordt een uniform topografisch basisbestand met objecten in heel Nederland op een schaal van 1:500 tot 1:5.000. Het doel van de realisatie van de BGT is dat de hele overheid gebruik maakt van dezelfde basisset grootschalige topografie van Nederland. Topografie is de beschrijving van de fysieke werkelijkheid. Dus de dingen die in het terrein fysiek aanwezig zijn.  +
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.  +
De Ministerraad van 14 december 2018 heeft de Baseline Informatiebeveiliging Overheid (BIO) voor het eerst vastgesteld voor het Rijk en in het interbestuurlijk verkeer met het Rijk. De BIO is: * een gemeenschappelijk normenkader, gebaseerd op de internationale norm [[NEN-EN-ISO/IEC 27002:2017 (Praktijkrichtlijn met beheersmaatregelen op het gebied van informatiebeveiliging)|ISO 27001]]/[[NEN-EN-ISO/IEC 27001:2017 (Managementsystemen voor informatiebeveiliging - Eisen)|2]] voor de beveiliging van de informatie(systemen) van de overheid; * een afgeleide van de [[BIR (Baseline Informatiebeveiliging Rijksdienst)|BIR (Baseline Informatiebeveiliging Rijksdienst) 2017]]; * een concretisering van een aantal normen tot verplichte overheidsmaatregelen. Iedere overheidslaag heeft besloten de bestaande eigen baseline voor informatiebeveiliging te vervangen door de BIO. Het gevolg van bovengenoemde besluiten is dat alle overheidsorganisaties hun bestaande sectorale baselines zullen vervangen door de BIO. De BIO vervangt voor de gemeenten, waterschappen, provincies en het Rijk respectievelijk de [[BIG (Baseline Informatiebeveiliging Gemeenten)|BIG (Baseline Informatiebeveiliging Gemeenten)]], [[BIR]], [[BIWA (Baseline Informatiebeveiliging Waterschappen)|BIWA (Baseline Informatiebeveiliging Waterschappen)]] en [[IBI (Interprovinciale Baseline Informatiebeveiliging)|IBI (Interprovinciale Baseline Informatiebeveiliging)]]. Om te voorkomen dat het Rijk in de informatie-uitwisseling met andere bestuurslagen andere normen gaat eisen, heeft de Ministerraad besloten om de BIO te hanteren in de informatie-uitwisseling tussen het Rijk en alle bestuurslagen. Een actuele PDF-versie van de BIO is ontsloten op [https://cip-overheid.nl/category/producten/bio/#bio-tekst cip-overheid.nl] en [https://bio-overheid.nl/category/producten#BIO bio-overheid.nl].Een actuele versie van de Excel-versie, een overzicht van alleen de BIO-maatregelen en de BIO controls is te bekijken en downloaden op [https://bio-overheid.nl/category/producten#Excelversie bio-overheid.nl]. ==Hulpbronnen voor BIO-toepassing in de praktijk== Het [[Centrum Informatiebeveiliging en Privacybescherming (CIP)]] ontwikkelt in samenwerking met het [[BZK (Ministerie van Binnenlandse Zaken en Koninkrijksrelaties)|ministerie van BZK]] de zogenaamde BIO Thema-uitwerkingen, die voor een bepaald onderwerp een praktische uitwerking van de BIO betekenen. BIO Thema-uitwerkingen worden ontsloten die op NORA online in de [[ISOR (Information Security Object Repository)]]. Meer informatie en documenten van het CIP delen zij op de websites van CIP-overheid en BIO-overheid en in het forum op Pleio (vereist lidmaatschap): : → [https://cip-overheid.nl/ cip-overheid.nl] : → [https://bio-overheid.nl/ bio-overheid.nl] : → [https://cip.pleio.nl/ cip.pleio.nl] Ook de [[IBD (Informatiebeveiligingsdienst)|Informatiebeveiligingsdienst (IBD)]], de sectorale CERT/CSIRT voor alle Nederlandse gemeenten, heeft een set met praktische documenten gepubliceerd, zoals een template voor een verwerkingsregister en handreikingen voor (gemeentelijke) processen zoals dataclassificatie in het kader van de BIO. : → [https://www.informatiebeveiligingsdienst.nl/producten/ informatiebeveiligingsdienst.nl/producten/]  
Objecten voor applicatieontwikkeling worden gerelateerd aan de ontwikkelfasen en geïdentificeerd aan de hand van onderzoeksvragen en risicogebieden. De objecten zijn afgeleid vanuit de optiek van de kwaliteitscriteria: Beschikbaarheid, Integriteit, Vertrouwelijkheid en Controleerbaarheid (BIVC), die vervolgens zijn ingedeeld in drie domeinen: beleid, uitvoering en control. 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: 1.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. 2.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. 3.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 identificeren van objecten== 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 het 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 van applicatieontwikkeling== Dit document bevat de uitwerking van het thema 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. 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 dit thema 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-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|Standard of Good Practice (SoGP)]] 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 van applicatieontwikkeling== Dit thema 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. Het thema 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 van applicatieontwikkeling== In dit thema 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); * het type gebruikers en bedrijfseisen omdat deze eisen organisatieafhankelijk zijn; * de toegangsbeveiligingsaspecten omdat deze aspecten in het thema ‘Toegangsbeveiliging’ geadresseerd zijn. [[Afbeelding:Thema Applicatieontwikkeling - Overzicht van type applicaties.png|thumb|none|500px|Overzicht type applicaties|alt=”Overzicht van type applicaties”]] De begrenzing van dit document is in onderstaande afbeelding weergegeven. [[Bestand:APO Relatie BIO Thema-uitwerking Applicatieontwikkeling met aanpalende documenten.png|thumb|none|500px|Relatie BIO Thema-uitwerking met aanpalende documenten|alt=”Overzicht van type applicaties”]] ==Ontwikkelcyclus van 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. 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 onderstaande afbeelding weergegeven. [[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”]] ===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 de leverancier wordt bij uitbesteding de rechterkant aangeduid als het leveranciersperspectief en de linkerkant als het klantperspectief. Hierover maken 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 de 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]]  +
Beslisbomen ondersteunen 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’. Hieronder is als aanpak een beslisboom uitgewerkt en in relatie tot de risicoafweging. Belangrijk daarbij is 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 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 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 aspecten 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”]] [[Afbeelding:BIO Thema Clouddiensten - Procesflow voor de risicoanalyse.png|thumb|none|500px|Beslisboom|alt=”Beslisboom voor risicobeoordeling”]] '''Afhankelijkheid en kwetsbaarheid''' Vraag 1: Gaat het om persoonsgegevens en/of (zeer) vertrouwelijke bedrijfsgegevens? NB Onder persoonsgegevens verstaat de [[Algemene Verordening Gegevensbescherming (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-PIA, PIA en/of risicobeoordeling). NB Die gedetailleerde risicoanalyse zal in het geval van: * Privacy gevoelige gegevens bestaan uit een zogenaamde Pre-PIA (risico inschatting op basis van 9 vragen), afhankelijk van de uitkomst gevolgd door een formele (D)PIA. * 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 type processen (= 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 objecten in het beleidsdomein== Onderstaande afbeelding toont de dreigingen/kwetsbaarheden van de benoemde objecten per invalshoek. De invalshoeken zijn: * Intentie, Een organisatie heeft bij het verwerven van clouddiensten doelstellingen geformuleerd, zoals: een efficiënte bedrijfsvoering, een schaalbare en flexibele dienstverlening. Hiervoor ontwikkelt zij beleid en strategie. Omdat dit met onzekere informatie wordt ontwikkeld, moeten de stakeholders risicoanalyse(s) laten uitvoeren. Voor het uitvoeren van risicoanalyses moet een te hanteren risicoaanpak (methode) zijn vastgesteld (risicomanagement). * 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. * 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). * Structuur, De inzet van de actoren dienen goed georganiseerd te worden door een organisatiestructuur en de benodigde IT-objecten een architectuur. [[Afbeelding:Kwetsbaarheden_van_de_beleidsprincipes.png|thumb|none|650px|Dreigingen/kwetsbaarheden van beleidsobjecten |alt=”De dreigingen/kwetsbaarheden van de beleidsobjecten”]] ==Dreigingen/kwetsbaarheden in relatie tot de cloudbeleidsobjecten== Onderstaande afbeelding geeft voor het beleidsdomein en dankzijde vermelde dreigingen/kwetsbaarheden en risico’s de geïdentificeerde beveiligingsobjecten voor clouddiensten weer. De vermelde 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 staat voor Structuur, Inhoud, Vorm en Analysevolgorde. Ze zijn ingedeeld in de drie domeinen: beleid, uitvoering en control en vier 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 conform het SIVA-raamwerk”]] : → [[BIO Thema Clouddiensten/Risico's in relatie met clouddiensten#Dreigingen en/of kwetsbaarheden|Ga terug naar Dreigingen en/of kwetsbaarheden]]  
==Toelichting control-domein== Onderstaande afbeelding toont de dreigingen/kwetsbaarheden van de benoemde objecten per invalshoek. De invalshoeken zijn: * 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. * Functie, De organisatie heeft beheersingsprocessen ingericht en verricht voor beveiligingscontroles en kwetsbaarheden van de clouddiensten. * Gedrag, De organisatie verricht in haar processen activiteiten voor het monitoren van clouddiensten en technische kwetsbaarheden. * Structuur, De organisatie heeft voor de clouddiensten een beheersingsorganisatie ingericht. [[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 in relatie tot de 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 wordt weergegeven in onderstaande afbeelding. [[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]]  +
==Toelichting uitvoeringsdomein== Onderstaande afbeelding toont de dreigingen/kwetsbaarheden van de benoemde objecten per invalshoek. De invalshoeken zijn: * Intentie, In het uitvoeringsdomein zal de organisatie onder andere haar beleid vertalen naar richtlijnen voor het uitvoeren van een risicoanalyse en zal de organisatie de implementatie vertalen naar procedures. * Functie, In dit domein worden voor clouddiensten organisatorische en technisch georiënteerde maatregelen getroffen. * Gedrag, De clouddiensten kennen een aantal specifieke elementen, zoals toegang en technisch georiënteerde componenten. * Structuur, De clouddiensten moeten een goed overzicht bieden via een architectuur. [[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 in relatie tot de 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: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]]  +
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 drie 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 dit thema 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 het thema ligt op beschikbaarheid, integriteit, vertrouwelijkheid en controleerbaarheid van de data en de betrouwbaarheid van de bedrijfsprocessen. De uitwerking van het [[BIO Thema Clouddiensten|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 van het thema== De BIO Thema-uitwerking Clouddiensten wordt uitgewerkt langs twee lijnen: structuur en objecten. De structuur van het BIO Thema 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 domein beleid, uitvoering of control. Er wordt een standaard opzet voor BIO Thema-uitwerkingen gevolgd. Vanwege het bijzondere karakter van dit thema zijn voor betere begripsvorming enkele onderwerpen toegevoegd. Deze thema-uitwerking volgt de volgende opzet: * Context van de relatie tussen de CSC en de CSP (zie [[BIO Thema Clouddiensten/Inleiding#Context van de relatie tussen de CSC en de CSP|Context van de relatie tussen de CSC en de CSP]]) * Context en globale structuur van het thema (zie [[BIO Thema Clouddiensten/Inleiding#Context en globale structuur van clouddiensten|Context en globale structuur van clouddiensten]]) * Scope en begrenzing (zie [[BIO Thema Clouddiensten/Inleiding#Scope en begrenzing van clouddiensten|Scope en begrenzing van 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 en/of kwetsbaarheden|Dreigingen en/of 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 van de relatie tussen de CSC en de 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”]] 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 de 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. [[Afbeelding:Thema Clouddiensten - Twee deliverables van een CSP en de eisen en wensen aan de vraag en levering kant.png|thumb|none|500px|Twee deliverables van een CSP en de eisen/wensen aan de CSC-kant|alt=”Twee deliverables van een CSP en de eisen en wensen aan de vraag en levering kant”]] 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 van het thema== 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. ===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. De vragen die vanuit de CSC en de CSP gesteld kunnen worden, zijn: * 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 de 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. [[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”]] ==Scope en begrenzing== 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. Dit thema 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 dit thema 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 dit thema 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 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 van de BIO Thema-uitwerking== Dit thema is een hulpmiddel bij het kiezen van een aantal te adresseren cloud-objecten bij het verwerven van clouddiensten. Bij de opzet van dit thema 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 twee risicogroepen: # Data, Gegevens van de burger of de Cloud Service Consumer (CSC) zijn verloren geraakt of zijn 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 de 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 stonden twee 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 deze 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 de drie domeinen: Beleid, Uitvoering en Control. 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 ministerie van [[BZK (Ministerie van Binnenlandse Zaken en Koninkrijksrelaties)|Ministerie van Binnenlandse Zaken 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 het Ministerie van Binnenlandse Zaken (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)|VIR-BI]] en de [[BIO (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-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-okt-2019 in een matrix overzicht]] Betekenis van de nummers 1, 2, 3 en 4 in de matrix: 1. 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 2. Er dienen passende voorzieningen beschikbaar te zijn om activiteiten van APTs 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 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. 3. De verwerking van de (DepV) gerubriceerde BIO‐BBN2 gegevens is vóóraf door de Secretaris Generaal (SG) goedgekeurd. 4. 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”]]  
Hierna volgt een korte verantwoording over de aanpak, de keuzes die gemaakt zijn en de inhoudelijke objecten die gebruikt zijn in dit thema. Om te komen tot een document dat breed draagvlak heeft en toegevoegde waarde biedt aan overheidsorganisaties zijn de objecten getraceerd langs: # CSC-eisen # Bedreigingen/kwetsbaarheden # Baseline ==CSC-eisen== Om de specifiek CSC-georiënteerde aandachtspunten te traceren, zijn vragen gesteld aan overheidsorganisaties om te komen tot een set van eisen en wensen. Met de eisen en wensen zijn objecten geïdentificeerd. Hierbij zijn aan doelorganisaties en cloud-groepssessies enkele vragen gesteld, zoals: * Hoe kan dit thema jullie organisatie helpen bij het verwerven van clouddiensten? * Wat moet minimaal uitgewerkt worden in het thema clouddiensten? Welke eisen worden door overheidsorganisaties gesteld bij het verwerven van clouddiensten? * Zijn vanuit dit thema verbindingen noodzakelijk met functionele eisen voor clouddiensten en normatiek? Aan enkele overheidsorganisaties, die inmiddels al over specifieke normenkaders voor cloud beschikken, zijn vragen gesteld over de beschikbaarstelling van hun beleidskaders of normenkaders op dit vlak. ==Bedreigingen/kwetsbaarheden== Om specifieke objecten te identificeren, is ook gericht op de algemene dreigingen en kwetsbaarheden die voortvloeien uit het toepassen van de clouddiensten. Sommige overheidsorganisaties die inmiddels over specifieke normenkaders voor cloud beschikken, zijn tevens de vraag om hun kaders, via dit thema voor een groter publiek open te stellen voor hergebruik. ==Baselines== Hiernaast zijn bestaande baselines geraadpleegd, voor zover ze specifiek zijn voor clouddiensten. De specifieke objecten, ook vanuit de eisen en wensen van de CSC-zijde en de dreigingen, uit de baselines zijn geselecteerd voor en toegespitst op de cloud-omgeving. Verder is er een koppeling gelegd met de [[BIO (Baseline Informatiebeveiliging Overheid)|BIO]] en met de [[NEN-ISO/IEC 27017:2015 (Code of practice for information security controls based on ISO/IEC 27002 for cloud services)|ISO 27017]], die specifiek gericht is op clouddiensten. Onderstaande afbeelding geeft een overzicht van de beschreven stappen. [[Afbeelding:BIO Thema Clouddiensten - Het traject van de totstandkoming van het thema cloud document.png|thumb|none|500px|Traject totstandkoming van de BIO Thema-uitwerking Clouddiensten|alt=”Het traject van de totstandkoming van het thema cloud document”]] Aan enkele overheidsorganisaties, die inmiddels al over specifieke cloudnormenkaders beschikken, is de vraag gesteld om hun cloudbeleidskader en/of cloudnormenkader beschikbaar te stellen.  
Dit document bevat een referentiekader voor het thema Clouddiensten, door het [[Centrum Informatiebeveiliging en Privacybescherming (CIP)|Centrum Informatiebeveiliging en Privacybescherming (CIP)]] opgesteld om overheidsorganisaties een beeld te geven van de meest relevante onderwerpen bij het verwerven van veilige clouddiensten. Het document is bedoeld als handreiking, gerelateerd aan de toepassing van de [[BIO (Baseline Informatiebeveiliging Overheid)|Baseline Informatiebeveiliging Overheid (BIO)]] en verschaft een overzicht van de uitwerking van clouddienstenobjecten vanuit de optiek van de Cloud Service Consumer (CSC). Voor de beperking van de omvang van dit document worden de geïdentificeerde objecten gerelateerd aan algemene clouddiensten. Dit document doet geen uitspraken over de vraag of cloud ingezet mag worden. Die keuze is onderworpen aan het vigerend beleid. Bij een keuze voor cloud, kan dit document worden gehanteerd bij de inrichting. De BIO is verplicht verklaard voor de overheidspartijen. Vanwege de snelle ontwikkelingen van clouddiensten hebben overheidspartijen een grote behoefte aan overzicht en inzicht in de meest cruciale componenten die bij de verwerving van clouddiensten aandacht behoeven. Temeer omdat specifieke op clouddiensten gerichte beveiligingsobjecten ontbreken in de BIO. Dat komt omdat de BIO gebaseerd is op een generieke baseline [[NEN-EN-ISO/IEC 27002:2017 (Praktijkrichtlijn met beheersmaatregelen op het gebied van informatiebeveiliging)|ISO 27002]]. Aanvullend op deze ISO zijn door [[NEN (Stichting Koninklijk Nederlands Normalisatie Instituut)|NEN]]-[[ISO (International Organization for Standardization)|ISO]]/[[IEC (International Electrotechnical Commission)|IEC]] een aantal implementatiekaders opgesteld en bestaan er kaders zoals het [[Cybersecurity Framework Version 1.1|Cybersecurity Framework (CSW)]] van [[NIST (National Institute of Standards and Technology)|National Institute of Standards and Technology (NIST)]] en de [[Cloud Controls Matrix (CCM)|Cloud Control Matrix (CCM)]] van [[CSA (Cloud Security Alliance)|Cloud Security Alliance (CSA)]], gericht op de beveiliging van clouddiensten. Ook de [[The Standard of Good Practice for Information Security 2018|Standard of Good Practice (SoGP)]], standaarden van de [[BSI (Bundesamt für Sicherheit in der Informationstechnik)|Bundesamt für Sicherheit in der Informationstechnik (BSI)]], [[ITU (International Telecommunication Union)|International Telecommunication Union (ITU)]] en de [[ICT-Beveiligingsrichtlijnen voor Webapplicaties-Richtlijnen|ICT-Beveiligingsrichtlijnen voor Webapplicaties]] van het [[NCSC (Nationaal Cyber Security Centrum)|Nationaal Cyber Security Centrum (NCSC)]] bevatten relevante controls en maatregelen voor clouddiensten. Een probleem voor overheidspartijen is dat een handig overzicht ontbreekt voor een samenvatting van alle relevante zaken over clouddiensten, eenduidig gerelateerd aan de BIO. Een veel gehoorde uitspraak is: ‘We zien door de bomen het bos niet meer.’. De schrijfgroep heeft diverse workshops georganiseerd waarin verschillende overheidspartijen hebben geparticipeerd. Deze partijen hebben hun beleidsdocumenten ter beschikking gesteld en hun visie, risico’s en problematiek gedeeld waarmee ze in de praktijk geconfronteerd worden. Met deze informatie en risico’s verbonden aan clouddiensten heeft de schijfgroep dit document opgesteld en ter review aan de overheidspartijen aangeboden. Versie 1.1 bevat een compleet beeld van onderwerpen die voor informatieveiligheid en privacy de aandacht vereisen bij de verwerving van clouddiensten. De privacyaspecten zijn in de handreiking Cloudcomputing en Privacy van de [[IBD (Informatiebeveiligingsdienst)|Informatiebeveiligingsdienst (IBD)]] uitgewerkt. Voor de structurering van dit document is dezelfde systematiek gekozen als bij de overige [[Alle normenkaders|BIO Thema-uitwerkingen]]. De beschrijving van de systematiek is in dit document kort weergegeven. Dit document beperkt zich tot die zaken, die vanuit de CSC richting de Cloud Service Provider (CSP) van belang zijn, inclusief de koppelvlakken tussen de CSC en de CSP. Uiteraard speelt de CSC in de informatieketen een belangrijke rol en moet zij haar IT-huishouding op orde hebben. Pas dan kan sprake zijn van een goede samenwerking tussen de CSC en de CSP. Dit gegeven is een belangrijk uitgangspunt voor stakeholders binnen de overheidspartijen. Er zijn veel inhoudelijke suggesties en reacties ontvangen. De intentie van dit document is de lezer verder te helpen bij vraagstukken over clouddiensten. Daar waar verbeterd kan worden, kan dit thema verrijkt worden met aangeleverde teksten.  
<table class="wikitable"> <tr> <th>  ID </th> <th>  Betekenis van de objecten in relatie tot  het thema  </th> <th>  Vertaling naar Thema:  Serverplatform  </th> </tr> <tr> <td>  B.01  </td> <td>  Beleid en  procedures informatietransport  </td> <td>  De waarborging  van de bescherming van informatie in netwerken, door inzet van  beheerprocedures voor informatietransport en het hanteren van procedures voor  bewaking van netwerken.  </td> </tr> <tr> <td>  B.02  </td> <td>  Overeenkomsten  informatietransport  </td> <td>  Contracten en  afspraken, waarin het dienstverleningsniveau, beveiligingsmechanismen en  beheersingseisen voor netwerkdiensten zijn vastgelegd, zowel voor intern  geleverde diensten als voor uitbestede diensten.  </td> </tr> <tr> <td>  B.03  </td> <td>  Cryptografiebeleid  </td> <td>  Beleid en  afspraken, specifiek gericht op de toepassing van cryptografie binnen  netwerken en communicatieservices.  </td> </tr> <tr> <td>  B.04  </td> <td>  Organisatiestructuur  netwerkbeheer  </td> <td>  Opzet van de  administratieve organisatie van netwerk en communicatiebeheer.  </td> </tr> <tr> <td>  U.01  </td> <td>  Richtlijnen  netwerkbeveiliging  </td> <td>  Algemene,  operationele beveiligingsrichtlijnen voor ontwerp, implementatie en beheer  van communicatievoorzieningen.  </td> </tr> <tr> <td>  U.02  </td> <td>  Beveiligde  inlogprocedures  </td> <td>  Is gerelateerd  aan twee aspecten: Aanmelden en Procedure.  ·  Aanmelden (inloggen) behelst het leggen van een  verbinding- via authenticatie middelen.  ·  De procedure is de samenhangende beschrijving van  welke activiteiten moeten plaatsvinden.  </td> </tr> <tr> <td>  U.03  </td> <td>  Netwerk  beveiligingsbeheer  </td> <td>  Het beheer van  beveiligingsprocedures en -mechanismen.  </td> </tr> <tr> <td>  U.04  </td> <td>  Vertrouwelijkheid-  geheimhoudingsovereenkomst  </td> <td>  De eisen die aan  dienstverleners en partners gesteld worden in de operatie voor het waarborgen  van de vertrouwelijkheid van gegevens en de uitvoering van bedrijfsprocessen.  </td> </tr> <tr> <td>  U.05  </td> <td>  Beveiliging  netwerkdiensten  </td> <td>  De eisen die aan  dienstverleners gesteld worden t.a.v. te nemen maatregelen voor  beveiligingsmechanismen, het dienstverleningsniveau en de kwaliteit van de  beheerprocessen.  </td> </tr> <tr> <td>  U.06  </td> <td>  Zonering en  filtering  </td> <td>  Gaat over twee  aspecten: Scheiding en Gecontroleerde doorgang.  ·  Scheiding is het positioneren van netwerken in  afzonderlijke fysieke ruimten of het segmenteren van netwerken in  afzonderlijk te beveiligen (logische) domeinen.  ·  Gecontroleerde doorgang is het reguleren van de  toegang van personen tot netwerkvoorzieningen en/of het en filteren van  informatiestromen op basis van beleidsregels met filters en algoritmen.  </td> </tr> <tr> <td>  U.07  </td> <td>  Elektronische  berichten  </td> <td>  Beveiliging van  elektronisch berichtenverkeer, zoals b.v. e-mail, web-verkeer, chat-sessies  en ‘streaming’ audio en video. Beveiliging omvat maatregelen voor bescherming  van het berichtenverkeer, zoals geautoriseerde toegang, correcte adressering  en integer datatransport, beschikbaarheid en (wettelijke) bepalingen voor  elektronische handtekening en onweerlegbaarheid.  </td> </tr> <tr> <td>  U.08  </td> <td>  Toepassingen via  openbare netwerken  </td> <td>  Gebruik van  openbare netwerken voor uitwisseling van informatie van uitvoeringsdiensten  vereist bescherming tegen inbraak, waarmee frauduleuze praktijken, geschillen  over contracten en onbevoegde openbaarmaking of onbevoegde wijziging kunnen  worden voorkomen.  </td> </tr> <tr> <td>  U.09  </td> <td>  Gateway / Firewall  </td> <td>  Beveiligingsmechanisme  voor zonering en gecontroleerde toegang.  </td> </tr> <tr> <td>  U.10  </td> <td>  Virtual Private Networks (VPN)  </td> <td>  Beveiligingsmechanisme  voor het inrichten van een vertrouwd toegangspad tussen 2 of meerdere  netwerk-nodes.  </td> </tr> <tr> <td>  U.11  </td> <td>  Cryptografische services  </td> <td>  Versleuteling van  netwerkverkeer, met behulp van hardware of software voorzieningen, die kunnen  voorkomen op alle zeven lagen van het OSI-model. Cryptografische services voor communicatie  met partners en burgers maken gebruik van Public Key Infrastuctuur middelen,  zoals de aan certificaten gebonden private en publieke sleutels.  </td> </tr> <tr> <td>  U.12  </td> <td>  Wireless Access  </td> <td>  Toegang tot  draadloze netwerken bedoeld voor mobiele communicatie.  </td> </tr> <tr> <td>  U.13  </td> <td>  Netwerk connecties  </td> <td>  Verbindingen  netwerk-eindpunten (nodes) worden beheerd en zijn vastgelegd in een  netwerktopologie.  </td> </tr> <tr> <td>  U.14  </td> <td>  Netwerk authenticatie  </td> <td>  Voorziening, die  controleert of een netwerkdevice geautoriseerd is om op het netwerk te kunnen  worden aangesloten.  </td> </tr> <tr> <td>  U.15  </td> <td>  Netwerkbeheeractiviteit  </td> <td>  Activiteiten die  uitsluitend door netwerkbeheerders kunnen worden uitgevoerd op  communicatievoorzieningen.  </td> </tr> <tr> <td>  U.16  </td> <td>  Vastleggen netwerkevents  </td> <td>  Het uniek en  onveranderlijk vastleggen van (beveiligings) gebeurtenissen in een netwerk  (in een audit-logfile).  </td> </tr> <tr> <td>  U.17  </td> <td>  Netwerksecurityarchitectuur  </td> <td>  Beschrijving en  beelden van de structuur en onderlinge samenhang van de verschillende  beveiligingsfuncties in een netwerk.  </td> </tr> <tr> <td>  C.01  </td> <td>  Naleving richtlijnen netwerkbeheer en evaluatie.  </td> <td>  Evaluatie op de  naleving van netwerkbeveiligingsbeleid.  </td> </tr> <tr> <td>  C.02  </td> <td>  Netwerksecurity Compliance checking  </td> <td>  Periodieke  toetsing en managementrapportage over naleving van het beveiligingsbeleid  voor netwerkdiensten.  </td> </tr> <tr> <td>  C.03  </td> <td>  Evalueren robuustheid  netwerkbeveiliging  </td> <td>  Toetsing van de  robuustheid (resilience) van beveiligingsfuncties in  communicatievoorzieningen.  </td> </tr> <tr> <td>  C.04  </td> <td>  Evalueren gebeurtenissen (monitoring)  </td> <td>  Het beoordelen  van de (doorlopend) verzamelde security gerelateerde gebeurtenissen in  netwerken.  </td> </tr> <tr> <td>  C.05  </td> <td>  Beheersorganisatie  netwerkbeveiliging  </td> <td>  De opzet van een  toereikende organisatiestructuur voor het beheren van- en rapporteren over  netwerken en communicatievoorzieningen.  </td> </tr> <caption align="bottom">Communicatievoorzieningen, Omschrijving van de geïdentificeerde ISO-27002 objecten</caption></table>  
Dit document bevat een referentiekader voor het thema Communicatievoorzieningen. Het is geënt op controls uit de [[BIO (Baseline Informatiebeveiliging Overheid)|Baseline Informatiebeveiliging Overheid (BIO) 2019]], [[NEN-EN-ISO/IEC 27002:2017 (Praktijkrichtlijn met beheersmaatregelen op het gebied van informatiebeveiliging)|NEN-ISO/IEC 27002: 2017]] (hierna genoemd ISO 27002), implementatiestandaarden-reeks ISO 27033 en tevens op best practices als: [[BSI (Bundesamt für Sicherheit in der Informationstechnik)|Bundesamt für Sicherheit in der Informationstechnik (BSI)]] en [[The Standard of Good Practice for Information Security 2018|Standard of Good Practice (SoGP)]]. ==Opzet van het thema== Het thema Communicatievoorzieningen brengt de voor communicatiebeveiliging relevante controls uit de BIO overzichtelijk bij elkaar. Vervolgens zijn relevante items die ontbraken, aangevuld uit andere baselines, zoals de BSI en SoGP. De [[patronen|NORA-patronen]] zijn gebruikt voor afbeeldingen en begeleidende teksten. NORA staat voor Nederlandse Overheid Referentie Architectuur De implementatiestandaard ISO 27033 deel 1 t/m 6 biedt, gerelateerd aan de ISO 27002, overzicht en een technische duiding van netwerkbeveiliging. Dit thema volgt de standaardopzet voor BIO Thema-uitwerkingen: # Context en globale structuur van het thema [[BIO Thema Communicatievoorzieningen/Inleiding#Context van communicatievoorzieningen|(zie hoofdstuk Context van communicatievoorzieningen)]] # Scope en begrenzing van het thema [[BIO Thema Communicatievoorzieningen/Inleiding#Scope en begrenzing|(zie hoofdstuk Scope en begrenzing)]] # Globale relaties tussen de geïdentificeerde beveiligingsobjecten [[BIO Thema Communicatievoorzieningen/Inleiding#Globale relaties tussen de beveiligingsobjecten|(zie hoofdstuk Globale relaties tussen de beveiligingsobjecten)]] ==Context van communicatievoorzieningen== De basis voor de uitwerking van het thema Communicatievoorzieningen is de BIO. In hoofdstuk 13 van de BIO worden verschillende typen communicatievoorzieningen genoemd, zoals geïllustreerd in de afbeelding 'Schematische weergave context communicatievoorzieningen', te weten: * Openbare diensten, Het gebruik van openbare diensten, zoals: instant messaging en sociale media (vehikel). * Elektronische berichten, Informatie opgenomen in elektronische berichten (inhoud). * Informatietransport, Het transporteren van informatie via allerlei communicatiefaciliteiten, zoals: e-mail, telefoon, fax en video (inhoud). * Netwerkdiensten, Het leveren van aansluitingen, zoals: firewalls, gateways, detectiesystemen en technieken voor te beveiligen netwerkdiensten, zoals authenticatie (vehikel). * Netwerk (infrastructuur), Dit betreft de fysieke en logische verbindingen (vehikel). [[Afbeelding:Schematische weergave context communicatievoorzieningen feb 2021.png|thumb|none|400px|Schematische weergave context communicatievoorzieningen|alt=”Schematische weergave context communicatievoorzieningen”]] Iedere organisatie met klantprocessen past deze communicatievoorzieningen toe en heeft een of meer koppelingen met de buitenwereld ingericht. Deze communicatie verloopt altijd via het onderste element: de netwerkinfrastructuur. Het gebruik van netwerkvoorzieningen vindt plaats zowel mobiel als via vaste netwerkvoorzieningen. In de praktijk bestaan er veel verschillende soorten koppelingen en een verscheidenheid aan netwerkvoorzieningen. Onderstaande afbeelding schetst de belangrijkste soorten van netwerkkoppelingen: * Tussen organisaties onderling * Tussen organisaties en publieke netwerken * Binnen organisaties [[Afbeelding:Thema Communicatievoorzieningen - Soorten netwerkkoppelingen.png|thumb|none|400px|Soorten netwerkkoppelingen|alt=”Soorten netwerkkoppelingen”]] Het doel van een netwerk is de uitwisseling van data tussen informatiedomeinen. Een informatiedomein bestaat uit een op hard- en softwarematige gebaseerde beveiligde verzameling van informatie. De beveiligingsmaatregelen binnen de ISO-standaard hebben betrekking op de hiervoor vermelde communicatievoorzieningen. Een van de meest toegepaste beveiligingsmaatregelen van de netwerkinfrastructuur is segmentering en compartimentering, tezamen zonering genoemd. Naast zonering zijn er andere beveiligingsobjecten van toepassing, zoals: ‘vertrouwd toegangspad’ en beveiliging in ‘koppelvlakken’. Hiervoor bieden de NORA-patronen een praktische invulling. In dit thema wordt een netwerk beschouwd als een infrastructuur (transportmedium), bestaande uit fysieke en logische verbindingen voorzien van koppelvlakken. Netwerken kunnen daarbij worden opgedeeld in segmenten, waarbij meerdere systemen logisch met elkaar gekoppeld zijn binnen één segment. ==Scope en begrenzing== Dit thema omvat een set communicatie-beveiligingsobjecten en -maatregelen voor netwerkvoorzieningen <sup class="reference smartref" id="cite_ref-ISO27033_1-0">[[BIO Thema Communicatievoorzieningen/Inleiding#cite_note-ISO27033-1|1]]</sup>, zoals weergegeven in de afbeelding 'Schematische weergave context communicatievoorzieningen'. De uitwerking van dit thema beperkt zich tot deze type communicatievoorzieningen. Er zijn essentiële objecten uit andere best practices dan de BIO gebruikt, die gerelateerd zijn aan dit type communicatievoorzieningen. Bepaalde type communicatiefaciliteiten, zoals: Voice over IP (VOIP), intranet en extranet zijn in dit thema niet uitgewerkt. Er wordt niet diepgaand ingegaan op: * bepaalde type verbindingen, zoals Virtual Private Network (VPN)- en gateway-verbindingen; * communicatievoorzieningen, zoals instant messaging en e-mail. De begrenzing van dit document is in onderstaande afbeelding weergegeven. [[Bestand:CVZ Relatie BIO Thema-uitwerking met aanpalende documenten.png|thumb|none |400px|Relatie BIO Thema-uitwerking met aanpalende documenten|alt=”Relatie BIO Thema-uitwerking met aanpalende documenten”]] ==Globale relaties tussen de beveiligingsobjecten== Onderstaande afbeelding geeft een voorbeeld van de toepassing van enkele beveiligingsobjecten in een informatievoorzieningslandschap waarin een organisatie met een gebruiker communiceert. Daarbij is sprake van netwerkconnecties die de verschillende netwerken en informatievoorzieningen met elkaar verbinden. Veilige koppelingen tussen organisaties en gebruikers kunnen worden opgezet met VPN’s. Gateways en firewalls zorgen met zonering en filtering voor de beoogde scheiding van de binnen- en buitenwereld en een gecontroleerde doorgang van vertrouwde informatie. Cryptografische services verzorgen de zonering voor het gegevenstransport via private en publieke netwerken, zodat informatie veilig kan worden uitgewisseld en bedrijfstoepassingen kunnen worden gebruikt. In de beschermde kantooromgeving van grote organisaties worden mobiele werkplekken met het bedrijfsnetwerk verbonden via draadloze toegang en worden beveiligd met onder andere netwerkauthenticatie. Een netwerkbeheerorganisatie draagt met richtlijnen zorg voor de instandhouding van netwerkbeveiliging en het actueel houden van beveiligingsmaatregelen. Via het vastleggen van events, de evaluatie van de netwerkmonitoring en het evalueren van de netwerkbeveiliging worden de actuele werking van de maatregelen getoetst en waar nodig versterkt. [[Afbeelding:Thema Communicatievoorzieningen - Toepassing van beveiligingsobjecten.png|thumb|none|400px|Toepassing van beveiligingsobjecten|alt=”Toepassing van beveiligingsobjecten”]] Meer over de technologie van beveiligingsobjecten is te vinden op de [[NORA online]] onder het thema [[Beveiliging]] bij de 'Patronen voor informatiebeveiliging'.  
==Inleiding en doel== Dit document biedt de gebruiker een korte samenvatting van het thema Communicatievoorzieningen en legt daarbij een verbinding tussen de BIO-norm met de uitvoeringspraktijk. Doel van dit document en elk BIO-thema, is organisaties handvatten te bieden en wegwijs te maken in welke beveiligingsnormen van toepassing zijn per aandachtsgebied en welke praktijkhulp daarbij beschikbaar is. ==Context== De basis voor de uitwerking van het thema Communicatievoorzieningen is de BIO en daarmee in het bijzonder Hoofdstuk 13 van ISO-27002; hierin worden verschillende type communicatievoorzieningen genoemd, zoals geschetst in onderstaande figuur: * Openbare diensten – het gebruik van openbare diensten, zoals: Instant messaging en sociale media (IV); * Elektronische berichten – Informatie opgenomen in elektronische berichten (Data); * Informatietransport - het transporteren van informatie via allerlei communicatiefaciliteiten, zoals: email, telefoon, fax video (Data); * Netwerkdiensten - het leveren van aansluitingen, zoals: firewalls, gateways, detectiesystemen en technieken voor de beveiligen netwerkdiensten, zoals authenticatie (IV); * Netwerk (infrastructuur) - het betreft fysieke en logische verbindingen (IV). [[Bestand:CVZ Schematische weergave context communicatievoorzieningen.png||thumb|none|500px|Schematische weergave context communicatievoorzieningen|alt=”Schematische weergave context communicatievoorzieningen”]] Iedere organisatie met klantprocessen, gebruikt communicatievoorzieningen en heeft daarvoor één of meer koppelingen met de buitenwereld ingericht. Deze communicatie verloopt altijd via de onderste element: de netwerkinfrastructuur. Het gebruik van netwerkvoorzieningen vindt plaats zowel mobiel als via vaste netwerkvoorzieningen. In de praktijk bestaan er veel verschillende soorten koppelingen en een verscheidenheid aan netwerkvoorzieningen. De beveiligingsmaatregelen binnen ISO hebben betrekking op de boven vermelde communicatievoorzieningen. Een van de belangrijkste beveiligingsmaatregelen van netwerkinfrastructuur is segmentering. Hierbij zijn beveiligingsobjecten van toepassing, zoals: zonering, filtering, vertrouwd toegangspad en koppelvlakken. Hiervoor bieden de NORA patronen een praktische invulling. In dit thema beschouwen we een netwerk als een infrastructuur (transportmedium) bestaande uit fysieke en logische verbindingen voorzien van koppelvlakken. ==Beveiligingsobjecten met cross reference naar handreikingen== Tabel "Beveiligingsobjecten met bronverwijzing" geeft een overzicht van de relevante, voor communicatiebeveiliging toe te passen beveiligingsobjecten, die afgeleid zijn van BIO-controls met een verwijzing naar praktische handreikingen. Daar waar er sprake is van een 1:1 relatie met BIO-controls, is dat hieronder aangegeven. De handreikingen zijn de door ISO gepubliceerde implementatiegidsen zoals ISO27033, de NIST, de Standard of Good Practice van ISF en NORA patronen. Hieronder is gekozen voor een alfabetische bronverwijzing per document, waarbij na de letter, b.v: a) het hoofdstuk/paragraaf wordt vermeld. De Bronverwijzing geeft het Documentnaam, Versie, Eigenaar en Toelichting. Voor dreigingen, aanbevelingen, planning en ontwerp van organisatie en techniek, kan de BSI: IT-Grundschutz catalogues worden geraadpleegd, die vrij toegankelijk is op internet; zie bronverwijzing. <table class="wikitable"><tr style="background-color:#d9d9d9"> <tr> <th class="tg-0lax">  Beveiligingsobject  </th> <th class="tg-0lax">  BIO Control  </th> <th class="tg-0lax">  Handreikingen  Zie Bronverwijzing voor  documentnaam en details.  </th> <th class="tg-0lax">  Toelichting of link  </th> </tr> <tr> <td class="tg-0lax">  Beleid en procedures  informatietransport  </td> <td class="tg-0lax">  13.2.1  </td> <td class="tg-0lax">  a)-6.2  </td> <td class="tg-0lax">  Overview and Concepts. Het  algemene deel van Network Security  </td> </tr> <tr> <td class="tg-0lax">  Overeenkomsten  informatietransport  </td> <td class="tg-0lax">  13.2.2  </td> <td class="tg-0lax">  g)-S.6  </td> <td class="tg-0lax">  Guidelines  for the design and implementation of network security  </td> </tr> <tr> <td class="tg-0lax">  Cryptografiebeleid  </td> <td class="tg-0lax">  10.1.1; 18.1.5.1  </td> <td class="tg-0lax">  a)- 8.8  </td> <td class="tg-0lax">  Reference  networking scenario’s Threats design techniques and control issues  </td> </tr> <tr> <td class="tg-0lax">  Organisatiestructuur  Netwerkbeheer  </td> <td class="tg-0lax">  ISO 27001 ISMS  </td> <td class="tg-0lax">  a)-8.2, l)  </td> <td class="tg-0lax">  Securing communications between  networks using security gateways  </td> </tr> <tr> <td class="tg-0lax">  Richtlijnen  netwerkbeveiliging  </td> <td class="tg-0lax">  Niet in BIO  </td> <td class="tg-0lax">  a) -8.2.2.3, b)-6,7,8  </td> <td class="tg-0lax">  Securing communications across  networks using Virtual Private Networks  </td> </tr> <tr> <td class="tg-0lax">  Beveiligde  inlogprocedure  </td> <td class="tg-0lax">  9.4.2  </td> <td class="tg-0lax">  a)-8.4  </td> <td class="tg-0lax">  Securing wireless IP network  access  </td> </tr> <tr> <td class="tg-0lax">  Netwerk  beveiligingsbeheer   </td> <td class="tg-0lax">  13.1.1  </td> <td class="tg-0lax">  a)-8.2  </td> <td class="tg-0lax">  https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/itgrundschutzkataloge_node.html  </td> </tr> <tr> <td class="tg-0lax">  Vertrouwelijkheid/geheimhoudingsovereenkomst  </td> <td class="tg-0lax">  13.2.4  </td> <td class="tg-0lax">  j) Roles and Responsibilities NW1.1  </td> <td class="tg-0lax">  Institute of Standards and  Technology: www.nist.gov  </td> </tr> <tr> <td class="tg-0lax">  Beveiliging  netwerkdiensten  </td> <td class="tg-0lax">  13.1.2  </td> <td class="tg-0lax">  a)-10.6  </td> <td class="tg-0lax">  Patronen:  https://www.noraonline.nl/wiki/Beveiliging  </td> </tr> <tr> <td class="tg-0lax">  Zonering en  filtering  </td> <td class="tg-0lax">  13.1.3  </td> <td class="tg-0lax">  a)-10.7, b)-7.2.3,  i)-Zoneringsmodel  </td> <td class="tg-0lax">  Information Security Forum: www.securityforum.org  </td> </tr> <tr> <td class="tg-0lax">  Elektronische  berichten  </td> <td class="tg-0lax">  13.2.3  </td> <td class="tg-0lax">  a)-10.3, 10.8  </td> <td class="tg-0lax">  Nationaal Cyber Security  Centrum (NCSC): www.ncsc.nl  </td> </tr> <tr> <td class="tg-0lax">  Toepassingen via  openbare netwerken  </td> <td class="tg-0lax">  14.2.1  </td> <td class="tg-0lax">     </td> <td class="tg-0lax">  Information Technology  Infrastructure Library  </td> </tr> <tr> <td class="tg-0lax">  Gateway / Firewall  </td> <td class="tg-0lax">  Niet in BIO  </td> <td class="tg-0lax">  d) geheel, i)-NORA  Koppelvlak, j)-NC1.5  </td> <td class="tg-0lax">  ISO-kader  voor: Encryption Algorithms  </td> </tr> <tr> <td class="tg-0lax">  Virtual Private  Networks (VPN)  </td> <td class="tg-0lax">  Niet in BIO  </td> <td class="tg-0lax">  e) geheel, i)-NORA Vertrouwd  toegangspad  </td> <td class="tg-0lax">  ISO-Information Security  Management Systems Guidance  </td> </tr> <tr> <td class="tg-0lax">  Cryptografische service  </td> <td class="tg-0lax">  Hoofdstuk 10  </td> <td class="tg-0lax">  a)-8.2.2.5, i)-NORA Encryptie patronen, j) NC1.1  </td> <td class="tg-0lax">  Encryption  algorithms: Asymmetric ciphers  </td> </tr> <tr> <td class="tg-0lax">  Wireless Access  </td> <td class="tg-0lax">  Niet in BIO  </td> <td class="tg-0lax">  f) geheel, i)-NORA  Draadloos netwerk  </td> <td class="tg-0lax">  Korte beschrijving van het SIVA raamwerk  met een uitgewerkte casus van de wijze waarop SIVA toegepast kan worden.  </td> </tr> <tr> <td class="tg-0lax">  Netwerk connecties  </td> <td class="tg-0lax">  Niet in BIO  </td> <td class="tg-0lax">  a)-8.2.2.5, i)-NORA Koppelvlak  </td> <td class="tg-0lax"></td> </tr> <tr> <td class="tg-0lax">  Netwerk  authenticatie  </td> <td class="tg-0lax">  Niet in BIO  </td> <td class="tg-0lax">  i)-NORA  Beschouwingsmodel Netwerk  </td> <td class="tg-0lax"></td> </tr> <tr> <td class="tg-0lax">  Netwerkbeheeractiviteit  </td> <td class="tg-0lax">  13.1  </td> <td class="tg-0lax">  a), b)-8.4  </td> <td class="tg-0lax"></td> </tr> <tr> <td class="tg-0lax">  Vastleggen  netwerkevents  </td> <td class="tg-0lax">  12.4  </td> <td class="tg-0lax">  a), b)-8.5  </td> <td class="tg-0lax"></td> </tr> <tr> <td class="tg-0lax">  Netwerk security  architectuur  </td> <td class="tg-0lax">  Niet in BIO  </td> <td class="tg-0lax">  a)-9.2, b)-8.6, NORA div. patronen, j) Network design  </td> <td class="tg-0lax"></td> </tr> <tr> <td class="tg-0lax">  Naleving richtlijnen  netwerkbeheer en evaluaties  </td> <td class="tg-0lax">  18.2.2  </td> <td class="tg-0lax">  j) Corporate Governance: SM1.1.1, SM3.5.2  </td> <td class="tg-0lax"></td> </tr> <tr> <td class="tg-0lax">  Netwerk security compliancy checking  </td> <td class="tg-0lax">  18.2.3  </td> <td class="tg-0lax">  a)-8.2.2.4, b)-7.2.6, 8.7  </td> <td class="tg-0lax"></td> </tr> <tr> <td class="tg-0lax">  Evalueren robuustheid  netwerkbeveiliging  </td> <td class="tg-0lax">  18.2.1,  18.1.2,  ISO 27001 ISMS  </td> <td class="tg-0lax">  a)-8.2.5, j) Network resilience: NW1.3  </td> <td class="tg-0lax"></td> </tr> <tr> <td class="tg-0lax">  Evalueren  gebeurtenissen (monitoring)  </td> <td class="tg-0lax">  16.1  </td> <td class="tg-0lax">  a)-8.2.4  </td> <td class="tg-0lax"></td> </tr> <tr> <td class="tg-0lax">  Beheersorganisatie Netwerkbeveiliging  </td> <td class="tg-0lax">  13.1  </td> <td class="tg-0lax">  n), j) Network  Documentation: NW 1.4  </td> <td class="tg-0lax"></td> <caption align="bottom">Communicatievoorzieningen, ISOR:Communicatievoorzieningen - Beveiligingsobjecten met bronverwijzing</caption></table> [[Categorie:ISOR]] [[Categorie:BIO Thema Communicatievoorzieningen]] ==Overzicht objecten gepositioneerd in BUC/IFGS matrix== Hieronder zijn alle onderwerpen voor communicatiebeveiliging samengevat. Vervolgens worden deze onderwerpen (objecten) verbonden aan BIO-‘controls’, of aan controls uit andere relevante standaarden. De figuur 'Voor Communicatievoorzieningen relevante beveiligingsobjecten' is het resultaat van een volledigheidsanalyse, uitgevoerd met de SIVA methode (zie: SIVA toepassingssystematiek). De wit ingekleurde objecten zijn relevant voor het thema, maar ontbreken als control in de ISO 27002. Ze zijn afkomstig uit andere standaarden en ISO implementatiegidsen (zie: cross-reference). [[Bestand:CVZ Overzicht beveiligingsobjecten.png|thumb|none|500px|Voor Communicatievoorzieningen relevante beveiligingsobjecten|alt=”Voor Communicatievoorzieningen relevante beveiligingsobjecten”]] ==Bronverwijzing== Onderstaande lijst van brondocumenten verwijst waar mogelijk naar publiek- toegankelijke documenten. * Om ‘dode’ verwijzingen te voorkomen is minimaal gebruik gemaakt van links. * Via Rijksweb of overheids interne websites of Google-search kunnen de documenten gevonden worden. * Op NEN-ISO/IEC documenten rusten licentierechten; voor de overheid zijn deze afgekocht (log in via NEN-connect). * Voor raadplegen van ISF documenten, zoals o.a. de SoGP moet de gebruikersorganisatie lid zijn van het ISF. * IT-Grundschutz, NORA en NIST zijn vrij toegankelijk op internet. <table class="wikitable"><tr style="background-color:#d9d9d9"> <tr> <th class="tg-s268">  Nr.  </th> <th class="tg-0lax">  Documentnaam  </th> <th class="tg-0lax">  Versie  </th> <th class="tg-0lax">  Eigenaar  </th> <th class="tg-0lax">  Toelichting of link  </th> </tr> <tr> <td class="tg-0lax">  a)  </td> <td class="tg-0lax">  ISO  27033 Deel 1  </td> <td class="tg-0lax">  Aug  2015  </td> <td class="tg-0lax">  NEN-ISO/IEC  </td> <td class="tg-0lax">  Overview and Concepts. Het  algemene deel van Network Security  </td> </tr> <tr> <td class="tg-0lax">  b)  </td> <td class="tg-0lax">  ISO  27033 Deel 2  </td> <td class="tg-0lax">  Aug 2012  </td> <td class="tg-0lax">  NEN-ISO/IEC  </td> <td class="tg-0lax">  Guidelines  for the design and implementation of network security  </td> </tr> <tr> <td class="tg-0lax">  c)  </td> <td class="tg-0lax">  ISO  27033 Deel 3  </td> <td class="tg-0lax">  Dec 2010  </td> <td class="tg-0lax">  NEN-ISO/IEC  </td> <td class="tg-0lax">  Reference  networking scenario’s Threats design techniques and control issues  </td> </tr> <tr> <td class="tg-0lax">  d)  </td> <td class="tg-0lax">  ISO  27033 Deel 4  </td> <td class="tg-0lax">  Feb  2014  </td> <td class="tg-0lax">  NEN-ISO/IEC  </td> <td class="tg-0lax">  Securing communications between  networks using security gateways  </td> </tr> <tr> <td class="tg-0lax">  e)  </td> <td class="tg-0lax">  ISO  27033 Deel 5  </td> <td class="tg-0lax">  Aug  2013  </td> <td class="tg-0lax">  NEN-ISO/IEC  </td> <td class="tg-0lax">  Securing communications across  networks using Virtual Private Networks  </td> </tr> <tr> <td class="tg-0lax">  f)  </td> <td class="tg-0lax">  ISO  27033 Deel 6  </td> <td class="tg-0lax">  Juni  2016  </td> <td class="tg-0lax">  NEN-ISO/IEC  </td> <td class="tg-0lax">  Securing wireless IP network  access  </td> </tr> <tr> <td class="tg-0lax">  g)  </td> <td class="tg-0lax">  BSI: IT-Grundschutz  </td> <td class="tg-0lax">  2013  </td> <td class="tg-0lax">  DE  gov.  </td> <td class="tg-0lax">  https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/itgrundschutzkataloge_node.html  </td> </tr> <tr> <td class="tg-0lax">  h)  </td> <td class="tg-0lax">  NIST  </td> <td class="tg-0lax">  nvt  </td> <td class="tg-0lax">  US gov.  </td> <td class="tg-0lax">  Institute of Standards and  Technology: www.nist.gov  </td> </tr> <tr> <td class="tg-0lax">  i)  </td> <td class="tg-0lax">  NORA,  thema beveiliging  </td> <td class="tg-0lax">  Wiki  </td> <td class="tg-0lax">  NL gov.  </td> <td class="tg-0lax">  Patronen:  https://www.noraonline.nl/wiki/Beveiliging  </td> </tr> <tr> <td class="tg-0lax">  j)  </td> <td class="tg-0lax">  ISF  Standard of Good Practice (SoGP)  </td> <td class="tg-0lax">  2007  </td> <td class="tg-0lax">  ISF  </td> <td class="tg-0lax">  Information Security Forum: www.securityforum.org  </td> </tr> <tr> <td class="tg-0lax">  k)  </td> <td class="tg-0lax">  NCSC  (diverse documenten)  </td> <td class="tg-0lax">  nvt  </td> <td class="tg-0lax">  NCSC  </td> <td class="tg-0lax">  Nationaal Cyber Security  Centrum (NCSC): www.ncsc.nl  </td> </tr> <tr> <td class="tg-0lax">  l)  </td> <td class="tg-0lax">  ITIL  </td> <td class="tg-0lax">  Versie 3  </td> <td class="tg-0lax">  ITIL foundation  </td> <td class="tg-0lax">  Information Technology  Infrastructure Library  </td> </tr> <tr> <td class="tg-0lax">  m)  </td> <td class="tg-0lax">  ISO 18033-1 General  </td> <td class="tg-0lax">  Aug 2015  </td> <td class="tg-0lax">  NEN-ISO/IEC  </td> <td class="tg-0lax">  ISO-kader  voor: Encryption Algorithms  </td> </tr> <tr> <td class="tg-0lax">  n)  </td> <td class="tg-0lax">  ISO 27003 ISMS  </td> <td class="tg-0lax">  Apr 2017  </td> <td class="tg-0lax">  NEN-ISO/IEC  </td> <td class="tg-0lax">  ISO-Information Security  Management Systems Guidance  </td> </tr> <tr> <td class="tg-0lax">  o)  </td> <td class="tg-0lax">  ISO 18033-2  </td> <td class="tg-0lax">  Juni  2006  </td> <td class="tg-0lax">  NEN-ISO/IEC  </td> <td class="tg-0lax">  Encryption  algorithms: Asymmetric ciphers  </td> </tr> <tr> <td class="tg-0lax">  p)  </td> <td class="tg-0lax">  SIVA toepassingssystematiek  </td> <td class="tg-0lax">  Versie  0.4  </td> <td class="tg-0lax">  Werkgroep Normatiek  </td> <td class="tg-0lax">  Korte beschrijving van het SIVA raamwerk  met een uitgewerkte casus van de wijze waarop SIVA toegepast kan worden.  </td> </tr> <caption align="bottom">Communicatievoorzieningen, Bronverwijzing</caption></table> [[Categorie:ISOR]] [[Categorie:BIO Thema Communicatievoorzieningen]]  
==Schematische weergave huisvesting IV-objecten== Huisvesting IV omvat een geheel van objecten voor het leveren van betrouwbare hostingdiensten. De essentiële objecten van huisvesting IV worden in afbeelding 'Schematische weergave huisvesting IV-objecten' weergegeven. De elementen worden toegelicht met het beleids-, uitvoerings- en control-domein. [[Bestand:HVI Schematische weergave huisvesting informatievoorzieningsobjecten.png|none|thumb|500px|Afbeelding: Schematische weergave huisvesting IV-objecten|alt=” Schematische weergave huisvesting IV-objecten”]] ==Beleidsdomein== Binnen het beleidsdomein bevat huisvesting IV randvoorwaarden. Objecten die als randvoorwaarden gelden voor de gehele huisvesting IV zijn: beleid, wet- en regelgeving, contracten en organisatiestructuur e.d. ==Uitvoeringsdomein== Binnen het uitvoeringsdomein bevat huisvesting IV een scala aan componenten die grofweg zijn onder te verdelen in: * Terrein, Terrein betreft de locaties van huisvesting IV. * Gebouwen, faciliteiten en werkruimten, Gebouwen, faciliteiten en werkruimten zijn de aan huisvesting IV-georiënteerde objecten. Ze zorgen voor het fysieke bestaan van huisvesting IV. Onder het fysieke bestaan vallen ook de terreinen en de zonering (in ruimten) van gebouwen. * Voorzieningen, Voorzieningen zijn gerelateerd aan de fysiek georiënteerde objecten voor huisvesting IV. Dit is gericht op bedrijfsmiddelen en nutsvoorzieningen (zoals gas, elektra, water maar ook brandblussers etc.). Er zijn bedrijfsmiddelen en specifieke IT-middelen ingezet waarmee huisvesting IV-diensten worden geleverd. Deze middelen zijn continu onderhevig aan veranderingen en vernieuwingen. Voor een optimale dienstverlening moeten deze middelen onderhouden en/of gecontroleerd worden. Met andere woorden, dit zijn zowel fysieke als elektronisch en informatietechnologie-gerelateerde objecten voor de te leveren huisvesting IV-diensten. ==De organisatie van huisvesting IV-objecten== De geïdentificeerde huisvesting IV-objecten zijn met het beleids-, uitvoerings- en control-domein georganiseerd. Hiermee worden deze aspecten in een juiste contextuele samenhang gepositioneerd. De betekenissen van de lagen zijn: * Beleidsdomein, Binnen dit domein bevinden zich conditionele elementen over huisvesting IV. Hier zijn eisen opgenomen over geboden en verboden, zoals het huisvesting IV-beleid, de te hanteren wet- en regelgeving en andere vormen van reguleringen en beperkingen. * Uitvoeringsdomein, Binnen dit domein bevinden zich: ** elementen die gerelateerd zijn aan operationele activiteiten van huisvesting IV; ** 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-domein, Binnen dit domein bevinden zich elementen die zorgdragen voor de beheersing en/of het in standhouden van de activiteiten in relatie tot huisvesting IV en of deze wel naar wens verlopen. Objecten worden inclusief omschrijving opgeslagen in de objectenbibliotheek ISOR. ISOR staat voor Information Security Object Repository. Enkele van de objecten zijn uniek voor de [[BIO (Baseline Informatiebeveiliging Overheid)|Baseline Informatiebeveiliging Overheid (BIO)]]. Objecten die aanvullend aan de [[NEN-EN-ISO/IEC 27002:2017 (Praktijkrichtlijn met beheersmaatregelen op het gebied van informatiebeveiliging)|ISO 27002]] voor de beveiliging van een bepaald toepassingsgebied nodig geacht worden, zijn met de [[SIVA-methodiek|Structuur, Inhoud, Vorm en Analysevolgorde (SIVA)-methodiek]] bepaald. Deze relateren zo mogelijk aan standaarden als de [[The Standard of Good Practice for Information Security 2018|Standard of Good Practice (SoGP)]].  
Deze thema-uitwerking bevat een referentiekader voor het thema Huisvesting Informatievoorzieningen, hierna genoemd Huisvesting IV. Het is gebaseerd op de controls uit de [[BIO (Baseline Informatiebeveiliging Overheid)|Baseline Informatiebeveiliging Overheid (BIO)]]. Voor die aspecten, waar de BIO onvoldoende praktische invulling geeft, zijn onder andere de volgende best practices geraadpleegd: [[NEN-EN-ISO/IEC 27002:2017 (Praktijkrichtlijn met beheersmaatregelen op het gebied van informatiebeveiliging)|ISO 27002]], [[The Standard of Good Practice for Information Security 2018|Standard of Good Practice (SoGP)]] en [[NIST (National Institute of Standards and Technology)|National Institute of Standards and Technology (NIST)]]. Afbeelding 'Overzicht BIO-thema’s en positie thema Huisvesting IV' geeft de relatie weer tussen het thema Huisvesting IV en de overige [[Alle normenkaders|BIO Thema-uitwerkingen]]. [[Bestand:Thema Huisvesting - Overzicht van thema's en de positie van Huisvesting IT Infrastructuur.png|thumb|none|500px|Overzicht BIO-thema’s en positie thema Huisvesting IV|alt=”Overzicht BIO-the-ma’s en positie thema Huisvesting IV”]] ==Huisvesting IV== In deze thema-uitwerking is een set beveiligingsmaatregelen voor het thema Huisvesting IV opgenomen. Deze beveiligingsmaatregelen zijn gerelateerd aan relevante onderwerpen (objecten) uit de BIO. Objecten die ontbreken in de BIO en die uit analyses voortvloeien, worden betrokken uit andere best practices, zoals de ISO 27002 en de SoGP. Voor noodzakelijke details bij specifieke maatregelen wordt verwezen naar operationele practices. De relatie tussen deze documenten wordt in afbeelding 'Relatie BIO Thema-uitwerking met aanpalende documenten' weergegeven. [[Bestand:HVI Relatie BIO Thema-uitwerking met aanpalende documenten.png|thumb|none|500px|Relatie BIO Thema-uitwerking met aanpalende documenten|alt=”Relatie BIO Thema-uitwerking met aanpalende documenten”]] De objecten en de bijbehorende maatregelen gelden zowel voor implementatie- als voor auditdoeleinden. Samenvattend komt het erop neer dat de objecten en de bijbehorende maatregelen georganiseerd zijn in drie domeinen: beleid, uitvoering en control. Afbeelding 'Thema Huisvesting Relatie tussen objecten in het beleids-, uitvoerings- en control-domein' schetst de structuur waarin een relatie wordt gelegd tussen de objecten binnen het beleids-, uitvoerings- en control-domein voor huisvesting IV. [[Bestand:HVI Relatie tussen objecten in het beleids-, uitvoerings- en control-domein.png|thumb|none|500px|Relatie tussen objecten in het beleids-, uitvoerings- en control-domein|alt=”Relatie tussen objecten in het beleids-, uitvoerings- en control-domein”]] ==Scope en begrenzing van Huisvesting IV== De te stellen eisen aan huisvesting IV worden in het bijzonder bepaald door de fysieke bescherming van de apparatuur, die gebruikt wordt voor verwerking, transport en opslag van data. De opkomst van de IT-clouddiensten betekent veranderingen in de aanschaf van IT-diensten en de daarvoor benodigde huisvesting. Het management van de doelorganisatie blijft verantwoordelijk voor het gehele bedrijfsproces en onderliggende IT-ondersteuning. Daarom worden er besluiten genomen op basis van: functionaliteit, wet- en regelgeving (beveiliging) en kosten. Dit heeft invloed op de keuze welke type huisvesting IV past bij de organisatie. De volgende drie opties zijn mogelijk: # Fysieke huisvesting, Bij deze traditionele huisvesting is het rekencentrum ondergebracht binnen één fysieke locatie onder beheer van de doelorganisatie. # Modulaire huisvesting, Bij deze huisvestingsvorm is het rekencentrum ondergebracht in mobiele bouwblokken, die flexibel ‘gestapeld’ kunnen worden tot de benodigde capaciteit bereikt is (vrachtcontainers). # Virtuele huisvesting, Bij deze vorm is het rekencentrum ondergebracht in een (private of publieke) cloud. Bij deze vorm van huisvesting valt slechts een beperkt deel van de bedrijfsmiddelen onder het technisch beheer en de bestuurlijke invloed van de doelorganisatie. Men neemt een dienst af en stelt eisen. Hoe groot de invloed van de doelorganisatie is, hangt af van inrichtingskeuzes, maar vooral van de te leveren diensten door leveranciers, zoals Infrastructure As A Service (IAAS), Platform as a Service (PAAS) of Software As A Service (SAAS). Deze thema-uitwerking beschrijft optie 1 ‘Fysieke huisvesting’ en daarbij de objecten voor huisvesting IV, die gerelateerd zijn aan terreinen, gebouwen, ruimten en middelen, zoals aangegeven in onderstaande afbeelding. Vanuit het huisvestingsbeleid (zie [[ISOR:BIO Thema Huisvesting Informatievoorziening Beleid|het beleidsdomein]]) wordt de inrichting en beveiliging van de resources binnen het uitvoeringsdomein aangestuurd en met beheersing op de uitvoering wordt grip verkregen op de naleving van de gestelde beveiligingseisen (zie [[ISOR:BIO Thema Huisvesting Informatievoorziening Uitvoering|het control-domein]]). [[Bestand:HVI Overzicht fysieke huisvesting informatievoorzieningen.png|thumb|none|500px|Overzicht fysieke huisvesting IV|alt=”Overzicht fysieke huisvesting IV”]] ==Aanpak uitwerking thema huisvesting IV== Het toelichtingsdocument schetst de standaardmethodiek waarmee BIO Thema-uitwerkingen worden opgesteld. Een uitgebreide uitwerking van de methodiek is beschreven in het document: ‘SIVA en toepassingssystematiek’.  
==Context beveiliging Huisvesting-IV== [[Afbeelding:Thema Huisvesting - Verbindingsniveau voor huisvesting.png|thumb|none|250px|Verbindingsniveau voor Huisvesting Informatievoorziening|alt=”Verbindingsniveau voor Huisvesting Informatievoorziening”]] Een gebouw van een willekeurig vrijstaand rekencentrum is doorgaans gepositioneerd op een terrein waarbij de toegang door middel van hekwerk is afgesloten voor publiek. Dit vormt de eerste barrière van fysieke beveiliging. Personen zoals bezoekers moeten zich melden aan de toegangspoort alvorens ze naar binnen kunnen. Medewerkers kunnen direct naar binnen, gebruik makend hun toegangspas. Eenmaal op het terrein, kunnen medewerkers alleen de ruimten waarvoor ze bevoegd zijn betreden met hun toegangspas. De informatiesystemen zelf zijn ondergebracht in afgeschermde, klimaat geconditioneerde ruimten, voorzien van een stabiele energievoorziening. Goederen worden via een seperate laad-en los omgeving van- en naar de gebouwen en ruimten gebracht. Kabels voor nuts- en netwerkvoorzieningen worden extra beschermd en waar nodig dubbel uitgevoerd, zodat de continuïteit van informatievoorziening naar behoefte gegarandeerd is. Figuur 'Context Huisvesting Informatievoorziening' schetst enkele basiselementen voor de huisvesting van informatievoorzieningen (IV). [[Afbeelding:Thema Huisvesting - Context Huisvesting-IV.png|thumb|none|600px|Context Huisvesting Informatievoorziening|alt=”Context Huisvesting Informatievoorziening”]] Figuur 'Essentiële objecten in het uitvoering domein' geeft laat van het uitvoeringsdomein een schematische invulling zien. Het beleidsdomein omvat de randvoorwaarden voor de uitvoering van Huisvesting Informatievoorziening. De beheersing wordt verzorgd door objecten vanuit het control domein, zoals beoordelingsrichtlijnen en Continuïteitsmanagement (BCM). [[Afbeelding:Thema Huisvesting - Essentiële objecten in het uitvoeringsdomein.png|thumb|none|700px|Essentiële objecten in het uitvoering domein|alt=”Essentiële objecten in het uitvoering domein”]] Huisvesting Informatievoorziening omvat een geheel van objecten voor het leveren van betrouwbare hosting diensten. De essentiële objecten van Huisvesting-IV, of groepen daarvan, zijn uitgelicht in onderstaande figuur. [[Afbeelding:Thema Huisvesting - Objecten in het uitvoeringsdomein.png|none|thumb|500px|Objecten in het uitvoering domein|alt=”Objecten in het uitvoering domein”]] Het uitvoeringsdomein bevat een scala aan componenten die grofweg onder te verdelen zijn in Terreinen, Gebouwen, Faciliteiten, Werkruimten en Voorzieningen. De gebouwen zijn gevestigd op een locatie. *'''Terrein''' – de omheinde, beschermde locaties van de Huisvesting IV *'''Gebouwen''' – Dit zijn aan de huisvesting georiënteerde objecten die zorgen voor het fysieke bestaan van een Huisvesting Informatievoorziening. Hieronder valt ook de fysieke zonering van gebouwen in ruimten. *'''Voorzieningen''' – Voorzieningen zijn gerelateerd aan de fysiek georiënteerde objecten ten behoeve van de huisvesting. Dit is gericht op: Bedrijfsmiddelen en Nutsvoorzieningen (zoals gas, elektra, water maar ook brandblussers etc.). *'''Faciliteiten''' - Middelen waarmee beveiligingsfuncties gerealiseerd worden, zoals toegangspoorten, brandmelders/blussers etc. Er zijn bedrijfsmiddelen en specifieke IT-middelen ingezet waarmee Huisvesting Informatievoorziening diensten worden geleverd. Deze middelen zijn continu onderhevig aan veranderingen en vernieuwingen. Voor een optimale dienstverlening moeten deze middelen onderhouden en/of gecontroleerd worden. M.a.w. dit zijn zowel fysieke als elektronisch en informatietechnologie gerelateerde objecten ten behoeve van de te leveren huisvesting van IV diensten. ==Generieke objecten== Onderstaande tabel toont alle relevante items op een rij, die in samenhang de Huisvesting Informatievoorziening kunnen beveiligen. <table class="wikitable"><tr style="background-color:#d9d9d9"><th> Nr </th> <th> Bron: ISO/BIO of alternatief </th> <th> Generieke objecten </th></tr><tr><td>1. </td> <td>5.1.1. </td> <td style="background-color:#ffcc00">Huisvestingsbeleid </td></tr><tr><td>2. </td> <td>7.2.2. </td> <td style="background-color:#ffcc00">Training en Awareness </td></tr><tr><td>3. </td> <td>8.1.2. </td> <td style="background-color:#ffcc00">Eigenaarschap </td></tr><tr><td>4. </td> <td>18.1.1. </td> <td style="background-color:#ffcc00">Wet en regelgeving </td></tr><tr><td>5. </td> <td>Uit SIVA analyse </td> <td style="background-color:#ffcc00">Organisatie </td></tr><tr><td>6. </td> <td>Uit SIVA analyse </td> <td style="background-color:#ffcc00">Architectuur </td></tr><tr><td>7. </td> <td>idem -> ITIL </td> <td style="background-color:#ffcc00">Contractmanagement </td></tr><tr><td>8. </td> <td>idem -> ITIL </td> <td style="background-color:#ffcc00">Servicelevelmanagement </td></tr><tr><td>9. </td> <td>idem -> NIST </td> <td style="background-color:#ffcc00">Certificering </td></tr><tr><td>10. </td> <td>8.1.1. </td> <td style="background-color:#ff9999">Bedrijfsmiddelen inventaris </td></tr><tr><td>11. </td> <td>11.1.1. </td> <td style="background-color:#ff9999">Fysieke zonering </td></tr><tr><td>12. </td> <td>11.1.2. </td> <td style="background-color:#ff9999">Fysieke toegangsbeveiliging </td></tr><tr><td>13. </td> <td>11.1.3. </td> <td style="background-color:#ff9999">Beveiligingsfaciliteit </td></tr><tr><td>14. </td> <td>11.1.4. </td> <td style="background-color:#ff9999">Interne en Externe bedreigingen </td></tr><tr><td>15. </td> <td>11.1.5. </td> <td style="background-color:#ff9999">Richtlijnen gebieden en ruimten </td></tr><tr><td>16. </td> <td>11.1.6. </td> <td style="background-color:#ff9999">Laad- en loslocatie </td></tr><tr><td>17. </td> <td>11.2.1. </td> <td style="background-color:#ff9999">Apparatuur positionering </td></tr><tr><td>18. </td> <td>11.2.2. </td> <td style="background-color:#ff9999">Nutsvoorzieningen </td></tr><tr><td>19. </td> <td>11.2.3. </td> <td style="background-color:#ff9999">Bekabeling </td></tr><tr><td>20. </td> <td>11.2.4. </td> <td style="background-color:#ff9999">Apparatuur onderhoud </td></tr><tr><td>21. </td> <td>11.2.5. </td> <td style="background-color:#ff9999">Bedrijfsmiddelen verwijdering </td></tr><tr><td>22. </td> <td>11.2.7. </td> <td style="background-color:#ff9999">Apparatuur verwijdering </td></tr><tr><td>23. </td> <td>9.2.1. </td> <td style="background-color:#99ccff">Registratieprocedure </td></tr><tr><td>24. </td> <td>9.2.4. </td> <td style="background-color:#99ccff">Beoordeling Fysieke toegangsrechten </td></tr><tr><td>25. </td> <td>Uit SIVA analyse </td> <td style="background-color:#99ccff">Controle richtlijn Huisvesting-IV </td></tr><tr><td>26. </td> <td>idem </td> <td style="background-color:#99ccff">Onderhoudsplan </td></tr><tr><td>27. </td> <td>idem </td> <td style="background-color:#99ccff">Huisvestingsbeheerorganisatie </td></tr><tr><td>28. </td> <td>idem -> ITIL </td> <td style="background-color:#99ccff">Continuïteitsmanagement </td></tr> <caption align="bottom">Tabel 6: Vastgestelde generieke objecten</caption></table> [[:ISOR:Tabellen BUC legenda]] Dergelijke items worden in de BIO- thema’s objecten genoemd. De meeste van deze objecten zijn in de vorm van een beheersmaatregel al van kracht in de ISO-27001. De objecten zijn generiek gemaakt, om ze voor andere thema’s kunnen hergebruiken. Generieke objecten worden inclusief omschrijving opgeslagen in de objectenbibliotheek ISOR. Enkele van de objecten zijn uniek voor de overheid en daarom in de BIO ‘verplicht’ genormeerd zijn. Objecten, die aanvullend aan de ISO norm nodig geacht worden voor de beveiliging van een bepaald toepassingsgebied, zijn met behulp van de SIVA analyse bepaald en relateren daarbij zo mogelijk aan standaarden als ITIL, NIST, BSI of de Standard of Good Practice. ==Positionering van objecten gerelateerd aan SIVA basiselementen== [[Bestand:HVI Overzicht objecten voor huisvesting informatievoorzieningen in het beleidsdomein.png|thumb|none|500px|Objecten in het Beleidsdomein|alt=”Objecten in het beleids-domein”]] [[Bestand:HVI Overzicht objecten voor huisvesting informatievoorzieningen in het uitvoeringsdomein.png|thumb|none|500px|Objecten in het Beleidsdomein|alt=”Objecten in het uitvoeringsdomein”]] [[Bestand:HVI Overzicht objecten voor huisvesting informatievoorzieningen in het control-domein.png|thumb|none|500px|Objecten in het Beleidsdomein|alt=”Objecten in het control-domein”]] Figuur 'Objecten in hun B-U-C domein' zet de objecten uit de lijst van figuur 4 bij elkaar in de aandachtsgebieden Beleid, Uitvoering en Control, feitelijk een andere view op de inhoud van de vorige pagina. In totaal gaat het om Gebouwen en voorzieningen, wat alles is wat je nodig hebt om ICT te kunnen huisvesten, zoals infrastructuur: kabels, stroomvoorziening, koeling etc. inclusief de nodige procedures en beheervoorzieningen. In cursief-rood zijn de SIVA-basiselementen weergegeven. De “witte blokken” zijn de objecten die weliswaar niet genormeerd zijn in de ISO-norm, maar waarvan wel geacht wordt dat ze een onmisbare bijdrage leveren aan de weerbaarheid en de integrale beveiliging van de bedrijfsmiddelen, informatievoorzieningen en data. ==Cross Reference naar praktijktoepassingen== Tenslotte een Cross-Reference van beveiligingsobjecten naar beproefde praktijkvoorbeelden. Doel is de overheden praktische handreikingen aan te bieden, in de vorm van richtlijnen en patronen; bij voorkeur gesorteerd op verschillende schaalgroottes met een bijbehorende uitvoeringscontext. <table class="wikitable"><caption align="bottom">cross-reference naar praktijktoepassingen</caption> <tr><td>Nr. </td> <td>Bron:ISO… </td> <td>  </td> <td>Onderwerp </td> <td>Referentie naar praktijktoepassing(Verwijzing naar brondocumenten) </td></tr><tr><td>1. </td> <td>5.1.1. </td> <td style="background-color:#ffd966">B </td> <td>Huisvestingsbeleid </td> <td>a):H2 en H3, b), c):met focus op “Te beschermen belangen” (TBB), e) </td></tr><tr><td>2. </td> <td>7.2.2. </td> <td style="background-color:#ffd966">B </td> <td>Training en Awareness </td> <td>a):H4, h), j), i </td></tr><tr><td>3. </td> <td>8.1.2. </td> <td style="background-color:#ffd966">B </td> <td>Eigenaarschap </td> <td>a):H2 (voor rijk), j), i) </td></tr><tr><td>4. </td> <td>18.1.1. </td> <td style="background-color:#ffd966">B </td> <td>Wet en regelgeving </td> <td>i) </td></tr><tr><td>5. </td> <td>SIVA </td> <td style="background-color:#ffd966">B/U </td> <td>Organisatie </td> <td>a):H4 </td></tr><tr><td>6. </td> <td>SIVA </td> <td style="background-color:#ffd966">B/U </td> <td>Architectuur </td> <td>i), Richtlijnen - Rijks vastgoedbedrijf (RVB) </td></tr><tr><td>7. </td> <td>ITIL </td> <td style="background-color:#ffd966">B </td> <td>Contractmanagement </td> <td>a):H8, f) </td></tr><tr><td>8. </td> <td>ITIL </td> <td style="background-color:#ffd966">B </td> <td>Servicelevelmanagement </td> <td>f) </td></tr><tr><td>9. </td> <td>NIST </td> <td style="background-color:#ffd966">B </td> <td>Certificering </td> <td>g) </td></tr><tr><td>10. </td> <td>8.1.1. </td> <td style="background-color:#ff9999">U/VZ </td> <td>Bedrijfsmiddelen inventaris </td> <td>i) </td></tr><tr><td>11. </td> <td>11.1.1. </td> <td style="background-color:#ff9999">U/GB </td> <td>Fysieke zonering </td> <td>a): H6, c), e), i) </td></tr><tr><td>12. </td> <td>11.1.2. </td> <td style="background-color:#ff9999">U/VZ </td> <td>Fysieke toegangsbeveiliging </td> <td>a): H6, b), c), i) </td></tr><tr><td>13. </td> <td>11.1.3. </td> <td style="background-color:#ff9999">U/VZ </td> <td>Beveiligingsfaciliteit </td> <td>NKBR 5.4 voor sleutelplan </td></tr><tr><td>14. </td> <td>11.1.4. </td> <td style="background-color:#ff9999">U </td> <td>Interne en Externe bedreigingen </td> <td>i), k) </td></tr><tr><td>15. </td> <td>11.1.5. </td> <td style="background-color:#ff9999">U/GB </td> <td>Richtlijnen gebieden en ruimten </td> <td>a):geheel document, j), i), o) </td></tr><tr><td>16. </td> <td>11.1.6. </td> <td style="background-color:#ff9999">U/GB </td> <td>Laad- en loslocatie </td> <td>a):H6 </td></tr><tr><td>17. </td> <td>11.2.1. </td> <td style="background-color:#ff9999">U/VZ </td> <td>Apparatuur positionering </td> <td>a):H7 voor beveiligingsvoorzieningen, i), o) </td></tr><tr><td>18. </td> <td>11.2.2. </td> <td style="background-color:#ff9999">U/VZ </td> <td>Nutsvoorzieningen </td> <td>i), Richtlijnen - RVB </td></tr><tr><td>19. </td> <td>11.2.3. </td> <td style="background-color:#ff9999">U/VZ </td> <td>Bekabeling </td> <td>i), o), Richtlijnen - RVB </td></tr><tr><td>20. </td> <td>11.2.4. </td> <td style="background-color:#ff9999">U/VZ </td> <td>Apparatuur onderhoud </td> <td>i), Richtlijnen - RVB </td></tr><tr><td>21. </td> <td>11.2.5. </td> <td style="background-color:#ff9999">U/VZ </td> <td>Bedrijfsmiddelen verwijdering </td> <td>i) </td></tr><tr><td>22. </td> <td>11.2.7. </td> <td style="background-color:#ff9999">U/VZ </td> <td>Apparatuur verwijdering </td> <td>i) </td></tr><tr><td>23. </td> <td>9.2.1. </td> <td style="background-color:#99ccff">C </td> <td>Registratieprocedure </td> <td>i) </td></tr><tr><td>24. </td> <td>9.2.4. </td> <td style="background-color:#99ccff">C </td> <td>Beo. Fysieke toegangsrechten </td> <td>i) </td></tr><tr><td>25. </td> <td>SIVA </td> <td style="background-color:#99ccff">C </td> <td>Controle richtlijn Huisvesting-IV </td> <td>? Richtlijnen - RVB </td></tr><tr><td>26. </td> <td>SIVA </td> <td style="background-color:#99ccff">C </td> <td>Onderhoudsplan </td> <td>? Richtlijnen - RVB </td></tr><tr><td>27. </td> <td>SIVA </td> <td style="background-color:#99ccff">C </td> <td>Huisvestingsbeheerorganisatie </td> <td>a):H4 </td></tr><tr><td>28. </td> <td>ITIL </td> <td style="background-color:#99ccff">C </td> <td>Continuïteitsmanagement </td> <td>i), l, m), o), ITIL documentatie </td></tr></table> Met deze voorbeelden kunnen overheden hun eigen omgeving toetsen en waar nodig (her)inrichten. ==Brondocumenten== Onderstaande lijst van brondocumenten verwijst vrijwel grotendeels naar publiek- toegankelijke documenten. Er is minimaal gebruik gemaakt van links, om ‘dode’ verwijzingen te voorkomen. Via Rijksweb of overheids interne websites of Google-search kunnen de documenten gevonden worden. <table class="wikitable"><caption align="bottom">Bronverwijzing</caption><tr ><td> Nr. </td> <td> Documentnaam </td> <td> Versie + datum </td> <td> Eigenaar </td> <td> Toelichting </td></tr><tr ><td> a) </td> <td> Normenkader Beveiliging Rijkskantoren (NKBR) </td> <td> 2.02-10-2015 </td> <td> ICBRBzK </td> <td> Normenkader voor beveiliging van rijkskantoren. Standaard voor inrichting van nieuwbouw en wijzigingenContent heeft vooralsnog de status van Departementaal Vertrouwelijk (Dep.V) </td></tr><tr ><td> b) </td> <td> Kader Rijkstoegangs-beleid </td> <td> 1.0 van 11/5/10 </td> <td> ICBR </td> <td> Beleidskader, gericht op veiligheid van de in Rijksgebouwen werkzame personen, informatie en eigendommen; als onderdeel van ‘integrale beveiliging’ </td></tr><tr ><td> c) </td> <td> Zoneringsmodel rijkskantoren </td> <td> 5-jul-11 </td> <td> BzK </td> <td> Modelmatig opdelen van gebouwen in zones, waarvoor verschillende beveiligingsregimes gelden. Bevat tevens huisvestingsbeleid: Te Beschermen Belangen (TBB) </td></tr><tr ><td> d) </td> <td> Richtlijnen Rijks Vastgoedbedrijf (RVB) </td> <td> volgt </td> <td> RVB </td> <td> Nader te bepalen set van eisen in samenspraak met RVB </td></tr><tr ><td> e) </td> <td> NIST PE Physical and Environ-mental Protection (PE) </td> <td> jun-10 </td> <td> NIST </td> <td> Ontwerp & toets-criteria voor facilitaire apparatuur voor Huis-vesting-IV en fysieke zonering </td></tr><tr ><td> f) </td> <td> NIST MA System Mainenance Policy and Procedures </td> <td> jun-10 </td> <td> NIST </td> <td> Ontwerp & toets-criteria voor beheersingsprocedures </td></tr><tr ><td> g) </td> <td> NIST CA Security Assessment and Authorization Policy and Procedures </td> <td> jun-10 </td> <td> NIST </td> <td> Ontwerp & toets-criteria voor Certificering van organisaties </td></tr><tr ><td> h) </td> <td> NIST AT Awaress and Training Policy and Procedures </td> <td> jun-10 </td> <td> NIST </td> <td> Ontwerp & toets-criteria voor bewustwording en opleiding van medewerkers </td></tr><tr ><td> i) </td> <td> NIST CM Configuration Management Policy and Procedures </td> <td> jun-10 </td> <td> NIST </td> <td> Ontwerp & toets-criteria voor configuratiebeheer, configuratiebeleid en - procedures </td></tr><tr ><td> j) </td> <td> Standard of Good Practice (SoGP) </td> <td> Periodiek </td> <td> ISF </td> <td> Beschrijft zes aspecten van security, ieder daarvan gerelateerd aan bedrijfsmiddelen </td></tr><tr ><td> k) </td> <td> KWAS </td> <td> Periodiek </td> <td> NCSC </td> <td> Beschrijft Kwetsbaarheden van IV, gerelateerd aan bedreigingen van buitenaf of van binnenuit </td></tr><tr ><td> l) </td> <td> NEN-ISO-22323 </td> <td> 2012 </td> <td> BzK </td> <td> Societal security - Business continuity management systems - Guidance (ISO 22313:2012,IDT) beschrijft Bedrijfscontinuïteitsmanagement normatief </td></tr><tr ><td> m) </td> <td> NORA patronen voor bedrijfs-continuïteit / BCM </td> <td> 2014 </td> <td> BzK </td> <td>https://www.noraonline.nl/wiki/Beveiliging/index In deze index van de NORA-wiki voor het thema beveiliging vindt u een reeks van patronen gericht op de Bedrijfscontinuïteit van IV. Daarbij staan ook huisvesting specifieke onderwerpen uitgewerkt </td></tr><tr ><td> n) </td> <td> BIR 1.0 </td> <td> 2011 </td> <td> BzK </td> <td> BIR TNK, eerste versie, met voor het Rijk aangescherpte ISO-implementatierichtlijnen, die in een aantal gevallen relevant zijn voor Huisvesting-IV en die in sommige gevallen een relevante aanvulling vormen op de huidige set van implementatierichtlijnen van de ISO 2013 </td></tr><tr ><td> o) </td> <td> Telecommunication Infrastructure Standard for Data Centers (TIA-942) </td> <td> Periodiek </td> <td> ieee802.org /ANSI </td> <td> Telecommunicatie-standaarden voor infrastructuur van datacenters. Vooral bedoeld voor Netwerken en Hosting, maar geeft ook richtlijnen voor bekabeling en de bescherming daarvanEr zijn diverse whitepapers over TIA-942 te downloaden via Internet </td></tr></table> Op NEN-ISO documenten rusten licentierechten.  
===Schematische weergave Middleware-objecten=== (...) De essentiële objecten van Middleware worden in afbeelding '''XX''' weergegeven. De elementen worden toegelicht met het beleids-, uitvoerings- en control-domein. ===Beleidsdomein=== Binnen het beleidsdomein bevat Middleware randvoorwaarden. Objecten die als randvoorwaarden gelden voor Middleware zijn: beleid, wet- en regelgeving, contracten en organisatiestructuur e.d. (...) ===Uitvoeringsdomein=== <volgt nog> ===Control-domein=== <volgt nog> ===De organisatie van Middleware-objecten=== De geïdentificeerde Middleware-objecten zijn met het beleids-, uitvoerings- en control-domein georganiseerd. Hiermee worden deze aspecten in een juiste contextuele samenhang gepositioneerd. De betekenissen van de lagen zijn:<br><br> '''Beleidsdomein'''<br> Binnen dit domein bevinden zich conditionele elementen over Middleware. Hier zijn eisen opgenomen over (...). '''Uitvoeringsdomein'''<br> Binnen dit domein bevinden zich: * elementen die gerelateerd zijn aan operationele activiteiten van Middleware; * 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-domein'''<br> Binnen dit domein bevinden zich elementen die zorgdragen voor de beheersing en/of het in standhouden van de activiteiten in relatie tot Middleware en of deze wel naar wens verlopen. <br><br> Objecten worden inclusief omschrijving opgeslagen in de objectenbibliotheek ISOR. ISOR staat voor Information Security Object Repository. Enkele van de objecten zijn uniek voor de BIO. Objecten die aanvullend aan de ISO 27002 voor de beveiliging van een bepaald toepassingsgebied nodig geacht worden, zijn met de SIVA-methodiek bepaald. Deze relateren zo mogelijk aan standaarden als de SoGP.  +
Objecten worden geïdentificeerd aan de hand van onderzoeksvragen en risicogebieden. De objecten zijn afgeleid vanuit de optiek van de kwaliteitscriteria: Beschikbaarheid, Integriteit, Vertrouwelijkheid en Controleerbaarheid (BIVC), die vervolgens zijn ingedeeld in drie domein: beleid, uitvoering en control. De vragen die hierbij een rol hebben gespeeld, zijn: # Welke randvoorwaardelijke elementen spelen een rol bij de inrichting van het serverplatform vanuit de optiek van BIVC en wat is de consequentie bij afwezigheid? # Welke elementen spelen een rol bij de inrichting van het serverplatform vanuit de optiek van BIVC en wat is de consequentie bij afwezigheid? # Welke elementen spelen een rol bij de beheersing van het serverplatform vanuit de optiek van BIVC en wat is de consequentie bij afwezigheid? Onderstaande afbeelding geeft de positionering weer van servers binnen de lagenstructuur binnen het uitvoeringsdomein. Die functieblokken bevatten op hun beurt beveiligingsmaatregelen, die vanuit de normatiek geduid worden als beveiligingsobjecten. ==Vaststellen beveiligingsobjecten voor serverplatform== De afbeeldingen uit het [[ISOR:BIO Thema Serverplatform Beleid|Beleidsdomein]], [[ISOR:BIO Thema Serverplatform Uitvoering|Uitvoeringsdomein]] en [[ISOR:BIO Thema Serverplatform Control|Control-domein]] geven een overzicht van alle relevante beveiligingsobjecten voor het thema Serverplatform, afkomstig uit de [[BIO (Baseline Informatiebeveiliging Overheid)|Baseline Informatiebeveiliging Overheid (BIO)]] die gebaseerd is op de [[NEN-EN-ISO/IEC 27002:2017 (Praktijkrichtlijn met beheersmaatregelen op het gebied van informatiebeveiliging)|ISO 27002]]. De BIO volgt dezelfde hoofdstukindeling en controlteksten. Uit de contextuele analyse blijkt dat er enkele onderwerpen bestaan die niet in de BIO voorkomen. Voor deze onderwerpen, waarvoor de BIO geen control heeft geformuleerd, worden controls uit andere baselines geadopteerd, zoals: [[The Standard of Good Practice for Information Security 2018|SoGP]], [[NIST (National Institute of Standards and Technology)|NIST]] en [[ICT-Beveiligingsrichtlijnen voor Webapplicaties-Richtlijnen]] van het [[NCSC (Nationaal Cyber Security Centrum)|Nationaal Cyber Security Centrum (NCSC)]]. ==Globale relaties tussen de geïdentificeerde beveiligingsobjecten== Het thema Serverplatform omvat het geheel van beleid, richtlijnen, procedures, processen, mensen (actoren), middelen en registraties voor het betrouwbaar functioneren van serverplatforms die het fundament vormen voor informatiesystemen. De essentiële objecten voor serverplatforms worden ingedeeld naar de domeinen: beleid, uitvoering en control. Deze objecten worden in [[ISOR:BIO Thema Serverplatform Beleid|Beleidsdomein]], [[ISOR:BIO Thema Serverplatform Uitvoering|Uitvoeringsdomein]] en [[ISOR:BIO Thema Serverplatform Control|Control-domein]] verder toegelicht en uitgewerkt. Moderne, gevirtualiseerde systeemomgevingen zien er mogelijk qua systeemtopologie geheel anders uit, maar de basiselementen die het fundament vormen voor informatiesystemen zijn niet anders. [[Afbeelding:Thema Serverplatform - Gelaagdheid serverplatform met enkele beveiligingsobjecten (Bron- Nora).png|thumb|none|350px|Gelaagdheid serverplatform met enkele beveiligingsobjecten|alt=”Gelaagdheid serverplatform met enkele beveiligingsobjecten”]] ===Beleiddomein=== Dit domein geeft de randvoorwaarden, conditionele aspecten en contraints waar de inrichting van het serverplatform aan moet voldoen. ===Uitvoeringsdomein=== De keuze van objecten uit de ISO 27002 voor het thema Serverplatform vloeit voort uit enkele uitgangspunten die gerelateerd zijn aan serverplatform: * Initiële installatie, De initiële installatie wordt uitgevoerd met richtlijnen en procedures, bijvoorbeeld: bedieningsprocedure (ISO 27002-terminologie). * Beveiligings- en beheerfuncties, De beveiligingsfunctie is gerelateerd aan protectiemechanismen die de beveiliging van de server moeten bevorderen, zoals malwareprotectie en hardenen van features. De beheerfunctie is gerelateerd aan enkele processen, zoals: server-onderhoud en beheer van kwetsbaarheden. * Feature-configuratie, Servers hebben verschillende features. Deze features moeten adequaat zijn geconfigureerd om het beveiligingsniveau te kunnen garanderen. * Structuur en ontwerp, De configuraties van servers en de koppelingen en relatie tussen verschillende servers moet in een ontwerpdocument worden vastgelegd. ===Control-domein=== Er zijn beoordelingsrichtlijnen vastgesteld voor het evalueren van de vastgestelde randvoorwaarden en de uitvoeringscomponenten.  
. <table class="wikitable"> <tr> <th class="tg-s268">ID</th> <th >Relevante beveiligingsobjecten</th> <th >Omschrijving</th> </tr> <tr> <td >B.01</td> <td >Beleid voor(beveiligd) onderhouden van serverplatforms</td> <td >Het resultaat van de besluitvorming ten aanzien van het onderhoud van serverplatforms die het verantwoordelijk management van een organisatie heeft vastgelegd.</td> </tr> <tr> <td >B.02</td> <td >Principes serverplatform beveiliging</td> <td >Principiële uitgangspunten voor het inrichten van serverplatforms, zoals: “Security by design” en “Defense in depth".</td> </tr> <tr> <td >B.03</td> <td >Serverplatform Architectuur</td> <td >Raamwerk en/of blauwdrukken waarmee wordt aangegeven op welke wijze serverplatforms zijn ingericht, samenhangen, beveiligd en beheerst.</td> </tr> <tr> <td >U.01</td> <td >Bedieningsprocedure</td> <td >Een reeks verbonden taken of activiteiten die noodzakelijk zijn voor het beheren van serverplatforms.</td> </tr> <tr> <td >U.02</td> <td >Standaarden voor configuratie servers</td> <td >Documenten waarin afspraken zijn vastgelegd ten aanzien van configuraties en parametrisering serverinstellingen.</td> </tr> <tr> <td >U.03</td> <td >Malwareprotectie</td> <td >Beschermingsmechanismen om servers te beschermen tegen schadelijke code en om schadelijke code te detecteren en te neutraliseren.</td> </tr> <tr> <td >U.04</td> <td >Beheer van server kwetsbaarheden</td> <td >Proactieve beveiliging van servers door het verwerven van inzicht in de kwetsbaarheden en zwakheden in de software die op de server zijn geïnstalleerd.</td> </tr> <tr> <td >U.05</td> <td >Patch-management</td> <td >Het proces dat zorgt voor het verwerven, testen en installeren van patches (wijzigingen ter opheffing van bekende beveiligingsproblemen in de code) op (verschillende softwarecomponenten van) een computersysteem.</td> </tr> <tr> <td >U.06</td> <td >Beheer op afstand</td> <td >Het beheer van server door beheerders vanuit een niet-vertrouwde omgeving.</td> </tr> <tr> <td >U.07</td> <td >Onderhoud apparatuur</td> <td >Het actualiseren van configuraties van een serverplatform binnen een tijdsinterval.</td> </tr> <tr> <td >U.08</td> <td >Veilig verwijderen of hergebruiken van apparatuur</td> <td >Het opschonen van apparatuur en het veilig stellen van data op de apparatuur.</td> </tr> <tr> <td >U.09</td> <td >Hardenen van servers</td> <td >Het proces van het uitschakelen of verwijderen van overbodige en/of niet gebruikte functies, services en accounts, waarmee de beveiliging wordt verbeterd.</td> </tr> <tr> <td >U.10</td> <td >Serverconfiguratie</td> <td >Het conform de vereisten instellen van de verschillende features van serverplatforms.</td> </tr> <tr> <td >U.11</td> <td >Virtueel serverplatform</td> <td >Het beschikbaar stellen van één of meer gescheiden ‘logische’ omgevingen op één fysieke server.</td> </tr> <tr> <td >U.12</td> <td >Beperking software installatie</td> <td >Het stellen van regels voor het installeren op servers of serverplatforms.</td> </tr> <tr> <td >U.13</td> <td >Kloksynchronisatie</td> <td >Het gelijkrichten van klokken op verschillende servers.</td> </tr> <tr> <td >U.14</td> <td >Ontwerpdocumentatie</td> <td >Een document waarin de relatie tussen servers en de instellingen van configuraties zijn vastgelegd.</td> </tr> <tr> <td >C.01</td> <td >Evaluatierichtlijnen serverplatforms</td> <td >Richtlijnen die evaluatie activiteiten van servers ondersteunen.</td> </tr> <tr> <td >C.02</td> <td >Beoordeling technische serveromgeving</td> <td >Het proces van beoordelen op naleving van de beleidsregels en normen van de organisatie voor serverplatforms.</td> </tr> <tr> <td >C.03</td> <td >Logbestandenbeheerders</td> <td >Het vastleggen van activiteiten van beheerders.</td> </tr> <tr> <td >C.04</td> <td >Registratiegebeurtenissen</td> <td >Het proces van registreren van gebeurtenissen op een server vanuit beveiligingsoptiek.</td> </tr> <tr> <td >C.05</td> <td >Monitorenservers en besturingssystemen</td> <td >Het proces van bewaken, reviewen, analyseren van vastgelegde gebeurtenissen en het rapporteren hierover.</td> </tr> <tr> <td >C.06</td> <td >Beheerorganisatieservers en besturingssystemen</td> <td >De adequaat gepositioneerde organisatorische eenheid die verantwoordelijk is voor de beheersing van de serverplatforms.</td> </tr> <caption align="bottom">Serverplatform, Definiëring/omschrijving van beveiligingsobjecten</caption></table>  
Dit document bevat een referentiekader voor het thema Serverplatform. Het is geënt op de controls uit de [[BIO (Baseline Informatiebeveiliging Overheid)|Baseline Informatiebeveiliging Overheid (BIO)]], die gebaseerd is op de [[NEN-EN-ISO/IEC 27002:2017 (Praktijkrichtlijn met beheersmaatregelen op het gebied van informatiebeveiliging)|NEN-ISO/IEC 27002: 2017]] (hierna genoemd ISO 27002). Er wordt ook gebruik gemaakt van andere best practices zoals: [[The Standard of Good Practice for Information Security 2018]] en [[NIST (National Institute of Standards and Technology)]]. Dit kader dient evenals andere [[Alle normenkaders|BIO-thema’s]] als een toetsinstrument voor interne en externe leveranciers, om inzicht te geven over het beveiligings- en beheersingsniveau van haar ontwikkel- en onderhoudsorganisatie. Dit thema geeft tevens inzicht in de kwaliteitszorg die de leverancier dient toe te passen bij het opleveren van nieuwe infrastructuur. ==Opzet van het thema== Het thema Serverplatform wordt achtereenvolgens uitgewerkt langs twee onderdelen: structuur en objecten. De structuur van dit themadocument bestaat uit een indeling op basis van Beleid, Uitvoering en Control (BUC). De objecten vormen de inhoudelijke onderwerpen die in de vorm van controls en onderliggende maatregelen zullen worden behandeld. De objecten en de bijbehorende maatregelen worden gestructureerd met een (BUC-)lagenstructuur. Dit thema volgt de standaard opzet voor BIO-thema’s: * scope en begrenzing van het thema ([[BIO Thema Serverplatform/Inleiding#Scope en begrenzing van serverplatform|Scope en begrenzing van serverplatform]]); * context van het thema ([[BIO Thema Serverplatform/Inleiding#Context van serverplatform|Context van Serverplatform]]); * beveiligingsobjecten en uitwerking van deze objecten op de BUC-lagen ([[BIO Thema Serverplatform/Objecten serverplatform#Vaststellen beveiligingsobjecten voor serverplatform|Vaststellen beveiligingsobjecten voor serverplatform]]); * globale relaties van de geïdentificeerd beveiligingsobjecten ([[BIO Thema Serverplatform/Objecten serverplatform#Globale relaties tussen de geïdentificeerde beveiligingsobjecten|Globale relaties tussen de geïdentificeerde beveiligingsobjecten]]). ==Scope en begrenzing van serverplatform== In dit thema is de scope van het begrip serverplatform beperkt tot de basisfunctionaliteit en algemene onderwerpen die gerelateerd zijn aan serverplatforms. Enkele componenten van dit thema zijn: server-hardware, virtualisatietechnologie en besturingssysteem. Organisaties zullen met deze informatie hun eigen servers in hun omgeving moeten beoordelen en nagaan welke risico’s aanvullend gemitigeerd moeten worden. De thema-uitwerking beschrijft niet de kenmerken van specifieke typen servers, zoals: bestandserver, applicatieserver, webserver, mailserver of databaseserver. De objecten voor serverplatform komen direct of indirect uit de BIO of andere best practices. De vertaling van de BIO-titel Beleid voor beveiligd ontwikkelen (zie paragraaf 14.2.1) naar het object voor serverplatforms wordt Beleid voor beveiligde inrichting en onderhoud. De BIO-titel Principes voor engineering van beveiligde systemen wordt het object Principes voor inrichten beveiligde servers. De begrenzing van dit document is in onderstaande afbeelding weergegeven. [[Bestand:SVP Relatie BIO Thema-uitwerking met aanpalende documenten.png|thumb|none|500px|Relatie BIO Thema-uitwerking met aanpalende documenten|alt=”Relatie BIO Thema-uitwerking met aanpalende documenten”]] ==Context van serverplatform== Servers zijn computers, die via werkstations (clients), een of meerdere diensten aan eindgebruikers of aan andere computersystemen beschikbaar stellen. Voorbeelden van servers zijn: fileserver, database-server, mailserver, webserver en File Transfer Protocol (FTP)-server. Het kan ook gerelateerd zijn aan software die deze dienst mogelijk maakt: accepteert verzoeken van gebruikers en verwerkt deze. Aan een server hangt een of meerdere clients. Onderstaande afbeelding geeft een globale context van enkele typen servers en hoe ze in relatie staan met beleids- en beheersingsaspecten. [[Afbeelding:Thema Serverplatform - Context thema Serverplatform.png|thumb|none|500px|Context van het thema Serverplatform|alt=”Context thema Serverplatform”]] Een externe gebruiker logt bijvoorbeeld aan op een webserver vanuit het internet. Dit type server geeft de relevante gebruikersgegevens door aan een portal-toegangsserver, die op zijn beurt applicatieve diensten vanuit backoffice-servers beschikbaar stelt. De onderste gebruiker in de afbeelding is een medewerker van een vertrouwde partij en zoekt via een semi-vertrouwd kanaal informatie op een webserver van de partnerorganisatie. De interne gebruiker logt aan op z’n werkstation via het lokale netwerk. In veel gevallen is er ook sprake van ‘middleware’, oftewel applicatiecode die bepaalde functies vervult tussen de gebruikersapplicatie en het besturingssysteem.  
Dit document bevat een referentiekader voor het thema Softwarepakketten. Het is geënt op controls uit de [[BIO (Baseline Informatiebeveiliging Overheid)|Baseline Informatiebeveiliging Overheid (BIO)]] die gebaseerd is op [[NEN-EN-ISO/IEC 27002:2017 (Praktijkrichtlijn met beheersmaatregelen op het gebied van informatiebeveiliging)|NEN-ISO/IEC 27002: 2017]] (hierna genoemd ISO 27002). Er is bij de samenstelling van dit thema tevens gebruik gemaakt van andere normenkaders en internationale standaarden zoals [[OWASP Application Security Verification Standard 4.0.2|Application Security Verification Standard (ASVS)]] van [[OWASP (Open Source Foundation for Application Security)|Open Source Foundation for Application Security (OWASP)]], de [[ICT-Beveiligingsrichtlijnen voor Webapplicaties-Richtlijnen|ICT-Beveiligingsrichtlijnen voor Webapplicaties]] van het [[NCSC (Nationaal Cyber Security Centrum)|Nationaal Cyber Security Centrum (NCSC)]] en [[SIG Evaluation Criteria Security - Guidance for producers|SIG Evaluation Criteria Security: Guidance for producers]]. Voor het concretiseren van de controls uit de BIO zijn deze eisen tevens gerelateerd aan normen uit de [[Centrum Informatiebeveiliging en Privacybescherming (CIP)]]-[[Grip op Secure Software Development|publicatie Secure Software Development (SSD)]]. Hoewel SSD zich specifiek richt op softwareontwikkeling zijn bepaalde objecten en hieraan gerelateerde controls ook van toepassing op de aanschaf van standaard softwarepakketten. Het landschap van softwarepakketten is zeer divers qua functionaliteit en schaalgrootte. Daarom is het onmogelijk om daarvoor één dekkende lijst van beveiligingseisen op te stellen. Wel is aan te geven welke onderwerpen tijdens het verwervingsproces van belang zijn en waar beveiligingseisen uit afgeleid kunnen worden. Daarom wordt specifiek gericht op objecten die bij het verwerven van belang zijn. Om de juiste objecten te identificeren, wordt uitgegaan van de fases van het verwervingsproces. Hierbij wordt gericht op de fases plannen en selecteren waarin een business case en het stellen van Programma van Eisen (PvE) een onderdeel zijn. Binnen de business case wordt met name aandacht besteed aan objecten gerelateerd aan informatieveiligheid en privacybescherming. In dit thema wordt een softwarepakket beschouwd als een bestaand softwarepakket dat op de markt is gebracht door een leverancier en kan in verschillende organisaties worden toegepast. Het betreft standaard softwarepakketten die gebaseerd zijn op best practices binnen een bepaalde sector en op een verzameling van op elkaar afgestemde computerprogramma’s, die bepaalde bedrijfsfunctionaliteiten bieden. Voorbeelden van softwarepakketten zijn Enterprise Resource Planning (ERP)-pakket en Office-suites. Softwarepakketten kunnen na verwerving in een eigen rekencentrum geïnstalleerd worden, maar ook afgenomen worden als een standaard clouddienst of als een hybride vorm hiervan, dat wil zeggen: in eigen rekencentrum en in de cloud. Web-gebaseerde toepassingen kunnen ook op een lokale server draaien. ==Levenscyclus van een softwarepakket== De [[NEN-ISO/IEC 27034-5:2017 (Protocols and application security controls data structure)|ISO 27034-5 ‘Protocols and application security controls data structure’]] uit 2017 beschrijft een referentiemodel, waarin de levenscyclus van software is gedefinieerd, vanaf de voorbereiding via de verwerving tot en met de uitfasering van het product. Onderstaande afbeelding is daarvan afgeleid en wordt gebruikt bij de uitleg van beveiligingseisen. [[Bestand:SWP Levenscyclus van een softwarepakket.png|thumb|500px|none|alt=”Dit schema geeft de fases van een softwarepakket aan, waarbij implementeren en gebruiken en onderhouden buiten scope is”|Levenscyclus van een softwarepakket]] ==Voorbereiding vanuit de klantorganisatie== Voordat de werving en selectie van een softwarepakket start, worden de onderstaande stappen doorlopen, waarmee belangrijke vraagstukken worden ingevuld. De output van deze stappen maakt onderbouwing van keuzes mogelijk en maakt deze transparant en traceerbaar voor bestuurders en de inhoudelijke functies in zowel de business- als de informatievoorzieningsketen. ===Stap 1. Inventariseren=== De uitgangssituatie wordt in kaart gebracht, zowel van de organisatie als de techniek. Onderzocht wordt welke functionele behoeften er precies bestaan binnen de klantorganisatie (hierna genoemd klant) en welke afhankelijkheden verwacht worden tussen de al beschikbare bedrijfsfuncties en de beoogde nieuwe functionaliteit. ===Stap 2. Onderbouwen=== Een business case omschrijft de noodzaak voor een nieuw softwarepakket en de verwachte resultaten en voordelen daarvan. Binnen een business case worden ook de nieuwe IT-functionaliteiten vastgesteld waarin de kosten-baten worden geanalyseerd. ===Stap 2a. en 2b. Contextanalyse en scenario-ontwikkeling=== Na of tijdens de uitwerking van de business case wordt met een risicoanalyse (zie [[NEN-ISO/IEC 27005:2018 (Information security risk management)|ISO 27005 ‘Information security risk management’]] uit 2018) de in- en externe context vastgesteld. Dus in welke omgeving moet het pakket kunnen functioneren? Vanuit de business case en contextanalyse worden doelscenario’s ter besluitvorming uitgewerkt. Enkele vraagstukken daarbij zijn hieronder belicht. '''Cloud of on-premise''' Voor standaard softwarepakketten wordt door leveranciers steeds meer overgegaan naar clouddiensten. Sommige software is zelfs alleen nog als clouddienst af te nemen. Business drivers als kosten/baten, ‘time-to-market’ en ‘wendbaarheid’ kunnen functionaliteit, geleverd als clouddienst heel aantrekkelijk maken. Organisaties die zijn overgestapt naar clouddiensten hebben ervaren dat die keuze een grote impact heeft op de bedrijfsvoering zoals men die gewend was met een eigen rekencentrum. Die impact geldt zowel voor de afnemende gebruikersorganisatie als voor de vorm van IT-dienstverlening. '''Inpasbaarheid''' Er bestaat vrijwel altijd een bestaande IT-omgeving waarin het softwarepakket moet passen. Dat geldt tot op zekere hoogte ook voor clouddiensten. Dit zijn technische integratievraagstukken. Daarom is het van belang om voldoende IT-deskundigheid in te zetten bij een context- en risicoanalyse en bij het opstellen van een globaal ontwerp, Programma van Eisen (PvE) en de vaststelling van de technische randvoorwaarden. Raadpleeg daarbij de actuele vakliteratuur voor de te nemen technische maatregelen. '''Risico’s''' De uit te voeren risicoanalyses zijn onder andere gericht op de vereiste bedrijfscontinuïteit, informatieveiligheid en privacyaspecten van de voorgenomen nieuwe bedrijfsfunctionaliteit. Daarvoor wordt onder andere een Business Impact Assessment (BIA), een risicoanalyse en indien nodig een Data Protection Impact Assessment (DPIA) uitgevoerd. Mede met de uitkomsten van deze analyses kan het meest geschikte implementatiescenario worden gekozen. '''Continuïteit''' Continuïteitsvraagstukken zijn: wat is de maximaal toelaatbare uitvalduur van het softwarepakket en wat is het maximaal toelaatbare dataverlies? Beide factoren kunnen cruciaal zijn voor het voortbestaan van een bedrijf en maken onderdeel uit van Bedrijfscontinuïteitsmanagement (BCM). '''Classificatie''' De classificatie van de data die door het pakket verwerkt zal worden, vormt eveneens een belangrijke input, zowel voor de BIA als voor de DPIA, maar ook voor beveiligingseisen gericht op de transport en opslag van gegevens. ====Stap 3. en 4. Ontwerpen en conditioneren==== Als de scenariokeuze is gemaakt, wordt een functioneel ontwerp opgesteld. Hierin worden de bedrijfsfuncties uitgewerkt tot een PvE. Dit PvE dient als basis voor de selectie van IT-diensten zoals een softwarepakket. Bij het vaststellen van een PvE wordt aandacht besteed aan zowel bedrijfsfuncties als aan informatieveiligheid en privacybescherming, waarvoor een set van functionele en non-functionele eisen wordt opgesteld. In deze BIO Thema-uitwerking zijn de objecten geïdentificeerd en de hieraan gerelateerde BIO-controls gedefinieerd die voor het ontwerp van bedrijfsfuncties en vanuit de verwervingsoptiek noodzakelijk kunnen zijn. Het gaat hier zowel om de organisatie als de techniek. De objecten zijn conform de standaard opzet van BIO Thema-uitwerkingen uitgewerkt in twee onderdelen: structuur en objecten. De structuur van elk thema is een indeling van objecten op basis van het beleids-, uitvoerings- en control-domein. De objecten representeren de inhoudelijke informatiebeveiligingsonderwerpen, die bij voorkeur uit de BIO-/ISO 27002-controls en -maatregelen zijn geadopteerd. Zoals bij de [[BIO Thema Softwarepakketten - Inleiding#Inleiding|inleiding]] is aangegeven, zijn sommige controls voor concretisering gerelateerd aan andere baselines zoals SSD-controls en -maatregelen. ==Scope en begrenzing== Dit thema is voornamelijk gericht op conditionele, beveiligings- en beheersingsaspecten en generieke beveiligingseisen die gerelateerd zijn aan de verwerving van softwarepakketten. Buiten scope van dit thema vallen: #operationele implementatie en configuratie van het verworven softwarepakket; #activiteiten die specifiek gaan over de infrastructuur van externe hosting en generieke clouddiensten; zie daarvoor de BIO Thema-uitwerkingen Clouddiensten, Serverplatform en Communicatievoorzieningen. #specifieke gebruikers- en businesseisen omdat deze eisen organisatieafhankelijk zijn. # applicatieontwikkelingseisen, zie daarvoor de BIO Thema-uitwerking Applicatieontwikkeling. De begrenzing van dit document is in onderstaande afbeelding weergegeven. [[Bestand:SWP Relatie BIO Thema-uitwerking softwarepakketten met aanpalende documenten.png|thumb|500px|none|alt=”Dit schema geeft aan hoe de relatie is tussen deze en andere BIO Thema-uitwerkingen, documenten op normatief niveau en de ISOR waarin de thema's worden ontsloten.”|Relatie BIO Thema-uitwerkingen met aanpalende documenten]] De relatie tussen de verschillende BIO Thema-uitwerkingen is in onderstaande afbeelding weergegeven. [[Bestand:SWP Postionering thema Softwarepakketten in relatie tot andere thema's.png|thumb|500px|none|alt=”Dit schema geeft aan hoe de relatie is tussen deze en alle andere BIO Thema-uitwerkingen.”|Postitionering thema Softwarepakketten in relatie tot andere thema's]] ==Relaties tussen beveiligingsobjecten== Het thema Softwarepakketten omvat het geheel van beleid, richtlijnen, procedures, processen, mensen (actoren), middelen en registraties voor het betrouwbaar functioneren van softwarepakketten. De essentiële objecten voor softwarepakketten worden ingedeeld in het beleids-, uitvoerings- en control-domein. Deze objecten worden in de volgende drie hoofdstukken uitgewerkt. [[Bestand:SWP Softwarepakketten in het beleids-, uitvoerings- en control-domein.png|thumb|500px|none|alt=”Dit schema geeft de relatie tussen deze en alle andere BIO Thema-uitwerkingen weer.”|Postitionering thema Softwarepakketten in relatie tot andere thema's]] ===Beleidsdomein=== Dit zijn de randvoorwaarden, conditionele aspecten en constraints die bij de verwerving van softwarepakketten in acht moeten worden genomen. ===Uitvoeringsdomein=== De control-keuze uit de BIO voor dit thema vloeit voort uit enkele uitgangspunten die gerelateerd zijn aan software: * Beveiligings- en beheerfuncties, Het softwarepakket beschikt over beveiligingsfuncties en beschermingsmechanismen die de beveiliging van softwarepakketten moeten bevorderen, zoals virusprotectie en mogelijkheden om tekortkomingen in de beveiliging achteraf te kunnen corrigeren, zoals patchmanagement. * Configuratie van features, Het softwarepakket beschikt over features om een adequaat niveau van beveiliging te kunnen bereiken. * Structuur en ontwerp, De samenhang tussen de modules binnen het softwarepakket, de geboden koppelingsmogelijkheden met een externe applicatie en de faciliteiten voor import en export zijn inzichtelijk gemaakt met een softwarearchitectuur. ===Control-domein=== Voor het evalueren van de effectiviteit van de genomen controls en maatregelen uit het beleids- en uitvoeringsdomein zijn in dit domein de daarvoor benodigde objecten, controls en maatregelen bepaald.  
Deze BIO Thema-uitwerking is door [[Centrum Informatiebeveiliging en Privacybescherming (CIP)]] opgesteld om overheidsorganisaties een beeld te geven van de meest relevante onderwerpen, met name voor de verwerving van standaard software. Daarmee wordt bestaande software bedoeld, die als product op de markt is gebracht om binnen een groot aantal organisaties te kunnen worden gebruikt. Voor algemene informatie over diverse soorten softwarepakketten zie: [https://www.softwarepakketten.nl/ www.softwarepaketten.nl] <sup class="reference smartref" id="cite_ref-Softwarepaketten.nl_1-0">[[BIO Thema Softwarepakketten - Voorwoord en motivatie#cite_note-Softwarepaketten.nl-1|1]]</sup>. De belangrijkste aanleiding voor het opstellen van dit thema is dat de [[BIO (Baseline Informatiebeveiliging Overheid)|Baseline Informatiebeveiliging Overheid (BIO)]] de overheden weinig concrete handvatten biedt voor het verwerven van standaard softwarepakketten. Daarnaast is er de visie dat de complexiteit van de IT verschuift van infrastructuur naar applicaties. Daarom behandelt dit thema in samenhang de beveiligingseisen voor de verwerving van softwarepakketten. Het kiezen van een softwarepakket blijkt in de praktijk vooral een integratievraagstuk. Hoe past de technologie en het gebruik van een softwarepakket (of dienst) veilig binnen de bestaande bedrijfsvoering? Dit is vooral een taak van de klantorganisatie. De verwervingseisen voor een softwarepakket zijn daarom geënt op zowel de noodzakelijke bedrijfs- en beveiligingsfunctionaliteiten als integratie of koppelingsmogelijkheden.  +
Objecten worden geïdentificeerd aan de hand van onderzoeksvragen en risicogebieden. De objecten zijn afgeleid vanuit de optiek van de kwaliteitscriteria: Beschikbaarheid, Integriteit, Vertrouwelijkheid en Controleerbaarheid (BIVC), die vervolgens zijn ingedeeld in drie domeinen: beleid, uitvoering en control. De vragen die hierbij een rol hebben gespeeld zijn: # Welke randvoorwaardelijke elementen spelen een rol bij de inrichting van toegangsbeveiliging vanuit de optiek van BIVC en wat is de consequentie bij afwezigheid? # Welke elementen spelen een rol bij de inrichting van toegangsbeveiliging vanuit de optiek van BIVC en wat is de consequentie bij afwezigheid? # Welke elementen spelen een rol bij de beheersing van toegangsbeveiliging vanuit de optiek van BIVC en wat is de consequentie bij afwezigheid? Afbeelding 'Schematische weergave van de componenten van logische toegangsbeveiliging in een drielagenstructuur' geeft de positionering weer van toegangsbeveiligingselementen binnen het uitvoeringsdomein. Deze elementen geven een verband van elementen die binnen de organisatieonderdelen een rol spelen. De elementen kunnen direct of indirect voorkomen als beveiligingsobjecten. ==Globale relaties tussen de geïdentificeerde beveiligingsobjecten== De [[BIO (Baseline Informatiebeveiliging Overheid)|Baseline Informatiebeveiliging Overheid (BIO)]] is ingedeeld op basis van de hoofdstukindeling van de [[NEN-EN-ISO/IEC 27002:2017 (Praktijkrichtlijn met beheersmaatregelen op het gebied van informatiebeveiliging)|ISO 27002]]. Bij het ontwikkelen van een thema, zoals de toegangsbeveiliging, is het noodzakelijk om na te gaan uit welke onderdelen (objecten) de omgeving van toegangsbeveiliging precies bestaat. Zonder een beeld over de samenhang tussen de objecten is het lastig om de normen in de juiste samenhang uit de BIO te selecteren. Afbeelding 'Schematische weergave van de componenten van logische toegangsbeveiliging in een drielagenstructuur' geeft een voorbeeld van de betrokken onderdelen uit de business en ICT-omgeving waar een organisatie over het algemeen mee te maken hebben. Deze onderdelen kunnen gerelateerd zijn aan de beveiligingsobjecten in een toegangsbeveiligingsomgeving. Toegangsbeveiliging omvat het geheel van actoren, beleid, richtlijnen, procedures, processen, registratiesystemen ten behoeve van een vertrouwd en betrouwbaar gebruik van informatiesystemen. De essentiële onderdelen van toegangsbeveiliging worden in onderstaande figuur weergegeven. De onderdelen zijn hieronder toegelicht op basis van de domeinen (beleid, uitvoering en control) waarin deze voorkomen. ===Beleidsdomein=== Dit domein bevat algemene conditionele elementen met betrekking tot de inrichting van de toegangsbeveiliging zoals toegangsbeleid. Het bevat ook andere conditionele en randvoorwaardelijke aspecten die van toepassing zijn op het uitvoeringsdomein en het control-domein. Het bevat over het algemeen de objecten: beleid, cryptografie, organisatiestructuur en architectuur. ===Uitvoeringsdomein=== Dit domein omvat verschillende organisatieonderdelen die betrokken zijn bij de inrichting van de toegangsbeveiliging. Toegangsbeveiliging is een continu proces die de samenwerking van deze bedrijfsonderdelen nodig heeft. Deze bedrijfsonderdelen zijn gezamenlijk verantwoordelijk voor de juiste inrichting van de beveiligingsobjecten over toegangsbeveiliging. De betrokken organisatieonderdelen zijn onder andere: '''Personeelsafdeling''' <br>De personeelsafdeling zorgt ervoor dat medewerkers in het personeelsregistratiesysteem worden opgenomen en zorgt, in samenwerking met business, dat vanuit een organisatorische en procedurele invalshoek elementen worden vastgelegd. De van belang zijnde elementen zijn: gegevens/proceseigenaar, gebruiker, rol, profiel en taak. De relatie tussen deze elementen kan gelezen worden als: * Een gebruiker heeft een rol. * Op basis van deze rol wordt zijn profiel bepaald. * Op basis van zijn profiel worden de rechten bepaald op basis waarvan hij zijn taak kan uitvoeren. '''ICT afdeling''' <br>De ICT-afdeling zorgt voor ICT-voorzieningen en de geautoriseerde toegang tot benodigde applicaties en het authenticatiemiddel. Dit wordt vastgelegd in termen van identificatie, authenticatie en autorisatie. Er zijn verschillende type gebruikers: eindgebruikers (remote-gebruikers) en beheerders. Deze gebruikers moeten aan specifieke toegangseisen voldoen. De gebruikersgegevens, de rollen en profielen worden vastgelegd in registratiesystemen. In dit geval zijn er drie registratiesystemen vermeld. In de praktijk is dit afhankelijk van het type organisatie. Er zijn ook registraties die worden gebruikt voor analysedoeleinden. '''Facilitair Bedrijf''' <br>Het Facilitair bedrijf zorgt voor een fysieke toegang tot terreinen, gebouwen en ruimten op basis van een toegangsmiddel. Hierbij ontvangen de medewerkers bijvoorbeeld een toegangspas (= identificatiemiddel). ===Control-domein=== Dit domein bevat evaluatie-, meet- en beheersingsaspecten op basis waarvan toegangsbeveiliging wordt beheerst en bijgestuurd. Het vervult hiermee een controlfunctie die kort en lang cyclisch van aard kunnen zijn. Dit domein bevat beheersprocessen, zoals de Information Technology Infrastructure Library (ITIL)-processen, die noodzakelijk zijn voor de beheersing van de configuraties van IT-componenten en de instandhouding van het beveiligingsniveau. De informatie uit de evaluaties en de beheerprocessen is niet alleen gericht op het bijsturen en/of aanpassen van het eerder geformuleerde beleid maar ook op implementatie van de toegangsbeveiliging. In Afbeelding 'Schematische weergave van de componenten van logische toegangsbeveiliging in een drielagenstructuur' wordt de hiervoor uitgelegde domeinenstructuur geïllustreerd. De domeinindeling is verder uitgewerkt in de pagina [[ISOR:BIO Thema Toegangsbeveiliging Control|Control-domein]]. Gevirtualiseerde systeemomgevingen zien er qua systeemtopologie geheel anders uit, maar de basiselementen voor de toegang zijn dezelfde. [[Afbeelding:Thema Toegangsbeveiliging - Schematische weergave van de componenten van het logische toegangsbeveiliging systeem in een 3-lagenstructuur.png|thumb|600px|none|alt=” Schematische weergave componenten toegangsbeveiliging in drielagenstructuur”|Schematische weergave componenten logische toegangsbeveiliging in drielagenstructuur]]  
Dit document representeert een referentiekader voor het thema toegangsbeveiliging en is geënt op controls uit best practices zoals: [[BIO (Baseline Informatiebeveiliging Overheid)|Baseline Informatiebeveiliging Overheid (BIO)]], [[NEN-EN-ISO/IEC 27001:2017 (Managementsystemen voor informatiebeveiliging - Eisen)|NEN-ISO/IEC 27001:2017]] (hierna genoemd ISO 27001) en [[NEN-EN-ISO/IEC 27002:2017 (Praktijkrichtlijn met beheersmaatregelen op het gebied van informatiebeveiliging)|NEN-ISO/IEC 27002: 2017 (hierna genoemd ISO 27002)]], [[The Standard of Good Practice for Information Security 2018|Standard of Good Practice (SoGP)]] en de [[NIST (National Institute of Standards and Technology)|National Institute of Standards and Technology (NIST)]]. ==Opzet van het thema== Het thema toegangsbeveiliging wordt uitgewerkt langs twee onderdelen: structuur en objecten. De structuur van deze thema-uitwerking bestaat uit een indeling op basis van Beleid, Uitvoering en Control (BUC). De objecten vormen de inhoudelijke onderwerpen die in de vorm van controls en onderliggende maatregelen worden behandeld. De objecten en de bijbehorende maatregelen worden gestructureerd door middel van met de (BUC-)lagenstructuur. Dit thema volgt de standaard opzet voor BIO-thema’s: # Scope en begrenzing van het thema (zie [[BIO Thema Toegangsbeveiliging/Inleiding#Scope en begrenzing van toegangsbeveiliging|Scope en begrenzing van toegangsbeveiliging]]); # Context en globale structuur van het thema (zie [[BIO Thema Toegangsbeveiliging/Inleiding#Context en globale structuur toegangsbeveiliging|Context en globale structuur toegangsbeveiliging]]); # Globale relaties tussen de geïdentificeerde beveiligingsobjecten (zie [[BIO Thema Toegangsbeveiliging/Objecten voor toegangbeveiliging#Globale relaties tussen de geïdentificeerde beveiligingsobjecten|Globale relaties tussen de geïdentificeerde beveiligingsobjecten]]); ==Scope en begrenzing van toegangsbeveiliging== De uitwerking van logische toegangsbeveiliging is in dit thema gericht op identificatie, authenticatie en autorisatie van (interne en externe) medewerkers voor systemen die op een bepaalde locatie staan. De uitwerking van fysieke beveiliging is dit thema gericht op de fysieke toegang tot terreinen, gebouwen en ruimten (bijvoorbeeld rekencentra). Specifieke apparaat gebonden mechanismen voor toegangsbeveiliging, zoals toegang tot besturingssystemen, netwerken, mobiele computers en telewerken zullen in andere thema’s worden behandeld. De begrenzing van dit document is in onderstaande afbeelding weergegeven. [[Bestand:TBV Relatie BIO Thema-uitwerking met aanpalende documenten.png|thumb|500px|none|alt=”Relatie BIO Thema-uitwerking met aanpalende documenten”|Relatie BIO Thema-uitwerking met aanpalende documenten]] ==Context en globale structuur toegangsbeveiliging== Organisaties maken gebruik van informatiesystemen om hun bedrijfsprocessen te ondersteunen en medewerkers zijn gehuisvest in gebouwen en ruimten. De informatiesystemen maken gebruik van cruciale data van de organisatie zelf en van haar klanten. Het is van belang dat deze informatiesystemen worden beveiligd en beheerst, anders loopt de organisatie het risico dat deze data misbruikt wordt, wat kan leiden tot bijvoorbeeld boetes, imagoschade, klantenverlies e.d. In dit kader speelt toegangsbeveiliging een cruciale rol. Toegangsbeveiliging omvat logische en fysieke toegangsbeveiliging, zoals in de afbeelding 'Globale opzet logische en fysieke beveiliging' hieronder wordt weergegeven. Logische toegangsbeveiliging omvat het geheel van richtlijnen, procedures en beheersingsprocessen en faciliteiten die noodzakelijk zijn voor het verschaffen van toegang tot informatiesystemen, besturingssystemen, netwerken, mobiele devices en telewerken van een organisatie. Fysieke toegangsbeveiliging omvat het geheel van richtlijnen, procedures en beheersingsprocessen en systemen die noodzakelijk zijn voor het verschaffen van fysieke toegang tot terreinen, gebouwen en ruimten. [[Bestand:TBV Globale opzet logische en fysieke toegangsbeveiliging.png|thumb|500px|none|alt=” Globale opzet logische en fysieke beveiliging”|Globale opzet logische en fysieke beveiliging]]  
'''De toegangsbeveiligingsobjecten in de drie domeinen Beleid, Uitvoering en Control in een oogopslag''' <br> [[Bestand:TBV Overzicht objecten voor toegangsbeveiliging in het beleidsdomein.png|thumb|500px|none|alt=”Overzicht van objecten gerelateerd aan SIVA basiselementen in het beleidsdomein”|Afbeelding 10: Toegangsbeveiligingsobjecten binnen het beleidsdomein]] [[Bestand:TBV Overzicht objecten voor toegangsbeveiliging in het uitvoeringsdomein.png|thumb|500px|none|alt=”Overzicht van objecten gerelateerd aan SIVA basiselementen in het uitvoeringsdomein”|Afbeelding 11: Toegangsbeveiligingsobjecten binnen het uitvoeringsdomein]] [[Bestand:TBV Overzicht objecten voor toegangsbeveiliging in het control-domein.png|thumb|500px|none|alt=”Overzicht van objecten gerelateerd aan SIVA basiselementen in het control-domein”|Afbeelding 12: Toegangsbeveiligingsobjecten binnen het control-domein]]  +
Voor de inrichting en evaluatie van voorzieningen voor toegangsbeveiliging dient de fasering van afbeelding 'De relaties tussen de drie fases' te worden gebruikt. Dit geldt voor zowel interne als externe medewerkers. * Indiensttreding (instroom), In deze fase gelden algemene en specifieke richtlijnen voor de taken en verantwoordelijkheden van de werkgever en de werknemer. De werkgever zal in de fase, na een zorgvuldige selectieprocedure, de noodzakelijke zaken voor de werknemer moeten regelen. * Tijdens dienstverband (doorstroom), In deze fase worden werknemers, afhankelijk van hun functie, via trainingen en opleidingen bewust gemaakt van het omgaan met bedrijfsmiddelen (onder andere bedrijfsgegevens) en hoe zij moeten omgaan met aspecten van informatiebeveiliging. * Uitdiensttreding (uitstroom), In deze fase treft de werkgever de noodzakelijke maatregelen voor het beëindigen van het dienstverband. De werknemer zal de aan hem verstrekte bedrijfsmiddelen volgens afgesproken procedure moeten inleveren. [[Afbeelding:Thema Toegangsbeveiliging - De relaties tussen de drie fases.png|thumb|550px|none|alt=” Relaties tussen de drie fases”|Relaties tussen de drie fases]] ==Indiensttreding nieuwe medewerkers== Met het verstrekken van de aanstellingsbeschikking komt een medewerker, aangenomen door een manager, in dienst. Bij indiensttreding ontvangt de medewerker een toegangspas waarmee hij toegang krijgt tot het terrein, gebouw en de bij de functie horende ruimtes (fysieke toegangsbeveiliging). Naast de fysieke ruimtes krijgt de medewerker ook toegang tot logische ruimtes, ofwel: de persoonlijk en gemeenschappelijke gegevensverzamelingen en tot de algemene kantoorautomatiseringsomgeving, zoals de KA- of de Front-Office omgeving en specifieke applicaties. Voor de werkzaamheden binnen de specifieke applicaties kan hij weer algemene en specifieke rechten krijgen. Achter de schermen worden heel wat stappen gezet om deze nieuwe medewerker daadwerkelijk in te voeren als een actieve functionaris. Hierbij zijn verschillende afdelingen betrokken zoals: * De Personeelsafdeling (of Human Resource Management) zorgt daarbij voor invoering van de nieuwe medewerker in het personeelsbestand. * De Facilitaire dienst of Facilitair bedrijf zorgt voor een fysieke werkplek (bureau, stoel etc.) en maakt een toegangspas aan (= identificatiemiddel). * De Gegevens-/Proceseigenaar zorgt voor mandaatregister waaruit blijkt welke personen bevoegd zijn voor uitvoering van welke taken (autorisaties). * De ICT-afdeling zorgt voor ICT-voorzieningen misschien en de geautoriseerde toegang tot benodigde applicaties evenals het authenticatiemiddel (zoals een toegangspas). [[Afbeelding:Thema Toegangbeveiliging - Processtappen en acties bij de indiensttreding (instroom) van een medewerker.png|thumb|750px|none|alt=”Processtappen en acties bij de indiensttreding (instroom) van een medewerker”|Processtappen en acties bij indiensttreding (instroom) van een medewerker]] Deze stappen staan niet los van elkaar. Zij dienen namelijk één gemeenschappelijk doel: het bieden van geautoriseerde toegang en daarvoor zijn meerdere gegevens van de medewerker en meerdere acties vanuit de organisatie nodig om de benodigde zaken te regelen om de medewerker in de positie te stellen voor het uitvoeren van zijn taken. Omgekeerd zal de medewerker kennis moeten nemen van de missie/visie van de organisatie en van haar informatiebeveiligingsbeleid. Afbeelding 'Processtappen en acties bij de indiensttreding (instroom) van een medewerker' geeft een beeld van de processtappen bij de indiensttreding (instroom) van een medewerker. Nadat de processtappen en acties bij de indiensttreding van de medewerker zijn doorlopen, is de medewerker geïdentificeerd. De medewerker (gebruiker) bezit dan de nodige middelen, een fysiek toegangsbewijs voor toegang tot terreinen, gebouwen en ruimtes van de organisatie in de vorm van een toegangspas en een logisch toegangsbewijs in de vorm van een account voor toegang tot Informatievoorzieningen (IV) faciliteiten. Na het met de inloggegevens (identificatie/accountnaam en authenticatie) inloggen, krijgt de gebruiker toegang tot applicaties. Aan het account, het identificatiebewijs van de gebruiker, zijn toegangsrechten (autorisaties) gekoppeld. Autorisatie (profiel) komt tot stand op basis van de rol van de gebruiker en geeft hem het recht bepaalde taken in de applicatie uit te voeren. Bij doorstroom is er sprake van wijzigingen van de toegangsgegevens (identificatie, authenticatie en autorisatie). Bij uitstroom is er sprake van blokkering van deze gegevens. De persoonlijke gegevens van de gebruiker zijn opgeslagen in het personeelssysteem, de rol en het profiel zijn opgeslagen in het autorisatiesysteem. De profielen en de taken zijn op hun beurt weer opgeslagen in het informatiesysteem. Afbeelding 'Het autorisatieproces' geeft hiervan een overzicht. [[Afbeelding:Thema Toegangbeveiliging - Het autorisatieproces.png|thumb|750px|none|alt=” Het autorisatieproces”|Het autorisatieproces]] ==Tijdens het dienstverband== Tijdens het dienstverband heeft de medewerker (gebruiker) toegang tot de informatiesystemen op basis van de bij de indiensttreding verkregen middelen en toegangsrechten. Daarvoor moeten fysieke toegangssystemen, authenticatiesystemen en autorisatiesystemen worden ingericht. Tijdens het dienstverband kunnen werkzaamheden van medewerkers worden gewijzigd en of op een andere functie/project worden geplaatst. Er kan ook sprake zijn van een (tijdelijke) overplaatsing. Dan zullen de nodige wijzigingen in functieprofielen (autorisatie) en taakrollen in het registratiesysteem worden doorgevoerd. De oorspronkelijke functie dient dan te worden gedeactiveerd en de toegangsrechten worden aangepast, geblokkeerd of verwijderd. ==Uitdiensttreding== Uiteindelijk kan een medewerker door bepaalde redenen uit dienst treden. Dit houdt in dat bepaalde gegevens van de medewerkers dienen te worden geregistreerd en autorisaties voor het gebruik van applicaties moeten worden verwijderd. <br><br> : → [[ISOR:Autorisatieproces|Ga terug naar U.04 Autorisatieproces]]  
De BIO Thema-uitwerking Applicatieontwikkeling, hierna genoemd normenkader, is opgesteld door Wiekram Tewarie ([[UWV (Uitvoeringsinstituut Werknemersverzekeringen)|Uitvoeringsinstituut Werknemersverzekeringen (UWV)]]/[[Centrum Informatiebeveiliging en Privacybescherming (CIP)|Centrum Informatiebeveiliging en Privacybescherming (CIP)]]) en Jaap van der Veen (CIP). De opdrachtgever is de voorzitter van de werkgroep BIO en de directeur CIP. Het CIP-kernteam heeft versie 2.0 van dit normenkader gereviewd. Zodoende valt dit normenkader in het regime ‘becommentarieerde praktijk’. ==Considerans== CIP-producten steunen op kennis van professionals uit verschillende organisaties actief in het CIP-netwerk, zowel uit de overheid als de markt. Opmerkingen en aanvullingen kun je melden op [https://www.cip-overheid.nl/contact/ cip-overheid.nl/contact]. ==Leeswijzer== Voorafgaand aan het [[ISOR:BIO Thema Applicatieontwikkeling Beleid|Beleidsdomein]], [[ISOR:BIO Thema Applicatieontwikkeling Uitvoering|Uitvoeringsdomein]] en [[ISOR:BIO Thema Applicatieontwikkeling Control|Control-domein]], de kern van dit thema, heeft elke BIO Thema-uitwerking een inleiding met een standaard paragraafindeling. De volgende leeswijzer geldt voor dit normenkader: *Voor de aanduiding van personen wordt de mannelijke vorm aangehouden (hij/hem/zijn) ongeacht het geslacht. *De controls, hierna genoemd criteria, en maatregelen, hierna genoemd normen, vermeld in dit normenkader zijn in het beleids-, uitvoerings- en control-domein georganiseerd, waarmee ze bij de overeenkomstige functionarissen kunnen worden geadresseerd. Deze functionarissen zijn niet benoemd omdat dit organisatie-afhankelijk is. *Van best practices (open standaarden al dan niet toegankelijk met een licentie), zijn de meest actuele versies afgekort vermeld, tenzij de actuele versie niet toereikend is. *Voor een overzicht van alle gebruikte best practices, afkortingen en begrippen en een generieke toelichting op de opzet van de thema-uitwerkingen, zie de Structuurwijzer BIO Thema-uitwerkingen.  
De BIO Thema-uitwerking Clouddiensten, hierna genoemd normenkader, is opgesteld door Wiekram Tewarie ([[UWV (Uitvoeringsinstituut Werknemersverzekeringen)|Uitvoeringsinstituut Werknemersverzekeringen (UWV)]]/[[Centrum Informatiebeveiliging en Privacybescherming (CIP)|Centrum Informatiebeveiliging en Privacybescherming (CIP)]]) en Jaap van der Veen (CIP). De opdrachtgever is de de directeur CIP. Het CIP-kernteam heeft versie 2.0 van dit normenkader gereviewd. Zodoende valt dit normenkader in het regime ‘becommentarieerde praktijk’. ==Considerans== CIP-producten steunen op kennis van professionals uit verschillende organisaties actief in het CIP-netwerk, zowel uit de overheid als de markt. Opmerkingen en aanvullingen kun je melden op [https://www.cip-overheid.nl/contact/ cip-overheid.nl/contact]. ==Leeswijzer== Voorafgaand aan het [[ISOR:BIO Thema Clouddiensten Beleid|beleidsdomein]], [[ISOR:BIO Thema Clouddiensten Uitvoering|uitvoeringsdomein]] en [[ISOR:BIO Thema Clouddiensten Control|control-domein]], de kern van dit document, heeft elke BIO Thema-uitwerking een inleiding met een standaard paragraafindeling. Aanvullend geldt: * Voor de aanduiding van personen wordt de mannelijke vorm aangehouden (hij/hem/zijn) ongeacht het geslacht. * De controls en maatregelen vermeld in deze thema-uitwerking zijn in het beleids-, uitvoerings- en control-domein georganiseerd, waarmee ze bij de overeenkomstige functionarissen kunnen worden geadresseerd. Deze functionarissen zijn niet benoemd omdat dit organisatie-afhankelijk is. * Van best practices (open standaarden al dan niet toegankelijk met een licentie) zijn de meest actuele versies afgekort vermeld, tenzij de actuele versie niet toereikend is. * Voor een overzicht van alle gebruikte best practices, afkortingen en begrippen en een generieke toelichting op de opzet van de thema-uitwerkingen, zie de Structuurwijzer BIO Thema-uitwerkingen.  +
De BIO Thema-uitwerking Communicatievoorzieningen, hierna genoemd normenkader, is opgesteld door Wiekram Tewarie ([[UWV (Uitvoeringsinstituut Werknemersverzekeringen)|Uitvoeringsinstituut Werknemersverzekeringen (UWV)]]/[[Centrum Informatiebeveiliging en Privacybescherming (CIP)|Centrum Informatiebeveiliging en Privacybescherming (CIP)]]) en Jaap van der Veen (CIP). De opdrachtgever is de voorzitter van de werkgroep BIO en de directeur CIP. Het CIP-kernteam heeft versie 2.0 van dit normenkader gereviewd. Zodoende valt dit normenkader in het regime ‘becommentarieerde praktijk’. ==Considerans== CIP-producten steunen op kennis van professionals uit verschillende organisaties actief in het CIP-netwerk, zowel uit de overheid als de markt. Opmerkingen en aanvullingen kun je melden op [https://www.cip-overheid.nl/contact/ cip-overheid.nl/contact]. ==Leeswijzer== Voorafgaand aan het [[ISOR:BIO Thema Communicatievoorzieningen Beleid|beleidsdomein]], [[ISOR:BIO Thema Communicatievoorzieningen Uitvoering|uitvoeringsdomein]] en [[ISOR:BIO Thema Communicatievoorzieningen Control|control-domein]], de kern van dit thema, heeft elke BIO Thema-uitwerking een inleiding met een standaard paragraafindeling. De volgende leeswijzer geldt voor dit normenkader: *Voor de aanduiding van personen wordt de mannelijke vorm aangehouden (hij/hem/zijn) ongeacht het geslacht. *De controls, hierna genoemd criteria, en maatregelen, hierna genoemd normen, vermeld in dit normenkader zijn in het beleids-, uitvoerings- en control-domein georganiseerd, waarmee ze bij de overeenkomstige functionarissen kunnen worden geadresseerd. Deze functionarissen zijn niet benoemd omdat dit organisatie-afhankelijk is. *Van best practices (open standaarden al dan niet toegankelijk met een licentie), zijn de meest actuele versies afgekort vermeld, tenzij de actuele versie niet toereikend is. *Voor een overzicht van alle gebruikte best practices, afkortingen en begrippen en een generieke toelichting op de opzet van de thema-uitwerkingen, zie de Structuurwijzer BIO Thema-uitwerkingen.  
De BIO Thema-uitwerking Huisvesting informatievoorzieningen, hierna genoemd normenkader, is opgesteld door Wiekram Tewarie ([[UWV (Uitvoeringsinstituut Werknemersverzekeringen)|Uitvoeringsinstituut Werknemersverzekeringen (UWV)]]/[[Centrum Informatiebeveiliging en Privacybescherming (CIP)|Centrum Informatiebeveiliging en Privacybescherming (CIP)]]) en Jaap van der Veen (CIP). De opdrachtgever is de voorzitter van de werkgroep BIO en de directeur CIP. Het CIP-kernteam heeft versie 2.0 van dit normenkader gereviewd. Zodoende valt dit normenkader in het regime ‘becommentarieerde praktijk’. ==Considerans== CIP-producten steunen op kennis van professionals uit verschillende organisaties actief in het CIP-netwerk, zowel uit de overheid als de markt. Opmerkingen en aanvullingen kun je melden op [https://www.cip-overheid.nl/contact/ cip-overheid.nl/contact]. ==Leeswijzer== Voorafgaand aan het [[ISOR:BIO Thema Huisvesting Informatievoorziening Beleid|beleidsdomein]], [[ISOR:BIO Thema Huisvesting Informatievoorziening Uitvoering|uitvoeringsdomein]] en [[ISOR:BIO Thema Huisvesting Informatievoorziening Control|control-domein]], de kern van dit thema, heeft elke BIO Thema-uitwerking een inleiding met een standaard paragraafindeling. De volgende leeswijzer geldt voor dit normenkader: *Voor de aanduiding van personen wordt de mannelijke vorm aangehouden (hij/hem/zijn) ongeacht het geslacht. *De controls, hierna genoemd criteria, en maatregelen, hierna genoemd normen, vermeld in dit normenkader zijn in het beleids-, uitvoerings- en control-domein georganiseerd, waarmee ze bij de overeenkomstige functionarissen kunnen worden geadresseerd. Deze functionarissen zijn niet benoemd omdat dit organisatie-afhankelijk is. *Van best practices (open standaarden al dan niet toegankelijk met een licentie), zijn de meest actuele versies afgekort vermeld, tenzij de actuele versie niet toereikend is. *Voor een overzicht van alle gebruikte best practices, afkortingen en begrippen en een generieke toelichting op de opzet van de thema-uitwerkingen, zie de Structuurwijzer BIO Thema-uitwerkingen.  
De BIO Thema-uitwerking Serverplatform, hierna genoemd normenkader, is opgesteld door Wiekram Tewarie ([[UWV (Uitvoeringsinstituut Werknemersverzekeringen)|Uitvoeringsinstituut Werknemersverzekeringen (UWV)]]/[[Centrum Informatiebeveiliging en Privacybescherming (CIP)|Centrum Informatiebeveiliging en Privacybescherming (CIP)]]) en Jaap van der Veen (CIP). De opdrachtgever is de voorzitter van de werkgroep BIO en de directeur CIP. Het CIP-kernteam heeft versie 2.0 van dit normenkader gereviewd. Zodoende valt dit normenkader in het regime ‘becommentarieerde praktijk’. ==Considerans== CIP-producten steunen op kennis van professionals uit verschillende organisaties actief in het CIP-netwerk, zowel uit de overheid als de markt. Opmerkingen en aanvullingen kun je melden op [https://www.cip-overheid.nl/contact/ cip-overheid.nl/contact]. ==Leeswijzer== Voorafgaand aan het [[ISOR:BIO Thema Serverplatform Beleid|beleidsdomein]], [[ISOR:BIO Thema Serverplatform Uitvoering|uitvoeringsdomein]] en [[ISOR:BIO Thema Serverplatform Control|control-domein]], de kern van dit thema, heeft elke BIO Thema-uitwerking een inleiding met een standaard paragraafindeling. De volgende leeswijzer geldt voor dit normenkader: *Voor de aanduiding van personen wordt de mannelijke vorm aangehouden (hij/hem/zijn) ongeacht het geslacht. *De controls en maatregelen vermeld in deze thema-uitwerking zijn in het beleids-, uitvoerings- en control-domein georganiseerd, waarmee ze bij de overeenkomstige functionarissen kunnen worden geadresseerd. Deze functionarissen zijn niet benoemd omdat dit organisatie-afhankelijk is. *Van best practices (open standaarden al dan niet toegankelijk met een licentie) zijn de meest actuele versies afgekort vermeld, tenzij de actuele versie niet toereikend is. *Voor een overzicht van alle gebruikte best practices, afkortingen en begrippen en een generieke toelichting op de opzet van de thema-uitwerkingen, zie de Structuurwijzer BIO Thema-uitwerkingen.  +
De BIO Thema-uitwerking Softwarepakketten, hierna genoemd normenkader, is opgesteld door Wiekram Tewarie ([[UWV (Uitvoeringsinstituut Werknemersverzekeringen)|Uitvoeringsinstituut Werknemersverzekeringen (UWV)]]/[[Centrum Informatiebeveiliging en Privacybescherming (CIP)|Centrum Informatiebeveiliging en Privacybescherming (CIP)]]) en Jaap van der Veen (CIP). De opdrachtgever is de directeur CIP. Het CIP-kernteam heeft versie 1.1 van dit normenkader gereviewd. Zodoende valt dit normenkader in het regime ‘becommentarieerde praktijk’. ==Considerans== CIP-producten steunen op kennis van professionals uit verschillende organisaties actief in het CIP-netwerk, zowel uit de overheid als de markt. Opmerkingen en aanvullingen kun je melden op [https://www.cip-overheid.nl/contact/ cip-overheid.nl/contact]. ==Leeswijzer== Voorafgaand aan het [[Softwarepakketten Beleid|beleidsdomein]], [[Softwarepakketten Uitvoering|uitvoeringsdomein]] en [[Softwarepakketten Control|control-domein]], de kern van dit thema, heeft elke BIO Thema-uitwerking een inleiding met een standaard paragraafindeling. De volgende leeswijzer geldt voor dit normenkader: *Voor de aanduiding van personen wordt de mannelijke vorm aangehouden (hij/hem/zijn) ongeacht het geslacht. *De controls, hierna genoemd criteria, en maatregelen, hierna genoemd normen, vermeld in dit normenkader zijn in het beleids-, uitvoerings- en control-domein georganiseerd, waarmee ze bij de overeenkomstige functionarissen kunnen worden geadresseerd. Deze functionarissen zijn niet benoemd omdat dit organisatie-afhankelijk is. *Van best practices (open standaarden al dan niet toegankelijk met een licentie), zijn de meest actuele versies afgekort vermeld, tenzij de actuele versie niet toereikend is. *Voor een overzicht van alle gebruikte best practices, afkortingen en begrippen en een generieke toelichting op de opzet van de thema-uitwerkingen, zie de Structuurwijzer BIO Thema-uitwerkingen.  +
De BIO Thema-uitwerking Toegangsbeveiliging, hierna genoemd normenkader, is opgesteld door Wiekram Tewarie ([[UWV (Uitvoeringsinstituut Werknemersverzekeringen)|Uitvoeringsinstituut Werknemersverzekeringen (UWV)]]/[[Centrum Informatiebeveiliging en Privacybescherming (CIP)|Centrum Informatiebeveiliging en Privacybescherming(CIP)]]) en Jaap van der Veen ([[Belastingdienst]]). De opdrachtgever is de voorzitter van de werkgroep BIO en de directeur CIP. Het CIP-kernteam heeft versie 2.0 van dit normenkader gereviewd. Zodoende valt dit normenkader in het regime ‘becommentarieerde praktijk’. ==Considerans== CIP-producten steunen op kennis van professionals uit verschillende organisaties actief in het CIP-netwerk, zowel uit de overheid als de markt. Opmerkingen en aanvullingen kun je melden op [https://www.cip-overheid.nl/contact/ cip-overheid.nl/contact]. ==Leeswijzer== Voorafgaand aan het [[ISOR:BIO Thema Toegangsbeveiliging Beleid|beleidsdomein]], [[ISOR:BIO Thema Toegangsbeveiliging Uitvoering|uitvoeringsdomein]] en [[ISOR:BIO Thema Toegangsbeveiliging Control|control-domein]], de kern van dit thema, heeft elke BIO Thema-uitwerking een inleiding met een standaard paragraafindeling. De volgende leeswijzer geldt voor dit normenkader: *Voor de aanduiding van personen wordt de mannelijke vorm aangehouden (hij/hem/zijn) ongeacht het geslacht. *De controls en maatregelen vermeld in deze thema-uitwerking zijn in het beleids-, uitvoerings- en control-domein georganiseerd, waarmee ze bij de overeenkomstige functionarissen kunnen worden geadresseerd. Deze functionarissen zijn niet benoemd omdat dit organisatie-afhankelijk is. *Van best practices (open standaarden al dan niet toegankelijk met een licentie) zijn de meest actuele versies afgekort vermeld, tenzij de actuele versie niet toereikend is.  +
De BIR is een gemeenschappelijk normenkader voor de beveiliging van de informatie(systemen). De BIR 2017 is volledig gebaseerd op de internationale norm [[NEN-EN-ISO/IEC 27002:2017 (Praktijkrichtlijn met beheersmaatregelen op het gebied van informatiebeveiliging)|ISO/IEC 27002]]. Het concretiseert een aantal eisen tot verplichte operationele afspraken (rijksmaatregelen), om een eenduidig minimumniveau van beveiliging voor gegevens te garanderen. De standaard basisbeveiligingsniveaus (BBN's) met bijbehorende beveiligingseisen maken risicomanagement eenvoudiger.  +
BLAU zal bestaan uit een kernset van de gegevens uit de huidige Polisadministratie van het UWV. De polisadministratie is reeds operationeel en gevuld. Zij het niet met de wettelijke status van een basisregistratie (de planning van de Polisadministratie is daarom niet opgenomen in de releasekalender). Gegevens uit de Polisadministratie kunnen echter wel geleverd worden aan overheidsorganisaties (voor zover wetgeving dat toestaat). Wat betreft planning (primo 2018) bevindt BLAU zich nog in een pril stadium. Er is nog geen besluit genomen of de basisregistratie BLAU onwikkeld wordt.  +
De Basisregistratie Inkomen (BRI) bevat van circa dertien miljoen burgers het authentieke inkomensgegeven. Dit is -uitsluitend - het verzamelinkomen, of als dat er niet is, het belastbare jaarloon over het afgelopen kalenderjaar. En gegevens zoals het burgerservicenummer (BSN). [https://www.stelselvanbasisregistraties.nl/registraties/ Stelsel van basisregistraties]  +
De Basisregistratie Kadaster (BRK) bevat informatie over percelen, eigendom, hypotheken, beperkte rechten (zoals recht van erfpacht, opstal en vruchtgebruik) en leidingnetwerken. Daarnaast staan er kadastrale kaarten in met perceel, perceelnummer, oppervlakte, kadastrale grens en de grenzen van het Rijk, de provincies en gemeenten.  +
Deze te downloaden koppeltabel biedt de relatie tussen BAG-verblijfsobjecten en het bijbehorende kadastrale perceel. [http://www.kadaster.nl/web/Themas/Registraties/BAG/BAGartikelen/BRKBAG-koppeling.htm BRK-BAG koppeltabel op website Kadaster]  +
Bestandslevering van de BRK. Integreert administratieve en geografische gegevens. Leverbaar als eenmalige standlevering, dagelijkse mutatielevering. Filtering mogelijk op gemeente, gebied en subject. Downloadservice. * [http://www.kadaster.nl/web/artikel/BRK-Levering-2/BRK-Levering-1.htm BRK Levering op website Kadaster] Verwerkingstermijn: maximaal 15 werkdagen.  +
Bestandslevering van de BRK. Integreert administratieve en geografische gegevens. Leverbaar als eenmalige standlevering, periodieke standlevering. Filtering mogelijk op gemeente, gebied en subject. Downloadservice. Verwerkingstermijn: maximaal 15 werkdagen. * [http://www.kadaster.nl/web/Themas/Registraties/BRK.htm BRK Levering op website Kadaster]  +
Informatie over de ondergrond (bodem, geologie, grondwater, mijnbouw) is nodig bij een groot aantal overheidstaken, zoals het winnen van water, aardgas of aardwarmte of de opslag van CO2. Dat moet duurzaam, veilig en efficiënt gebeuren. De daarvoor benodigde ondergrondgegevens en -modellen zijn te gebruiken vanuit de Basisregistratie Ondergrond (BRO). De BRO maakt deel uit van het stelsel van basisregistraties. De BRO voegt daar modellen (zoals de Bodemkaart) en gegevens (zoals grondwaterstanden en boringen) over de diepe en ondiepe ondergrond aan toe. Nu zijn deze ondergrondgegevens nog in beheer bij verschillende organisaties. Ze zijn daardoor niet in dezelfde mate gedigitaliseerd, gestandaardiseerd en geharmoniseerd en maar deels publiek beschikbaar. Dankzij de BRO hebben alle gegevens een gevalideerde, hoge kwaliteit en zijn ze voor iedereen vrij beschikbaar. De overheid kan planprocessen en beheerstaken efficiënter uitvoeren en de kwaliteit van haar dienstverlening verbeteren.  +
De Basisregistratie Personen (BRP) is een basisregistratie in ontwikkeling (programma Modernisering GBA). De BRP bevat persoonsgegevens over alle ingezetenen van Nederland en over personen die niet in Nederland wonen - of hier slechts kort verblijven - maar die een relatie hebben met de Nederlandse overheid, de 'niet-ingezeten'. De BRP wordt gebaseerd op twee bestaande administraties: *GBA (Gemeentelijke Basisadministratie Persoonsgegevens): Gegevens over personen ingeschreven bij een Nederlandse gemeente. De GBA heeft op dit moment al de status van een basisregistratie; *RNI (Registratie Niet-Ingezetenen). Gegevens over personen die niet in Nederland wonen, maar wel een relatie met de Nederlandse overheid hebben. Zoals grensarbeiders, buitenlandse studenten en 'pensionado's'. De RNI is op 6 januari 2014 ingevoerd met de inwerkingtreding van de nieuwe wet basisregistratie personen. Daarnaast is er nog de PIVA Verstrekkingen. Deze bevat gegevens over personen ingeschreven op de BES-eilanden (Bonaire, Sint Eustatius en Saba). De persoonslijsten in de PIVA-V en de persoonslijsten in de GBA komen grotendeels overeen, maar er zijn enkele verschillen. In het document ‘Verschillenmatrix persoonslijst GBA versus PIVA’ worden deze verschillen beschreven. Mogelijk zullen in de toekomst de BES-eilanden ook onderdeel uitmaken van de BRP. Daar is echter nog geen besluit over genomen.  +
De Basisregistratie Topografie (BRT) is dé unieke bron voor alle topografische informatie. De BRT gegevens worden geactualiseerd, beheerd en uitgeleverd door het Kadaster.  +
In de Basisregistratie Voertuigen worden gegevens vastgelegd over voertuigen en de eigenaren daarvan. Uit de registratie verstrekt de Dienst voor het Wegverkeer informatie aan burgers en bedrijven. De gegevens zijn landelijk beschikbaar voor overheidsinstanties, zoals de politie en de Belastingdienst.  +
Met BSI-Standard 200-2 biedt [[BSI (Bundesamt für Sicherheit in der Informationstechnik)|Bundesamt für Sicherheit in der Informationstechnik (BSI)]] een methodologie voor effectief beheer van informatiebeveiliging. Dit kan worden aangepast aan de eisen van organisaties van verschillende soorten en maten. In BSI-Standard 200-2 wordt dit geïmplementeerd via de drie methodieken: # Standard Protection # Basic Protection # Core Protection  +
Het onderwerp bedrijfscontinuïteitsbeheer (BCM) is al jaren stevig verankerd in IT-Grundschutz en biedt met de vorige BSI-standaard 100-4 een gefundeerde ondersteuning voor calamiteitenbeheer. De voortdurende ontwikkelingen en ervaringen op het gebied van BCM, emergency management en (IT) crisismanagement, evenals de gerelateerde BSI-standaarden voor informatiebeveiliging, hebben de noodzaak aangetoond om de BSI Standard 100-4 fundamenteel te moderniseren. De BSI 200-4 biedt praktische instructies voor het opzetten en opzetten van een Business Continuity Management Systeem (BCMS) in uw eigen organisatie. Op deze manier maakt het vooral onervaren BCM-gebruikers een gemakkelijke introductie tot het onderwerp mogelijk. Voor ervaren BCM-gebruikers wordt een normatieve catalogus van eisen ter beschikking gesteld. Er is momenteel geen certificering voor de standaard gepland. Na de Community Draft-fase tot 30 juni 2021 zullen alle opmerkingen dienovereenkomstig worden bekeken en verwerkt.  +
Citeren, vinden en verbinden van wet- en regelgeving gaat door toepassing van de BWB standaard sneller, eenvoudiger en geeft minder kans op fouten. Gebruik van de standaard biedt daardoor verbetering van interoperabiliteit. De open standaard BWB biedt een eenduidige manier van verwijzen naar (onderdelen van) wet- en regelgeving. De laatste versie (versie 1.3.1) maakt het mogelijk om in wet- en regelgeving te kunnen verwijzen naar: * taalversies en onderdelen van internationale verdragen, * wet- en regelgeving waarvan de indeling niet voldoet aan de gebruikelijke nummering van hoofdstukken en paragrafen, en * ruime begrippen zoals “enig artikel”. De drie Juriconnect standaarden BWB, ECLI en JCDR zijn gericht op standaardisatie van identificatie met het doel om de geïdentificeerde inhoud te delen. De standaard BWB (Basis Wetten Bestand) is gericht op verwijzing naar geconsolideerde wet- en regelgeving. Voor verwijzing naar wet- en regelgeving of onderdelen daarvan in wetten.overheid.nl, is aan elke regeling een uniek identificatienummer (BWBID) toegekend. De Juriconnect standaard voor BWB beschrijft hoe deze verwijzing wordt vormgegeven. Nota bene: op de website van Juriconnect wordt de BWB standaard ook wel aangeduid als de standaard "logische links naar wetgeving". De standaard JCDR (Juriconnect Decentrale Regelgeving) is gericht op identificatie van en verwijzing naar geconsolideerde decentrale regelgeving. Elke overheid legt een collectie algemeen verbindende voorschriften aan met de teksten van verordeningen en keuren, waarin de later vastgestelde wijzigingen zijn verwerkt (geconsolideerde vorm). Deze collectie is de Centrale Voorziening Decentrale Regelgeving (CVDR). De Juriconnect standaard voor decentrale voorzieningen beschrijft hoe dient te worden verwezen naar documenten die in CVDR zijn opgeslagen. De ECLI standaard (European Case Law Identifier) is gericht op identificatie voor citatie in het juridische domein. De ECLI is een Europese standaard notatie voor het uniek identificeren van jurisprudentie, met een sterke basis en input vanuit LJN (Landelijk Jurisprudentie Nummer). De standaard beschrijft de wijze waarop, met behulp van een Uniform Resource Identifier (URI), kan worden verwezen naar een European Case Law Identifier.  , Citeren, vinden en verbinden van wet- en regelgeving gaat door toepassing van de BWB standaard sneller, eenvoudiger en geeft minder kans op fouten. Gebruik van de standaard biedt daardoor verbetering van interoperabiliteit.  +
Citeren, vinden en verbinden van wet- en regelgeving gaat door toepassing van de BWB standaard sneller, eenvoudiger en geeft minder kans op fouten. Gebruik van de standaard biedt daardoor verbetering van interoperabiliteit.  +
BZK en VNG werken aan een portaal met alle API's van organisaties met een publieke taak  +
Een gemeenschappelijk normenstelsel binnen een organisatie, waaruit passende maatregelen kunnen worden afgeleid. Een type baseline is de baseline kwaliteit, dat wil zeggen een organisatiebreed normenkader waarin de organisatie ook alle concrete maatregelen beschrijft die de kwaliteit van de diensten waarborgen.  +
Baseline Informatiebeveiliging Overheid (BIO) openbaar gepubliceerd  +
Een in een basisregistratie opgenomen gegeven.  +
Een bij wet als basisregistratie aangemerkte registratie.  +
Batch-gewijs via bestanden: afnemer stuurt een lijst BSN’s en krijgt BSN’s + AIG (authentiek inkomen gegeven) terug.  +
Batch-gewijs via bestanden: afnemer stuurt een lijst BSN’s en krijgt BSN’s + AIG (authentiek inkomen gegeven) terug.  +
==Definitie== Een reeks verbonden taken of activiteiten die noodzakelijk zijn voor het beheren van serverplatforms. ==Toelichting== Bedieningsprocedures zijn een reeks verbonden taken of activiteiten die noodzakelijk zijn voor het beheren van serverplatforms. De activiteiten kunnen gerelateerd zijn aan het starten en afsluiten van de computer, back-up en onderhoud van servers.  +
==Toelichting== De eigenschappen van het softwarepakket voldoen aan de businessbehoefte van de klant en ondersteunt daarmee op een veilige manier het bedrijfsproces. Het softwarepakket bevat goed-gedefinieerde mogelijkheden en interfaces. Integratie en mogelijke koppelingen spelen daarbij een belangrijke rol. Het is zinvol na te gaan welke (open) standaarden een softwarepakket ondersteunt en in hoeverre deze in de toekomst actueel gehouden worden. Denk daarbij aan een standaard als Pan-European Public Procurement OnLine (PEPPOL) voor E-factureren. Het softwarepakket dient de klant naast businessfuncties ook voldoende ‘digitale behendigheid’ te leveren, waardoor de organisatie componenten kan veranderen, naar behoefte kan uitbreiden en het softwarepakket aan het einde van de levenscyclus kan vervangen onafhankelijk van de belendende systemen. ==Schaalgrootte== Elke schaalgrootte. ==Voor wie== Klant.  +
==Toelichting== Omdat de klant voor de continuïteit van haar bedrijfsvoering in hoge mate afhankelijk kan zijn van de beschikbare functionaliteit van softwarepakketten zijn maatregelen voor calamiteiten van essentieel belang. De beoogde continuïteit kan daarbij bepaald worden door externe factoren, zoals het ‘omvallen’ van cloud-leveranciers of de hostingproviders. Bedrijfscontinuïteit omvat een set van maatregelen, die tijdens calamiteiten, zoals natuurrampen, binnen de overeengekomen maximale uitvalsduur (Recovery Time Objective (RTO)), zorgt voor het herstel van data en de kritische dienstverlening, waarbij dataverlies beperkt blijft tot het maximaal toegestane dataverlies. Bekende continuïteitsmaatregelen zijn: redundantie, disaster recovery en het periodiek aantonen dat herstelfuncties werken. ==Schaalgrootte== Middel en groot. ==Voor wie== Klant en leverancier.  +
==Definitie== Omvat het beheersingsproces en de activiteiten die organisaties beschermen tegen ontwrichtende gebeurtenissen. ==Toelichting== BCM beschrijft de eisen voor een managementsysteem om organisaties te beschermen tegen ontwrichtende gebeurtenissen, om de kans op deze gebeurtenissen te verkleinen en om te zorgen dat een organisatie daar volledig van kan herstellen. Hierbij zal de organisatie zich onder andere richten op ontwikkeling, implementatie en onderhoud van beleid, strategieën en programma’s om de effecten van mogelijk ontwrichtende gebeurtenissen de organisatie te kunnen beheersen. In de cloud-omgeving vertrouwt de CSC, de CSP als derde partij. De CSP zal de CSC zekerheid moeten geven over documentatie over assets en resources, incidentmanagement, bedrijfscontinuïteit, herstelplannen, beleid, beheerprocessen en back-up-management.  +
==Definitie== Betreft maatregelen, die tijdens normaal bedrijf en bij voorkomende calamiteiten, binnen de overeengekomen maximale uitvalduur, zorgen voor het herstel van de data en de dienstverlening, waarbij dataverlies wordt voorkomen. ==Toelichting== Omdat de CSC voor haar bedrijfsvoering sterk afhankelijk is van de CSP en van externe factoren zijn bedrijfscontinuïteitsservices van essentieel belang. Bedrijfscontinuïteitsservices omvatten het pakket van maatregelen, dat zowel voor normaal bedrijf (met QoS) als voor situaties van calamiteiten, zoals natuurrampen, binnen de overeengekomen maximale uitvalsduur Recovery Time Objective (RTO), zorgt voor het herstel van data en de kritische dienstverlening, waarbij dataverlies beperkt blijft tot het overeengekomen maximale dataverlies. Bekende continuïteitsmaatregelen zijn redundantie, disaster recovery en het periodiek aantonen dat herstelfuncties werken.  +
==Definitie== Alle machines, apparatuur, informatie en software die overzichtelijk geïnventariseerd zijn. ==Toelichting== NB De control uit de BIO is ten opzichte van de [[NEN-EN-ISO/IEC 27001:2017 (Managementsystemen voor informatiebeveiliging - Eisen)|ISO 27001]] veranderd. In de huisvesting van de rekencentra zijn verschillende bedrijfsmiddelen, voorzieningen en hieraan gerelateerde componenten opgenomen, zoals: glasvezel en bekabeling, back-upvoorzieningen, klimaatbeheersing, airconditioning en geavanceerde brandblussystemen. Het is van belang de componenten van deze voorzieningen zelf en/of informatie over deze voorzieningen te inventariseren en te registreren zodat de juiste informatie beschikbaar is, wanneer gebeurtenissen daarom vragen.  +
==Definitie== Het verwijderen van elk middel, waarin of waarmee bedrijfsgegevens kunnen worden opgeslagen en/of verwerkt en waarmee toegang tot gebouwen, ruimten en IT-voorzieningen kan worden verkregen (bedrijfsproces, gedefinieerde groep activiteiten en gegevens, gebouw, apparaat en IT-voorziening). ==Toelichting== Bedrijfsmiddelen zijn alle objecten waarmee bedrijfsgegevens kunnen worden opgeslagen en/of verwerkt en objecten, waarmee toegang tot gebouwen, ruimten en IT-voorzieningen kan worden verkregen. Verwijdering van deze middelen dient nauwkeurig met vastgestelde procedures te worden uitgevoerd (ingevoerd, gebruikt en afgevoerd).  +
Alle informatieteksten zijn in begrijpelijke taal door de dienstverlener opgesteld. Hierdoor kunnen afnemers direct een aanvraag doen of een vraag stellen en is de dienst voor iedereen begrijpelijk.  +
De mate waarin gegevens eenvoudig gelezen en geïnterpreteerd kunnen worden door gebruikers.  +
Is in de wet/regelgeving/beleid/regel etc. voldoende aandacht besteed aan de volgende zaken: <br /> # Zijn de zinsbouw en schrijfstijl laagdrempelig genoeg? # Wordt gebruik gemaakt van lange zinnen of bijzinnen? # Is er een (memorie van) toelichting beschikbaar? # Welke voorkennis wordt van de lezer verwacht? # Is bij een wetswijziging een geconsolideerde versie beschikbaar? # Zijn puur technische (wets)wijzigingen meegenomen en zijn die wijzigingen als zodanig gemarkeerd?  +
Het begrip 'Informatiecatalogus' sec wordt nauwelijks gebruikt: wat is een 'informatiecatalogus' exact en waarin dit verschilt van een gegevenswoordenboek, metadata rond gebruik en een dienstbeschrijving moet nader gepreciseerd worden. Of zijn het dezelfde soort dingen? Zie ook issue IKV-006  +
Soms worden begrippen als synoniemen door elkaar gebruikt, of definities gehanteerd die in veel sectoren niet herkend zullen worden  +
==Definitie== Het beheer van servers door beheerders vanuit een niet-vertrouwde omgeving. ==Toelichting== Toegang tot de servers is beperkt tot geautoriseerde personen en informatiesystemen. Onder bepaalde voorwaarden is het beheerders ‘van buiten’ de door de organisatie beheerde netwerken, toegestaan servers te benaderen.  +
==Definitie== Proactieve beveiliging van servers door het verwerven van inzicht in de kwetsbaarheden en zwakheden in de software die op de server zijn geïnstalleerd. ==Toelichting== Kwaadwillenden maken gebruik van kwetsbaarheden en zwakheden in software die op de servers zijn geïnstalleerd. Kwetsbaarhedenbeheer is een proactieve benadering van beveiliging door de kans te verminderen dat gebreken in software de beveiliging van een server in gevaar brengt. Zonder inzicht in de huidige stand van zaken, tast de beheerder in het duister en kan hij niet goed anticiperen op nieuwe ontwikkelingen. Vragen die hierbij een rol spelen: * Hoe is de serveromgeving opgebouwd en geconfigureerd? * Wat zijn bekende kwetsbaarheden en zwakheden? Gerelateerd aan kwetsbaarhedenbeheer is het patchmanagementproces. Het [[NEN-EN-ISO/IEC 27002:2017 (Praktijkrichtlijn met beheersmaatregelen op het gebied van informatiebeveiliging)|ISO 27002]]-onderwerp ‘Beheer van technische kwetsbaarheden’ (in paragraaf 12.6.1) behandelt wat betreft de maatregelen twee onderwerpen: # Kwetsbaarhedenbeheer (vulnerability-management); # Patchmanagement (zie [[ISOR:Patchmanagement|U.05 Patchmanagement)]]. In dit thema worden deze twee onderwerpen apart beschreven.  +
==Beschrijving== Het moet mogelijk zijn om vertegenwoordigingsbevoegdheden te creëren, te wijzigen en te beëindigen. ==Voorbeelden== ==Rationale== Het verdient sterk de aanbeveling om een vertegenwoordigingsbevoegdheid expliciet vast te leggen. Op die manier wordt voorkomen dat er discussie ontstaat over de vraag óf er een vertegenwoordigingsbevoegdheid is verleend en voor welke diensten. Het initiatief tot een vrijwillige machtiging kan zowel bij de vertegenwoordigde als de vertegenwoordiger liggen. De persoon die niet het initiatief heeft genomen moet de machtiging kunnen bevestigen. De memorie van toelichting WDO, onder artikel 5 lid 1 onderdeel b, zegt over het vastleggen van een machtiging het volgende: “Bij de vastlegging in elektronische vorm wordt de strekking van de vertegenwoordigingsbevoegdheid uitgedrukt in termen van de elektronische diensten (wat) die de vertegenwoordiger namens de vertegenwoordigde mag uitvoeren. Hierbij moet bedacht worden, dat registratie geen voorwaarde is voor het ontstaan van een machtiging; het is een hulpmiddel voor een bestuursorgaan of aangewezen organisatie om te bepalen of iemand is gemachtigd, oftewel het vormt een aanwijzing op basis waarvan bestaan, aard en omvang van de machtiging bepaald kan worden. De machtigingsdienst controleert thans niet of de aan de registratie ten grondslag liggende volmacht in alle opzichten rechtsgeldig is, dus bijvoorbeeld of de vertegenwoordigde handelingsbekwaam was op het moment van afgeven van de machtiging en registratie ervan.” We hebben ervoor gekozen om het kunnen creëren, wijzigen (ook wel: corrigeren) en beëindigen (ook wel: intrekken) door alle betrokkenen (verstrekker, vertegenwoordigde en vertegenwoordiger) samen te nemen tot één generieke functie. Een verdere rationale voor deze generieke functie en de implicaties die hieruit voortkomen is te vinden in: * Algemene kenmerken van machtigen (hoofdstuk 3), * Specifieke kenmerken van vrijwillige machtiging (paragraaf 3.1), * Specifieke kenmerken van wettelijke vertegenwoordiging (paragraaf 3.2), * Wettelijk kader A en B (paragraaf 4.1.1), * Beleidskader D (paragraaf 4.1.2), * Maatschappelijke en technische ontwikkeling F (paragraaf 4.1.3). Met ‘beheren’ bedoelen we hieronder steeds ‘creëren, wijzigen en beëindigen’. ==Implicaties== # Het is mogelijk om machtigingen tussen natuurlijke personen, tussen niet-natuurlijke personen en tussen natuurlijke en niet-natuurlijke personen te beheren. # Het is mogelijk om een vertegenwoordigingsbevoegdheid met meerdere vertegenwoordigers te beheren. # Het is mogelijk om een vertegenwoordigingsbevoegdheid voor een dienst, combinatie van diensten of alle diensten te beheren. # Bij vrijwillig machtigen kunnen vertegenwoordigde en vertegenwoordiger instemmen met de machtiging. # Het is mogelijk om een bij gerechtelijke uitspraak geregelde vertegenwoordigingsbevoegdheid te beheren. # Bij een bij gerechtelijke uitspraak geregelde vertegenwoordigingsbevoegdheid is de gerechtelijke uitspraak waarop deze is gebaseerd vermeld. # Het moet mogelijk zijn om de vertegenwoordigde en de vertegenwoordigers waartussen de vertegenwoordigingsrelatie geldt eenduidig te vermelden in de vertegenwoordigingsbevoegdheid. Dit betekent dat deze personen een unieke aanduiding moeten hebben. # Het moet mogelijk zijn om diensten waarvoor de vertegenwoordigingsbevoegdheid geldt eenduidig te vermelden in de vertegenwoordigingsbevoegdheid. Dit betekent dat diensten een unieke aanduiding moeten hebben die op gestandaardiseerde wijze opgenomen kan worden in een vertegenwoordigingsbevoegdheid. # Derde partijen kunnen een voorstel tot intrekking of wijziging van een vertegenwoordigingsbevoegdheid doen. Na controle op de grond van de intrekking wordt de intrekking verwerkt. Hiervoor zijn afspraken nodig over welke partijen voorstellen kunnen doen, wat de gronden zijn en waar deze gevonden kunnen worden. ==Documentatie== * [[media:GO_Machtigen_en_vertegenwoordigen.pdf|GO Machtigen en vertegenwoordigen (PDF, 642 kB)]] ==Kaders== Deze kaders zijn bepalend voor deze generieke functie. * [[Algemene_Wet_Bestuursrecht | Algemene Wet Bestuursrecht]] * [https://www.digitaleoverheid.nl/dossiers/wet-digitale-overheid/ Wet digitale overheid] * [https://www.rijksoverheid.nl/documenten/publicaties/2017/10/10/regeerakkoord-2017-vertrouwen-in-de-toekomst/ Regeerakkoord 2017]  
==Definitie== Betreft de inrichting en het functioneren van de organisatie rond het functionele en technische beheer van clouddiensten en de bijbehorende taken, verantwoordelijkheden en bevoegdheden. ==Toelichting== Voor het adequaat beheersen en beheren van clouddiensten moet de CSP een beheersingsorganisatie hebben ingericht, waarin de structuur en verantwoordelijkheden voor beheersprocessen met toereikende bevoegdheden zijn uitgedrukt en op het juiste niveau zijn gepositioneerd. In de relatie tussen de beheersingsprocessen van de CSP en de CSC moeten ook de taken en verantwoordelijkheden tussen het functioneel- en technisch beheer zijn overeengekomen.  +
==Definitie== De opzet van een toereikende organisatiestructuur voor het beheren van en rapporteren over netwerken en communicatievoorzieningen. ==Toelichting== Het adequaat beheersen en beheren van de communicatievoorzieningen vereist een organisatiestructuur waarin de procesverantwoordelijkheden en de toereikende bevoegdheden van de functionarissen zijn vastgelegd en op het juiste niveau zijn gepositioneerd.  +
==Definitie== Een organisatorische eenheid die verantwoordelijk is voor de beheersing van de servers en serverplatformomgeving en die adequaat is gepositioneerd. ==Toelichting== Voor het adequaat beheersen en beheren van servers en serverplatforms zou een beheersorganisatiestructuur moeten zijn vastgesteld, waarin de verantwoordelijkheden voor de beheersprocessen met toereikende bevoegdheden zijn uitgedrukt en op het juiste niveau zijn gepositioneerd.  +
==Definitie== De organisatie die verantwoordelijk is voor de beheersing van de te bouwen computerprogramma’s. ==Toelichting== De projectmanager heeft een (beheers)organisatiestructuur ingericht, waarbij de verantwoordelijkheden voor de beheersprocessen met toereikende bevoegdheden zijn uitgedrukt en op het juiste niveau zijn gepositioneerd.  +
==Definitie== De organisatorische beheersstructuur waarin de rollen en de verantwoordelijkheden van de betrokken actoren voor de beheersing van huisvesting IV duidelijk zijn verankerd. ==Toelichting== De verantwoordelijke stakeholder voor de beheersorganisatie van huisvesting IV behoort een organisatiestructuur vastgesteld te hebben, waarin de verantwoordelijkheden voor de beheersprocessen met toereikende bevoegdheden zijn uitgedrukt en op het juiste niveau zijn gepositioneerd.  +
==Definitie== De organisatie die verantwoordelijk is voor het ondersteunen van het beheer en de doorontwikkeling van het afsprakenstelsel. De beheersingsorganisatie controleert en bewaakt dat dienstverleners en deelnemers het afsprakenstelsel naleven. ==Toelichting== Voor het adequaat beheersen en beheren van het toegangsbeveiligingssysteem dient een beheersorganisatiestructuur te zijn vastgesteld, waarin de verantwoordelijkheden voor de beheersprocessen met toereikende bevoegdheden zijn uitgedrukt en op het juiste niveau zijn gepositioneerd.  +
in een omgeving die vooraf gedefinieerd is en volgens wetgeving en referentiearchitectuur is ingericht. Het is een structurele aanpak.  +
==Definitie== Een middel voor energietransport van een bron naar een bestemming. ==Toelichting== Binnen huisvesting IV is alle apparatuur verbonden met een bekabelingssysteem die in speciale kabelruimten is geïnstalleerd. Deze bekabelingsruimten kunnen doelwit worden van misbruik door bijvoorbeeld speciale afluisterapparatuur aan te sluiten. Het is daarom noodzakelijk om deze bekabelingsruimten te voorzien van specifieke beveiligingsmaatregelen.  +
Heeft een eerste registratie, de [https://www.belastingdienst.nl/wps/wcm/connect/bldcontentnl/belastingdienst/prive/werk_en_inkomen/geregistreerde_inkomen_en_de_inkomensverklaring/alles_over_geregistreerde_inkomen/alles-over-het-geregistreerde-inkomen BRI], via Linked Data ontsloten en werkt Linked Data voor datamining.  +
==Definitie== De waarborging van de bescherming van informatie in netwerken, door inzet van beheerprocedures voor informatietransport en het hanteren van procedures voor het bewaking van netwerken. ==Toelichting== De [[NEN-EN-ISO/IEC 27002:2017 (Praktijkrichtlijn met beheersmaatregelen op het gebied van informatiebeveiliging)|ISO 27002 2017]]: 14.2.1 formuleert ‘Beveiligd ontwikkelen’ als een eis voor het opbouwen van een beveiligde dienstverlening, architectuur, software en beveiligd systeem. Dit object richt zich op inrichtings- en onderhoudsaspecten van communicatievoorzieningen. In het te formuleren beleid worden onder andere standaarden en procedures beschreven voor het beveiligd inrichten en onderhouden van communicatievoorzieningen.  +
==Definitie== Het resultaat van besluitvorming, waarmee het voor het beveiligd ontwikkelen (top)management van de organisatie heeft vastgelegd welke regels en protocollen gehanteerd moeten worden om op een veilige wijze veilige applicaties e.d. te ontwikkelen. ==Toelichting== De [[NEN-EN-ISO/IEC 27002:2017 (Praktijkrichtlijn met beheersmaatregelen op het gebied van informatiebeveiliging)|ISO 27002 2017]], artikel 14.2.1 formuleert ‘Beveiligd ontwikkelen’ als een eis voor het opbouwen van een beveiligde dienstverlening, architectuur, software en een beveiligd systeem. In dit thema worden bij het object ‘Beleid voor (beveiligd) ontwikkelen’ aan applicatieontwikkelingsbeleid gerelateerde specifieke aspecten benadrukt. In zo’n beleid worden onder andere methoden en technieken voor requirementsanalyse en -richtlijnen voor beveiliging in de levenscyclus van softwareontwikkeling besproken.  +
==Definitie== Het resultaat van een besluitvorming over het onderhouden van serverplatforms waarin het verantwoordelijke management voor serverplatforms van een organisatie heeft vastgelegd op welke wijze serverplatforms onderhouden dienen te worden. ==Toelichting== De [[NEN-EN-ISO/IEC 27002:2017 (Praktijkrichtlijn met beheersmaatregelen op het gebied van informatiebeveiliging)|ISO 27002 2017]] formuleert ‘beveiligd ontwikkelen’ in paragraaf 14.2.1 ‘Beleid voor beveiligd ontwikkelen’ als een eis voor het opbouwen van een beveiligde dienstverlening, software, systemen en architectuur. In dit thema wordt bij het object ‘Beleid voor beveiligde inrichting en onderhoud’ inrichtings- en onderhoudsaspecten van serverplatform benadrukt. In het beleid worden onder andere standaarden en procedures beschreven voor het beveiligd inrichten en onderhouden van servers.  +
==Definitie== Het proces van evalueren van de serveromgeving. ==Toelichting== Het is noodzakelijk om de technische omgeving regelmatig te beoordelen om de beveiliging doeltreffend te kunnen beheersen. Hiertoe dienen periodiek zowel de organisatorische als technische aspecten beoordeeld te worden, zoals: de toepassing van het geformuleerd inrichtingsbeleid voor servers, serverplatformarchitectuur, taken en verantwoordelijkheden, gebruik van technische middelen, frequentie, controle aanpak en inschakelen van externe specialisten. Als resultaat dient een rapportage van bevindingen aan het management te worden uitgebracht.  +
==Definitie== Het onderhouden van c.q. zorgen voor de toegangsrechten. Beoordeling toegangsrechten is gerelateerd aan twee aspecten: beoordelingsproces en toegangsrechten. Het aspect beoordelingsproces behelst het uitvoeren van met elkaar samenhangende activiteiten over het evalueren van toegangsrechten op validiteit of deze nog voldoen aan de actuele situatie. Het aspect toegangsrechten impliceert een recht om toegang te krijgen, zoals tot een locatie of systeem. ==Toelichting== Het is nodig om de (logische en fysieke) toegangsrechten van gebruikers regelmatig te beoordelen om de toegang tot gegevens en informatiediensten doeltreffend te kunnen beheersen. De toekenningen en wijzigingen van toegangsrechten dienen daarom periodiek gecontroleerd te worden. Hiertoe dienen maatregelen te worden getroffen in de vorm van: * het voeren van controle-activiteiten op de registratie van toegangsrechten; * het uitbrengen van rapportages aan het management.  +
==Definitie== Beoordelingsrichtlijnen geven de voorschriften en/of aanwijzingen voor het beoordelen van beheeractiviteiten. Procedures geven de handelingen aan, die volgens omschreven stappen moeten worden uitgevoerd. ==Toelichting== De inrichting van de toegangsbeveiliging moet beheerst worden. Hiertoe dient periodiek door een bepaalde functionaris met specifieke bevoegdheden controle-activiteiten te worden verricht. Deze activiteiten dienen ondersteund te worden met procedures en instructies, anders bestaat het risico dat de resultaten van de controle-activiteiten niet voldoen aan de verwachte eisen. De structuur van de beheersingsorganisatie geeft de samenhang van de ingerichte processen weer. Een control en de bijbehorende maatregelen worden hieronder vermeld.  +
==Definitie== Het stellen van regels aan het installeren van servers en serverplatforms. ==Toelichting== Voor het gebruik van software (door een beheerder) op een server zijn regels opgesteld.  +
==Toelichting== Bij voorkeur dienen geleverde softwarepakketten ongewijzigd te worden toegepast. Wijzigingen van applicatiecode die niet door de leverancier zijn aangebracht, leveren bij actualisaties van het onderliggende serverplatform en interactie met andere platformen vaak technische problemen op. Ze veroorzaken daarbij mogelijk beveiligingsrisico’s. Eventuele wijzigingen dienen onder strikte voorwaarden, met goedkeuring van de leverancier plaats te vinden. Anderzijds worden organisaties die clouddiensten gebruiken soms geconfronteerd met nieuwe versies, die ze nog niet hebben kunnen testen voordat ze in de organisatie worden toegepast. ==Schaalgrootte== Middel en groot. ==Voor wie== Klant en leverancier.  +
==Definitie== Richtlijnen die gaan over het geven van een verminderde reikwijdte specifiek voor het installeren van computerprogramma’s. ==Toelichting== Het installeren van software kan betrekking hebben op 3 type actoren: # Gebruikers, om een bepaald type data-analyse in de business-omgeving te kunnen uitvoeren; # Softwareontwikkelaars, voor requirementsspecificatie, het creëren van datamodellen en het genereren van de programmacode; # Technische beheerders, voor het beheren van servers en netwerkcomponenten. Dit thema is gericht op eisen die gerelateerd zijn aan het installeren van software door ontwikkelaars voor het specificeren van gebruikersrequirements. Hierbij kan gedacht worden aan het toekennen van minimale rechten aan ontwikkelaars om additionele hulpsoftware te installeren of het toekennen van rechten die gerelateerd zijn aan de regels: need-to-use, need-to-know, need-to-modify, need-to-delete. Het doel hiervan is om risico’s die gerelateerd zijn aan het onbedoeld wijzigen van kritische assets (zoals informatie, software, applicaties en system security controls) te beperken.  +
==Doel== Het bereikbaarheidsprofielbeheer geeft burgers de mogelijkheid voor het eenmalig aangeven en onderhouden van zijn bereikbaarheid en voorkeuren in contact met de overheid. ==Scope== Bezien vanuit het gemak en herkenbaarheid voor de betrokkene, is het zeer belangrijk dat er één gemeenschappelijke plek is voor het beheren van de (digitale) bereikbaarheid, de voorkeuren en kanaaladressen. Dat voorkomt dat een burger dit op veel verschillende plekken en op telkens andere wijze moet doen. En het voorkomt ook dat dat profiel niet consistent of niet actueel is (waardoor het niet meer betrouwbaar zou zijn voor andere overheidsorganisaties). ==Afspraak== * Gebruik van deze generieke functie is verplicht voor overheidsorganisaties. * De verantwoordelijkheid ervoor wordt gedeeld door alle overheidsorganisaties. * Stelselafspraken zijn nodig om de gedeelde verantwoordelijkheid voor en het gebruik van deze functie te regelen. ==Voorziening== De overheid heeft een bereikbaarheidsprofielbeheer-voorziening waar burgers (personen die contact hebben met de overheid) gebruik van kunnen maken. Met deze voorziening is het onder meer mogelijk dat: # Een betrokkene geeft na authenticatie binnen zijn bereikbaarheidsprofiel aan op welk emailadres hij bepaalde berichten wil ontvangen; # Een betrokkenen geeft na authenticatie aan via welk telefoonnummer hij bepaalde sms-notificaties wil ontvangen; # DUO verstuurt een notificatie naar het door een betrokkenen opgegeven telefoonnummer dat er een nieuw bericht in een beveiligde omgeving beschikbaar is. NB. Nader onderzocht moet worden in welke mate bereikbaarheidsprofielenbeheer ook voor bedrijven van toepassing is. ==GO-principes== # GO-BP-1 Denken vanuit behoeften van “burgers en bedrijven” # GO-BP-2 Rekening houden met diversiteit bij “burgers en bedrijven” # GO-BP-4 Gebruik van ontkoppelde functies ==Voorbeelden== Bij MijnOverheid.nl kan je jouw e-mail adres instellen voor berichten en notificaties. ==Status== Medio 2020 is via een pressure-cooker versnelling aangebracht in de oplevering van GO. Een vijftal werkgroepen heeft in 2 maanden tijd uitwerking gegeven aan: * ‘Why’ van de GDI inclusief bijbehorende visual, * uitgangspunten voor het vastleggen van generieke functies (capability’s), * visies voor de domeinen Interactie, Gegevensuitwisseling, Identificatie en Authenticatie (Toegang), Machtigen en Infrastructuur. Resultaten van de pressure cooker zijn overgedragen om mee te nemen in de Gemeenschappelijke Overheidsarchitectuur (GO). GO brengt samenhang aan, verwijdert dubbelingen en verdiept visies zodanig dat besluitvorming in de PL en (naar beoordeling door PL) in het OBDO mogelijk is. Voor het domein Interactie geldt dat bovendien nog afstemming met de beleidsomgeving moet plaatsvinden. Gegevensuitwisseling heeft nu nog een bredere scope dan GDI en zal daarom binnen de GDI-context in samenhang met andere domeinen uitgewerkt worden. ==Documentatie== De visie uit de pressure cooker GO t.a.v. Interactie is opgenomen in het document van de werkgroep Interactie: [[media:GO_Pressure_Cooker_Interactie.pdf|GO_Pressure_Cooker_Interactie.pdf (PDF, 2,29 MB)]]. ==Naamgeving== Het visie document uit de pressure cooker gebruikt voor deze capability de naam '''Bereikbaarheidsprofielbeheer voor burgers'''  
De berichtenbox voor bedrijven is een beveiligd e-mailsysteem waarmee u, via Antwoord voor bedrijven, digitaal berichten kunt uitwisselen met Nederlandse overheidsinstanties (de Rijksoverheid, provincies, gemeenten en waterschappen). De berichtenbox is bedoeld voor ondernemers die gevestigd zijn in de Europese Economische Ruimte (EER) - dus ook in Nederland - en die hun diensten in Nederland willen aanbieden. De berichtenbox kan gebruikt worden voor procedures die onder de Dienstenwet vallen, en voor procedures waarbij de bevoegde instantie ervoor gekozen heeft deze (ook) via de berichtenbox te laten verlopen.  +
De berichtenbox (op MijnOverheid) is de digitale postbus voor berichten van de overheid aan burgers. De gemeente meldt bijvoorbeeld dat een paspoort moet worden verlengd. Of de RDW meldt dat een auto gekeurd moet worden. Als er een bericht in de box staat, wordt dit per e-mail gemeld aan de betreffende persoon. Berichten versturen via de berichtenbox is (nog) niet mogelijk.  +
==Definitie== Het beschermen van beschikbare gegevens die gebruikt worden om aan te tonen dat een informatiesysteem werkt conform de vastgestelde eisen en wensen. ==Toelichting== Voor het testen van informatiesystemen wordt gebruik gemaakt van verschillende soorten gegevens. Het gebruik van operationele databases met persoonsgegevens of enige andere vertrouwelijke informatie moet worden vermeden en aangepast. Testgegevens dienen zorgvuldig te worden gekozen, beschermd en gecontroleerd.  +
Diensten zijn operationeel en toegankelijk om te gebruiken volgens de afspraken tussen de betrokken partijen.  +
gegevens worden opgeslagen volgens duurzame normen en afhankelijk van de organisatiekeuze beschikbaar gesteld aan verschillende afnemers. Dit kan zich bijvoorbeeld uiten in technische, privacy afgeschermde, digitale, open of gesloten vormen.  +
Bestandsleveringen van de verschillende BRT-datasets. Via PDOK: * [http://www.kadaster.nl/web/artikel/productartikel/TOP10NL.htm TOP10NL] (voor schaalniveau’s tussen 1:5.000 en 1:25.000) wordt geleverd in bestandsformaten GML. * [http://www.kadaster.nl/web/artikel/productartikel/TOPvector.htm TOPvector] (voor schaalniveau’s tussen 1:25.000 en 1:250.000) wordt geleverd in de bestandsformaten DGN, DXF en Shape. * [http://www.kadaster.nl/web/artikel/productartikel/TOPgrenzen.htm TOPgrenzen] wordt geleverd in de bestandsformaten DGN en Shape. * [http://www.kadaster.nl/web/artikel/productartikel/TOPnamen.htm TOPnamen] wordt geleverd in de bestandsformaten GDB, Dbase of Excel. (Datasets alleen voor geheel Nederland of deelgebied)  +
De beschikbaarheid en de kwaliteit van diensten voldoen aan vooraf bepaalde normen. Aangeboden informatie dient bijvoorbeeld juist, authentiek, actueel en volledig te zijn. Processen zijn zodanig ingericht dat dit is gegarandeerd en monitoring van het kwaliteitsniveau plaatsvindt.  +
De kwaliteit van diensten voldoet aan vooraf bepaalde normen. Processen zijn zodanig hierop ingericht dat dit is gegarandeerd en dat monitoring van het kwaliteitsniveau plaatsvindt.  +
De mate waarin de organisatie zich voor de informatievoorziening kan verlaten op een informatiesysteem. De betrouwbaarheid van een informatiesysteem is daarmee de verzamelterm voor de begrippen beschikbaarheid, integriteit en vertrouwelijkheid.  +
==Definitie== De inlogprocedure is gerelateerd aan de aspecten aanmelden en procedure. #Aanmelden (inloggen) behelst het leggen van een verbinding via authenticatiemiddelen. #De procedure is de samenhangende beschrijving van welke activiteiten moeten plaatsvinden. ==Toelichting== De toegang tot systemen en toepassingen wordt beheerst met beveiligde inlogprocedures. Daarbij dient de geclaimde identiteit op passende wijze en met een geschikte techniek te worden vastgesteld. De procedure om in te loggen, wordt zo ontworpen, dat de kans op onbevoegde toegang minimaal is.  +
Het traject van ontwikkelen van een applicatie en het in productie nemen van de resultaten van dit ontwikkeltraject vindt gefaseerd plaats in specifieke omgevingen. Bij de ontwikkeling worden vier omgevingen onderscheiden: # Ontwikkelomgeving, Hierin wordt de programmacode ontwikkeld. Om te voorkomen dat ontwikkelingen het productieproces kunnen beïnvloed is deze omgeving gescheiden van de productie omgeving. # Testomgeving, Hierin worden de uit de ontwikkelomgeving afkomstige producten getest door professionele testteams. Aanwezige, in de testomgeving gesignaleerde, onvolkomenheden in de software worden weer via ontwikkelomgeving aangepast. Dit is een iteratief proces totdat uit de test naar voren komt dat het product geschikt is om in productie te nemen; # Acceptatieomgeving, Hierin worden de softwareproducten (nog éénmaal grondig) getest en bij positief resultaat door de gebruikers en beheerders geaccepteerd. Bij eventuele onvolkomenheden worden de softwareproducten niet geaccepteerd (no-go) en terug gestuurd naar de testomgeving of ontwikkelomgeving; # Productieomgeving, Hierin worden de nieuwe softwareproducten uitgerold. De Productie omgeving is de omgeving waarin de nieuwe softwareproducten functioneel en actief moeten zijn. De in de voorgaande omgevingen uitgevoerde stappen moeten zo veel mogelijk garanderen dat nieuw ontwikkelde software geen fouten bevat die de productiegegevens kunnen corrumperen. In principe zijn alle omgevingen los van elkaar ingericht en vindt behalve via formele overdrachten geen contact plaats tussen de verschillende omgevingen.  +
Informatiebeveiliging is het geheel van preventieve, detectieve, repressieve en correctieve maatregelen, alsmede procedures en processen om eventuele gevolgen van beveiligingsincidenten tot een acceptabel (passend), vooraf bepaald niveau te beperken. De maatregelen zijn gebaseerd op een risicoanalyse en wettelijke verplichtingen (waaronder - in het geval van persoonsgegevens - ook de AVG).  +
Beveiliging en Gegevensbeschrijvingen in openbare review  +
==Definitie== De eisen die aan dienstverleners gesteld worden voor de te nemen maatregelen voor de beveiligingsmechanismen, het dienstverleningsniveau en de kwaliteit van beheerprocessen. ==Toelichting== De eisen voor communicatievoorzieningen betreffen enerzijds de verantwoordelijkheden voor de informatiebeveiliging van het transport en de distributie van informatie en anderzijds de beveiligde toegang tot de transportvoorzieningen zelf.  +
==Toelichting== Op het hoogste niveau beschrijft een zogenaamde enterprise-architectuur de context van de organisatie en op hoofdlijnen het geheel aan organisatorische en functionele activiteiten en tot welke bedrijfsoutput dit resulteert. De beveiligingsarchitectuur beschrijft met het beveiligingsbeleid in samenhang welke organisatorische en technische beveiligingsmaatregelen de beoogde bedrijfsfunctionaliteit en dienstverlening ondersteunen voor eindgebruikers en klanten. ==Schaalgrootte== Middel en groot. ==Voor wie== Klant.  +
==Definitie== De faciliteiten waarmee bedrijfsmiddelen en voorzieningen binnen ruimten beveiligd worden. ==Toelichting== De rekencentra bevatten verschillende type ruimten zoals: kantoren, bekabelingsruimten en serverruimten. Deze ruimten moeten conform de beveiligingsgraad van deze ruimten voorzien zijn van beveiligingsfaciliteiten.  +
==Definitie== Een specialistische functie om de beveiligingsdoelstellingen te bereiken en waaraan een autoriteit en verantwoordelijkheden zijn gekoppeld voor het - in relatie tot de beveiliging - coördineren en (laten) verrichten van werkzaamheden. ==Toelichting== De organisatie beschikt over middelen en informatie die beveiligd moeten worden. Hiervoor moeten de juiste rollen zijn benoemd binnen een centraal orgaan, de beveiligingsfunctie. De functionarissen binnen deze functies hebben specifieke verantwoordelijkheden voor het realiseren van toegangsbeveiliging binnen de gehele organisatie, waaronder het toegangsbeveiligingssysteem.  +
==Definitie== Omvat een of meer in- en/of externe personen, die een taak, verantwoordelijkheid en bevoegdheid hebben om de beveiliging in relationele samenhang te organiseren. ==Toelichting== De beveiligingsfunctie omvat de geformaliseerde taken en verantwoordelijkheden voor clouddiensten. Binnen de beveiligingsfunctie is geregeld dat contact wordt onderhouden met verantwoordelijken binnen de CSC-organisatie wanneer sprake is van beveiligingsincidenten. De beveiligingsorganisatie van de CSP zorgt/ziet toe op het naleven van het informatiebeveiligingsbeleid, clouddienstenbeleid en overig hieraan gerelateerd beleid. Hoewel een ‘Beveiligingsfunctie’ als zelfstandig object beschouwd kan worden, is voor de eenvoud gekozen om deze in dit thema te integreren met de organisatie. Waar nodig grijpt de beveiligingsorganisatie in. De taken, verantwoordelijkheden, bevoegdheden en middelen die de beveiligingsorganisatie hiervoor heeft zijn vooraf expliciet, in relatie tot de CSC, benoemd en vastgesteld. Ook moet vooraf vaststaan hoe de rapportagelijnen tussen de beveiligingsverantwoordelijken zijn georganiseerd.  +
==Definitie== Een groepering van mensen die in onderlinge samenwerking activiteiten ontplooien voor het beveiligen van in dit geval toegangsvoorzieningen om op doelmatige wijze overeengekomen toegangsbeveiligingsdoelstellingen te bereiken. Als collectief dragen zij bij aan de realisatie van de geformuleerde beveiligingsdoelstellingen. ==Toelichting== De beveiligingsorganisatie ziet toe op het naleven van het informatiebeveiligingsbeleid. Waar nodig grijpt de beveiligingsorganisatie in. Welke taken, verantwoordelijkheden, bevoegdheden en middelen een beveiligingsorganisatie hierin heeft, wordt vooraf expliciet benoemd en vastgesteld. Ook moet vaststaan hoe de rapportagelijnen zijn uitgestippeld.  +
==Doel== Doel van Bevoegdhedenbeheer is het toekennen van een bevoegdheid aan een entiteit om namens een andere entiteit te mogen handelen. ==Scope== Bevoegdhedenbeheer betreft de “levenscyclus” van bevoegdheden: vanaf het onderkennen (ontstaan en eventueel aanpassen), naar het toekennen aan digitale identiteiten en het verklaren daarvan, tot aan het intrekken (verwijderen) van bevoegdheden.<br /> ==Voorbeelden== Doorgaans wordt Bevoegdhedenbeheer ook wel Autorisatiebeheer of Access Management genoemd. <br /> Uitgangspunt hierbij is, dat met bepaalde “regels” wordt bepaald wat mag (of wat niet mag) en dat op het moment dat ergens toegang tot wordt gevraagd, wordt gecontroleerd of dat volgens die regels mag.<br /> Zo’n regel kan bijvoorbeeld ook zijn, dat een persoon door iemand anders gemachtigd is om iets te doen. Machtigen wordt daarom gezien als onderdeel van Bevoegdhedenbeheer. ==Status== Medio 2020 is via een pressure-cooker versnelling aangebracht in de oplevering van GO. Een vijftal werkgroepen heeft in 2 maanden tijd uitwerking gegeven aan: * ‘Why’ van de GDI inclusief bijbehorende visual, * uitgangspunten voor het vastleggen van generieke functies (capability’s), * visies voor de domeinen Interactie, Gegevensuitwisseling, Identificatie en Authenticatie (Toegang), Machtigen en Infrastructuur. Resultaten van de pressure cooker zijn overgedragen om mee te nemen in de Gemeenschappelijke Overheidsarchitectuur (GO). GO brengt samenhang aan, verwijdert dubbelingen en verdiept visies zodanig dat besluitvorming in de PL en (naar beoordeling door PL) in het OBDO mogelijk is. Voor het domein Interactie geldt dat bovendien nog afstemming met de beleidsomgeving moet plaatsvinden. Gegevensuitwisseling heeft nu nog een bredere scope dan GDI en zal daarom binnen de GDI-context in samenhang met andere domeinen uitgewerkt worden. ==Documentatie== De visie uit de pressure cooker GO t.a.v. Machtigen is opgenomen in het document van de werkgroep: [[media:GO_Pressure_Cooker_Machtigen.pdf|GO_Pressure_Cooker_Machtigen.pdf (PDF, 419 kB)]]. ==Naamgeving== Deze generieke functie Bevoegdhedenbeheer is nieuw toegevoegd aangezien in diverse beschrijvingen van GO naast Machtigen ook “bevoegdheden” worden genoemd en dat aansluit bij de bevindingen van de NORA expertgroep IAM, waar deze functie reeds was beschreven.  
De bevoegdheden die aan de uitvoeringsorganisatie zijn verleend, bakenen de wettelijke taken van de organisatie af. Daarmee is in abstracte zin vastgesteld wat de organisatie wel en wat ze niet mag doen. Pas wanneer een uitvoeringsorganisatie bevoegd is een wettelijke taak uit te voeren, kan er sprake zijn van rechtmatige uitvoering.  +
Persoonsgegevens mogen niet langer worden bewaard dan noodzakelijk is om het doel te bereiken waarvoor ze zijn verzameld of niet langer dan de bewaartermijn die sectorspecifieke wetgeving stelt. De bewaartermijn kan worden beëindigd door actieve verwijdering van de gegevens of door anonimisering van de persoonsgegevens. Bij anonimisering zijn de gegevens niet meer herleidbaar tot de betrokkenen.<br>NB: De AVG is niet van toepassing op de persoonsgegevens van overleden personen<sup class="noot">[[Algemene Verordening Gegevensbescherming (AVG)|AVG]] overweging 27: "De lidstaten kunnen regels vaststellen betreffende de verwerking van de persoonsgegevens van overleden personen."</sup>.  +
De mate waarin de juistheid van een gegeven kan worden aangetoond  +
Eventueel gemaakte fouten in een geleverde dienst worden tijdig hersteld. De levering van een dienst kan door allerlei omstandigheden anders verlopen dan was voorzien. Nationaal zijn afspraken gemaakt dat dan herstel plaatsvindt, zie NORA AP29 [[De dienstverlener voldoet aan de norm]]. Doorgaans zal het de burger c.q. een vertegenwoordiger van het bedrijf zijn dat de fout (of vermeende fout) bij de dienstverlener aankaart. Bij verschil van inzicht tussen de burger en de behandelend ambtenaar, kan dat leiden tot een klacht of een eventuele escalatie naar de Ombudsman. Ingeval het verschil van inzicht een besluit van een bevoegd gezag betreft, kan het ook leiden tot een bezwaar- en/of beroepsschrift volgens de [[Algemene Wet Bestuursrecht]]. De fout kan echter ook blijken vanuit de sturing op de kwaliteit van de dienst door de dienstverlener, zie NORA AP31 [[PDCA-cyclus in besturing kwaliteit]]. In dat geval kan de verantwoordelijke overheidsorganisatie het herstel proactief zelf inzetten. De afhandeling van deze correcties vindt plaats o.b.v. compassie en met de menselijke maat en verloopt uiteindelijk via [[Diensten leveren volgens de afspraken]]. En deze correctie zal worden verantwoord tot op het hoogste niveau, zoals dat ook is beoogd bij het [https://nl.wikipedia.org/wiki/ISO_9001 ISO 9001 Kwaliteitssysteem]. In geval de oorzaak van de fout structureel van aard is, zal dat worden doorgegeven aan een collega-ambtenaar die kan laten overgaan tot het her-ontwerp van die dienst, zie [[(Her)ontwerpen van een dienst]]. Dit mechanisme om tot tijdig herstel te komen is zeer wezenlijk in de vertrouwensrelatie tussen burgers en de overheid. Het is immers dat je niet in “goede tijden”, maar juist als het “fout gaat” wordt getest op karakter, normen en waarden! Als overheid (ambtenaar) willen we leren van onze fouten. En toeslagen-debacles moeten voortaan worden voorkómen. De mogelijkheden om tot herstel te komen zullen daarom voor elke dienst klip en klaar moeten zijn. Als in een dienstlevering iets niet goed is gelopen en een burger een beroep doet op 1 of meer van de 5 genoemde correctiemogelijkheden, dan zal elke vraag om correctie uiteindelijk altijd moeten leiden tot een actie vanuit de overheid om te [[Sturen op (verbetering van) de kwaliteit van dienstverlening]]. En van daar uit zal altijd een correctieve -en mogelijk ook preventieve- actie ondernomen moeten worden (wat in de praktijk immers nog regelmatig niet goed verloopt).  
Het bieden van een democratisch proces om volksvertegenwoordigers te kiezen, zorgt er voor dat de stem van de Nederlandse burgers -die tevens stemmen vanuit hun rol als eigenaar of medewerker van bedrijven- niet alleen wordt gehoord, maar via het Kabinet en Parlement ook feitelijk invloed heeft op de visie en het beleid waarmee de Nederlandse samenleving vorm krijgt. De trigger voor deze capability komt vanuit de Politiek, waar verkiezingscampagnes kunnen worden gestart. En de noodzakelijke input daarbij, is de verkiezing van volksvertegenwoordigers door stemgerechtigde burgers. Zie voor meer details de beschrijving van dit proces: [https://www.rijksoverheid.nl/onderwerpen/democratie/werking-parlementaire-democratie de werking van de parlementaire democratie].  +
De overheid (het ambtelijke apparaat c.q. de uitvoeringsorganisaties) biedt een aanbod van diensten dat past bij de behoeften van burgers en bedrijven. Anno 2021 maakt elke overheidsorganisatie de diensten die zij levert voor burgers en bedrijven toegankelijk via de eigen website. Die diensten moeten zodanig zijn beschreven, dat burgers en bedrijven vooraf al kunnen weten wat ze mogen verwachten. In principe zal zo’n beschrijving staan op de website(s) van de overheidsorganisatie(s) waar de dienst wordt aangeboden. De ca. 1400 overheidsorganisaties doen dat ieder op hun eigen manier en met verschillende technische oplossingen. Nationaal zijn afspraken gemaakt welke aspecten van een dienst worden beschreven, zie NORA AP05 [[Nauwkeurige dienstbeschrijving]], maar in de praktijk wordt deze afspraak niet altijd gevolgd. Voor burgers en bedrijven betekent dat een divers palet aan websites van de overheid, waar je geen overzicht op hebt en niet gemakkelijk je weg in kunt vinden. Als oplossing daarvoor is een [https://www.overheid.nl/producten_en_diensten gemeenschappelijke zoekmachine] gemaakt, waarmee burgers en bedrijven alle aangeboden diensten vanuit die een (1) plek kunnen vinden en die daardoor dus functioneert als een soort “virtuele” diensten-catalogus van de Nederlandse Overheid. Gegeven dit aanbod van diensten van de overheid, is van belang na te gaan in hoeverre dat aanbod past bij de behoefte van burgers en bedrijven. Waar kunnen burgers en bedrijven hun wensen kenbaar maken voor nieuwe diensten en feedback geven op het aanbod? Dat lijkt momenteel alleen mogelijk als de overheid daar zelf proactief in is en die wensen specifiek uitvraagt bij een geleverde dienst of meer algemeen via bijvoorbeeld landelijke onderzoeken. Een nog openstaande vraag hierbij is: op basis van welke criteria weegt de overheid af in hoeverre het mogelijk is om aan die wensen te voldoen? Daarbij zal een afweging worden gemaakt tussen individuele wensen en collectieve belangen, of tussen algemene afspraken en de discretionaire bevoegdheid van overheidsorganisaties e.d. Verder kan het ook handig zijn voor de overheid om aan te geven welke diensten (tijdelijk) niet worden geleverd, of welke nieuwe worden voorzien. Vanuit de NORA bestaan in elk geval 2 principes die voor het ontwerp van een dienst rekening houden met feedback van de gebruikers. Zie NORA AP19 [[Perspectief gebruiker]] en NORA AP31 [[PDCA-cyclus in besturing kwaliteit]] Maar dat is eenmalig bij de opzet en raakt dus niet de reflecties van burgers en bedrijven op het reeds bestaande dienstenaanbod. Vanuit NORA wordt daarom geadviseerd om dit dienstenaanbod niet los te zien van het [[Sturen op (verbetering van) de kwaliteit van dienstverlening]], waarbij de reflecties van burgers via het [[(Her)ontwerpen van een dienst]] kunnen worden verwerkt in een aangepast Dienstenaanbod. Voorbeelden van een Dienstenaanbod zijn: De publieke diensten van de [https://www.denhaag.nl gemeente Den Haag] of de [https://www.belastingdienst.nl/ Belastingdienst]. Of de mogelijkheid om via de gemeenschappelijke zoekmachine alle door de [https://www.overheid.nl/ Nederlandse Overheid] aangeboden publieke diensten te vinden.  
{{{Beschrijving}}}  +
Boekje met 10 praktijktoepassingen van Linked Data in Nederland  +
Voorziening die deel uitmaakt van de infrastructuur van de e-overheid.  +
Indeling van bouwstenen zoals gehanteerd in NORA 3.0 Katern strategie. Indeling in Contactfuncties, Identity Management, Basisregistraties, Elektronische informatie-uitwisseling.  +
<br> ==Verslag sessie== Meer informatie: * [[NORA review]] * [[NORA review kwaliteitskader]] In deze sessie waren van te voren geen PSA's ingebracht. Met een groep van een man of 14 bekeken Eric Brouwer, Peter Bergman en Robert van Wessel daarom de referentiearchitectuur van Regie op Gegevens, die waarschijnlijk in het najaar in een nieuwere versie in openbare review zal gaan via noraonline.nl. Dit leidde tot discussies over onder andere: * Is het verschil tussen een PSA en een referentiearchitectuur altijd duidelijk? Zou een PSA bijvoorbeeld actionable moeten zijn? * Horen beleidsbrieven bij het juridisch kader, of hoort daar alleen wet- en regelgeving? * Beoordeel je in een NORA review of het voldoet aan NORA, of het een goede architectuur is, of allebei? Beide, tot op zeker hoogte ;-) * Moet er (altijd) een IST en SOLL transitie in een PSA voorkomen? * Hoeveel ruimte moet de huidige situatie in beslag nemen in een PSA? * Zou op noraonline naast het begrip [[PSA (Project Startarchitectuur)]] niet ook referentiearchitectuur en bijv. productarchitectuur gedefinieerd moeten worden? * Is de architectuurscope niet vaak groter dan de projectscope? * De samenhang met andere projecten / programma's hoort ook in een PSA thuis * Hoe dik of dun je PSA kan zijn is afhankelijk van wat er al als (enterprise) architectuur is beschreven. Idealiter trek je zaken die je in PSA's goed beschrijft naar je enterprise architectuur toe en maakt zo een serie van 'bouwblokken' die je in andere PSA's kunt gebruiken - of er naar verwijzen. Dan heb je uiteindelijk een veel dunner document nodig. ==Oorspronkelijke sessiebeschrijving== ===Hoe NORA-proof is mijn PSA?=== Steeds meer opdrachtgevers weten het al: bij je verandertraject in de eigen organisatie of digitale dienst aan de burger neem je een projectleider in de hand EN een onafhankelijk architect. De projectleider zorgt dat je inderdaad van A naar Beter komt binnen tijd en budget, de architect zorgt dat het eindresultaat ook inderdaad Beter is: ontworpen volgens de laatste inzichten, aansluitend op de omgeving en conform alle relevante wettelijke en kwaliteits-kaders. Het middel daarvoor is de [[PSA (Project Startarchitectuur)]]. Maar hoe zorg je dat dat PSA niet alleen de eigen directe context meeneemt, maar ook de kennis en afspraken op nationaal niveau in de NORA? We laten zien hoe je dat al in 1 uur kunt laten checken. ===Zo stellen we dat vast voor een willekeurige PSA!=== In deze sessie laat een NORA-expert ter plekke zien hoe hij een nog niet eerder door hem bekeken PSA analyseert en waardeert aan de hand van de PSA-instrumenten die de NORA biedt. Denk daarbij aan de [https://www.noraonline.nl/images/noraonline/6/64/ICTU_Handleiding_voor_het_maken_van_een_PSA.pdf PSA handleiding], de [[Principes|Architectuur Principes]], het [[Vijflaagsmodel]] en [[Thema's]]. Een hiertoe aangeleverde PSA wordt van commentaar en adviezen voorzien. Zo concreet, dat je daar in het project direct mee aan de slag kunt! ==Opzet van de sessie== We beginnen met een korte beschrijving van de ingebrachte PSA's, waarna de aanwezigen ter plekke kiezen welke PSA in deze sessie behandeld gaat worden. De gekozen PSA brengen we integraal in beeld, waarbij we de expert volgen die het document doorloopt. Hij denkt hardop en geeft zo een kijkje in de keuken van de NORA peer-review. Natuurlijk is er gelegenheid om in de chat vragen te stellen over het hoe en waarom, al zullen die om wille van de tijd mogelijk deels pas na afloop van de sessie kunnen worden beantwoord. Na de sessie delen we alle commentaren en bevindingen met degene die de PSA heeft aangeleverd. <br /> Vragen en aanvullingen over de methodiek van de NORA review bundelen we en publiceren we na afloop van de NORA Gebruikersweek voor alle deelnemers op noraonline.nl. ===OPROEP - breng zelf een PSA in voor de peer-review=== We dagen jullie uit om zelf een PSA in te brengen, die publiekelijk mag worden gedeeld. Het zou mooi zijn als het gaat om een nog lopend project, zodat de feedback ook echt kan worden gebruikt door de eigen architect om het op een hoger plan te brengen. Maar misschien zijn er andere redenen om een PSA te willen reviewen, bijvoorbeeld wanneer na afloop bleek dat er het een en ander over het hoofd gezien is: had een NORA review dat kunnen voorkomen? PSA's die niet besproken worden kunnen na afloop van de Gebruikersweek alsnog voor een NORA review worden aangemeld. Maar misschien heeft deelname aan de sessie je belangrijkste vragen al beantwoord - we horen het graag. Lever je PSA in pdf-format aan via [mailto:nora@ictu.nl?subject=PSA%20voor%20Bring%20Your%20Own%20PSA%20Gebruikersweek&body=Beste%20mensen%20van%20NORA%2C%0AHierbij%20lever%20ik%20een%20PSA%20om%20te%20bespreken%20in%20de%20sessie%20Bring%20Your%20Own%20PSA.%20Ik%20zal%20aanwezig%20zijn%20bij%20de%20sessie%20op%20donderdag%2027%20mei%20%28sessie%201%29%20%2F%20dinsdag%201%20juni%20%2F%20allebei.%0A%0AHet%20PSA%20is%20van%20het%20project%20of%20programma%20.....%2C%20dat%20nog%20van%20start%20gaat%20%2F%20al%20loopt%20%2F%20al%20is%20afgerond.%0AOnze%20belangrijkste%20vragen%20bij%20het%20PSA%20zijn%3A%20%0A%0A%0AMet%20vriendelijke%20groeten%2C%0ANaam%2C%20rol%20t.o.v.%20PSA%2C%20organisatie. nora@ictu.nl], inclusief een korte beschrijving van het project/programma en de belangrijkste vragen die jullie hebben. NB: Kun je niet deze sessie, maar wil je wel graag meedoen? Deze sessie wordt twee keer aangeboden in de NORA Gebruikersweek, op [[Bring Your Own PSA (sessie 1)|donderdag 27 mei]] en [[Bring Your Own PSA (sessie 2)|dinsdag 1 juni]].  
<br> ==Verslag sessie== Meer informatie: * [[NORA review]] * [[NORA review kwaliteitskader]] In deze intieme sessie konden alle deelnemers (delen van) een eigen PSA laten zien en bespreken. Een aantal inzichten die uit de sessie kwam: * In een PSA moet veel meer staan als de context nog niet in bijvoorbeeld een enterprise architectuur staat beschreven. * De betrokkenheid van stakeholders in een PSA is heel belangrijk - niet alleen voor de architect maar als het goed is juist voor de stakeholders zelf. * PSA's schrijven is een kunst die je door oefenen en reviewen steeds beter onder de knie krijgt. Verschillende reviewers halen verschillende elementen uit een PSA naar voren, waardoor uiteindelijk een completer beeld en document ontstaat. ==Oorspronkelijke sessiebeschrijving== ===Hoe NORA-proof is mijn PSA?=== Steeds meer opdrachtgevers weten het al: bij je verandertraject in de eigen organisatie of digitale dienst aan de burger neem je een projectleider in de hand EN een onafhankelijk architect. De projectleider zorgt dat je inderdaad van A naar Beter komt binnen tijd en budget, de architect zorgt dat het eindresultaat ook inderdaad Beter is: ontworpen volgens de laatste inzichten, aansluitend op de omgeving en conform alle relevante wettelijke en kwaliteits-kaders. Het middel daarvoor is de [[PSA (Project Startarchitectuur)]]. Maar hoe zorg je dat dat PSA niet alleen de eigen directe context meeneemt, maar ook de kennis en afspraken op nationaal niveau in de NORA? We laten zien hoe je dat al in 1 uur kunt laten checken. ===Zo stellen we dat vast voor een willekeurige PSA!=== In deze sessie laat een NORA-expert ter plekke zien hoe hij een nog niet eerder door hem bekeken PSA analyseert en waardeert aan de hand van de PSA-instrumenten die de NORA biedt. Denk daarbij aan de [https://www.noraonline.nl/images/noraonline/6/64/ICTU_Handleiding_voor_het_maken_van_een_PSA.pdf PSA handleiding], de [[Principes|Architectuur Principes]], het [[Vijflaagsmodel]] en [[Thema's]]. Een hiertoe aangeleverde PSA wordt van commentaar en adviezen voorzien. Zo concreet, dat je daar in het project direct mee aan de slag kunt! ===Opzet van de sessie=== We beginnen met een korte beschrijving van de ingebrachte PSA's, waarna de aanwezigen ter plekke kiezen welke PSA in deze sessie behandeld gaat worden. De gekozen PSA brengen we integraal in beeld, waarbij we de expert volgen die het document doorloopt. Hij denkt hardop en geeft zo een kijkje in de keuken van de NORA peer-review. Natuurlijk is er gelegenheid om in de chat vragen te stellen over het hoe en waarom, al zullen die om wille van de tijd mogelijk deels pas na afloop van de sessie kunnen worden beantwoord. Na de sessie delen we alle commentaren en bevindingen met degene die de PSA heeft aangeleverd. <br /> Vragen en aanvullingen over de methodiek van de NORA review bundelen we en publiceren we na afloop van de NORA Gebruikersweek voor alle deelnemers op noraonline.nl. ===OPROEP - breng zelf een PSA in voor de peer-review=== We dagen jullie uit om zelf een PSA in te brengen, die publiekelijk mag worden gedeeld. Het zou mooi zijn als het gaat om een nog lopend project, zodat de feedback ook echt kan worden gebruikt door de eigen architect om het op een hoger plan te brengen. Maar misschien zijn er andere redenen om een PSA te willen reviewen, bijvoorbeeld wanneer na afloop bleek dat er het een en ander over het hoofd gezien is: had een NORA review dat kunnen voorkomen? PSA's die niet besproken worden kunnen na afloop van de Gebruikersweek alsnog voor een NORA review worden aangemeld. Maar misschien heeft deelname aan de sessie je belangrijkste vragen al beantwoord - we horen het graag. Lever je PSA in pdf-format aan via [mailto:nora@ictu.nl?subject=PSA%20voor%20Bring%20Your%20Own%20PSA%20Gebruikersweek&body=Beste%20mensen%20van%20NORA%2C%0AHierbij%20lever%20ik%20een%20PSA%20om%20te%20bespreken%20in%20de%20sessie%20Bring%20Your%20Own%20PSA.%20Ik%20zal%20aanwezig%20zijn%20bij%20de%20sessie%20op%20donderdag%2027%20mei%20%28sessie%201%29%20%2F%20dinsdag%201%20juni%20%2F%20allebei.%0A%0AHet%20PSA%20is%20van%20het%20project%20of%20programma%20.....%2C%20dat%20nog%20van%20start%20gaat%20%2F%20al%20loopt%20%2F%20al%20is%20afgerond.%0AOnze%20belangrijkste%20vragen%20bij%20het%20PSA%20zijn%3A%20%0A%0A%0AMet%20vriendelijke%20groeten%2C%0ANaam%2C%20rol%20t.o.v.%20PSA%2C%20organisatie. nora@ictu.nl], inclusief een korte beschrijving van het project/programma en de belangrijkste vragen die jullie hebben. NB: Kun je niet deze sessie, maar wil je wel graag meedoen? Deze sessie wordt twee keer aangeboden in de NORA Gebruikersweek, op [[Bring Your Own PSA (sessie 1)|donderdag 27 mei]] en [[Bring Your Own PSA (sessie 2)|dinsdag 1 juni]].  
De plaats waar een gegeven of document voor de eerste keer is vastgelegd  +
Het burgerservicenummer (BSN) is het persoonsnummer voor contacten met de overheid. Dit unieke nummer helpt om bijvoorbeeld persoonsverwisselingen te voorkomen. Iedereen die zich voor het eerst inschrijft bij een gemeente krijgt een BSN. Een pasgeboren kind krijgt bij inschrijving in de BRP pas een BSN. Het BSN staat op het paspoort, rijbewijs en identiteitskaart.  +
==Definitie== Een methode om de mogelijke bedrijfsimpact die een organisatie zou kunnen ervaren, als gevolg van een incident, die de informatie in een systeem (bijvoorbeeld een applicatie) in gevaar brengt. ==Toelichting== Eén van de specifieke activiteiten bij applicatieontwikkeling is het uitvoeren van een BIA. Hierbij wordt vanuit verschillende optieken de doelomgeving geanalyseerd, om op deze manier de juiste requirements voor de te ontwikkelen applicatie te kunnen identificeren en traceren.  +
C
In de afgelopen jaren zijn er wereldwijd diverse incidenten geweest waarbij een partij PKI-certificaten kon aanvragen (en krijgen) voor andermans domeinen. Het ging hier met name om fouten in het uitgifteproces. Toepassing van de standaard CAA verkleint de kans dat iemand een certificaat kan aanvragen voor domeinen van bijvoorbeeld overheidsinstellingen of banken. Hiermee kunnen met name man-in-the-middle (MitM) aanvallen worden voorkomen. De CAA-standaard biedt verder de mogelijkheid aan CA's om melding te maken van foutief aangevraagde certificaten. Hierdoor krijgen domeineigenaren meer inzicht in eventuele foutieve of frauduleuze aanvragen voor het domein.  +
In de afgelopen jaren zijn er wereldwijd diverse incidenten geweest waarbij een partij PKI-certificaten kon aanvragen (en krijgen) voor andermans domeinen. Het ging hier met name om fouten in het uitgifteproces. Toepassing van de standaard CAA verkleint de kans dat iemand een certificaat kan aanvragen voor domeinen van bijvoorbeeld overheidsinstellingen of banken. Hiermee kunnen met name man-in-the-middle (MitM) aanvallen worden voorkomen. De CAA-standaard biedt verder de mogelijkheid aan CA's om melding te maken van foutief aangevraagde certificaten. Hierdoor krijgen domeineigenaren meer inzicht in eventuele foutieve of frauduleuze aanvragen voor het domein.  +
A cornerstone of the UN/CEFACT standardisation activities is the Core Component Technical Specification (CCTS). Core Components are the syntax-neutral and technology-independent building blocks that can be used for data modeling. Major benefits of CCTS include improved reuse of existing data artifacts, improved enterprise interoperability, and consistency across vertical industry standards. (bron: wikipedia)  +
Binnen de ISOR-pagina’s kom je de term 'CIP-netwerk' tegen als grondslag bij de uitwerking van bepaalde criteria en normen. Deze grondslag wordt gebruikt wanneer voor het betreffende criterium/norm geen onbetwiste aanwijsbare bron uit een best practice als grondslag geadopteerd kan worden. Deze grondslag geeft aan dat de betreffende norm opgesteld is door leden uit de CIP-community die, individueel of in de werkgroepen/schrijfgroepen, hebben bijgedragen aan het opstellen van de betreffende BIO Thema-uitwerking. Het CIP-netwerk is de community van het [[Centrum Informatiebeveiliging en Privacybescherming (CIP)|Centrum Informatiebeveiliging en Privacybescherming (CIP)]] die kennis deelt en ontwikkelt op het bredere terrein van informatiebeveiliging en privacybescherming. Eén van de kennisproducten van het CIP is de [[ISOR|Information Security Object Repository (ISOR)]], een verzameling van BIO Thema-uitwerkingen ter ondersteuning van organisaties bij de implementatie van de [[BIO (Baseline Informatiebeveiliging Overheid)|Baseline Informatiebeveiliging Overheid (BIO)]]. Meer informatie vind je over de BIO en het CIP op: * BIO [https://bio-overheid.nl/over-de-bio bio-overheid.nl/over-de-bio] * CIP [https://cip-overheid.nl/over-cip cip-overheid.nl/over-cip]  +
Met behulp van CMIS kunnen applicaties als Content Management Systemen (CMS) en Document Management Systemen (DMS) werken met content die afkomstig is uit verschillende repositories (een soort van opslagplaats voor ongestructureerde data), zonder nieuwe koppelingen te hoeven bouwen of gebruik te hoeven maken van leverancierseigen oplossingen. Het is hierdoor eenvoudiger om informatie en de bijbehorende metadata uit verschillende databases en over organisatiegrenzen heen uit te wisselen. Bovendien is het met CMIS eenvoudiger om te migreren van een systeem naar een ander systeem.  +
Met behulp van CMIS kunnen applicaties als Content Management Systemen (CMS) en Document Management Systemen (DMS) werken met content die afkomstig is uit verschillende repositories (een soort van opslagplaats voor ongestructureerde data), zonder nieuwe koppelingen te hoeven bouwen of gebruik te hoeven maken van leverancierseigen oplossingen. Het is hierdoor eenvoudiger om informatie en de bijbehorende metadata uit verschillende databases en over organisatiegrenzen heen uit te wisselen. Bovendien is het met CMIS eenvoudiger om te migreren van een systeem naar een ander systeem.  +
In de ontwerp-, realisatie-, en onderhoudsfases van bouwprojecten wisselen opdrachtgevers en opdrachtnemers heel diverse informatie uit, die wel met elkaar verbonden is. Denk aan eisen- en functiespecificaties, objectenbomen, GIS-data, 2D-tekeningen, 3D-modellen, IFC-modellen en objecttype-bibliotheken.  De uitwisseling van deze informatie gaat vaak moeizaam omdat partijen verschillende software gebruiken waardoor de informatie niet uitwisselbaar of leesbaar is. <br /> COINS maakt het mogelijk om data over objecten, opgeslagen in verschillende digitale formaten die voldoen aan verschillende standaarden, in onderlinge samenhang en systeemonafhankelijk uit te wisselen. Dankzij COINS kunnen opdrachtgevers en opdrachtnemers die software van verschillende leveranciers gebruiken gemakkelijker samenwerken.   +
In de ontwerp-, realisatie-, en onderhoudsfases van bouwprojecten wisselen opdrachtgevers en opdrachtnemers heel diverse informatie uit, die wel met elkaar verbonden is. Denk aan eisen- en functiespecificaties, objectenbomen, GIS-data, 2D-tekeningen, 3D-modellen, IFC-modellen en objecttype-bibliotheken.  De uitwisseling van deze informatie gaat vaak moeizaam omdat partijen verschillende software gebruiken waardoor de informatie niet uitwisselbaar of leesbaar is. <br /> COINS maakt het mogelijk om data over objecten, opgeslagen in verschillende digitale formaten die voldoen aan verschillende standaarden, in onderlinge samenhang en systeemonafhankelijk uit te wisselen. Dankzij COINS kunnen opdrachtgevers en opdrachtnemers die software van verschillende leveranciers gebruiken gemakkelijker samenwerken.   +
CORA procesmodel uitgebreid met werkprocessen  +
CSS maakt een op een realtief eenvoudige wijze een uniforme opmaak van websites mogelijk. CSS is een simpel mechanisme om opmaak (bijvoorbeeld lettertypes, kleuren, tussenruimtes) toe te voegen aan web pagina's. Met behulp van één stylesheet kunnen alle pagina's van een website uniform worden opgemaakt.  +, CSS maakt een op een realtief eenvoudige wijze een uniforme opmaak van websites mogelijk.  +
CSS maakt een op een realtief eenvoudige wijze een uniforme opmaak van websites mogelijk.  +
CSV-bestanden (Common Format and MIME Type for Comma-Separated Values Files) kunnen in een rekenblad- of een databaseprogramma worden ingelezen en vervolgens op een beeldscherm als tabel worden gepresenteerd. CSV bestanden bestaan uit regels met informatie waarbij naar ieder los gegeven een komma wordt geplaatst. Het wordt veelgebruikt om gegevens tussen verschillende spreadsheet programma's uit te wisselen en kan ook gebruikt worden op gegevens uit databases over te zetten naar een andere database.  +, CSV bestanden kunnen in een rekenblad- of een databaseprogramma worden ingelezen en vervolgens op een beeldscherm als tabel worden gepresenteerd.  +
CSV bestanden kunnen in een rekenblad- of een databaseprogramma worden ingelezen en vervolgens op een beeldscherm als tabel worden gepresenteerd.  +
Synoniem voor '[[Generieke functie]]'  +
==Definitie== Een bewijs, afgegeven door een overheidsinstantie of een erkende organisatie, die bevestigt dat huisvesting informatievoorzieningen (IV) van objecten voldoet aan vooraf vastgestelde eisen. ==Toelichting== Certificering vindt plaats door een certificatie-instelling. Zo bestaan er bijvoorbeeld verschillende [[ISO (International Organization for Standardization)|International Organization for Standardization (ISO)]]-certificaten die door geaccrediteerde certificatie-instellingen worden afgegeven. Klanten eisen steeds vaker dat het certificaat is behaald voordat zij zaken willen doen met de betreffende IV-dienstverlener. Om een ISO-certificaat te kunnen behalen, dient aantoonbaar aan een aantal eisen te zijn voldaan. Om aan een ISO-norm te kunnen voldoen, moeten bijvoorbeeld de werkprocessen in de organisatie inzichtelijk zijn gemaakt en dienen ze beheersbaar en bestuurbaar te zijn.  +
De mate waarin gegevensobjecten zijn geïdentificeerd als het juiste objecttype.  +
==Definitie== Het labelen van informatie om er een bepaalde waarde aan toe te kennen en daarmee te kunnen bepalen welk niveau van bescherming deze informatie nodig heeft. ==Toelichting== Binnen de [[NEN-EN-ISO/IEC 27002:2017 (Praktijkrichtlijn met beheersmaatregelen op het gebied van informatiebeveiliging)|ISO 27002 2017]] is gesteld dat een organisatie haar informatie moet classificeren om ervoor te zorgen dat informatie een passend beschermingsniveau krijgt. Hiervoor moet de organisatie een classificatieschema opstellen en dit schema communiceren binnen de organisatie. Een classificatieschema geeft beveiligingsrichtlijnen voor zowel algemene informatiemiddelen als voor informatie in het ontwikkeltraject. Binnen dit thema moet de projectverantwoordelijke dit classificatieschema als input beschikbaar hebben om binnen deze context van de applicatie omgeving te kunnen toepassen. Het classificatieschema beidt specifieke richtlijnen voor het ontwikkeltraject.  +
De catalogus met nalevingscriteria voor cloudcomputing (C5) definieert een basisbeveiligingsniveau voor cloudcomputing. Het wordt gebruikt door professionele cloudserviceproviders, auditors en cloudklanten. Het [[BSI (Bundesamt für Sicherheit in der Informationstechnik)|Bundesamt für Sicherheit in der Informationstechnik (BSI)]] introduceerde C5 voor het eerst in 2016. Sindsdien is de criteriacatalogus snel ontstaan en heeft deze nu een brede marktpenetratie: BSI kent meer dan een dozijn C5-attesten op nationale, Europese en wereldwijde cloudserviceproviders die een breed scala aan cloudservices dekken. Naast grote cloudserviceproviders passen inmiddels ook middelgrote en kleine providers de catalogus toe. De criteriacatalogus ondersteunt klanten bij het selecteren, controleren en monitoren van hun cloudserviceproviders. De bijbehorende rapportages leggen de basis voor een gedegen risicobeoordeling. In 2019 werd de catalogus grondig herwerkt, aangepast aan nieuwe ontwikkelingen en de kwaliteit verder verhoogd.  +
De CCM van [[CSA (Cloud Security Alliance)|Cloud Security Alliance (CSA)]] is samengesteld uit 197 control-doelstellingen die zijn gestructureerd in 17 domeinen die alle belangrijke aspecten van cloudtechnologie omvatten. Het kan worden gebruikt als een hulpmiddel voor de systematische beoordeling van een cloudimplementatie en geeft richtlijnen over welke beveiligingscontroles moeten worden geïmplementeerd door welke actor binnen de cloudtoeleveringsketen. Het controleraamwerk is afgestemd op de CSA-beveiligingsrichtlijnen voor cloudcomputing en wordt beschouwd als een de-facto standaard voor cloudbeveiliging en naleving. Op 21 januari heeft CSA versie 4 van de Cloud Controls Matrix (CCM) uitgebracht. Dit is een opvolging van CCM V3.0.1. De eerste set toewijzingen van CCM V3.0.1 met [[NEN-EN-ISO/IEC 27001:2017 (Managementsystemen voor informatiebeveiliging - Eisen)|ISO/IEC 27001]] werd uitgebracht in februari 2021. Andere toewijzingen worden later binnen het tijdsbestek van juni tot september vrijgegeven. CSA zal werken aan het creëren van aanvullende mapping naar relevante normen, best practices, wet- en regelgeving (bijvoorbeeld [[NIST SP 800-53 Rev. 5 2020 (Security and Privacy Controls for Information Systems and Organizations)|NIST 800-53 Rev. 5]], ENISA Security Controls for Cloud Services, CIS Controls, PCI-DSS, AICPA TSP).  +
Cloud computing is een model voor het mogelijk maken van alomtegenwoordige, handige, on-demand netwerktoegang tot een gedeelde pool van configureerbare computerbronnen (bijvoorbeeld netwerken, servers, opslag, applicaties en diensten) die snel kunnen worden geleverd en vrijgegeven met een minimale beheersinspanning of interactie met de serviceprovider.  +
==Definitie== Omvat het plan, wegen en middelen waarmee beveiligingsdoelstellingen die de organisatie met clouddiensten wil nastreven, kunnen worden gerealiseerd. ==Toelichting== Organisaties staan voor de vraag, welke clouddiensten ze moeten verwerven en waar en hoe ze deze veilig kunnen inzetten. Hiervoor moeten de IT-stakeholders van CSC’s een beslissingsraamwerk ontwikkelen, waarmee systematisch de mogelijke scenario’s kunnen worden onderzocht. Dit raamwerk richt zich met name op typen applicaties en technische karakteristieken. Een strategie omvat uitspraken over de doelstellingen bij de inzet van de clouddiensten die de organisatie wil nastreven en de wegen waarlangs of de wijze waarop dit moet plaatsvinden. Om CSC’s te kunnen bedienen, heeft de CSP vanuit haar eigen optiek een cloud-beveiligingsstrategie ontwikkeld. Deze strategie geeft de CSC’s voldoende mogelijkheden om hun cloud-strategie te relateren aan de strategie van een specifieke CSP. Dit biedt de CSC de mogelijkheid om haar keuzes bij te stellen dan wel aanvullende eisen aan de CSP te stellen.  +
==Objecten, controls en maatregelen== De onderwerpen die specifiek voor clouddiensten in dit domein een rol spelen, zijn in afbeelding 'Overzicht clouddienstenobjecten in het beleidsdomein' vermeld. Is een objectblok geel gekleurd, dan komt de bijbehorende control voor in de BIO. Betreft het een wit gemarkeerd objectblok, dan heeft de BIO geen control gedefinieerd, maar is dit object wel noodzakelijk voor dit thema. Per specifiek beveiligingsobject worden de control (hoofdnorm) en maatregelen (sub-normen) beschreven in de navolgende paragrafen. [[Afbeelding:BIO Thema Clouddiensten - Beveiligingsobjecten uitgewerkt voor het Beleidsdomein ingedeeld naar IFGS invalshoeken.png|thumb|none|500px|Overzicht clouddienstenobjecten in het beleidsdomein|alt=”Beveiligingsobjecten uitgewerkt voor het Beleidsdomein ingedeeld naar IFGS invalshoeken”]]  +
De onderwerpen die voor clouddiensten specifiek binnen het control-aspect een rol spelen, zijn in onderstaande afbeelding weergegeven. Is een objectblok blauw gekleurd, dan komt de bijbehorende control voor in de BIO. Betreft het een wit gemarkeerd objectblok, dan heeft de BIO geen control gedefinieerd, maar is dit object wel noodzakelijk voor dit thema. [[Bestand:BIO Thema Clouddiensten - Beveiligingsobjecten uitgewerkt voor het Uitvoeringsdomein ingedeeld naar IFGS invalshoeken.png|thumb|none|500px|Overzicht clouddienstenobjecten in het control-domein|alt=”Beveiligingsobjecten uitgewerkt voor het Control domein ingedeeld naar IFGS invalshoeken”]]  +
==Objecten, controls en maatregelen== Is een objectblok oranje gekleurd, dan komt de bijbehorende control voor in de BIO. Betreft het een wit gemarkeerd objectblok, dan heeft de BIO geen control gedefinieerd, maar is dit object wel noodzakelijk voor dit thema. De onderstaande afbeelding geeft de onderwerpen weer die specifiek voor het uitvoeringsaspect een rol spelen. [[Bestand:CLD Overzicht objecten voor clouddiensten in het uitvoeringsdomein.png|thumb|none|500px|Overzicht clouddienstenobjecten in het uitvoeringsdomein |alt=”Beveiligingsobjecten uitgewerkt voor het Uitvoeringsdomein ingedeeld naar IFGS invalshoeken”]]  +
==Definitie== Omvat een specificatie, waarin de leverancier de clouddiensten en alle cruciale elementen hiervoor in samenhang beschrijft. ==Toelichting== In de clouddienstenarchitectuur legt de CSP de functionele relaties vast tussen IT-componenten in de gehele keten van de CSC en de CSP. Deze architectuur beschrijft hoe de IT-componenten moeten worden ingericht zodat ze de bedrijfsprocessen van de CSC ondersteunen.  +
==Definitie== Omvat een specificatie van de technische en organisatorische samenhang, waarin de CSP de relaties tussen de onderdelen van de clouddiensten en de ondersteuning van de CSC vastlegt. ==Toelichting== In de clouddienstenarchitectuur legt de CSP vast hoe de IT-functionaliteiten aan elkaar gerelateerd zijn en hoe zij onderling samenhangen. Uit de clouddienstenarchitectuur wordt duidelijk hoe IT-functionaliteiten de bedrijfsprocessen van de CSC ondersteunen.  +
==Definitie== Omvat beleidsuitgangspunten en de wijze waarop, in welk tijdbestek en met welke middelen, de beveiligingsdoelstellingen voor clouddiensten bereikt moeten worden. ==Toelichting== Het onderwerp clouddiensten moet een specifiek onderdeel zijn van het informatiebeveiligingsbeleid van de CSC. Een CSC kan ook kiezen voor een specifiek clouddienstenbeleid, waarbij in de informatiebeveiligingsparagraaf, het algemene informatiebeveiligingsbeleid specifiek voor clouddiensten wordt uitgewerkt of ingevuld. Het beleid zal uitgangspunten moeten bevatten over de wijze waarop, binnen welk tijdsbestek en met welke middelen clouddiensten de doelstellingen moeten bereiken. In dit beleid zal ook aandacht moeten worden besteed aan archiveringsbeleid, cryptografiebeleid, certificering en verklaringen. Om de CSC te kunnen bedienen, zal de CSP vanuit haar eigen optiek een cloud-beveiligingsbeleid hebben ontwikkeld. Dit beleid geeft de CSC mogelijkheden om haar cloud-beleid te relateren aan de strategie van de CSP en biedt de CSC de mogelijkheid om de keuzes bij te stellen dan wel aanvullende eisen aan de CSP te stellen.  +
==Toelichting== Om getransporteerde gegevens te beschermen, moeten deze worden beveiligd met een voldoende sterke beveiligingsmethode. ==Schaalgrootte== Elke schaalgrootte. ==Voor wie== Leverancier.  +
==Objecten, controls en maatregelen== Onderstaande afbeelding is het resultaat van de [[SIVA-methodiek|SIVA-analyse]] op relevante objecten voor het informatievoorzieningsbeleid. SIVA staat voor Structuur, Inhoud, Vorm en Analysevolgorde. Het wit ingekleurde object ontbreekt als control in de [[BIO (Baseline Informatiebeveiliging Overheid)|Baseline Informatiebeveiliging Overheid (BIO)]] maar is wel cruciaal voor dit thema. Deze afbeelding geeft een overzicht en de ordening van objecten. Voor de identificatie van de objecten en de ordening is gebruik gemaakt van basiselementen (zie de grijs gemarkeerde tekst) ingedeeld naar de [[Alle invalshoeken|invalshoek: Intentie, Functie, Gedrag of Structuur]]. [[Bestand:CVZ Overzicht objecten voor communicatievoorzieningen in het beleidsdomein.png|thumb|none|500px|Overzicht communicatievoorzieningenobjecten in het beleidsdomein|alt=”Overzicht communicatievoorzieningenobjecten in het beleidsdomein”]]  +
==Objecten, controls en maatregelen== Onderstaande afbeelding is het resultaat van de [[SIVA-methodiek|Structuur, Inhoud, Vorm en Analysevolgorde (SIVA)-analyse]] op relevante objecten voor netwerk-control. Beheersing van netwerk(diensten) beoogt de beveiligingsrisico’s te beperken. Hiertoe dienen periodiek door bepaalde functionarissen met specifieke bevoegdheden controleactiviteiten te worden verricht. Deze activiteiten dienen ondersteund te worden met procedures en richtlijnen (instructies). De structuur van de beheersingsorganisatie beschrijft de samenhang van de ingerichte processen. [[Afbeelding:Thema Communicatievoorzieningen - Onderwerpen die binnen het Controldomein een rol spelen.png|thumb|none|500px|Onderwerpen die binnen het Control domein een rol spelen|alt=”Onderwerpen die binnen het Control domein een rol spelen”]]  +
==Objecten, controls en maatregelen== Per object zijn de maatregelen uitgewerkt die risico’s kunnen reduceren (zie [[ISOR:BIO Thema Communicatievoorzieningen Uitvoering#Normen uit de BIO Thema Communicatievoorzieningen binnen dit aspect|Hoofdstuk Normen uit de BIO Thema Communicatievoorzieningen binnen dit aspect]]). Voor de implementatie wordt verwezen naar de zes uitvoeringskaders van de ISO 27033 en het [[Beveiliging|Nederlandse Overheid Referentie Architectuur (NORA)-thema Beveiliging]]. In de onderstaande afbeelding zijn de essentiële objecten voor communicatievoorzieningen weergegeven in de kolommen: [[Alle invalshoeken|Intentie, Functie, Gedrag en Structuur]]. Voor de wit ingekleurde objecten heeft de [[BIO (Baseline Informatiebeveiliging Overheid)|Baseline Informatiebeveiliging Overheid (BIO)]] geen control gedefinieerd. Deze objecten zijn voor een groot deel afkomstig uit de ISO 27033 deel 1 t/m 6. [[Afbeelding:Thema Communicatievoorzieningen - Onderwerpen die binnen het Uitvoeringdomein een rol spelen.png|thumb|none|500px|Onderwerpen die binnen het Uitvoering domein een rol spelen|alt=”Onderwerpen die binnen het Uitvoering domein een rol spelen”]]  +
Start Software voor data op het web community  +