In de Verenigde Staten heeft de National Security Agency (NSA) recentelijk een Cyber Advisory gepubliceerd over TLSI (Transport Layer Security Inspection). Deze advisory definieert TLSI en legt een aantal risico’s en bijbehorende uitdagingen uit. In dit artikel willen we daarom wat dieper ingaan op de encryptie en de-encryptie die hierbij komt kijken en welke uitdagingen dit met zich mee kan brengen.
Wat is TLSI?
De NSA definieert TSLI als een beveiligingsproces waarmee inkomend verkeer met een proxy device kan worden ontsleuteld (decrypted), geïnspecteerd en middels encryptie opnieuw kan worden versleuteld.
Encryptie is tegenwoordig overal
Vrijwel elk bedrijf of internetdienst heeft tegenwoordig encryptie ingeschakeld. Dit betekent dat al het verkeer tussen de eindgebruiker en de internetdienst versleuteld – encrypted – is. Hierdoor is het verkeer niet meer te lezen door derden die deze communicatiestroom al dan wel of niet opzettelijk onderscheppen.
Cybercriminelen maken ‘handig’ gebruik van encryptie
Nu dient encryptie in essentie een goed doel; het garandeert in zekere mate dat de degene met wie je zaken doet ook daadwerkelijk diegene is. Daarnaast helpt encryptie te voorkomen dat gegevens door anderen gelezen kunnen worden. Dit is voor veel soorten van communicatie erg fijn, denk bijvoorbeeld aan financiële of medische gegevens maar ook intellectueel eigendom.
Echter, encryptie kan ook gebruikt worden om ‘ongewenste’ data – virussen, cryptolockers etc. – ongezien te transporteren. Dit is dan ook iets waar cybercriminelen graag gebruik van maken. En zonder de juiste maatregelen zal deze ‘gevaarlijke’ data zonder problemen bij eindgebruikers of servers terechtkomen.
Voor het afdwingen van een goed securitybeleid is zichtbaarheid uitermate belangrijk. Wat je immers niet ziet, daar kun je ook niet op acteren. Deze zichtbaarheid is dus duidelijk iets wat encryptie ons ontneemt. Gelukkig kunnen we hier met een juiste inrichting van de infrastructuur, en met behulp van de juiste tools en technieken zoals TLSI, actie op ondernemen.
Public en private key: wat is het verschil
Om de mogelijkheden goed te begrijpen, moeten we een klein beetje de techniek in. De hedendaagse encryptie is veelal gebaseerd op een asynchrone versleuteling. Dit wil zeggen dat er twee zogenaamde encryptiesleutels zijn, de ‘publieke’ sleutel – public key – en de ‘privé sleutel – private key.
Gegevens worden met een publieke sleutel encrypted en kunnen alleen met de privésleutel weer decrypted worden, de gegevens worden dan weer leesbaar gemaakt. De privésleutel geef je dan ook nooit uit handen.
Een voorbeeld. Stel, iemand wil met mij communiceren. Diegene krijgt dan van mij, mijn publieke sleutel. Hiermee kan diegene de gegevens encrypten en vervolgens opsturen. Deze gegevens kunnen nu alleen nog maar ontsleuteld worden met mijn privésleutel, welke alleen ik in mijn bezit heb.
Dit resulteert in twee mogelijke scenario’s, waarin we willen ingrijpen om verkeer zichtbaar te maken om zodoende risico’s te detecteren en hierop te acteren:
- Het scenario waar we in bezit zijn van de privé sleutel
- Het scenario waar we niet in het bezit zijn van de privé sleutel
Het scenario waar we in bezit zijn van de privésleutel
Laten we beginnen met het meest eenvoudige scenario, daar waar we in het bezit zijn van de privésleutel. Hierbij kan gedacht worden aan een interne web- en/of mailserver, welke gebruik maakt van encryptie.
Normaal gesproken kunnen de gegevens pas weer gelezen worden op de server zelf, deze heeft immers de privésleutel. Dit betekent dat in het geval van ‘gevaarlijke’ data, deze pas gedetecteerd kan worden op de server zelf.
Omdat we in dit scenario zelf beschikken over de privésleutel kunnen we deze sleutel ook eenvoudig plaatsen op proxy device zoals een Next Generation Firewall (NGFW), waarmee dit apparaat ook in staat is om het verkeer te controleren (TLSI) en ‘gevaarlijke’ data te detecteren en hierop actie te ondernemen. Op deze manier kan een mogelijke besmetting vermeden worden voordat het de server bereikt.
Het scenario waar we niet in het bezit zijn van de privésleutel
Het tweede scenario is wat lastiger, immers hier beschikken we niet over de privésleutel. Een mogelijk voorbeeld; een gebruiker die Facebook of Dropbox bezoekt. In dit geval zijn de gegevens pas te lezen, en ‘gevaarlijke’ data pas te detecteren, op het moment dat deze op het apparaat van de eindgebruiker staan.
Ook deze data kunnen we eerder onderscheppen door gebruik te maken van een NGFW. Echter in dit scenario zal de gebruiker een verbinding opzetten met de firewall, en de firewall een verbinding met de gevraagde webserver. Er zijn dus eigenlijk twee versleutelde verbindingen, met de firewall in het midden. Doordat de firewall hier in het midden staat, kan deze al het verkeer controleren en hier eventueel actie op ondernemen.
Conclusie: Encryptie behoort een onderdeel te zijn van elk securitybeleid
Om een securitybeleid goed te kunnen uitvoeren is zichtbaarheid uitermate belangrijk. Naast de positieve dingen die encryptie doet, beperkt het helaas ook de zichtbaarheid.
Gelukkig zijn er methoden om deze zichtbaarheid gedeeltelijk of volledig terug te winnen en hiermee dus ook een betere beveiliging te realiseren. Encryptie, en hoe hier mee om te gaan, behoort dan ook onderdeel te zijn van elk securitybeleid.