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 1.2 is van classificatie "goed" naar "voldoende" teruggezet en voldoet daarmee niet meer aan de eisen van het afsprakenstelsel. Daarnaast is er eea gewijzigd in de beschrijving van het gebruik van de ciphersuites, ofwel te gebruiken algoritmes. |
---|---|
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. |
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 | |
Implementatietermijn | 1.4.0 |
Motivatie verkorte RFC procedure (patch) |
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 |
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:
Huidige tekst
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. |
Nieuwe tekst
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. |
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.
Huidige tekst
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. |
Nieuwe tekst
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.
Huidige tekst
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. |
Nieuwe tekst
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. |
Optie 4
We kiezen voor een combinatie van de twee voorgaande opties. We zullen verwijzen naar versie 2.1 van de ICT-beveiligingsrichtlijnen van NCSC, waardoor de ondersteuning van TLS 1.3 verplicht is. Echter, omdat een aantal deelnemers gebruikmaken van systemen die dit nog niet ondersteunen, beschrijven wij een uitzondering. Deze uitzondering zorgt er voor dat TLS 1.2 gebruikt mag worden, indien dit strikt noodzakelijk is.
Huidige tekst
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. |
Nieuwe tekst
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. TLS 1.2 Bij de release van versie 1.4.0 van dit afsprakenstelsel kan TLS 1.3 niet door alle deelnemers ondersteund worden, omdat dit niet wordt aangeboden door de gebruikte systemen. Daarom wordt het gebruik van TLS 1.2 tijdelijk gedoogd, alleen indien dit door technische beperkingen strikt noodzakelijk is. Door deze uitzondering moeten alle deelnemers TLS 1.2 blijven ondersteunen voor alle backchannel-verkeer. |
Optie 5
We kiezen voor een combinatie van de twee voorgaande opties. We zullen verwijzen naar versie 2.1 van de ICT-beveiligingsrichtlijnen van NCSC, maar verplichten niet meer de classificatie goed. Voldoende mag ook gebruikt worden, hierbij veronderstellen we dat iedereen een TLS versie voldoende moet ondersteunen en goed mag ondersteunen. Daarnaast benoemen we dat als een TLS versie goed mogelijk is, dat deze dan boven een voldoende geclassificeerde geprioriteerd moet worden. In de huidige situatie betekent dit dat TLS 1.3 ondersteund moet worden als dit door beide partijen ondersteund wordt, anders mag TLS 1.2 gebruikt worden.
Huidige tekst
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. |
Nieuwe tekst
1b. Er wordt gebruikgemaakt van TLS-versies die zijn geclassificeerd als "voldoende" of "goed" in de ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS), versie 2.1 van het NCSC. TLS-versies die als "voldoende" zijn geclassificeerd moeten door alle deelnemers ondersteund worden. TLS-versies die als "goed" zijn geclassificeerd moeten door alle deelnemers ondersteund worden, indien de door hen gebruikte componenten dit ondersteunen. TLS verbindingen worden opgezet met een zo hoog mogelijke TLS versie. Er wordt enkel gebruikgemaakt van algoritmen die zijn geclassificeerd als "goed", het is niet verplicht om alle algoritmen aan te bieden. |
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.
Eindoordeel
In release 1.4.0 van het afsprakenstelsel voeren we Optie 4 door. We verwijzen naar de NCSC ICT-beveiligingsrichtlijnen 2.1 en beschrijven een uitzondering voor het gebruik van TLS 1.2. Bij de volgende release(s) onderzoeken we opnieuw of het haalbaar is 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.
Dreiging | Kans | Impact | DreigingsID (intern) | Maatregelen |
---|---|---|---|---|
Bijlagen