Document toolboxDocument toolbox

MO-105 Samenvoeging normen A.18.2.3-1 en -2 (uitvoeren)

Owned by Martin Wilmink
Last updated: Apr 03, 2023
3 min read

Samenvatting

Waarom is deze RFC nodig?

Samenvoeging normen A.18.2.3-1 en -2

Oplossingsrichting

Nieuwe pagina A.18.2.3 met de samenvoeging
Pagina. A.18.2.3(1) en A.18.2.3(2) vervallen.

RACI
  • Responsible:
    • Martin Wilmink
  • Accountable:
    • Lead Architect
  • Consulted
    • Ontwikkelteam (ontwikkeling@medmij.nl)
    • Security Management (secmgt@medmij.nl) Maarten Smidt
    • Acceptatie (acceptatie@medmij.nl)
    • Stelselregie
    • Deelnemers (Expertgroepsessie)
  • Informed
    • Communicatie
    • Loket (info@medmij.nl)
    • Leveranciersmanagement


Aanpassing van

Normenkader informatiebeveiliging

Impact op rollen

N.V.T.

Impact op beheer

N.V.T.

Impact op RnA

N.V.T.

Impact op Acceptatie

Greybox ipv Whitebox pentest

PIA noodzakelijk
Gerelateerd aan (Andere RFCs, PIM issues)

MO-107, Controle uniciteit codes en tokens toevoegen aan norm A.18.2.3
Deze is aangemaakt na deze wijziging. De aanpassingen in MO-107 worden gelijk toegepast op deze wijziging.

Implementatietermijn

Release 2023-05

Motivatie verkorte RFC procedure (patch)


Uitwerking


Page titel: A.18.2.3 Beoordeling van technische naleving


Norm

RationaleDeze maatregel borgt dat deelnemers en de beheerorganisatie met regelmaat (en gebruikmakend van verschillende partijen) hun software, systemen en infrastructuur laten toetsen op bekende kwetsbaarheden.
Implementatie

Tenminste jaarlijks MOET een greybox applicatiepenetratietest worden uitgevoerd op de externe koppelvlakken door een externe, onafhankelijke organisatie.


De volgende specifieke MedMij eisen moeten ook aantoonbaar getoetst zijn in de pentest rapportage;

  • Voor alle deelnemers:
  • In geval van een Authorization server:
    • De uniciteit van de uitgegeven Authorization codes en Access tokens door middel van een code review, zie core.autorisatie.208

De externe koppelvlakken zijn:

  • DVP: Burgerfrontend, OAuth Client Redirect
  • DVA: Resourceserver koppelvlak, Autorization server interface(s) eindgebruiker en voor de DVP.
  • BO:  Stelselnode en administratieve front-end


Voor toetreding heeft een greybox applicatiepenetratietest minimaal al één keer plaatsgevonden en MOETEN de hoog en middel risico bevindingen op externe MedMij koppelvlakken zijn opgelost.

Voor penetratietesten die worden uitgevoerd na toetreding, dient een adequaat actieplan opgesteld te worden voor minimaal de hoge en midden risico's (CVSS-score (Common Vulnerability Scoring System) van 4,0 of hoger) ten aanzien van de MedMij dienstverlening. Dit actieplan wordt gedeeld met de beheerorganisatie. De corrigerende maatregelen worden tijdig doorgevoerd.

Bij grootschalige wijziging of herbouw vereisen eenmalig een greybox applicatiepenetratietest.

Voor penetratietesten die worden uitgevoerd na toetreding, dient een adequaat actieplan opgesteld te worden voor minimaal de hoge en midden risico's ten aanzien van de MedMij dienstverlening. Dit actieplan wordt gedeeld met de beheerorganisatie. De corrigerende maatregelen worden tijdig doorgevoerd.


Toelichting

Een greybox penetratietest houdt in dat de penetratietester zoveel mogelijk inzicht heeft in de applicatie. Dit kan onder meer inhouden:

  • Toegang tot architectuur/ontwerpdocumentatie;
  • Toegang tot broncode;
  • Inloggegevens voor verschillende rollen.

Het is niet nodig om een penetratietest uit te voeren op de gehele architectuur en/of alle programmacode. Het gaat met name om de beveiliging van de gegevens die over internet worden uitgewisseld, de focus moet dus liggen op de beveiliging van de externe koppelvlakken. Een app of een web portaal is ook een extern koppelvlak!

NEN 7510-1:2017A.18.2.3 Beoordeling van technische naleving
NEN 7510:2011A.15.2.2 Controle op technische naleving

Beoordeling

Auditmethode

Stel op basis van de meest recente rapportages vast of er wordt voldaan aan de jaarlijkse greybox applicatiepenetratietesten op de externe koppelvlakken conform de architectuur en specificaties van MedMij (en louter binnen de scope van het MedMij afsprakenstelsel).

Verificatie

  • Evidence m.b.t. de uitgevoerde jaarlijkse testen.
  • Met wie gesproken is ter bevestiging van de implementatie.
  • Evidence m.b.t. het melden van kwetsbaarheden

Rollen

DVP

(tick)

DVA

(tick)

BO

(tick)

DVP = Dienstverlener persoon, DVA = Dienstverlener aanbieder, BO = Beheerorganisatie

Optioneel: Impact op foutafhandeling (zie https://confluence.vzvz.nl/display/MMAS/Foutmeldingen+MedMij )


Principe's

Principe
Principe

1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal

  •  
11 Stelselfuncties worden vanaf de start ingevuld
  •  
2 Dienstverleners zijn transparant over de gegevensdiensten 
  •  
12 Het afsprakenstelsel is een groeimodel
  •  
3 Dienstverleners concurreren op de functionaliteiten
  •  
13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders
  •  
4 Dienstverleners zijn aanspreekbaar door de gebruiker
  •  
14 Uitwisseling is een keuze
  •  
5 De persoon wisselt gegevens uit met de zorgaanbieder
  •  
15 Het MedMij-netwerk is gebruiksrechten-neutraal
  •  
6 MedMij spreekt alleen af wat nodig is
  •  
16 De burger regisseert zijn gezondheidsinformatie als uitgever
  •  
7 De persoon en de zorgaanbieder kiezen hun eigen dienstverlener
  •  
17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld
  •  
9 De dienstverleners zijn deelnemers van het afsprakenstelsel
  •  
18 Afspraken worden aantoonbaar nageleefd en gehandhaafd
  •  
10 Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling
  •  
19 Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat
  •  
Toelichting


Risico's

Omschrijf de (privacy)risico's die kunnen ontstaan als deze RFC wordt aangenomen. In het onwaarschijnlijke geval dat deze RFC's geen risico's introduceert, geef dat dan wel aan.

DreigingKansImpactDreigingsID (intern)Maatregelen





Bijlagen

  File Modified
No files shared here yet.

Goedkeuring

BeoordelaarDatumToelichtingBeoordelaarDatumToelichting
Productmanager Stichting MedMij

Productmanager Beheerorganisatie

Leadarchitect Stichting MedMij

Leadarchitect Beheerorganisatie

Ontwerpteam




Deelnemersraad

Eigenaarsraad