image

Autoriteit Persoonsgegevens wijst organisaties op TLS-richtlijn

woensdag 24 april 2019, 08:20 door Redactie, 15 reacties

Organisaties moeten controleren dat zij geen uit te faseren TLS-configuratie voor het versleutelen van netwerkverkeer gebruiken, anders lopen ze risico om niet aan de AVG te voldoen. Dat laat de Autoriteit Persoonsgegevens weten.

Gisteren kwam het Nationaal Cyber Security Centrum (NCSC) van het ministerie van Justitie en Veiligheid met vernieuwde TLS-richtlijnen. Het TLS-protocol wordt gebruikt voor het beveiligen van internetverbindingen. Het gaat dan bijvoorbeeld om webverkeer, e-mailverkeer en bepaalde soorten virtual private networks. De eerste TLS-richtlijn van het NCSC verscheen in 2014. Sindsdien is de TLS-standaard verder doorontwikkeld, waarop er besloten is een vernieuwde richtlijn te publiceren.

In de vernieuwde richtlijn wordt onder andere aangeraden om bepaalde TLS-configuraties uit te faseren, omdat bekend is dat ze fragiel zijn met oog op de doorontwikkeling van aanvalstechnieken, aldus het NCSC. De Autoriteit Persoonsgegevens raadt organisaties aan om te controleren of ze gebruikmaken van deze uit te faseren TLS-configuraties.

In het geval deze configuraties inderdaad worden gebruikt moeten organisaties een risicoanalyse uitvoeren en eventueel maatregelen nemen om de risico’s te beheersen, zo stelt de privacytoezichthouder. Tevens dienen de voorwaarden en de termijn waarna de uit te faseren configuratie niet meer wordt gebruikt te worden gedocumenteerd. Organisaties doen er verstandig aan om over te stappen op TLS-configuraties die als "voldoende" of "goed" zijn beoordeeld. "Anders lopen organisaties het risico dat zij niet voldoen aan artikel 24 en 32 van de AVG", zo waarschuwt de Autoriteit Persoonsgegevens.

Reacties (15)
24-04-2019, 10:32 door Anoniem
Vorig jaar had ik een e-mail engineer die ook security minded was.
TLS1.2 of hoger zonder rc4, (dus ssl3, tls1, tls1.1 werden geblokkeerd maar OOK alle cypers onder de 128bit.
dus dan had je of supergoede encryptie met goede cyphers, maar omdat alle windows exchange servers die niet ondersteunen moest ook plain text ondersteund worden.
dus slechte encryptie is schijnbaar erger dan geen encryptie... DOH!
24-04-2019, 10:58 door Anoniem
De GGD geeft dus de algemene veiligheidsstandaard weer. Triest. Met al die globale monocultures. Met GGD bedoel ik hier de grootst gemene deler bij implicatie. Het minimale is de norm.
24-04-2019, 11:00 door Anoniem
Zou de AP zich niet veel meer bezig moeten houden met de rechtmatigheid van het transporteren van de persoonsgegevens over deze al dan niet voldoende beveiligde verbindingen?

Of is het minder erg als data gelekt wordt over een veilige verbinding?

(Denkend aan de dossiers die kennelijk bij SAVE via mail verstuurd worden: het is niet alleen onveilig om ze onbeveiligd te mailen, je hebt ook geen idee bij wie ze terecht komen en de vraag mag ook wel even gesteld worden of die dossiers uberhaupt bewaard en gedeeld hadden mogen worden).
24-04-2019, 11:20 door Anoniem
Door Anoniem: Vorig jaar had ik een e-mail engineer die ook security minded was.
TLS1.2 of hoger zonder rc4, (dus ssl3, tls1, tls1.1 werden geblokkeerd maar OOK alle cypers onder de 128bit.
dus dan had je of supergoede encryptie met goede cyphers, maar omdat alle windows exchange servers die niet ondersteunen moest ook plain text ondersteund worden.
dus slechte encryptie is schijnbaar erger dan geen encryptie... DOH!

TLS 1.2 is al meer dan 10 jaar oud, ik vraag mij dan altijd af wat er nog meer mist aan een server die dit niet ondersteund...

Er zullen ongetwijfeld mensen zijn die er van gruwen, maar mijn uitgaande mailserver dwingt gewoon STARTTLS af. Anders maar geen mail versturen.
24-04-2019, 12:48 door Anoniem
Dan beter even testen bij: https://www.cdn77.com/tls-test
En dan blijkt dat security dot nl geen TLS 1.3 ondersteunt,
of de server ondersteunt het niet of de CDN.
Secure Renegotiation Yes
Secure Client-Initiated Renegotiation No
Insecure Client-Initiated Renegotiation No
OCSP Stampling No
Strict Transport Security (HSTS) Yes
Session Resumption (Session IDs) Yes
Session Resumption (Session Tickets) Yes
Deflate Compression No
Downgrade Attack Prevention (TLS_FALLBACK_SCSV) Yes
Supports Insecure Ciphers No
Supports Weak Ciphers No
Common DH Prime No
Forward Secrecy Yes
BREACH Vulnerability No
CRIME Vulnerability No
OpenSSL CCS Injection No
Heartbleed Vulnerability No
POODLE Vulnerability No
BEAST Vulnerability Yes
FREAK Vulnerability No
LOGJAM Vulnerability No

Zou hier graag onze vriend Bitwiper even over horen?

luntrus
24-04-2019, 13:53 door [Account Verwijderd]
Door Anoniem:
Door Anoniem: Vorig jaar had ik een e-mail engineer die ook security minded was.
TLS1.2 of hoger zonder rc4, (dus ssl3, tls1, tls1.1 werden geblokkeerd maar OOK alle cypers onder de 128bit.
dus dan had je of supergoede encryptie met goede cyphers, maar omdat alle windows exchange servers die niet ondersteunen moest ook plain text ondersteund worden.
dus slechte encryptie is schijnbaar erger dan geen encryptie... DOH!

TLS 1.2 is al meer dan 10 jaar oud, ik vraag mij dan altijd af wat er nog meer mist aan een server die dit niet ondersteund...

Er zullen ongetwijfeld mensen zijn die er van gruwen, maar mijn uitgaande mailserver dwingt gewoon STARTTLS af. Anders maar geen mail versturen.

Eens! Hoewel ik bij de organisatie waar ik voor werk geen TLS bij email (nog) blokkeer, heb ik alle partijen aangeschreven een TLS (beter) in te richten. Alle belangrijke hebben dit gelukkig ook gedaan. Mailflow zonder TLS is daardoor behoorlijk omlaag gegaan.

Wellicht wordt het tijd om te overwegen om uitgaand altijd TLS af te dwingen. Eens onderzoeken wat de impact daar van zou zijn :)
24-04-2019, 13:56 door Briolet
Ik heb voor de aardigheid eens in het log van mijn mailserver gekeken. tls1.1 werd al jaren niet gebruikt. Het was of 1.0 of 1.2.

Tot mijn verbazing vond ik nog een TLS 1.0 connectie:
2019-03-28T11:40:15+01:00 postfix/smtpd[22483]: connect from mail04.megamail.nl[46.44.132.93]
2019-03-28T11:40:15+01:00 postfix/smtpd[22483]: Anonymous TLS connection established from mail04.megamail.nl[46.44.132.93]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
2019-03-28T11:40:15+01:00 postfix/policy-spf[22559]: Policy action=PREPEND Received-SPF: pass (megamail.nl.abnamro.com: Sender is authorized to use '3e6181798a8g0421c28789a849dc422f@megamail.nl.abnamro.com' in 'mfrom' identity (mechanism 'include:_spf.megamail.nl' matched)) receiver=GedeeldeData; identity=mailfrom; envelope-from="3e6181798a8g0421c28789a849dc422f@megamail.nl.abnamro.com"; helo=megamail.nl.abnamro.com; client-ip=46.44.132.93

Dit is een mailing van mijn bank. Ik dacht dat banken voorop zouden lopen met implementatie van betere standaarden. Ik zal ze hier eens over aanspreken. Ze besteden deze mailing uit aan megamail, maar dan nog kunnen ze eisen stellen bij het uitbesteden.

De andere v1.0 connectie was de mail cliënt op mijn oude Mac met El Capitan. Op die mac kan ik geen nieuwer systeem zetten. Ik kan natuurlijk wel een third-party mail client gebruiken.

Wel heel veel v1.0 en 1.1 connecties met allereij cyphers van bedrijven zoals shodan, die mailservers aan het testen zijn.
24-04-2019, 16:55 door Anoniem
Er zullen ongetwijfeld mensen zijn die er van gruwen, maar mijn uitgaande mailserver dwingt gewoon STARTTLS af.
Natuurlijk gruw ik daarvan: STARTTLS kan in principe worden onderschept en gestript, zodat het niet bij de mailserver aankomt. Ook als de mailserver geen SSL/TLS ondersteunt, krijg je zonder toeten of blazen een onbeveiligde verbinding.

Wil je alleen een beveiligde verbinding accepteren die aan bepaalde TLS/cipher eisen voldoet, dan is het veiliger om (indien mogelijk) de e-mailsettings in je mailclient zó in te stellen dat je mailclient alleen een veilige verbinding accepteert die aan jouw eisen voldoet. (of anders worden er geen wachtwoord of mails uitgewisseld en krijg je een foutmelding)

https://en.wikipedia.org/wiki/Opportunistic_TLS
24-04-2019, 21:47 door karma4
Door Anoniem: Zou de AP zich niet veel meer bezig moeten houden met de rechtmatigheid van het transporteren van de persoonsgegevens over deze al dan niet voldoende beveiligde verbindingen?
....
Het is een bericht van het NCSC, die zijn beter voor technische vragen dan het AP.
Ik heb ook de indruk dat het AP op het gebied van de GDPR faalt en daarvoor in de plaats andere zaken als "fantastisch van het AP" naar buiten brengt.
25-04-2019, 08:58 door Anoniem
Door karma4:
Door Anoniem: Zou de AP zich niet veel meer bezig moeten houden met de rechtmatigheid van het transporteren van de persoonsgegevens over deze al dan niet voldoende beveiligde verbindingen?
....
Het is een bericht van het NCSC, die zijn beter voor technische vragen dan het AP.
Ik heb ook de indruk dat het AP op het gebied van de GDPR faalt en daarvoor in de plaats andere zaken als "fantastisch van het AP" naar buiten brengt.

Ik weet niet of de AP faalt, ik denk wel schoenmaker houd je bij je leest.

Als iedereen het werk van een ander gaat doen dan doet niemand het werk dat hij eigenlijk moet doen. NCSC kan prima zelf zijn werk doen, dus laat de AP dan ook doen waar ze voor opgesteld zijn. En dat is beoordelen van de doelbinding en de reachtmatigheid, niet van de kwaliteit van de beveiliging.
25-04-2019, 11:43 door Anoniem
Door Anoniem: Ik weet niet of de AP faalt, ik denk wel schoenmaker houd je bij je leest.

Als iedereen het werk van een ander gaat doen dan doet niemand het werk dat hij eigenlijk moet doen. NCSC kan prima zelf zijn werk doen, dus laat de AP dan ook doen waar ze voor opgesteld zijn. En dat is beoordelen van de doelbinding en de reachtmatigheid, niet van de kwaliteit van de beveiliging.
Als je in de AVG kijkt naar wat de taken en bevoegdheden van de toezichthouder zijn dan zal je zien dat die heel wat breder zijn dan jij nu stelt. En daar kunnen zeker toegepaste technische maatregelen bij komen kijken omdat AP niet alleen toezicht houdt op de AVG maar ook allerlei andere privacygerelateerde wetten, verordeningen, maatregelen van bestuur en zelfs gedragcodes die allerlei branches voor zichzelf opstellen, inclusief de technische eisen en maatregelen die in dat alles genoemd kunnen worden.

Verder is het NCSC geen toezichthouder op wat dan ook maar een kenniscentrum en informatieknooppunt. De AP gaat hier niet op de stoel van de NCSC zitten maar wijst erop dat negeren van het advies dat nog steeds van het NCSC afkomstig is een schending van de AVG kan opleveren. Het zou juist het NCSC zijn dat zich niet bij zijn leest houdt als dat deze waarschuwing zou geven.

Of moet de waarschuwing maar helemaal niet gegeven worden en is het volgens jou zo dat een gegevenslek dat veroorzaakt is door toepassing van kwetsbare configuraties niet iets is waar het AP iets over te zeggen heeft? Ik zie niet in hoe AP adequaat toezicht kan houden als na de conclusie dat een lek door een slechte TLS-configuratie is ontstaan die conclusie niet gebruikt mag worden en een duidelijk nalatige organisatie daardoor vrijuit gaat. Hoe zie jij dat?
25-04-2019, 15:32 door Anoniem
Door Briolet: Ik heb voor de aardigheid eens in het log van mijn mailserver gekeken. tls1.1 werd al jaren niet gebruikt. Het was of 1.0 of 1.2.

Tot mijn verbazing vond ik nog een TLS 1.0 connectie:
2019-03-28T11:40:15+01:00 postfix/smtpd[22483]: connect from mail04.megamail.nl[46.44.132.93]
2019-03-28T11:40:15+01:00 postfix/smtpd[22483]: Anonymous TLS connection established from mail04.megamail.nl[46.44.132.93]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
2019-03-28T11:40:15+01:00 postfix/policy-spf[22559]: Policy action=PREPEND Received-SPF: pass (megamail.nl.abnamro.com: Sender is authorized to use '3e6181798a8g0421c28789a849dc422f@megamail.nl.abnamro.com' in 'mfrom' identity (mechanism 'include:_spf.megamail.nl' matched)) receiver=GedeeldeData; identity=mailfrom; envelope-from="3e6181798a8g0421c28789a849dc422f@megamail.nl.abnamro.com"; helo=megamail.nl.abnamro.com; client-ip=46.44.132.93

Dit is een mailing van mijn bank. Ik dacht dat banken voorop zouden lopen met implementatie van betere standaarden. Ik zal ze hier eens over aanspreken. Ze besteden deze mailing uit aan megamail, maar dan nog kunnen ze eisen stellen bij het uitbesteden.

De andere v1.0 connectie was de mail cliënt op mijn oude Mac met El Capitan. Op die mac kan ik geen nieuwer systeem zetten. Ik kan natuurlijk wel een third-party mail client gebruiken.

Wel heel veel v1.0 en 1.1 connecties met allereij cyphers van bedrijven zoals shodan, die mailservers aan het testen zijn.
Er mankeert nog veel meer aan de mailservers die jij hier noemt, o.a. verlopen certificaat.
Bagger. Lijkt me geen reclame voor (de mailveiligheid van) abnamro.
26-04-2019, 15:08 door karma4
Door Anoniem: ….
Verder is het NCSC geen toezichthouder op wat dan ook maar een kenniscentrum en informatieknooppunt. De AP gaat hier niet op de stoel van de NCSC zitten maar wijst erop dat negeren van het advies dat nog steeds van het NCSC afkomstig is een schending van de AVG kan opleveren. Het zou juist het NCSC zijn dat zich niet bij zijn leest houdt als dat deze waarschuwing zou geven.
….
Het is het NCSC dat al centraal meldpunt voor incidenten genomen is.
https://www.ncsc.nl/actueel/nieuwsberichten/wet-beveiliging-netwerk--en-informatiesystemen-per-9-november-van-kracht.html Het is de DNB die toeziet op financials inclusief de ICT invulling.

Het AP heeft he ICT toezicht NSIS II naar zich toe gehaald. De getoonde acties geven een vermengd beeld van Privacy toezicht met die andere taak. Zoiets klopt gewoon niet, toch gebeurt het. Daarmee geef ik het oordeel dat het AP faalt.
Ze gaan bewust of uit onkunde te vaak op andermans stoel zitten met veronderstellingen over ICT veiligheid welke niet kloppen. Dat is jammer wat zoiets gaat uiteindelijk tegenwerken.
27-04-2019, 17:13 door Anoniem
Door karma4: Het is het NCSC dat al centraal meldpunt voor incidenten genomen is.
Ja, en die melden dat het risico er is. AP meldt dat het een schending van de AVG kan opleveren. Ik bedooelde dat de laatste melding niet aan NCSC is om te maken, evenmin als de eerste aan AP is om te maken. En daar houden ze zich keurig aan.
Het is de DNB die toeziet op financials inclusief de ICT invulling.
Het is niet zo dat de ene toezichthouder de andere uitsluit. Als financiële instellingen de AVG overtreden valt dat onder het toezicht van de AP zonder dat dat met het toezicht van DNB conflicteert. Het is niet voor niets dat je in wetten ziet staan dat toezichthouders ook met elkaar samen horen te werken. Er zit gewoon overlap in.
Het AP heeft he ICT toezicht NSIS II naar zich toe gehaald.
Ze zijn toezichthouder erop, zoals voorganger CBP dat ook al was en zoals bijvoorbeeld de Belgische privacyautoriteit daar toezichthouder erop is. Jij lijkt bij allerlei bevoegdheden die het AP heeft te denken dat ze die op eigen houtje naar zich toe getrokken hebben. Dat kunnen ze helemaal niet, dat moet verankerd zijn in regelgeving waar regering en parlement over gaan voor ze een juridische basis hebben om toezicht te houden.

Ze zijn niet, zoals jij hardnekkig blijft beweren, behalve handhaver ook wetgever en rechter. De wetgever zit gewoon waar die in Nederland hoort te zitten en de rechterlijke macht is niet afgeschaft. Het AP heeft geen staatsgreep gepleegd. Wat er mis gaat in het plaatje is dat jouw beeld van wat een toezichthouder hoort te doen niet strookt met de werkelijkheid. De verklaring daarvoor is heel simpel: jij richt niet in je eentje het land in, niemand doet dat in zijn eentje, en hoe het werkt is tot stand gekomen in een lang proces van invloeden van allerlei mensen. Dus werkt het niet precies zoals wie dan ook zou bedenken dat het werkt als die het in zijn eentje voor het zeggen had. Dus ook niet precies zoals jij vindt dat het moet.
07-05-2019, 14:00 door Anoniem
Door Anoniem: Zou de AP zich niet veel meer bezig moeten houden met de rechtmatigheid van het transporteren van de persoonsgegevens over deze al dan niet voldoende beveiligde verbindingen?

Of is het minder erg als data gelekt wordt over een veilige verbinding?

(Denkend aan de dossiers die kennelijk bij SAVE via mail verstuurd worden: het is niet alleen onveilig om ze onbeveiligd te mailen, je hebt ook geen idee bij wie ze terecht komen en de vraag mag ook wel even gesteld worden of die dossiers uberhaupt bewaard en gedeeld hadden mogen worden).

Lekken is 1-op-1 gekoppeld aan veiligheid en niet aan rechtmatigheid. Als een verwerking niet rechtmatig is (lees: geen grondslag en specifiek doel, niet noodzakelijk, proportioneel en subsidiair) maar wel op een veilige manier wordt getransporteerd, dan is er geen sprake van een datalek, maar van onrechtmatig handelen. Ook niet goed, maar wel iets heel anders.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.