Beste lezer, de NORA-wiki wordt vernieuwd.
Op maandag 31 maart gaan we live!
Vanaf vrijdag 28 maart tot en met maandag 31 maart kun je als gebruiker geen wijzigingen aanbrengen in de wiki en kun je hinder ondervinden van de migratie naar de nieuwe wiki.
Vanaf dinsdag 1 april zal de wiki weer volledig beschikbaar zijn.
Alvast dank voor je begrip.
Lees voor meer informatie het volgende nieuwsbericht: Nieuwe NORA-wiki live op 31 maart – met meer dan een nieuw jasje
IFGS Intentie
Op deze pagina staan alle Privacyprincipes en Beveiligingsprincipes in de invalshoek. Alle ISOR-objecten binnen deze context zijn ook te herkennen aan het symbool
Alle objecten binnen deze invalshoek[bewerken]
| ID | Titel | link |
|---|---|---|
| APO_B.01 | Beleid voor (beveiligd) ontwikkelen | Beleid voor (beveiligd) ontwikkelen |
| APO_B.01.01 | De gangbare principes rondom Security by Design als uitgangspunt voor softwareontwikkeling | De gangbare principes rondom Security by Design als uitgangspunt voor softwareontwikkeling |
| APO_B.01.02 | Grip op Secure Software Development' als uitgangspunt voor softwareontwikkeling | Grip op Secure Software Development' als uitgangspunt voor softwareontwikkeling |
| APO_B.01.03 | Overwegingen bij het beleid voor beveiligd ontwikkelen van software | Overwegingen bij het beleid voor beveiligd ontwikkelen van software |
| APO_B.01.04 | Technieken voor beveiligd programmeren | Technieken voor beveiligd programmeren |
| APO_B.02 | Systeem-ontwikkelmethode | Systeem-ontwikkelmethode |
| APO_B.02.01 | Software wordt ontwikkeld conform een formeel vastgestelde ontwikkelmethodologie | Software wordt ontwikkeld conform een formeel vastgestelde ontwikkelmethodologie |
| APO_B.02.02 | Softwareontwikkelaars zijn getraind om de ontwikkelmethodologie toe te passen | Softwareontwikkelaars zijn getraind om de ontwikkelmethodologie toe te passen |
| APO_B.02.03 | Adoptie van ontwikkelmethodologie wordt gemonitord | Adoptie van ontwikkelmethodologie wordt gemonitord |
| APO_B.02.04 | Software wordt ontwikkelen conform standaarden en procedures | Software wordt ontwikkelen conform standaarden en procedures |
| APO_B.02.05 | De systeemontwikkelmethode ondersteunt dat de te ontwikkelen applicaties voldoen aan de vereisten | De systeemontwikkelmethode ondersteunt dat de te ontwikkelen applicaties voldoen aan de vereisten |
| APO_B.02.06 | Het softwareontwikkeling wordt projectmatig aangepakt | Het softwareontwikkeling wordt projectmatig aangepakt |
| APO_B.03 | Classificatie van informatie | Classificatie van informatie |
| APO_B.03.01 | Dataclassificatie als uitgangspunt voor softwareontwikkeling | Dataclassificatie als uitgangspunt voor softwareontwikkeling |
| APO_B.03.02 | Informatie in alle informatiesystemen is conform expliciete risicoafweging geclassificeerd | Informatie in alle informatiesystemen is conform expliciete risicoafweging geclassificeerd |
| APO_B.03.03 | Bij applicatieontwikkeling is informatie beschermd conform de vereisten uit het classificatieschema | Bij applicatieontwikkeling is informatie beschermd conform de vereisten uit het classificatieschema |
| APO_B.03.04 | Verplichtingen uit wet en regelgeving en organisatorische en technische requirements | Verplichtingen uit wet en regelgeving en organisatorische en technische requirements |
| APO_B.04 | Engineeringsprincipe voor beveiligde systemen | Engineeringsprincipe voor beveiligde systemen |
| APO_B.04.01 | Security by Design als uitgangspunt voor softwareontwikkeling | Security by Design als uitgangspunt voor softwareontwikkeling |
| APO_B.04.02 | Principes voor het beveiligen van informatiesystemen | Principes voor het beveiligen van informatiesystemen |
| APO_B.04.03 | Beveiliging is integraal onderdeel van systeemontwikkeling | Beveiliging is integraal onderdeel van systeemontwikkeling |
| APO_B.04.04 | Ontwikkelaars zijn getraind om veilige software te ontwikkelen | Ontwikkelaars zijn getraind om veilige software te ontwikkelen |
| APO_B.05 | Business Impact Analyse (BIA) | Business Impact Analyse (BIA) |
| APO_B.05.01 | Perspectieven bij de Business Impact Analyse | Perspectieven bij de Business Impact Analyse |
| APO_B.05.02 | Scenario's voor de Business Impact Analyse | Scenario's voor de Business Impact Analyse |
| APO_B.05.03 | Vaststelling op welke wijze een eventueel compromitteren invloed heeft op de financiën van de organisatie | Vaststelling op welke wijze een eventueel compromitteren invloed heeft op de financiën van de organisatie |
| APO_B.06 | Privacy en bescherming persoonsgegevens applicatieontwikkeling | Privacy en bescherming persoonsgegevens applicatieontwikkeling |
| APO_B.06.01 | GEB om vooraf in het ontwerp de privacy en gegevensbeschermingsmaatregelen mee te nemen | GEB om vooraf in het ontwerp de privacy en gegevensbeschermingsmaatregelen mee te nemen |
| APO_B.06.02 | Procesbeschrijving voor uitvoeren GEB's en voor opvolgen uitkomsten | Procesbeschrijving voor uitvoeren GEB's en voor opvolgen uitkomsten |
| APO_B.06.03 | Een tot standaard verheven GEB-toetsmodel wordt toegepast; dit model voldoet aan de in de AVG gestelde eisen | Een tot standaard verheven GEB-toetsmodel wordt toegepast; dit model voldoet aan de in de AVG gestelde eisen |
| APO_B.06.04 | Privacy by Design en GEB als onderdeel van een tot standaard verheven risicomanagement aanpak | Privacy by Design en GEB als onderdeel van een tot standaard verheven risicomanagement aanpak |
| APO_B.06.05 | Risicomanagement aanpak aantoonbaar toegepast | Risicomanagement aanpak aantoonbaar toegepast |
| APO_B.06.06 | Op basis van de AVG worden de principes Privacy by Design en Privacy by Default gehanteerd | Op basis van de AVG worden de principes Privacy by Design en Privacy by Default gehanteerd |
| APO_C.01 | Richtlijn evaluatie-ontwikkelactiviteiten | Richtlijn evaluatie-ontwikkelactiviteiten |
| APO_C.01.01 | Controle richtlijnen voor de evaluatie van de producten die uit de ontwikkelfasen voorvloeien | Controle richtlijnen voor de evaluatie van de producten die uit de ontwikkelfasen voorvloeien |
| APO_C.01.02 | Evaluatierichtlijnen voor het evalueren van intern ontwikkelde en extern verworven code | Evaluatierichtlijnen voor het evalueren van intern ontwikkelde en extern verworven code |
| APO_C.01.03 | Controle richtlijnen die binnen de relevante beheerprocessen worden toegepast | Controle richtlijnen die binnen de relevante beheerprocessen worden toegepast |
| APO_C.01.04 | Het kwaliteitshandboek bevat procedures voor Quality Control en Quality Assurance methodiek en reviewrichtlijnen | Het kwaliteitshandboek bevat procedures voor Quality Control en Quality Assurance methodiek en reviewrichtlijnen |
| APO_C.01.05 | De Quality Assurance methodiek wordt conform de richtlijnen nageleefd | De Quality Assurance methodiek wordt conform de richtlijnen nageleefd |
| APO_C.01.06 | Controleactiviteiten en rapportages over de ontwikkelactiviteiten en bijbehorende beheerprocessen | Controleactiviteiten en rapportages over de ontwikkelactiviteiten en bijbehorende beheerprocessen |
| APO_C.01.07 | Het applicatieontwikkelproces, de testcyclus en programmacodekwaliteit worden periodiek beoordeeld | Het applicatieontwikkelproces, de testcyclus en programmacodekwaliteit worden periodiek beoordeeld |
| APO_U.01 | Wijzigingsbeheerprocedure voor applicaties en systemen | Wijzigingsbeheerprocedure voor applicaties en systemen |
| APO_U.01.01 | Voor het wijzigingsbeheer gelden de algemeen geaccepteerde beheer frameworks | Voor het wijzigingsbeheer gelden de algemeen geaccepteerde beheer frameworks |
| APO_U.01.02 | Medewerkers (programmeurs) krijgen de juiste autorisatie om werkzaamheden te kunnen uitvoeren | Medewerkers (programmeurs) krijgen de juiste autorisatie om werkzaamheden te kunnen uitvoeren |
| APO_U.01.03 | Nieuwe systemen en belangrijke wijzigingen aan bestaande systemen volgen een formeel wijzigingsproces | Nieuwe systemen en belangrijke wijzigingen aan bestaande systemen volgen een formeel wijzigingsproces |
| APO_U.01.04 | Elementen van de procedures voor wijzigingsbeheer | Elementen van de procedures voor wijzigingsbeheer |
| APO_U.02 | Beperking software-installatie applicatieontwikkeling | Beperking software-installatie applicatieontwikkeling |
| APO_U.02.01 | Beleid ten aanzien van het type software dat mag worden geïnstalleerd | Beleid ten aanzien van het type software dat mag worden geïnstalleerd |
| APO_U.02.02 | Het toekennen van rechten om software te installeren vindt plaats op basis van 'Least Privilege' | Het toekennen van rechten om software te installeren vindt plaats op basis van 'Least Privilege' |
| APO_U.02.03 | De rechten verleend op basis van de rollen van het typen gebruikers en ontwikkelaars | De rechten verleend op basis van de rollen van het typen gebruikers en ontwikkelaars |
| ... meer resultaten | ||
Uitleg indeling[bewerken]
De ISOR (Information Security Object Repository) bevat normenkaders waarin beveiligingsprincipes of privacyprincipes en onderliggende normen zijn beschreven. Deze zijn conform de SIVA-methodiek ingedeeld naar Beleid, Uitvoering of Control en geordend naar één van de volgende invalshoeken: Intentie, Functie, Gedrag of Structuur. Vanuit elke invalshoek wordt een specifieke verzameling objecten geïdentificeerd.
Relaties tussen invalshoeken[bewerken]
Deze invalshoeken hebben onderling de volgende relatie:
- 'Intentie' wordt geëffectueerd door 'Functie'.
- 'Functie' effectueert 'Intentie' en wordt geëffectueerd door 'Gedrag'.
- 'Gedrag' effectueert 'Functie' en wordt geëffectueerd door 'Structuur'.
- 'Structuur' effectueert 'Gedrag'.
Uitleg invalshoeken[bewerken]
De component inhoud is de tweede doorsnede van het onderzoeksgebied. Deze doorsnede wordt bereikt door middel van vier invalshoeken: intentie, functie, gedrag en structuur.
Intentie[bewerken]
Het waarom-aspect, ofwel de bestaansreden van een organisatie. Voorbeelden hiervan zijn: organisatie, visie, doelstellingen, wetten en beleid, stakeholders en middelen.
Functie[bewerken]
Het wat-aspect, ofwel de organisatorische en technologische elementen die de intenties van de organisatie moeten realiseren. Voorbeelden hiervan zijn: organisatorische en technische functies, processen, taken en taakvereisten.
Gedrag[bewerken]
Het hoe-aspect (gedragsaspect), ofwel de menselijke en technische resources en eigenschappen van de technische resources die de organisatorische en technische functies moeten vormgeven. Voorbeelden hiervan zijn: actor, object, interactie, toestand, eigenschap en historie.
Structuur[bewerken]
Het hoe-aspect (vormaspect), ofwel de manier waarop een organisatorische en personele structuur is vormgegeven. Voorbeelden hiervan zijn: business-organisatiestructuur, business- architectuur, IT-architectuur en business-IT-alignment.
De relaties tussen de objecten vanuit de invalshoeken kunnen als volgt worden gelezen: de elementen uit de doel-invalshoek reguleren en/of worden bereikt door elementen uit de functie-invalshoek. De elementen uit de functie-invalshoek gebruiken of realiseren de elementen uit de gedrag-invalshoek die op hun beurt worden vormgegeven door elementen uit de structuur-invalshoek.
Invalshoeken niet gebruikt bij De Privacy Baseline[bewerken]
De verdeling naar Intentie, Functie, Gedrag en Structuur betreft de kern van het SIVA-methodiek en heeft tot doel lacunes te ontdekken in de objectanalyse die leidt tot normen. Deze indeling is voor de opzet van de Privacy Baseline niet gebruikt: het object is immers niet Privacy, maar de Privacywet. Het is niet de opzet geweest om de wet te toetsen op volledigheid en consistentie. De opzet van de Baseline is de gebruiker een handzame en geannoteerde lijst van toetsbare criteria mee te geven die aan de wet zijn ontleend. Omdat de invalshoeken bij het opstellen van de normen voor de Privacy Baseline geen rol hebben gespeeld, is bij de invalshoek "Onbekend" ingevuld.