Document toolboxDocument toolbox

RFC0052 Pentest scope en testwijze

Owned by schmidt (Unlicensed)
Last updated: Oct 11, 2021 by Former user (Deleted)
3 min read

Samenvatting

Waarom is deze RFC nodig?
  1. Pentest scope voor MedMij afsprakenstelsel eenduidig beschrijven zodat deze eenvoudiger door auditoren te beoordelen is en door MedMij deelnemers ook expliciet aan de pentest bij opdracht is me te geven. Dit betreft een minimale scope, deelnemer kan natuurlijk andere interfaces ook in opdracht geven.
  2. Pentest aanpak uniformeren met aanpak DigiD assessment en beter laten aansluiten bij de praktijk. In AS 1.4 wordt een whitebox/crystal box applicatie test voorgeschreven. Terugkoppeling uit de praktijk is dat meerdere gevallen is maar beperkte inzage in broncode mogelijk is, wat onderdeel is van een whitebox applicatietest. Daarnaast is de technische architectuur/inrichting van bijvoorbeeld Cloudleveranciers niet openbaar/beschikbaar en is het eigenlijk de logische/gevirtualiseerde architectuur die beschreven is.
  3. Per deelnemer type duidelijk maken welke interfaces/koppelvlakken expliciet meegenomen moeten zijn in de pentest.
    DVP: Burgerfrontend, OAuth Client Redirect
    DVZA: Resourceserver koppelvlak, Autorization server interface(s) eindgebruiker en voor DVP.
    BO: Stelselnode en administratieve front-end
  4. Aanpassing van een normelement die vereenvoudiging zou moeten bieden voor deelnemers en meer in lijn met DigiD assessment, relevant voor DVZA's en kostenbesparend omdat broncode inzage en whitebox pentest extra kosten met zich mee brengt. Door het toenemende gebruik van Cloud diensten en Cloud API's is inzage is broncode steeds minder mogelijk.

Voorstel is om de norm te wijzigen en een jaarlijkse greybox applicatietest te vereisen. Bij initiële aansluiting en bij grootschalige wijziging of herbouw, bijvoorbeeld in een gehele nieuwe programmeertaal eenmalig een whitebox applicatietest te vereisen.

Oplossingsrichting

Beschrijving welke technische interfaces onderdeel moeten zijn van de pentestscope en de wijze van testen aanpassen van whitebox applicatietesten naar grey box applicatie testen.

Aanpassing van

Normenkader A.18.2.3 (1) Beoordeling van technische naleving, met name de box Toelichting en auditmethode.


Impact op rollen

DVP, DVZA en BO

Impact op beheer

Security Team: Duidelijk communiceren naar auditors van deze wijziging. Bij publicatie en bij oplevering van verbeterplannen en beoordelen van auditrapporten

Impact op RnA

Niet voorzien

Impact op Acceptatie

Niet voorzien

PIA noodzakelijk
  •  
Gerelateerd aan (Andere RFCs, PIM issues)

 RFC0057

Eigenaar

R&S Team, Former user (Deleted) 

Implementatietermijn

AS 1.5

Motivatie verkorte RFC procedure (patch)



Goedkeuring

BeoordelaarDatumToelichtingBeoordelaarDatumToelichting
Productmanager Stichting MedMij

Productmanager Beheerorganisatie

Leadarchitect Stichting MedMij

Leadarchitect Beheerorganisatie

Ontwerpteam




Deelnemersraad

Eigenaarsraad

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


3, geen en minder onderscheid tussen deelnemers die gebruik maken van 'closed source' componenten en die zelf code ontwikkelen.
19: DVZA pentest DigiD en MedMij meer in lijn gebracht
18: Auditor kan beter en eenduidiger controleren dat pentest scope en diepgang voldoet

Uitwerking

Uitwerking in normenkader A.18.2.3 (2) Beoordeling van technische naleving:

Nieuwe tekst

Implementatie

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

De externe koppelvlakken zijn:

DVP: Burgerfrontend, OAuth Client Redirect

DVZA: Resourceserver koppelvlak, Autorization server interface(s) eindgebruiker en voor de DVP.

BO:  Stelselnode en administratieve front-end


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

Of bij grootschalige wijziging of herbouw eenmalig een whitebox applicatiepenetratietest te vereisen

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.


(cursief is nieuwe tekst of geheel vervangende tekst, doorgehaalde is verwijderde tekst.)

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
Niet alle publieke/semi publieke interfaces wordten getest waardoor kwetsbaarheden blijven bestaan

Klein

midden


Bijlagen

  File Modified
No files shared here yet.