RFC0052 Pentest scope en testwijze

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.
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)	1) 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 2)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 initiele aansluiting en bij grootschalige wijziging of herbouw, bijvoorbeeld in een gehele nieuwe programmeertaal eenmalig een whitebox applicatietest te vereisen.

Goedkeuring

Beoordelaar	Datum	Toelichting	Beoordelaar	Datum	Toelichting
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(1) (DVP en DVZA):

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.

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.

Dreiging	Kans	Impact	DreigingsID (intern)	Maatregelen
Niet alle publieke/semi publieke interfaces wordten getest waardoor kwetsbaarheden blijven bestaan	Klein	midden

Bijlagen

	File	Modified

No files shared here yet.