Beveiligingsaspect Uitvoering: verschil tussen versies
(met overzichten binnen normenkaders, koppen aangepast, uitleg omhoog) |
k (kleine tekstuele aanpassing, enter verwijderd) |
||
(2 tussenliggende versies door dezelfde gebruiker niet weergegeven) | |||
Regel 1: | Regel 1: | ||
Deze pagina geeft alle ISOR-objecten ([[Privacyprincipes]], [[Beveiligingsprincipes]] en [[Normen]]) binnen het {{PAGENAME}} weer. | Deze pagina geeft alle ISOR-objecten ([[Privacyprincipes]], [[Beveiligingsprincipes]] en [[Normen]]) binnen het {{PAGENAME}} weer. Alle objecten binnen dit aspect zijn ook te herkennen aan het onderstaande symbool.<br>[[Afbeelding:{{PAGENAME}}.png|50px|none|alt=Paars vierkant kader met daarin in wit de eerste letter van {{PAGENAME}}]] | ||
Alle objecten binnen dit aspect zijn ook te herkennen aan het symbool <br>[[Afbeelding:{{PAGENAME}}.png|50px|none|alt=Paars vierkant kader met daarin in wit de eerste letter van {{PAGENAME}}]] | |||
Deze hoofdletter vind je ook terug [[Uitleg ID binnen ISOR|in het ID]] van deze objecten. | Deze hoofdletter vind je ook terug [[Uitleg ID binnen ISOR|in het ID]] van deze objecten. | ||
__TOC__ | __TOC__ | ||
{{:Alle beveiligingsaspecten}} | {{:Alle beveiligingsaspecten}} | ||
==Deeloverzichten binnen {{PAGENAME}}== | ==Deeloverzichten binnen {{PAGENAME}}== | ||
Elk normenkader kent zijn eigen overzichtspagina van principes en normen binnen dit aspect | Elk normenkader kent zijn eigen overzichtspagina van principes en normen binnen dit aspect. In onderstaande tabel is dit weergegeven. | ||
{{#ask:[[Elementtype::Normenkader-aspect]][[Beveiligingsaspect:: | {{#ask:[[Elementtype::Normenkader-aspect]][[Beveiligingsaspect::Uitvoering]] | ||
|?Heeft | |?Heeft bron=Normenkader | ||
|format=sortable wikitable | |format=sortable wikitable | ||
|mainlabel=Overzichtspagina | |mainlabel=Overzichtspagina Uitvoering | ||
|limit=50 | |limit=50 | ||
}} | }} | ||
==Alle Principes binnen {{PAGENAME}}== | ==Alle Principes binnen {{PAGENAME}}== | ||
{{#ask:[[Beveiligingscontext::Uitvoering]][[Categorie:Privacyprincipes]]OR[[Beveiligingscontext::Uitvoering]][[Categorie:Beveiligingsprincipes]] | {{#ask:[[Beveiligingscontext::Uitvoering]][[Categorie:Privacyprincipes]]OR[[Beveiligingscontext::Uitvoering]][[Categorie:Beveiligingsprincipes]] |
Huidige versie van 15 nov 2021 om 14:26
Deze pagina geeft alle ISOR-objecten (Privacyprincipes, Beveiligingsprincipes en Alle Normen) binnen het Beveiligingsaspect Uitvoering weer. Alle objecten binnen dit aspect zijn ook te herkennen aan het onderstaande symbool.
Deze hoofdletter vind je ook terug in het ID van deze objecten.
Uitleg Beveiligingsaspecten[bewerken]
De Information Security Object Repository (ISOR) onderscheidt drie verschillende beveiligingsaspecten:
Benamingen en uitleg binnen de SIVA-methodiek
De SIVA-methodiek beschrijft dat de structuur is opgebouwd uit een aantal lagen waarmee de eerste doorsnede van een te onderzoeken gebied wordt weergegeven. Deze lagenstructuur geeft door middel van drie onderkende contexten een indeling in conditionele-, inrichtings- en managementaspecten. Deze aspecten worden hiermee in juiste contextuele samenhang gepositioneerd. De afbeelding SIVA-lagenstructuur en kenmerken geeft een overzicht van de lagenstructuur en enkele bijbehorende relevante kenmerken. De betekenissen die aan de lagen worden toegekend zijn:
Beleid
Deze laag bevat elementen die aangeven wat we in organisatiebrede zin willen bereiken en bevat daarom conditionele en randvoorwaardelijke elementen die van toepassing zijn op de overige lagen, zoals doelstellingen, beleid, strategie en vernieuwing, organisatiestructuur en architectuur. Met behulp van de karakterisering van het auditobject en aan de hand van enkele hulpvragen, worden de relevante beleidsaspecten geïdentificeerd. De hulpvragen zijn:
- Welke processen zouden moeten zijn ingericht?
- Welke algemene beleidsrichtlijnen zouden moeten zijn uitgevaardigd?
- Welke algemene organisatorische en technisch-structurele aspecten zijn relevant op het beleidsniveau?
Uitvoering
Deze laag omvat de implementatie van de IT-diensten, zoals webapplicaties, en de hieraan gerelateerde infrastructuur, zoals platform en netwerk. De juiste auditelementen worden geïdentificeerd op basis van enkele hulpvragen, zoals:
- Welke webapplicatie-componenten spelen een rol?
- Hoe moeten deze webapplicatie-componenten zijn geïmplementeerd, wat betreft eigenschappen en features-configuratie?
- Hoe moeten de features van de objecten zijn geconfigureerd?
- Welke gedrag moeten de betrokken objecten en actoren vertonen?
- Welke functies dienen te zijn geleverd?
- Welke specifieke voorschriften en instructies zouden moeten gelden voor de implementatie van het auditobject (business processen of IT componenten)?
- Hoe moeten objecten zijn samengesteld en vormgegeven?
Control
Deze laag bevat evaluatie- en metingaspecten van webapplicaties. Hiernaast bevat deze laag beheerprocessen die noodzakelijk zijn voor de instandhouding van het beveiligingsniveau. De informatie uit de evaluaties en de beheerprocessen zijn niet alleen gericht op het bijsturen van de geïmplementeerde webapplicaties, maar ook om het bijsturen van en/of aanpassen van visie en uitgestippeld beleid, afgesproken capaciteitsbehoefte en de eerder geformuleerde conditionele elementen in de beleidscontext, die gebaseerd zijn op “onzekere” informatie en aannames, De relevante control-aspecten worden geïdentificeerd met behulp van de karakterisering van het auditobject en enkele hulpvragen:
- Welke beheerprocessen zouden moeten zijn ingericht?
- Welke specifieke controlerichtlijnen moeten zijn uitgevaardigd om ervoor te zorgen dat de webapplicatie op de juiste wijze worden gerealiseerd voor het leveren van de juiste diensten?
- Aan welke (non-)functionele eisen moet binnen de beheerprocessen en bij assesments aandacht worden besteed?
- Welke organisatorische en technisch-structurele aspecten zijn van toepassing op de webapplicatie?
Deeloverzichten binnen Beveiligingsaspect Uitvoering[bewerken]
Elk normenkader kent zijn eigen overzichtspagina van principes en normen binnen dit aspect. In onderstaande tabel is dit weergegeven.
Alle Principes binnen Beveiligingsaspect Uitvoering[bewerken]
ID | Principe | Criterium |
---|---|---|
APO_U.01 | Wijzigingsbeheerprocedure voor applicaties en systemen | Wijzigingen aan systemen binnen de levenscyclus van de ontwikkeling behoren te worden beheerst door het gebruik van formele procedures voor wijzigingsbeheer. |
APO_U.02 | Beperking software-installatie applicatieontwikkeling | Voor het door gebruikers/ontwikkelaars installeren van software behoren regels te worden vastgesteld en te worden geïmplementeerd. |
APO_U.03 | Richtlijn programmacode | Voor het ontwikkelen van de (programma)code zijn specifieke regels van toepassing en behoort gebruik te zijn gemaakt van specifieke best practices. |
APO_U.04 | Analyse en specificatie informatiesysteem | De functionele eisen die verband houden met nieuwe informatiesystemen of voor uitbreiding van bestaande informatiesystemen behoren te worden geanalyseerd en gespecificeerd. |
APO_U.05 | Analyse en specificatie informatiebeveiligingseisen | De beveiligingseisen die verband houden met informatiebeveiliging behoren te worden opgenomen in de eisen voor nieuwe informatiesystemen en voor uitbreidingen van bestaande informatiesystemen. |
APO_U.06 | Applicatie-ontwerp | Het applicatieontwerp behoort gebaseerd te zijn op informatie, die is verkregen uit verschillende invalhoeken, zoals: business-vereisten en reviews, omgevingsanalyse en (specifieke) beveiliging. |
APO_U.07 | Applicatiefunctionaliteit | Informatiesystemen behoren zo te worden ontworpen, dat de invoerfuncties, verwerkingsfuncties en uitvoerfuncties van gegevens (op het juiste moment) in het proces worden gevalideerd op juistheid, tijdigheid en volledigheid om het bedrijfsproces optimaal te kunnen ondersteunen. |
APO_U.08 | Applicatiebouw | De bouw van applicaties inclusief programmacode behoort te worden uitgevoerd met (industrie) good practice en door individuen die beschikken over de juiste vaardigheden en tools en behoort te worden gereviewd. |
APO_U.09 | Testen systeembeveiliging | Tijdens ontwikkelactiviteiten behoren zowel bedrijfsfunctionaliteiten als de beveiligingsfunctionaliteiten te worden getest. |
APO_U.10 | Systeemacceptatietest | Voor nieuwe informatiesystemen, upgrades en nieuwe versies behoren programma’s voor het uitvoeren van acceptatietests en gerelateerde criteria te worden vastgesteld. |
APO_U.11 | Beschermen testgegevens | Testgegevens behoren zorgvuldig te worden gekozen, beschermd en gecontroleerd. |
APO_U.12 | Beveiligde ontwikkelomgeving | Organisaties behoren beveiligde ontwikkelomgevingen vast te stellen en passend te beveiligen voor verrichtingen op het gebied van systeemontwikkeling en integratie en die betrekking hebben op de gehele levenscyclus van de systeemontwikkeling. |
APO_U.13 | Applicatiekoppeling | De koppelingen tussen applicaties behoren te worden uitgevoerd met geaccordeerde koppelingsrichtlijnen om de juiste services te kunnen leveren en de informatiebeveiliging te kunnen waarborgen. |
APO_U.14 | Logging en monitoring applicatieontwikkeling | Applicaties behoren faciliteiten te bieden voor logging en monitoring om ongeoorloofde en/of onjuiste activiteiten van medewerkers en storingen binnen de applicatie tijdig te detecteren en vast te leggen. |
APO_U.15 | Applicatie-architectuur | De functionele en beveiligingseisen behoren in een applicatie-architectuur, conform architectuurvoorschriften, in samenhang te zijn vastgelegd. |
APO_U.16 | Tooling ontwikkelmethode | De ontwikkelmethode moet worden ondersteund door een tool dat de noodzakelijke faciliteiten biedt voor het effectief uitvoeren van de ontwikkelcyclus. |
CLD_U.01 | Standaarden voor clouddiensten | De CSP past aantoonbaar relevante nationale standaarden en internationale standaarden toe voor de opzet en exploitatie van de diensten en de interactie met de CSC. |
CLD_U.02 | Risico-assessment | De Cloud Service Provider (CSP) behoort een risico-assessment uit te voeren, bestaande uit een risico-analyse en risico-evaluatie met de criteria en de doelstelling voor clouddiensten van de CSP. |
CLD_U.03 | Bedrijfscontinuïteitsservices | Informatie verwerkende faciliteiten behoren met voldoende redundantie te worden geïmplementeerd om aan continuïteitseisen te voldoen. |
CLD_U.04 | Herstelfunctie voor data en clouddiensten | De herstelfunctie van de data en clouddiensten, gericht op ondersteuning van bedrijfsprocessen, behoort te worden gefaciliteerd met infrastructuur en IT-diensten, die robuust zijn en periodiek worden getest. |
... meer resultaten |
Alle onderliggende Normen binnen Beveiligingsaspect Uitvoering[bewerken]
ID | Norm | Stelling |
---|---|---|
APO_U.01.01 | Voor het wijzigingsbeheer gelden de algemeen geaccepteerde beheer frameworks | Wijzigingsbeheer vindt plaats op basis van algemeen geaccepteerde beheerframeworks, zoals Information Technology Infrastructure Library (ITIL), Application Services Library (ASL), Business Information Services Library (BiSL), Scrum, Software Improvement Group (SIG) en Secure Software Development (SSD). |
APO_U.01.02 | Medewerkers (programmeurs) krijgen de juiste autorisatie om werkzaamheden te kunnen uitvoeren | Het wijzigingsproces voor applicaties is zodanig ingericht dat medewerkers (programmeurs) de juiste autorisatie krijgen om hun 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 proces van indienen, prioriteren, besluiten, impactanalyse, vastleggen, specificeren, ontwikkelen, testen, kwaliteitscontrole en implementeren. |
APO_U.01.04 | Elementen van de procedures voor wijzigingsbeheer | Enkele elementen van procedures voor wijzigingsbeheer zijn:
|
APO_U.02.01 | Beleid ten aanzien van het type software dat mag worden geïnstalleerd | De organisatie heeft een strikt beleid gedefinieerd voor de software die ontwikkelaars mogen installeren. |
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 met ‘least privilege’. |
APO_U.02.03 | De rechten verleend op basis van de rollen van het typen gebruikers en ontwikkelaars | De rechten worden verleend met de rollen van de type gebruikers en ontwikkelaars. |
APO_U.03.01 | De programmacode voor functionele specificaties is reproduceerbaar | De programmacode voor functionele specificaties is reproduceerbaar, waarbij aandacht wordt besteed aan:
|
APO_U.03.02 | Programmacode wordt aantoonbaar veilig gecreëerd | De (programma)code wordt aantoonbaar veilig gecreëerd. |
APO_U.03.03 | Programmacode is effectief, veranderbaar en testbaar | De (programma)code is effectief, veranderbaar en testbaar waarbij gedacht kan worden aan:
|
APO_U.03.04 | Over het gebruik van vocabulaire, applicatieframework en toolkits zijn afspraken gemaakt | Over het gebruik van de vocabulaire, applicatie-framework en toolkits zijn afspraken gemaakt. |
APO_U.03.05 | Voor het ontwikkelen van programmacode wordt gebruik gemaakt van gestandaardiseerde vocabulaire | Voor het ontwikkelen van programmacode wordt gebruik gemaakt van gestandaardiseerde vocabulaire zoals de NEN-ISO/IEC 25010 Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models. |
APO_U.03.06 | Ontwikkelaars hebben kennis van algemene en vastgelegde beveiligingsfouten | Ontwikkelaars hebben kennis van algemene beveiligingsfouten, vastgelegd in een extern Common Vulnerability and Exposures (CVE)- systeem. |
APO_U.03.07 | Gebruik van programmacode uit externe programmabibliotheken | Het gebruik van programmacode uit externe programmabibliotheken mag pas worden gebruikt na getest te zijn. |
APO_U.04.01 | Functionele eisen van nieuwe informatiesystemen worden geanalyseerd en in Functioneel Ontwerp vastgelegd | De functionele eisen worden geanalyseerd en bepaald met verschillende invalshoeken (zoals stakeholders, business en wet- en regelgeving) en vastgelegd in een functioneel ontwerp. |
APO_U.04.02 | Het Functioneel Ontwerp wordt gereviewd waarna verbeteringen en/of aanvullingen plaatsvinden | Het functioneel ontwerp wordt gereviewd, waarna verbeteringen en of aanvullingen op het functioneel ontwerp plaatsvinden. |
APO_U.04.03 | Op basis van een goedgekeurd Functioneel Ontwerp wordt een Technisch Ontwerp vervaardigd | Met een goedgekeurd functioneel ontwerp wordt een technisch ontwerp vervaardigd dat ook ter review wordt aangeboden aan de kwaliteitsfunctionaris en beveiligingsfunctionaris. |
APO_U.04.04 | Alle vereisten worden gevalideerd door peer review of prototyping | Alle vereisten worden gevalideerd door een peer review of prototyping (Agile-ontwikkelmethode). |
APO_U.04.05 | Acceptatie-eisen worden vastgelegd parallel aan het Functioneel Ontwerp en Technisch Ontwerp | Parallel aan het vervaardigen van het functioneel ontwerp en technisch ontwerp worden acceptatie-eisen vastgelegd. |
APO_U.05.01 | Een expliciete risicoafweging wordt uitgevoerd ten behoeve van het vaststellen van de beveiligingseisen | Bij nieuwe informatiesystemen en bij wijzigingen op bestaande informatiesystemen moet een expliciete risicoafweging worden uitgevoerd ten behoeve van het vaststellen van de beveiligingseisen, uitgaande van de Baseline Informatiebeveiliging Overheid (BIO). |
... meer resultaten |