ISOR Beleid

Uit NORA Online
Ga naar: navigatie, zoeken


NB: Deze pagina maakt deel uit van de Historie van de NORANederlandse Overheid Referentie Architectuur en kan verouderde informatie bevatten!
De Privacy Baseline is op het moment in review: feedback gevraagd. Geef je feedback via nora@ictu.nl.

Binnen de ISOR (Information Security Object Repository) onderkennen we drie beveiligingscontexten of 'ISOR-domeinen:' Beleid, Uitvoering en Control. Alle objecten binnen de Repository zijn hierin ingedeeld.

Doelgroep objecten Beleid

...voor welke doelgroep zijn beveiligingseisen en subnormen in de view beleid precies relevant??...

Overzicht van alle beveiligingseisen in de view Beleid

ID BeschrijvingToelichting
AppO_BApplicatieontwikkeling BeleidBinnen het Beleiddomein zijn specifieke inrichting- en beveiligingsobjecten ten aanzien van Applicatieontwikkeling beschreven en per object zijn conformiteitsindicatoren uitgewerkt. Deze conformiteitindicatoren representeren een vast te stellen set van implementatie-elementen (maatregelen).

Onderstaande tabel en afbeelding tonen het resultaat van de SIVA analyse ten aanzien van relevante objecten voor Applicatieontwikkeling. De wit ingekleurde objecten ontbreken als control in de ISO2700x, maar zijn van belang voor dit thema. Om deze reden zijn aanvullende objecten uit andere baselines opgenomen.

”Onderwerpen die binnen het Beleid domein een rol spelen”
Onderwerpen die binnen het Beleid domein een rol spelen














AppO_B.01Beleid voor (beveiligd) ontwikkelenDe ISO baseline (ISO pg. 74) formuleert ‘Beveiligd ontwikkelen’ als een eis voor het opbouwen van een beveiligde dienstverlening, architectuurEen beschrijving van een complex geheel, en van de principes die van toepassing zijn op de ontwikkeling van het geheel en zijn onderdelen., software en een beveiligd systeem. In dit thema worden bij het object ‘beleid voor (beveiligd) ontwikkelen’ aan applicatieontwikkeling beleid gerelateerde specifieke aspecten benadrukt. In zo’n beleid worden onder andere methoden en technieken voor requirementanalyse en richtlijnen met betrekking tot beveiliging in de levenscyclus van softwareontwikkeling besproken.
AppO_B.01.01De gangbare principes rondom Security by Design als uitgangspunt voor softwareontwikkeling
AppO_B.01.02Grip op Secure Software Development' als uitgangspunt voor softwareontwikkeling
AppO_B.01.03Overwegingen bij het beleid voor beveiligd ontwikkelen van software
AppO_B.01.04Technieken voor beveiligd programmeren
AppO_B.02Systeem ontwikkelmethodeOntwikkel- en onderhoudsactiviteiten moeten worden uitgevoerd op basis van een systeem ontwikkelmethode, hierdoor wordt rekening gehouden met:
  • de vereisten uit wet en regelgeving;
  • de contractuele vereisten;
  • de beveiligingsvereisten;
  • een projectmatige aanpak.
AppO_B.02.01Software wordt ontwikkeld conform een formeel vastgestelde ontwikkelmethodologie
AppO_B.02.02Softwareontwikkelaars zijn getraind om de ontwikkelmethodologie toe te passen
AppO_B.02.03Adoptie van ontwikkelmethodologie wordt gemonitord
AppO_B.02.04Software wordt ontwikkelen conform standaarden en procedures
AppO_B.02.05De systeemontwikkelmethode ondersteunt dat de te ontwikkelen applicaties voldoen aan de vereisten
AppO_B.02.06Het softwareontwikkeling wordt projectmatig aangepakt
AppO_B.03Classificatie van InformatieBinnen ISO 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 de context van de applicatie omgeving te kunnen toepassen. Het classificatieschema beidt specifieke richtlijnen voor het ontwikkeltraject.
AppO_B.03.01Dataclassificatie' als uitgangspunt voor softwareontwikkeling
AppO_B.03.02Informatie in alle informatiesystemen is conform expliciete risicoafweging geclassificeerd
AppO_B.03.03Bij applicatieontwikkeling is informatie beschermd conform de vereisten uit het classificatieschema
AppO_B.03.04Verplichtingen uit wet en regelgeving en organisatorische en technische requirements
AppO_B.04Engineeringprincipes beveiligde systemenBij het ontwikkelen van applicaties worden engineeringprincipes in acht genomen. In ISO zijn twee principes expliciet genoemd: Security by design en defense in depth, hiernaast bestaan nog verschillende andere van belang zijnde principes (engineeringprincipes) die in andere baselines zijn opgenomen.
AppO_B.04.01Security by Design als uitgangspunt voor softwareontwikkeling
AppO_B.04.02Principes voor het beveiligen van informatiesystemen
AppO_B.04.03Beveiliging is integraal onderdeel van systeemontwikkeling
AppO_B.04.04Ontwikkelaars zijn getraind om veilige software te ontwikkelen
AppO_B.05Business Impact AnalyseEen van de specifieke activiteiten die bij applicatieontwikkeling moet worden uitgevoerd is de Business Impact Analyse (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 te traceren.
AppO_B.05.01Perspectieven bij de Business Impact Analyse
AppO_B.05.02Scenario's voor de Business Impact Analyse
AppO_B.05.03Vaststelling op welke wijze een eventueel compromitteren invloed heeft op de financiën van de organisatie
AppO_B.06Privacy en bescherming van persoonsgegevens (GEB/DPIA analyse)Bij het ontwikkelen van applicaties behoort de verantwoordelijke stakeholder rekening houden met privacy en de bescherming van persoonsgegevens in het kader van AVG. Privacybescherming betekent dat we een context analyse verrichten van de situatie waarin de desbetreffende applicatie ontwikkeld wordt. Hierbij wordt voorkomen dat eventuele inbreuk ontstaat op de persoonlijke levenssfeer van de personen waarvan persoonsgegevens worden verwerkt. Om inbreuk op de privacy vast te stellen wordt, voorafgaand aan het ontwerp van de applicatie, een Gegevensbescherming EffectBeoordeling (GEB), ook wel Data Protection Impact Assessment (DPIA) of Privacy ImpactAnalyse (PIA) genoemd, uitgevoerd. Deze verplichting komt voort uit de AVG en welke geldt vanaf 25 mei 2018.
AppO_B.06.01GEB om vooraf in het ontwerp de privacy en gegevensbeschermingsmaatregelen mee te nemen
AppO_B.06.02procesbeschrijving voor het uitvoeren van GEB's en voor het opvolgen van de uitkomsten
AppO_B.06.03Een tot standaard verheven GEB-toetsmodel wordt toegepast; dit model voldoet aan de in de AVG gestelde eisen
AppO_B.06.04Privacy by Design en GEB als onderdeel van een tot standaard verheven risicomanagement aanpak
AppO_B.06.05Risicomanagement aanpak aantoonbaar toegepast
AppO_B.06.06Op basis van de AVG worden de principes Privacy by Design en Privacy by Default gehanteerd
AppO_B.07Kwaliteitsmanagement systeem (KMS)De doelorganisatie heeft de ontwikkelactiviteiten procesmatig ingericht en voert ook de noodzakelijke kwaliteitscontroles uit.
AppO_B.07.01De doelorganisatie beschikt over een ontwikkel en onderhoudsbeleid
AppO_B.07.02De doelorganisatie beschikt over QA- en KMS-methodiek
AppO_B.07.03De ontwikkel en onderhoudsactiviteiten worden in samenhang georganiseerd en geïmplementeerd
AppO_B.07.04Voor informatie- en communicatie zijn processen ingericht
AppO_B.07.05Op de ontwikkel- en onderhoudsactiviteiten worden kwaliteitsmetingen en inspecties uitgevoerd
AppO_B.07.06Aan het management worden evaluatierapportages verstrekt
AppO_B.07.07applicatieontwikkeling- en onderhoudprocessen zijn beschreven en maken onderdeel uit van het KMS
AppO_B.08Toegangsbeveiliging op programmacodeToegang tot programmacode en samenhangende elementen (zoals ontwerpen, specificaties, verificatie- en validatieschema’s) is juist ingericht om onbevoegde functionaliteit en om onbedoelde wijzigingen te voorkomen, alsmede om intellectueel eigendom te beschermen.
AppO_B.08.01Om de toegang tot broncode bibliotheken te beheersen worden richtlijnen in overweging genomen
AppO_B.08.02Aanvullende beheersmaatregelen wanneer programmabroncode wordt gepubliceerd
AppO_B.09ProjectorganisatieBinnen de (project-)organisatie is een beveiligingsfunctionaris betrokken die verantwoordelijkheid draagt bij het ondersteunen van applicatieontwikkelingen (projecten). Binnen het project heeft hij de specifieke taak gericht op het vervaardigen van beveiligingsvoorschriften. De expliciete taken, verantwoordelijkheden en bevoegdheden van de beveiligingsfunctionaris zijn vooraf expliciet benoemd en vastgesteld. De beveiligingsfunctionaris ziet toe op het naleven van het informatiebeveiligingsbeleidHet informatiebeveiligingsbeleid verbindt de bedrijfsdoelstellingen met beveiligingsdoelstellingen. Met de beveiligingsdoelstellingen geeft een organisatie aan op welke wijze – door het treffen van beveiligingsmaatregelen – de bedrijfsdoelstellingen nagestreefd worden. en de architectuurvoorschriften. Ook staat vast hoe de rapporteringslijnen lopen.
AppO_B.09.01Taken van de beveiligingsfunctionaris
AppO_B.09.02Inzicht gegeven door de beveiligingsfunctionaris
Cloud_BClouddiensten BeleidDe onderwerpen die specifiek voor clouddiensten een rol spelen, zijn in afbeelding 'Overzicht beveiligingsprincipes in BUC- en IFGS-matrix' vermeld. Per specifiek beveiligingsprincipe worden de ‘control’ (hoofdnorm) en maatregelen (sub-normen) beschreven. De onderstaande afbeelding geeft de onderwerpen weer die specifiek voor het beleidsaspect een rol spelen.
”Beveiligingsobjecten uitgewerkt voor het Beleidsdomein ingedeeld naar IFGS invalshoeken”
Beveiligingsobjecten uitgewerkt voor het Beleidsdomein ingedeeld naar IFGS invalshoeken
Cloud_B.01Wet- en regelgevingNationale en internationale wet- en regelgeving die van toepassing zijn op clouddiensten, zoals in het bijzonder de AVG, heeft betrekking op de te nemen organisatorische en technische maatregelen, zoals bewustwording, mensen en fysieke middelen. De CSP zal deze vertalen naar specifieke eisen ten aanzien van cloudcomponenten.
Cloud_B.01.01Informeren welke wet- en regelgeving van toepassing is op clouddiensten
Cloud_B.01.02Selecteren relevante wettelijke eisen ter bescherming van persoonsgegevens
Cloud_B.01.03Identificeren vereisten die van toepassing zijn
Cloud_B.01.04Voorzien zekerheid over van toepassing zijnde wettelijke eisen en contractuele vereisten
Cloud_B.01.05Treffen van maatregelen en benoemen verantwoordelijkheden om te voldoen aan gestelde eisen
Cloud_B.01.06Vaststellen alle van toepassing zijnde wet- en regelgeving
Cloud_B.02CloudbeveiligingsstrategieOrganisaties 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 omtrent 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, zal de CSP vanuit haar eigen optiek een cloudbeveiligingsstrategie hebben ontwikkeld. Deze strategie geeft de CSC’s voldoende mogelijkheden om hun cloudstrategie 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.
Cloud_B.02.01Aangeven hoe cloudbeveiligingsstrategie bedrijfsdoelstellingen ondersteunt
Cloud_B.02.02Aangeven hoe te beschermen tegen bedreigingen en aandacht te besteden aan beveiligingscontext
Cloud_B.02.03Ondersteunen in behalen van bedrijfsdoelen door samenhang van beveiligingsmaatregelen
Cloud_B.03Exit-strategieOmdat geen enkel contract 'voor eeuwig' is, moet een CSC op een zeker moment afscheid kunnen nemen van de CSP. Als bij het afsluiten van de clouddienst geen bindende afspraken zijn gemaakt over het afscheid nemen, dan kan het heel lastig of kostbaar worden om data te migreren naar een andere CSP. De organisatie zal rekening moeten houden met een ‘Vendor lock-in’. Het is daarom van belang, nog voor het aangaan van een overeenkomst met een CSP, een exit-strategie te ontwikkelen. De exit-strategie dient de voorwaarden voor mutaties van data te bevatten. Het is ook mogelijk de praktische uitwerking van de exit-strategie op te nemen in een service level agreement. Om verschillende redenen kan een CSC de dienstverlening van de CSP willen beëindigen. Enerzijds planmatig, zoals bij het einde van de contracttermijn, anderszins omwille van moverende redenen, zoals niet voldoen aan de afspraken, overname van de CSP door een andere organisatie. Het niet planmatig beëindigen is gerelateerd aan de exit-strategie, dat onderdeel is van Bedrijfscontinuïteitsmanagement (BCM). Het planmatig beëindigen van de dienstverlening raakt de transitie en is onderdeel van Service Level Management (SLM).
Cloud_B.03.01Vastleggen bepalingen over exit-regeling
Cloud_B.03.02Overgaan tot exit buiten verstrijken contractperiode
Cloud_B.04ClouddienstenbeleidHet onderwerp cloud(diensten) zal een specifiek onderdeel moeten zijn van het informatiebeveiligingsbeleidHet informatiebeveiligingsbeleid verbindt de bedrijfsdoelstellingen met beveiligingsdoelstellingen. Met de beveiligingsdoelstellingen geeft een organisatie aan op welke wijze – door het treffen van beveiligingsmaatregelen – de bedrijfsdoelstellingen nagestreefd worden. van de CSC. Een CSC kan ook kiezen voor een specifiek clouddienstenbeleid, waarbij in de informatiebeveiligingsparagraaf, het algemene informatiebeveiligingsbeleidHet informatiebeveiligingsbeleid verbindt de bedrijfsdoelstellingen met beveiligingsdoelstellingen. Met de beveiligingsdoelstellingen geeft een organisatie aan op welke wijze – door het treffen van beveiligingsmaatregelen – de bedrijfsdoelstellingen nagestreefd worden. specifiek voor clouddiensten wordt uitgewerkt of ingevuld. Het beleid zal uitgangspunten moeten bevatten over de wijze waarop, binnen welk tijdbestek 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 cloudbeveiligingsbeleid hebben ontwikkeld. Dit beleid geeft de CSC mogelijkheden om haar cloudbeleid te relateren aan de strategie van CSP en biedt de CSC de mogelijkheid om de keuzes bij te stellen dan wel aanvullende eisen aan de CSP te stellen.
Cloud_B.04.01Bevatten organisatorisch en technische georiënteerde maatregelen in cloudbeveiligingsbeleid
Cloud_B.05TransparantieTransparantie is in de relatie van CSC en CSP een belangrijk item, dat wordt ondersteund door de clouddiensten-architectuurEen beschrijving van een complex geheel, en van de principes die van toepassing zijn op de ontwikkeling van het geheel en zijn onderdelen.. Hierin beschrijft de CSP de relaties tussen de componenten van de clouddiensten (hoe deze aan elkaar gekoppeld zijn). Het verschaft inzicht en overzicht over de ICT-componenten en hun onderlinge samenhang. Uit de clouddiensten-architectuurEen beschrijving van een complex geheel, en van de principes die van toepassing zijn op de ontwikkeling van het geheel en zijn onderdelen. blijkt hoe de componenten de bedrijfsprocessen van de CSC ondersteunen.
Cloud_B.05.01Bevatten diverse aspecten in systeembeschrijving
Cloud_B.05.02SLA/systeembeschrijving bevat specificatie van jurisdictie inzake data-opslag, verwerking en back-up-locatie
Cloud_B.05.03SLA/systeembeschrijving bevat specificatie voor publicatie-vereisten en onderzoeksmogelijkheden
Cloud_B.05.04SLA/systeembeschrijving bevat specificatie met betrekking tot beschikbaar zijn van valide certificaten
… overige resultaten