Page tree
Skip to end of metadata
Go to start of metadata

Samenvatting

Waarom is deze RFC nodig?

Het afsprakenstelsel verwijst voor het gebruik van TLS naar de ICT-beveiligingsrichtlijnen van het NCSC. Op 19 januari 2021 heeft het NCSC nieuwe richtlijnen gepubliceerd. De wijzigingen hebben impact op het afsprakenstelsel, de stelselnode en de deelnemers. TLS versie is van beoordeling goed naar voldoende teruggezet en voldoet daarmee niet meer aan de eisen. Daarnaast is er eea gewijzigd in de beschrijving van het gebruik van de ciphersuites, ofwel te gebruiken algoritmes.

https://www.ncsc.nl/binaries/ncsc/documenten/publicaties/2021/januari/19/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2.1/ICT-beveiligingsrichtlijnen+voor+Transport+Layer+Security+v2.1.pdf

Oplossingsrichting

In het afsprakenstelsel moeten de verwijzingen naar de versies van TLS worden verwijderd, zodat alleen nog verwezen wordt naar de richtlijnen van NCSC en het niveau dat ondersteund moet worden. Hiermee voorkomen we dat in de toekomst wijzigingen op het afsprakenstelsel doorgevoerd moeten worden, op het moment dat specifieke richtlijnen opnieuw worden gepubliceerd. Wel zal verwezen worden naar de juiste versie van de NCSC richtlijnen. De nieuwe versie is 2.1.

Daarnaast moet een plan worden opgesteld volgens welke de implementatie van de wijzigingen moet worden doorgevoerd door de stelselnode en de deelnemers van MedMij.

Aanpassing van

Hoofdstuk Netwerk

Onderzocht wordt of het haalbaar is om versie 1.3 te moeten ondersteunen.

Impact op rollen

DVP, DVZA

De impact op de DVP's en DVZA's zal worden geïnventariseerd. De vraag hierbij is of de deelnemers als kunnen voldoen aan de eisen van versie 2.1 van de NCSC beveiligingsrichtlijnen en als het antwoord hierop nee is, wanneer zij verwachten hier wel aan te kunnen voldoen.

Impact op beheer

-

Impact op RnA

Op de R&A moeten deze wijzigingen worden doorgevoerd.

Impact op Acceptatie

Het proces van accepteren blijft gelijk.

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


Eigenaar

Casper van der Harst

Arjan van Krimpen


Implementatietermijn

1.4.0

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
  •  
Dienstverleners concurreren op de functionaliteiten
  •  
13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders
  •  
Dienstverleners zijn aanspreekbaar door de gebruiker
  •  
14 Uitwisseling is een keuze
  •  
De persoon wisselt gegevens uit met de zorgaanbieder
  •  
15 Het MedMij-netwerk is gebruiksrechten-neutraal
  •  
MedMij spreekt alleen af wat nodig is
  •  
16 De burger regisseert zijn gezondheidsinformatie als uitgever
  •  
De persoon en de zorgaanbieder kiezen hun eigen dienstverlener
  •  
17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld
  •  
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


Uitwerking

Optie 1

Na onderzoek is gebleken dat versie 1.3 van TLS nog niet door iedereen ondersteund kan worden. In dit geval zal verwezen moeten blijven worden naar versie 2.0 van de NCSC ICT-beveiligingsrichtlijnen. In een volgende release moet opnieuw gekeken worden of dan wel verwezen kan worden naar de nieuwe richtlijnen. In de tussentijd kunnen we onze deelnemers wel stimuleren TLS versie 1.3 als primaire versie te ondersteunen, met als backup TLS versie 1.2. Op een later moment is het dan eenvoudiger om TLS versie 1.2 uit te schakelen en te voldoen aan de versie 2.1 van de NCSC ICT-beveiligingsrichtlijnen.

In dit geval moet de tekst van hoofdstuk Netwerk worden aangepast:

1b. Er wordt enkel gebruik gemaakt van TLS-versies en -algoritmen die zijn geclassificeerd als "goed" in de ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS), versie 2.0 van het NCSC. Een Node biedt alleen TLS 1.3 aan als hij ook TLS 1.2 aanbiedt.

Algoritmen

Het is niet verplicht om alle algoritmen aan te bieden die in de genoemde richtlijnen als "goed" zijn geclassificeerd.

1b. Er wordt enkel gebruik gemaakt van TLS-versies en -algoritmen die zijn geclassificeerd als "goed" in de ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS), versie 2.0 van het NCSC. Elke Node moet TLS 1.2 aanbieden. Daarnaast is het, met het oog op de toekomst, goed om ook TLS 1.3 aan te bieden. Het is niet verplicht om alle algoritmen aan te bieden die in de genoemde richtlijnen als "goed" zijn geclassificeerd.

Op 19 januari 2021 heeft het NCSC nieuwe richtlijnen gepubliceerd. In de nieuwe ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS), versie 2.1 is de beoordeling van TLS 1.2 afgeschaald van classificatie goed naar voldoende. Hiermee voldoet deze versie van TLS niet meer aan de norm. Omdat TLS 1.3 nog niet door iedereen ondersteund of gebruikt kan worden, verwijst het afsprakenstelsel nu nog naar ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS), versie 2.0. Wel stimuleren we de deelnemers TLS 1.3 alvast te ondersteunen, zodat later de overgang soepel kan verlopen.

Optie 2

Uit onderzoek is gebleken dat TLS versie 1.3 prima te ondersteunen is. In dat geval moet de tekst van het hoofdstuk Netwerk worden aangepast.

1b. Er wordt enkel gebruik gemaakt van TLS-versies en -algoritmen die zijn geclassificeerd als "goed" in de ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS), versie 2.0 van het NCSC. Een Node biedt alleen TLS 1.3 aan als hij ook TLS 1.2 aanbiedt.

Algoritmen

Het is niet verplicht om alle algoritmen aan te bieden die in de genoemde richtlijnen als "goed" zijn geclassificeerd.

1b. Er wordt enkel gebruik gemaakt van TLS-versies en -algoritmen die zijn geclassificeerd als "goed" in de ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS), versie 2.1 van het NCSC. Het is niet verplicht om alle algoritmen aan te bieden die in de genoemde richtlijnen als "goed" zijn geclassificeerd.

Optie 3

We kiezen voor een combinatie van de twee voorgaande opties. Voor backchannelverkeer moet TLS 1.3 gebruikt worden. Omdat we de zorggebruikers niet willen/kunnen verplichten gebruik te maken van een nieuwe(re) browser, moet voor het frontchannelverkeer primair gebruikgemaakt worden van TLS 1.3, maar blijft versie 1.2 als backup bestaan. Hierbij verwijzen we in het afsprakenstelsel naar versie 2.1 van de ICT-beveiligingsrichtlijnen van NCSC en accepteren we dat een TLS versie gebruikt wordt die als voldoende staat geclassificeerd.

1b. Er wordt enkel gebruik gemaakt van TLS-versies en -algoritmen die zijn geclassificeerd als "goed" in de ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS), versie 2.0 van het NCSC. Een Node biedt alleen TLS 1.3 aan als hij ook TLS 1.2 aanbiedt.

Algoritmen

Het is niet verplicht om alle algoritmen aan te bieden die in de genoemde richtlijnen als "goed" zijn geclassificeerd.

1b. Voor backchannelverkeer wordt enkel gebruik gemaakt van TLS-versies die zijn geclassificeerd als "goed" in de ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS), versie 2.1 van het NCSC. Voor frontchannelverkeer worden primair TLS-versies die zijn geclassificeerd als "goed" gebruikt, maar mag gebruikgemaakt worden van TLS-versies die zijn geclassificeerd als "voldoende". In beide gevallen worden enkel algoritmen gebruikt die geclassificeerd zijn als "goed".

Het is niet verplicht om alle algoritmen aan te bieden die in de genoemde richtlijnen als "goed" zijn geclassificeerd.

Te onderzoeken

  • Kunnen onze deelnemers TLS versie 1.3 ondersteunen? Dit geldt voor backchannel verkeer, maar zeker ook voor frontchannel verkeer.
  • Kunnen onze omgevingen (R&A en Zandbak) TLS versie 1.3 ondersteunen?
  • Moeten we rekening houden met de richtlijnen van DigiD?
  • Kunnen de browsers van zorggebruikers dit ondersteunen?

Richtlijnen van DigiD

De richtlijnen van DigiD benoemen het volgende: 'een https-verbinding (TLS 1.0 en/of 1.2 ondersteund)'. De vraag is of dit invloed heeft op de richtlijnen vanuit het afsprakenstelsel. Op dit moment wijken wij hier ook al van af, door alleen met "goed" geclassificeerde TLS versies te ondersteunen. In versie 2.0 van de NCSC ICT-beveiligingsrichtlijnen zijn dit TLS 1.2 en TLS 1.3. TLS 1.0 en TLS 1.1 zijn sinds Maart 2020 end-of-life en mogen niet meer ondersteund worden.

Ondersteuning door browsers

In de (versie van de) browsers die niet als groen zijn gemarkeerd, zijn meerdere problemen gevonden. Deze zijn niet veilig. Vraag is of wij zorggebruikers willen verplichten deze browsers niet meer te gebruiken.

Advies

In release 1.4.0 van het afsprakenstelsel voeren we Optie 1 door. We verwijzen voorlopig nog naar de NCSC ICT-beveiligingsrichtlijnen 2.0 en gaan de deelnemers stimuleren TLS 1.3 te ondersteunen (sowieso bij backchannelverkeer). Bij de volgende release(s) onderzoeken we opnieuw of het haalbaar is te verwijzen naar NCSC ICT-beveiligingsrichtlijnen 2.1 en zo het gebruik van TLS 1.2 te stoppen.

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
PNG File image2021-4-11_7-48-41.png about 10 hours ago by Casper van der Harst

  • No labels

1 Comment

  1. Is het zinnig om een ingangsdatum hiervoor in te stellen zodat:

    • deelnemers niet afgeschrikt worden om 1.4.0 te implementeren 
    • we ook 1.3.0 deelnemers meenemen