RFC0066 Pentest scope en testwijze (Patch)
Samenvatting
| Waarom is deze RFC nodig? | Bij het verwerken van RFC0052 Pentest scope en testwijze is door een misverstand alleen Norm A.18.2.3 (2) meegenomen en is Norm A.18.2.3 (1) ongewijzigd gebleven. Dit leidt tot een inconsistent voorschrift rond pentesten. |
|---|---|
| Oplossingsrichting | Norm A.18.2.3 (1) analoog aan A.18.2.3 (2) aanpassen zodat deze consistent worden. |
| RACI |
|
| Aanpassing van | Afsprakenstelsel |
| Impact op rollen | DVP, DVZA |
| Impact op beheer | nvt |
| Impact op RnA | nvt |
| Impact op Acceptatie | nvt |
| PIA noodzakelijk | neen |
| Gerelateerd aan (Andere RFCs, PIM issues) | |
| Implementatietermijn | 1.5.0 |
| Motivatie verkorte RFC procedure (patch) | Voorkomen onduidelijkheid rond pentest voorschriften. |
Uitwerking
Op pagina A.18.2.3 (1) Beoordeling van technische naleving aanpassen:
Implementatie Tenminste jaarlijks MOET een
whiteboxgreybox applicatiepenetratietesten 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;
- DNSSEC zie core.dns.300 en core.dns.301
- TLS zie verantwoordelijkheid core.tls.301 in combinatie met core.tls.302 en core.tls.304
- NCSC webapplicatie richtlijnen U/PW.02, U/PW.03, U/WA.03, U/WA.04 NB deze zijn voor DigiD assessments al verplicht. Zie NOREA Handreiking DigiD assessments
Voor toetreding heeft deze 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.
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.
| Dreiging | Kans | Impact | DreigingsID (intern) | Maatregelen |
|---|---|---|---|---|
| Niet alle publieke/semi publieke interfaces worden getest waardoor kwetsbaarheden blijven bestaan | Klein | Midden |
Bijlagen
Goedkeuring
| Beoordelaar | Datum | Toelichting | Beoordelaar | Datum | Toelichting |
|---|---|---|---|---|---|
| Productmanager Stichting MedMij | Productmanager Beheerorganisatie | ||||
| Leadarchitect Stichting MedMij | Leadarchitect Beheerorganisatie | ||||
| Ontwerpteam | |||||
| Deelnemersraad | Eigenaarsraad |