Beveiligingsaspect Uitvoering

Uit NORA Online
Versie door M.M.Vos (overleg | bijdragen) op 23 jan 2018 om 17:04 (uitvoering ipv control in queries)
Naar navigatie springen Naar zoeken springen

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 symbool

Paars vierkant kader met daarin in wit de eerste letter van Beveiligingsaspect Uitvoering

Deze hoofdletter vind je ook terug in het ID van deze objecten.

Principes[bewerken]

IDPrincipeCriterium
PRIV_U.01Doelbinding gegevensverwerkingDe verwerkingsverantwoordelijke heeft van alle verzamelingen en verwerkingen van persoonsgegevens tijdig, welbepaald en uitdrukkelijk omschreven:
  • De doeleinden, en:
  • De rechtvaardigingsgronden voor:
  1. De verdere verwerking op grond van de verenigbaarheid met de oorspronkelijke gerechtvaardigde doeleinden;
  2. De geautomatiseerde besluitvorming;
  3. De bijzondere categorieën persoonsgegevens;
  4. De persoonsgegevens betreffende strafrechtelijke veroordelingen en strafbare feiten;
  5. Het nationaal identificerend nummer;
  6. De persoonsgegevens ten behoeve van wetenschappelijk of historisch onderzoek met een statistisch oogmerk en archivering in het algemeen belang.
PRIV_U.02Register van verwerkingsactiviteitenDe verwerkingsverantwoordelijke en de verwerker hebben hun gegevens over de gegevensverwerkingen in een register vastgelegd, daarbij biedt het register een actueel en samenhangend beeld van de gegevensverwerkingen, processen en technische systemen die betrokken zijn bij het verzamelen, verwerken en doorgeven van persoonsgegevens.
PRIV_U.03KwaliteitsmanagementDe verwerkingsverantwoordelijke heeft kwaliteitsmanagement ingericht ten behoeve van de bewaking van de juistheid en nauwkeurigheid van persoonsgegevens. De verwerking is zo ingericht dat de persoonsgegevens kunnen worden gecorrigeerd, gestaakt of overgedragen. Indien dit gebeurt op verzoek van betrokkene dan wordt deze over de status van de afhandeling geïnformeerd.
PRIV_U.04Beveiligen van de verwerking van persoonsgegevensDe verwerkingsverantwoordelijke en de verwerker treffen technische en organisatorische maatregelen voor verwerking van persoonsgegevens op een passend beveiligingsniveauAVG Art. 32.
PRIV_U.05Informatieverstrekking aan betrokkene bij verzameling persoonsgegevensDe verwerkingsverantwoordelijke stelt bij elke verzameling van persoonsgegevens tijdig en op een vastgelegde en vastgestelde wijze informatie aan de betrokkene beschikbaar, zodat de betrokkene, tenzij een uitzondering geldt, toestemming kan geven voor de verwerkingAVG Art. 14.
PRIV_U.06Bewaren van persoonsgegevensDoor het treffen van de nodige maatregelen hanteert de organisatie voor persoonsgegevens een bewaartermijn die niet wordt overschreden.
PRIV_U.07Doorgifte persoonsgegevensBij doorgifte aan een andere verwerkingsverantwoordelijke zijn de onderlinge verantwoordelijkheden duidelijk en bij de doorgifte aan een verwerker zijn er afdoende garanties.

Bij de doorgifte naar buiten de EU:

  • Is er een vertegenwoordiger, en:
  • Is geen sprake van uitzonderingsgronden, en:
  • Geldt een door de Europese Commissie genomen adequaatheidsbesluit, of:
  • Zijn er passende waarborgenAVG Art. 44, of:
  • Geldt een afwijking voor een specifieke situatie.

Normen[bewerken]

IDNormStelling
APO_U.01.01Voor het wijzigingsbeheer gelden de algemeen geaccepteerde beheer frameworksWijzigingsbeheer 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.02Medewerkers (programmeurs) krijgen de juiste autorisatie om werkzaamheden te kunnen uitvoerenHet wijzigingsproces voor applicaties is zodanig ingericht dat medewerkers (programmeurs) de juiste autorisatie krijgen om hun werkzaamheden te kunnen uitvoeren.
APO_U.01.03Nieuwe systemen en belangrijke wijzigingen aan bestaande systemen volgen een formeel wijzigingsprocesNieuwe 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.04Elementen van de procedures voor wijzigingsbeheerEnkele elementen van procedures voor wijzigingsbeheer zijn:
  • Alle wijzigingsverzoeken/Request for Changes (RFC’s) verlopen volgens een formele wijzigingsprocedure (ter voorkoming van ongeautoriseerde wijzigingsaanvragen).
  • Het generieke wijzigingsproces heeft aansluiting met functioneel beheer.
  • Wijzigingen worden doorgevoerd door bevoegde medewerkers.
  • Van elk wijzigingsverzoek wordt de impact op de geboden functionaliteit beoordeeld.
  • Uitvoering en bewaking van de verantwoordelijkheden/taken zijn juist belegd.
  • Aanvragers van wijzigingen worden periodiek geïnformeerd over de status van hun wijzigingsverzoek.
APO_U.02.01Beleid ten aanzien van het type software dat mag worden geïnstalleerdDe organisatie heeft een strikt beleid gedefinieerd voor de software die ontwikkelaars mogen installeren.
APO_U.02.02Het 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.03De rechten verleend op basis van de rollen van het typen gebruikers en ontwikkelaarsDe rechten worden verleend met de rollen van de type gebruikers en ontwikkelaars.
APO_U.03.01De programmacode voor functionele specificaties is reproduceerbaarDe programmacode voor functionele specificaties is reproduceerbaar, waarbij aandacht wordt besteed aan:
  • gebruikte tools;
  • gebruikte licenties;
  • versiebeheer;
  • documentatie van code ontwerp, omgeving, afhankelijkheden, dev/ops en gebruikte externe bronnen.
  • APO_U.03.02Programmacode wordt aantoonbaar veilig gecreëerdDe (programma)code wordt aantoonbaar veilig gecreëerd.
    APO_U.03.03Programmacode is effectief, veranderbaar en testbaarDe (programma)code is effectief, veranderbaar en testbaar waarbij gedacht kan worden aan:
  • het juist registreren van bugs in de code;
  • het voorkomen van herintroductie van bugs in de code;
  • het binnen 72 uur corrigeren van beveiligingsfixes;
  • het vastleggen van afhankelijkheden van development en operations (dev/ops) van applicatie (relatie tussen software-objecten);
  • het adequaat documenteren van software-interface, koppelingen en Application Programming Interfaces (API’s).
  • APO_U.03.04Over het gebruik van vocabulaire, applicatieframework en toolkits zijn afspraken gemaaktOver het gebruik van de vocabulaire, applicatie-framework en toolkits zijn afspraken gemaakt.
    APO_U.03.05Voor het ontwikkelen van programmacode wordt gebruik gemaakt van gestandaardiseerde vocabulaireVoor 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.06Ontwikkelaars hebben kennis van algemene en vastgelegde beveiligingsfoutenOntwikkelaars hebben kennis van algemene beveiligingsfouten, vastgelegd in een extern Common Vulnerability and Exposures (CVE)- systeem.
    APO_U.03.07Gebruik van programmacode uit externe programmabibliothekenHet gebruik van programmacode uit externe programmabibliotheken mag pas worden gebruikt na getest te zijn.
    APO_U.04.01Functionele eisen van nieuwe informatiesystemen worden geanalyseerd en in Functioneel Ontwerp vastgelegdDe 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.02Het Functioneel Ontwerp wordt gereviewd waarna verbeteringen en/of aanvullingen plaatsvindenHet functioneel ontwerp wordt gereviewd, waarna verbeteringen en of aanvullingen op het functioneel ontwerp plaatsvinden.
    APO_U.04.03Op basis van een goedgekeurd Functioneel Ontwerp wordt een Technisch Ontwerp vervaardigdMet een goedgekeurd functioneel ontwerp wordt een technisch ontwerp vervaardigd dat ook ter review wordt aangeboden aan de kwaliteitsfunctionaris en beveiligingsfunctionaris.
    APO_U.04.04Alle vereisten worden gevalideerd door peer review of prototypingAlle vereisten worden gevalideerd door een peer review of prototyping (Agile-ontwikkelmethode).
    APO_U.04.05Acceptatie-eisen worden vastgelegd parallel aan het Functioneel Ontwerp en Technisch OntwerpParallel aan het vervaardigen van het functioneel ontwerp en technisch ontwerp worden acceptatie-eisen vastgelegd.
    APO_U.05.01Een expliciete risicoafweging wordt uitgevoerd ten behoeve van het vaststellen van de beveiligingseisenBij 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

    Uitleg Beveiligingsaspecten[bewerken]

    Beveiligingsaspect BeleidBeveiligingsaspect UitvoeringBeveiligingsaspect ControlAlle beveiligingsaspectenDrie paarse rechthoeken met in wit de teksten Beleid, Uitvoering en Control, met daarnaast een kleiner paars vierkant met de eerste letter van deze drie beveiligingsaspecten.

    De Information Security Object Repository (ISOR) onderscheidt drie verschillende beveiligingsaspecten:

    1. Beleid
    2. Uitvoering
    3. Control


    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:

    SIVA lagenstructuur en kenmerken.

    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?