Skip to end of banner
Go to start of banner

RFC0045 Beveiligingsrichtlijnen NCSC

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 22 Next »

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.

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

Former user (Deleted)


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:

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.

 Toelichting

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.

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.

1c. Gebruik van TLS False Start is verboden.

Toelichting

Gebruik van TLS False Start is verboden om te voorkomen dat er inhoudelijke verwerking plaatsvindt van uitgewisselde gegevens voordat voor de betreffende uitwisseling authenticatie en autorisatie geslaagd zijn (zie onder).

Nieuwe tekst

1b.

Er wordt gebruikgemaakt 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. Indien meerdere TLS-versies als "goed" geclassificeerd zijn, moet minimaal de laagste versie worden ondersteund. Hogere versies mogen worden aangeboden.

1c.Van de in 1b bedoelde TLS-versies en -algoritmen kan worden afgeweken, indien dit expliciet benoemd wordt in eisen binnen dit afsprakenstelsel.
1d.Gebruik van TLS False Start is verboden.
1e.Voor de TLS-handshake wordt de hoogste versie van TLS gebruikt die beide partijen ondersteunen.
1f.

TLS 1.2 moet door elke deelnemer ondersteund worden.

TLS 1.2

TLS 1.3 wordt in de ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS), versie 2.1 van het NCSC als enige met "goed" geclassificeerd. Daarmee is dit de enige TLS-versie die volgens 1b ondersteund mag worden. Bij deze release van dit afsprakenstelsel kan TLS 1.3 niet door alle deelnemers ondersteund worden, omdat dit niet wordt aangeboden door de gebruikte componenten. Daarom treedt 1c in werking en moet TLS 1.2 ook worden ondersteund. Zodra TLS 1.3 breed gedragen wordt, zal deze eis komen te vervallen. Vanaf dat moment is het gebruik van TLS 1.2 verboden. Deze wijziging kan op deze release van het afsprakenstelsel doorgevoerd worden met behulp van een patch.

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.

DreigingKansImpactDreigingsID (intern)Maatregelen





Bijlagen

  File Modified
No files shared here yet.

  • No labels