Gisteren (red. 23-04-2019) publiceerde het NCSC een nieuwe richtlijn ten aanzien het gebruik van het TLS protocol. Sommige oude protocollen worden niet meer als veilig beschouwd en de best practice is dan ook om webservers te voorzien van veilige versies van de protocollen. Vandaag meldde de Autoriteit Persoonsgegevens dat het updaten van protocollen niet zomaar een vrijblijvend advies is, nee, meldt de AP, als je niet updatet, zou je in beginsel non-compliant kunnen zijn met de #AVG.

Laat ik voorop stellen dat ik een groot voorstander ben van bijwerken van technologie naar de stand van de techniek. TLS 1.3 moet het dus worden, want dan is een website veilig. Maar, uhh, helaas, ook de stand van techniek is al verouderd, er blijken ook al kwetsbaarheden in TLS1.3 te zitten…

Maar los van dit aardigheidje, updaten blijft noodzakelijk. Maar ik verbaas me wel over de waarschuwing van onze AP. Alsof je door niet te updaten in beginsel een groter risico op datalekken loopt en je daarmee dus niet voldoet aan de wetgeving: “…proactief aan de slag te gaan en deze op termijn aan te passen naar een beveiligingsniveau ‘voldoende’ of ‘goed’. Anders lopen organisaties het risico dat zij niet voldoen aan artikel 24 en 32 van de AVG.”

Ik durf het aan om dit te bestempelen als#FUD: Fear, Uncertainty, Doubt.

Ten eerste zijn er veel meer oorzaken voor datalekken dan een minder dan actuele TLS-configuratie. Denk aan mensen die te veel autorisaties hebben, rollen met te veel rechten, mensen met autorisaties die ze niet nodig hebben, onbeveiligde databases (zoals de vele MongoDB’s zonder beveiliging), kritische accounts zonder MFA, persoonsgegevens die via de mail worden verzonden en zo kunnen we nog wel even doorgaan.

Ten tweede zijn mij geen security-incidenten of datalekken bekend die zijn ontstaan door misbruik van kwetsbaarheden in TLS. Toegegeven, er zijn theoretisch heel veel kwetsbaarheden en mogelijke aanvallen bekend, maar in de praktijk komen incidenten niet voor. Er zijn wel incidenten geweest met misbruik van certificaten (denk aan het Diginotar-drama), maar dat waren geen incidenten die te wijten waren aan een onvoldoende veilige SSL-/TLS-configuratie.

Elk certificaat is vanuit de optiek van vertrouwelijkheid beter dan geen certificaat.

Ten aanzien van authenticiteit durf ik dat alleen niet te stellen (maar daar zegt de AP niets over).

Ten derde: een veilige TLS-configuratie zegt niets over het niveau van beveiliging van een website. Zoals ik een paar jaar geleden zelf in Computable schreef, zegt een ‘veilig’ certificaat alleen dat er aandacht is voor het aspect ‘certificaat’. Er is zoveel meer te beveiligen dan een certificaat:Ten vierde: het gebruik van certificaten is de afgelopen jaren sterk toegenomen. Maar dat kwam niet door de toenemende aandacht voor #privacy, die toename werd veroorzaaakt doordat Google websites zonder certificaat een lagere ranking in de zoekresultaten geeft en mogelijk gemaakt doordat letsencrypt de certificaten en het beheer ervan betaalbaar (namelijk gratis) heeft gemaakt. Veilige certificaten kunnen gewoon gratis zijn. En dure certificaten hoef je eigenlijk niet meer te gebruiken.

Er is niets mis met een toezichthouder die adviseert over security-aspecten, maar de FUD-bangmakerij van vandaag helpt niet. We hebben vooral behoefte aan een toezichthouder die inhoudelijk oordelen velt. Niet aan een toezichthouder die alleen maar formele beoordelingen uitvoert (hebt u wel een PO, voert u wel (D)PIA’s uit, meldt u incidenten wel binnen 72 uur, is uw TLS-configuratie wel veilig) en die alleen wil dat we het #BSN geheim houden. Nee, we moeten een inhoudelijke beoordeling van misbruik van bijvoorbeeld dat BSN aangepakt zien. En ten aanzien van die TLS configuratie zou ik zeggen: updaten. Als je server en provider dat toestaan.

Dus geen FUD, maar daden.

PS: mijn #freethebsn website is nog steeds toegankelijk op www.freethebsn.nl. Met een letsencrypt certificaat.

Bron: Blog LinkedIn André Koot