Cryptografie juist en doeltreffend gebruiken in overeenstemming met wet- en regelgeving toepassen om de vertrouwelijkheid, authenticiteit, onweerlegbaarheid en/of integriteit van informatie te beschermen. Dit beleid is van toepassing voor alle medewerkers, leveranciers, partners en alle ander personeel of entiteiten in eender welke relatie met Vlaamse Overheid.
|
DOELSTELLINGEN
|
Implementatiemaatregel
Het gebruik van versleuteling MOET gebaseerd zijn op het risico van ongeoorloofde toegang en de informatieclassificatie van de te beschermen gegevens of informatiesystemen.
Cryptografische diensten MOETEN formeel worden goedgekeurd en MOETEN voldoen aan relevante regelgevende en wettelijke vereisten.
Gebruikers MOGEN NIET enige andere vorm van versleuteling gebruiken buiten de formeel goedgekeurde en geïmplementeerde encryptiemechanismen.
Versleuteling MOET gebeuren volgens common practices, crypto-algoritmes en protocollen, indien een encryptiestandaard niet langer als veilig wordt bevonden MOETEN na risicoanalyse de nodige mitigerende maatregelen genomen worden.
Data in Motion zijn gegevens die wordt verzonden of ontvangen over een netwerk. Dit kan zijn tussen twee computers, tussen een computer en een server, of tussen een computer en een mobiel apparaat. Data in motion is het meest kwetsbare type data, omdat het zich in transit bevindt en dus gemakkelijk kan worden onderschept door een aanvaller.
Symmetrische versleuteling
Bepaling van de sleutelsterkte
De sleutel tot het kiezen van een veilig symmetrisch algoritme zit vervat in:
De grootte/lengte van de cryptografische sleutel
De grootte van de cryptografische blokken
De gekozen encryptie blok modus (CBC/ECB/CTR/GCM/...)
Implementatiemaatregel
De versleuteling zoals aangegeven in onderstaande tabel MOET worden toegepast op basis van de informatieclassificatie van de te beschermen gegevens.
Als vuistregel voor het kiezen van een sterk symmetrisch encryptie algoritme kan bovenstaande tabel gebruikt worden. Het meest gebruikte algoritme vandaag en ook de de facto standaard sinds een aantal jaar is de Advanced Encryption Standard (AES). Dit is de opvolger van de Data Encryptie Standaard (DES).
Implementatiemaatregel
Het gebruik van het Advanced Encryption Standard (AES) algoritme is AANGEWEZEN.
Volgens NIST is AES-128 bit versleuteling de minimale norm om sensitieve data te gaan beveiligen tot en met 2030.
Implementatiemaatregel
Volgende nog frequent voorkomende symmetrische algoritmes worden niet meer veilig geacht en ZOUDEN NIET mogen worden gebruikt:
DES (Data Encryptie Standaard)
Dateert van 1977 en is gebaseerd op het Lucifer algoritme van IBM.
DES werd reeds gekraakt in 1997.
Het bestaat uit cijferblokken van 64 bit die versleuteld zijn met een 56 bit sleutel.
3DES of TDEA (Transparant Data Encryptie Algoritme)
Hierbij worden 3 afzonderlijke DES-bewerkingen achtereenvolgens op de te coderen data losgelaten. Dat kan op twee manieren: met 2 sleutels van 56 bits waarbij de eerste en derde bewerking met dezelfde sleutel worden uitgevoerd, of met 3 onafhankelijke sleutels van 56 bits.
3DES is tot vandaag nog niet gebroken maar NIST raad aan deze niet meer te gaan gebruiken na 2023, mede omdat de zwakheid van DES, nl. te kleine sleutel en cijferblokken, nog door 3DES gebruikt worden.
3DES wordt voornamelijk nog gebruikt in crypto hardware modules en voor het opzetten van een beveiligde tunnel (VPN).
De aanbeveling in dit document bestaat eruit om geen gebruik meer te maken van 3DES en als alternatief AES of CHACHA20 te gebruiken.
RC4
Is een stroomcijfer symmetrisch encryptie protocol dat vooral gebruikt werd om SSL/TLS applicaties te beveiligen. Ook werd het gebruikt in het populaire WEP-protocol om Wifi communicaties te gaan versleutelen.
WEP (en daarmee ook RC4) werd gekraakt in 2006 en aanbieders van browsers zoals Chrome, Firefox en Microsoft ondersteunen het niet meer.
RC4 wordt in sommige toepassingen en software nog steeds aangeboden en daarom dient vermeld te worden RC4 niet meer te gebruiken.
Asymmetrische versleuteling
Bepaling van de sleutelsterkte
Het security aspect van asymmetrische versleuteling zit hem net zoals bij symmetrische versleuteling in de lengte van de sleutel, maar ook met specifieke focus op:
Sleutel uitwisselingsprotocol
Hashing protocol
Authenticatie
Grootte/lengte van de encryptie sleutel
Implementatiemaatregel
De versleuteling zoals aangegeven in onderstaande tabel MOET worden toegepast op basis van de informatieclassificatie van de te beschermen gegevens.
Alhoewel NIST voor symmetrische encryptie een sleutellengte aanraadt van 128 bit lang in NIST SP 800-57 rev2, wordt er voor asymmetrische encryptie schema’s nog altijd 2048 bit RSA/DSA naar voor geschoven als een veilige sleutellengte.
Een 2048 bit RSA/DSA sleutel heeft dan ook maar de dezelfde encryptie sterkte als een symmetrische sleutel van 112 bit, wat tegenstrijdig is met wat er aangeraden wordt door NIST voor symmetrische sleutellengtes.
Afhankelijk van de informatieclassificatie en de toekomstbestendigheid van de te beschermen data en de vereiste performantie, dient er dan ook vanuit een security architectuur gezichtspunt een weloverwogen beslissing genomen te worden als een RSA-sleutel groter dan 2048 bit aangewezen is.
HTTP Encryptie
HTTP is een protocol dat communicatie tussen verschillende systemen mogelijk maakt. Meestal wordt het gebruikt voor het overbrengen van gegevens van een webserver naar een browser om webpagina's te bekijken maar het kan ook gebruikt worden als webservice (SOAP/REST/XML-RPC) om interactie tussen 2 machines over het netwerk te bewerkstelligen.
Het probleem bij HTTP is dat standaard, gegevens niet worden gecodeerd en dat deze door derden kunnen worden onderschept om gegevens te verzamelen die worden doorgegeven tussen de twee systemen.
Om dit te vermijden kan er gebruik gemaakt worden van HTTPS waarbij de “S” staat voor Secured.
Als een site gebruik maakt van HTTPS is dit in het URL-venster van een browser zoals Chrome/IE/Safari/... zichtbaar door een hangslot en HTTPS voor de des betreffende URL.
SSL/TLS Protocol
Er zijn zes protocollen in de SSL/TLS-familie: SSL v2, SSL v3, TLS 1.0, TLS 1.1, TLS 1.2 en TLS 1.3
TLS 1.2 is vrijgeven in 2008 en zorgt ervoor dat SHA-2 hashing en AES-encryptie kan gebruikt worden. Het laat ook gebruik van geauthenticeerde encryptie modi toe zoals GCM (Gallois Counter Mode)
TLS 1.3 is een vrij recent protocol en dateert van begin 2018. Het grote voordeel van TLS 1.3 is dat het ten opzichte van TLS 1.1/1.2 veel sneller is. Ook worden de facto oude “gebroken” encryptie protocollen (RC4/MD5/SHA-1/DH groepen 1/2/5/14) niet meer aangeboden t.o.v. TLS 1.2
Implementatiemaatregel
De volgende verouderde protocollen MOGEN NIET worden gebruikt en MOETEN worden gedeactiveerd:
SSL v2 is onveilig. Deze protocolversie is zo slecht dat het gebruikt kan worden om RSA-sleutels en sites met dezelfde naam aan te vallen, zelfs als ze op totaal verschillende servers staan (de DROWN-aanval).
SSL v3 is onveilig wanneer het gebruikt wordt met HTTP (de SSLv3 POODLE aanval) en zwak wanneer het gebruikt wordt met andere protocollen.
TLS 1.0 en TLS 1.1 zijn eveneens verouderde protocollen. De grootste zwakte (BEAST) is verholpen in moderne browsers, maar andere problemen blijven bestaan. TLS 1.0 is afgeschreven door PCI DSS. Op dezelfde manier zijn TLS 1.0 en TLS 1.1 in januari 2020 afgeschreven door moderne browsers.
Implementatiemaatregel
De volgende protocollen MOETEN worden gebruikt, volgens specificaties in onderstaande tabel:
TLS 1.2 en TLS 1.3 beschouwen we beide als veilig, het gebruik van TLS 1.3 is aangeraden en MOET waar technisch mogelijk worden ondersteunt.
Cipher suites
Om de overdracht van gegevens te beveiligen, gebruikt TLS/ SSL één of meer cipher suites. Een cipher suite is een combinatie van algoritmen voor authenticatie, codering en Message Authentication Code (MAC). Ze worden gebruikt tijdens het onderhandelen over beveiligingsinstellingen voor een TLS/ SSL-verbinding en voor de overdracht van gegevens.
Het is de server die aan de client de mogelijke cipher suites gaat aanbieden en afhankelijk van de browser/OS versie waarvan de client gebruikt maakt, wordt steeds de zo hoog mogelijkste cipher suite aangeboden die haalbaar is voor de client.
Een cipher suite ziet er als volgt uit:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS: HTTPS-protocol in gebruik
ECDHE: Sleutel uitwisselingsalgoritme – Asymmetrisch/Publiek aspect
RSA: Authenticatie (duidt het type certificaat aan) - Asymmetrisch/Publiek aspect
AES_256_GCM: Private AES 256 bit sleutel met 128 bit GCM geauthenticeerd blok cijfer.
SHA384: Hash algoritme gebruikt voor MAC (Message Authentication Code) authenticatie.
Implementatiemaatregel
Volgende verouderde cryptografische primitieven ZOUDEN NIET mogen worden gebruikt:
Anonieme Diffie-Hellman (ADH) suites bieden geen authenticatie.
NULL cipher suites bieden geen versleuteling.
Export cipher suites zijn onveilig als ze onderhandeld worden in een verbinding, maar ze kunnen ook gebruikt worden tegen een server die sterkere suites prefereert (de FREAK aanval).
Suites met zwakke cijfers (112 bits of minder) gebruiken versleuteling die gemakkelijk kan worden gebroken en zijn dus onveilig.
RC4 is onveilig.
64-bits blokcijfers (3DES / DES / RC2 / IDEA) zijn zwak.
Cijfersuites met RSA-sleuteluitwisseling zijn zwak, bijv. TLS_RSA
Implementatiemaatregel
Het gebruik van volgende Cipher Suites is AANGEWEZEN:
AEAD (Authenticated Encryption with Associated Data)-suites - CHACHA20_POLY1305, ACM en CCM.
PFS (Perfect Forward Secrecy)-sleutels - ECDHE_RSA, ECDHE_ECDSA, DHE_RSA, DHE_DSS, CECPQ1 en alle TLS 1.3-sleutels.
Implementatiemaatregel
Concreet MOET een Cipher Suite gebruikt worden met status ‘recommended’ in Transport Layer Security (TLS) Parameters (iana.org)
Een aantal hulpmiddelen die gebruikt kunnen worden om beveiligingsstatus van Cipher Suites te raadplegen Ciphersuite Info en Knowledge Base (scanigma.com)
PFS (Perfect Forward Secrecy)
Perfect Forward Secrecy is een protocol dat voorkomt dat met het verkrijgen van de private sleutel informatie die in eerste instantie versleuteld is verzonden, alsnog ontcijferd kan worden. Dit omdat er gebruik wordt gemaakt van unieke sessie sleutels.
Wanneer dit protocol gebruikt wordt, wordt er een tijdelijke sleutel aangemaakt voor elke verbinding. Als beide partijen de sessie sleutel vernietigen na afloop van de sessie, is deze later niet meer met de private sleutel te achterhalen. Dit zou betekenen dat iemand die de server zou hacken iedere sessie apart zou moeten ontcijferen.
TLS ondersteunt twee soorten algoritmes waarmee Perfect Forward Secrecy gebruikt kan worden: het standaard Diffie-Hellman algoritme en de speciaal voor het gebruik van Elliptic Curve cryptografie hiervoor aangepaste versie, ECDHE.
Nadeel van PFS is dat het niet werkt met RSA en dat het merkbaar langzamer werkt dan andere soorten encryptie. Door het combineren met ECDHE wordt dit snelheidsnadeel bijna te niet gedaan en is het enorme verbetering ten opzichte van het standaard DHE-algoritme.
Implementatiemaatregel
Het gebruik van Perfect Forward secrecy is altijd AANGEWEZEN.
Implementatiemaatregel
Vanaf informatieklasse 3 (vertrouwelijkheid) MOET Perfect Forward Secrecy worden gebruikt.
HSTS (HTTP Strict Transport Security)
HSTS is een HTTP-header die de client bij een verbindingspoging vertelt dat de opgevraagde site enkel en alleen via https mag worden benaderd. Het is een beveiligingsmaatregel om man-in-the-middle (MitM) aanvallen te voorkomen, specifiek stripping aanvallen. Bij stripping aanvallen kan een MitM de client doorsturen naar een onversleutelde (http) versie van de website in plaats van de https-versie.
De HSTS-header is in het leven geroepen om ervoor te zorgen dat de browser deze header respecteert en de website alleen via https benadert. Dit helpt bij het voorkomen van beveiligingsrisico's die kunnen ontstaan door het gebruik van onversleutelde verbindingen.
Implementatiemaatregel
Een HSTS-header MOET worden toegevoegd op elke website die gebruikmaakt van https.
Zie /wiki/spaces/ISMS/pages/6487048381 voor meer informatie over het implementeren van een HSTS-header.
VPN
VPN (Virtual Private Network) wordt voornamelijk gebruikt om een beveiligde verbinding op te zetten tussen:
Een eindgebruiker en een server/gateway – Client VPN
Twee kantoorgebouwen of locaties – Site to Site VPN
Om de beveiligde verbinding tot stand te brengen worden volgende protocollen het meest courant gebruikt: IPSEC en TLS. Voor de totstandkoming van de verbinding wordt er zowel gebruik gemaakt van symmetrische als asymmetrische encryptie protocollen.
IPSEC VPN bestaat uit 2 distinctieve fases:
IKE phase 1
Deze fase maakt gebruik van een wederzijdse authenticatie van de partijen die een VPN willen opzetten. Ook wordt in deze fase gebruik gemaakt van een gedeelde sleutel (preshared key) of van een digitaal certificaatIKE phase 2
Nadat IKE fase 1 succesvol is afgerond en de VPN-tunnel beveiligd en geauthenticeerd is, staat deze fase in voor het encrypteren van data dat door de VPN-tunnel dient te gaan.
Implementatiemaatregel
De beveiliging van IKE zoals aangegeven in onderstaande tabel MOET worden toegepast op basis van de informatieclassificatie van de te beschermen gegevens.
Er bestaan 2 versies van het IKE protocol, nl IKEv1 en IKEv2, niet te verwarren met de 2 verschillende fases die binnen het protocol in gebruik zijn.
Implementatiemaatregel
Het is AANGEWEZEN om IKEv2 te gebruiken boven IKEv1.
Dit omdat het IKEv2 protocol over betere beveiligingsmogelijkheden (bvb. tegen DoS aanval op VPN-infrastructuur) beschikt dan het v1 protocol en ook performanter is.
SFTP & FTPS
Zowel SFTP (FTP over SSH) als FTPS (FTP over SSL) zijn file protocollen die gebruikt kunnen worden om bestanden veilig te versturen tussen 2 partijen over een onbeveiligd medium.
Beide protocollen hebben hun eigen toepassingsgebied (zo wordt SFTP vaak gebruikt in technische en development omgevingen, terwijl FTPS meer geschikt is voor productie en schaalbare omgevingen). Qua encryptiesterkte is er geen onderscheid, ze zijn allebei even krachtig en moeten allebei rekening houden met de informatieclassificatie toepasselijke maatregelen, afhankelijk van het type encryptie (asymmetrisch of symmetrisch).
SFTP en FTPS zijn allebei even veilig, mits ze correct worden geconfigureerd. Beide protocollen kunnen echter een beveiligingsrisico vormen als ze niet volgens de best practices geïnstalleerd worden.
FTP over SSH is ontstaan als een extra functionaliteit voor systeembeheerders om software upgrades, beveiligde transfers of development omgevingen te ondersteunen. Dit protocol gebruiken in een productie omgeving kan enkele gevaren inhouden, namelijk:
SFTP maakt vooral gebruik van publieke/private sleutels waarbij er voor elke tegenpartij een sleutel moet worden aangemaakt en gehost. Dit kan operationeel lastig zijn.
SFTP is weliswaar zeer eenvoudig op te zetten omdat het gebaseerd is op het SSH-protocol, maar een goed geconfigureerde FTPS biedt veel meer en fijnere controle.
SFTP heeft standaard een aantal opties ingeschakeld, zoals “PermitRootLogin”
Ook FTP over SSL vereist enkele configuraties om dit protocol te beveiligen tot het minimaal verwachte niveau. FTPS is namelijk niet altijd versleuteld: dit moet expliciet in de configuraties worden aangegeven anders is de verbinding nog steeds niet versleuteld. Volgende parameters moeten worden afgedwongen:
Door de FTPS te koppelen met de VO PKI (Certificate Authorities) heb je een gegarandeerde vertrouwensrelatie en kan je zelfs de extra functionaliteit zoals CRL (Certificate Revocation Listing) gebruiken. Dit geeft je de mogelijkheid om met 1 klik de certificaten in te trekken als er ergens een certificaat of sleutel als gecompromitteerd wordt beschouwd.
Voor FTPS moeten een aantal extra configuraties worden gedaan zoals:
Implicit FTP over SSL (geen mogelijkheid bieden voor onversleutelde verbindingen)
Passive FTP-versie gebruiken (het sturen van controle en datakanaal in een standaard client-server model op 1 enkele TCP-poort), zodat geen dynamische portranges moeten toegelaten worden op de firewalls.
Elke gebruiker mag alleen toegang hebben tot zijn eigen omgeving (duidelijke toegangs- en gebruikersrechten configureren)
Koppelen van FTP user management aan een Radius of Identity & Access Management platform voor centraal gebruikersbeheer.
Implementatiemaatregel
SFTP en FTPS MOETEN volgens best practices worden geconfigureerd om de beveiligingsrisico's te beperken.
SMTP over TLS
SMTP over TLS wordt gebruikt voor het beveiligen van e-mailverkeer tussen mailserver en cliënt of tussen mailservers onderling. In deze opzet wordt de Simple Mail Transfer Protocol (SMTP) verbinding versleuteld via TLS om de integriteit en vertrouwelijkheid van de verzonden informatie te waarborgen.
Implementatiemaatregel
SMTP over TLS MOET steeds worden toegepast voor de beveiliging van e-mailverkeer.
Data at Rest (DAR) zijn gegevens op gegevensdragers, te onderscheiden in 3 niveaus:
Opslagniveau:
Mobiele geheugenmedia, zoals harddisks van laptops, USB-sticks, cd-roms, tape of insteek-memorymodules maar ook in geheugens van smartphones
Vaste geheugenmedia, zoals harddisk arrays van databanken, tape en optische media
Databankniveau
Applicatieniveau
Data at Rest encryptie in deze paragraaf heeft enkel betrekking tot de bescherming van gegevens in een datacenter, private of publieke cloud omgeving. Het encrypteren van dataopslag op laptops, mobiele toestellen zoals smartphone en tablets en andere eindgebruiker toestellen wordt hier niet besproken. (Zie Beveiliging van gebruikersapparatuur)
Voor dataopslag is de primaire controle tegen ongeautoriseerde toegang versleuteling, wat helpt om de vertrouwelijkheid te waarborgen. Beschikbaarheid en integriteit worden gecontroleerd door het gebruik van redundante opslag op meerdere fysieke locaties in de publieke cloud en/of privaat datacenter.
Volgende methoden voor de encryptie van ‘data at rest’ kunnen onderscheiden worden:
Versleutelen van de volledige instance
Een methode voor het versleutelen van alle gegevens die zijn gekoppeld aan de werking en het gebruik van een virtuele machine, zoals de gegevens die in rust zijn opgeslagen op het volume, schijfinvoer en uitvoer (I/O), alle snapshots gemaakt op basis van het volume, evenals alle gegevens die worden verzonden tussen de virtuele machine en het opslagvolume.
Versleutelen van een volume
Een methode voor het versleutelen van een enkel volume op een schijf. Bepaalde onderdelen van de harde schijf zijn niet-versleuteld gelaten bij het gebruik van deze methode. Volledige schijfversleuteling moet worden gebruikt om de volledige inhoud van de schijf te coderen.
Versleutelen van bestanden of mappen
Een methode voor het versleutelen van één enkel bestand of map. Deze manier van versleutelen wordt veelal gebruikt om data te gaan versleutelen in SaaS omgevingen.
Voor het versleutelen van gestructureerde data, data die opgeslagen zit in een databank zijn er verschillende mogelijkheden. Deze hangen voornamelijk af van de capaciteiten van de applicatie en onderliggende hardware, cloud vendor (AWS vs Azure).
Versleutelen van databanken
Voor de versleuteling van databanken zijn er meerder mogelijkheden maar dit document beperkt zich tot de twee meest gebruikte methodes:
TDE (Transparante Database Encryptie)
TDE versleutelt de hele databank door een AES-coderingsalgoritme waarbij ontwikkelaars geen wijzigingen in bestaande applicaties hoeven aan te brengen.
TDE voert in realtime I/O-versleuteling en ontsleuteling van de gegevens en logbestanden uit. Nadat de databank in het geheugen is geladen, zijn de gegevens toegankelijk voor beheerders (DBA's).
Als een databank gevoelige gegevens in specifieke kolommen bevat die moeten worden beschermd tegen databankbeheerders en gecodeerd in het geheugen moeten blijven (data in use), moet het gebruik van ‘Altijd Versleutelen’ worden geëvalueerd naast TDE.
Altijd versleutelen
Is een versleutelingsmethode ontworpen om gevoelige gegevens te beschermen in een Publieke Cloud SQL database. Deze methode van databankversleuteling zorgt ervoor dat sensitieve data in de databank niet door beheerders kan geconsulteerd worden omdat deze versleuteld is in de databankkolommen zelf en de encryptie sleutels op zichzelf versleuteld worden bewaard in de databank.
Deze methode heeft als nadeel dat het niet volledig transparant is voor de bovenliggende applicatie en de functionaliteit van de databank beperkt blijft.
Een belangrijk voordeel is dat deze methode ook ‘data in use’ versleuteld, waarbij databankinstructies die zich nog in het geheugen bevinden ook versleuteld worden zodat er geen informatie kan gelekt worden uit het geheugen (door een ‘dump’ van de inhoud).
Beide methodes kunnen gecombineerd gebruikt worden op een databankinstantie en het is dan ook aangeraden de ‘altijd versleutelen’ methode enkel te gebruiken om bepaalde delen van de databank die gevoelige data bevatten af te schermen.
Voor ‘data at rest’ te versleutelen kan er enkel beroep gedaan worden op symmetrische encryptie.
Implementatiemaatregel
Encryptie van de volledige verwerkingsketen (opslagniveau, applicatieniveau, databankniveau en op gebruikersapparatuur) MOET voor volgende informatieclassificatie worden toegepast.
Informatieklasse 3 (vertrouwelijkheid) in een onbeschermde omgeving (d.w.z. veiligheidsbeheer van omgeving niet onder Vo-controle)
Vanaf informatieclassificatie 4 (vertrouwelijkheid)
Data in Use zijn gegevens in tijdelijke opslag (bvb. geheugen) die verwerkt worden door een toepassing of systeem. Data in Use is minder kwetsbaar dan data at rest of data in motion, maar het kan nog steeds worden blootgesteld aan beveiligingsrisico's, zoals systeeminbreuken via malware-aanvallen. Het is doorgaans de laatste schakel om een volledige versleuteling gedurende de gehele levenscyclus van gegevens te bekomen.
Het implementeren van Data in Use encryptie technieken kunnen duur en complex zijn en daarom niet altijd haalbaar of verantwoord om te implementeren.
Implementatiemaatregel
Vanaf informatieklasse 3 (integriteit en vertrouwelijkheid) MOET een risicoanalyse worden uitgevoerd en de nodige mitigerende maatregelen doorgevoerd om het risico op het compromitteren van ‘data in use’ in te perken.
Sleutels versus certificaten
In de context van cryptografie worden de termen "sleutels" en "certificaten" vaak gebruikt, maar ze dienen verschillende doelen en hebben verschillende kenmerken:
Cryptografische Sleutels
Doel: Cryptografische sleutels worden gebruikt voor het versleutelen en ontsleutelen van informatie. Ze kunnen ook worden gebruikt voor het ondertekenen en verifiëren van digitale handtekeningen.
Soorten: Er zijn verschillende soorten sleutels zoals publieke en private sleutels in asymmetrische cryptografie, en gedeelde sleutels in symmetrische cryptografie.
Eigenschappen: Sleutels zijn in essentie lange reeksen cijfers en letters die volgens specifieke algoritmen zijn gegenereerd.
Beheer: Sleutels moeten zorgvuldig worden beheerd en opgeslagen. Ze mogen niet zomaar worden gedeeld of verspreid.
Levensduur: Sleutels hebben vaak een beperkte levensduur en dienen periodiek te worden vernieuwd om de veiligheid te behouden.
Digitale Certificaten
Doel: Een digitaal certificaat fungeert als een soort digitaal paspoort dat de identiteit van de houder verifieert en een publieke sleutel aan die identiteit koppelt.
Soorten: Certificaten worden meestal uitgegeven door een certificeringsautoriteit (CA), die de identiteit van de certificaathouder verifieert voordat een certificaat wordt uitgegeven.
Eigenschappen: Een certificaat bevat een publieke sleutel en extra informatie zoals de naam van de houder, de uitgevende instantie, en de geldigheidsperiode.
Beheer: Certificaten kunnen worden ingetrokken door de uitgevende CA en hun status kan worden gecontroleerd via een lijst van ingetrokken certificaten (CRL) of via het Online Certificate Status Protocol (OCSP).
Levensduur: Net als sleutels hebben certificaten een beperkte geldigheidsduur en moeten ze worden vernieuwd voordat ze verlopen.
In essentie zijn sleutels de geheime codes die worden gebruikt voor versleuteling en andere cryptografische processen, terwijl certificaten publiek beschikbare documenten zijn die sleutels en identiteiten aan elkaar koppelen. Certificaten bevatten doorgaans publieke sleutels, maar niet de bijbehorende private sleutels.
Beschikbaarheid
Beschikbaarheid van crypto-apparatuur
De beschikbaarheid van apparatuur en oplossingen voor versleuteling en ontcijfering is essentieel voor de beveiliging van gevoelige gegevens en informatiesystemen.
Implementatiemaatregel
Crypto-apparatuur MOET beschikbaar zijn op een manier die voldoet aan de vereisten van de informatieclassificatie:
Informatieklasse 1 en 2 (beschikbaarheid): reservecomponenten voorzien.
Vanaf informatieklasse 3 (beschikbaarheid): high-availability (redundante) infrastructuur implementeren.
Beschikbaarheid van cryptografische sleutels en certificaten
Cryptografische sleutels en certificaten zijn nodig om gegevens te versleutelen en ontcijferen. Als deze sleutels verloren gaan of verlopen, is de versleutelde informatie niet meer toegankelijk. Daarom is het belangrijk om de levenscyclus van sleutels en certificaten goed te beheren en te documenteren. Dit helpt om onvoorziene omstandigheden te voorkomen.
Implementatiemaatregel
De sleutelbeheerlevenscyclus MOET worden gedocumenteerd en volgende zaken omvatten:
Een beleid voor het genereren, bewaren en verwijderen van sleutels en certificaten.
Een proces voor het back-uppen van sleutels en certificaten.
Een proces voor het herstellen van versleutelde gegevens als sleutels of certificaten verloren gaan of verlopen.
Implementatiemaatregel
Bij het back-uppen van sleutels en certificaten MOET rekening worden gehouden met de volgende zaken:
De back-up moet veilig worden opgeslagen.
De back-up moet kunnen worden hersteld.
De back-up moet voldoen aan de wettelijke vereisten.
Sleutelbeheer
Om encryptie effectief te kunnen gebruiken, moeten de encryptiesleutels net zo zorgvuldig en veilig worden beheerd als de gegevens die door die sleutels worden versleuteld, en dat gedurende de hele levensduur van die sleutels. Sleutelbeheer omvat de handelingen en taken die nodig zijn om cryptografische sleutels aan te maken, te beschermen en het gebruik ervan te controleren. Het proces van aanmaak tot vernietiging van de encryptiesleutel wordt beschreven als de sleutelbeheerlevenscyclus.
Sleutelbeheerlevenscyclus
Implementatiemaatregel
De sleutelbeheerlevenscyclus MOET worden gedocumenteerd en dient de volgende onderwerpen te omvatten:
Rollen en verantwoordelijkheden en belangrijke beheerprotocollen, zoals belangrijke ceremonies, met inbegrip van de eerbiediging van de need-to-know autorisatie en beveiligde sleutelopslag (bijv. verzegelde enveloppen)
Het beheer van de volledige levenscyclus van cryptografische sleutels, met inbegrip van de gebruiksperioden van de initiator en de ontvanger
Het genereren van adequate sleutels (type, lengte, willekeurige generatie, ...) voor de toepassingen waarvoor cryptografische besturingselementen nodig zijn
Het genereren en verkrijgen van certificaten van openbare sleutel
Het distribueren van sleutels naar beoogde gebruikers, inclusief hoe sleutels moeten worden geactiveerd wanneer ze worden ontvangen
Het opslaan van sleutels, waaronder hoe geautoriseerde gebruikers toegang krijgen tot sleutels
Het wijzigen of bijwerken van sleutels, inclusief regels over wanneer sleutels moeten worden gewijzigd en hoe dit zal gebeuren
Omgaan met gecompromitteerde sleutels
Sleutels intrekken, inclusief hoe sleutels moeten worden verlopen, ingetrokken of gedeactiveerd (bijvoorbeeld wanneer sleutels zijn aangetast of wanneer sleutels het einde van hun levensduur bereiken)
Het herstellen van sleutels die verloren of beschadigd zijn als onderdeel van het beheer van de bedrijfscontinuïteit (bijvoorbeeld voor het herstel van versleutelde informatie)
Het vernietigen van sleutels
Logging en auditing van belangrijke beheer gerelateerde activiteiten
De pensionering of vervanging van oude of vermoedelijke gecompromitteerde sleutels
Het valideren van de integriteit van sleutels
Het opslaan van sleutels in het minimumaantal plaatsen en formulieren.
Juridische en Ontsluitingsprocedures
Implementatiemaatregel
Voor informatie die is versleuteld en waarvoor de organisatie de eigenaar is, MOET een gedetailleerde procedure voor ontsleuteling worden opgesteld. Deze procedure is bedoeld voor situaties waarin een gerechtelijk bevel vereist dat de informatie toegankelijk wordt gemaakt.
Assetbeheer van Sleutels en Certificaten
Implementatiemaatregel
Elk certificaat en elke sleutel MOET als een asset worden beschouwd en als zodanig worden beheerd. Daarbij hoort ook het toewijzen van een eigenaar.
Het doel van elk certificaat MOET worden vastgelegd, inclusief de specifieke gebruikscategorieën zoals data-verificatie, digitale handtekeningen en encryptie/decryptie.
Er MOET een planning zijn voor het vervangen of vernieuwen van certificaten en sleutels.
Sleuteldistributie en -configuratie
Implementatiemaatregel
Sleutels MOETEN veilig worden verspreid via de daarvoor bestemde protocollen.
Het aantal omgevingen waarin sleutels worden verspreid, MOET zo beperkt mogelijk zijn. Het verspreiden van sleutels via openbare netwerken MOET zoveel mogelijk worden vermeden.
De sleutels die intern worden gegenereerd, MOETEN voldoen aan de eisen die zijn vastgelegd in de "Sleutelconfiguratie specificatie". Deze specificatie schrijft onder andere voor dat up-to-date versleutelingsmethoden moeten worden gebruikt.
Software gebruikt voor het beheer van cryptografische sleutels en certificaten MOET regelmatig worden bijgewerkt en gemonitord, in overeenstemming met het "Patching beleid" en het "Kwetsbaarhedenbeheer beleid".
Verstrekken van openbare sleutels en certificaten
Openbare sleutels worden gebruikt voor het versleutelen van gegevens die alleen toegankelijk moeten zijn voor de ontvanger. De openbare sleutel is beschikbaar voor iedereen, terwijl de private sleutel geheim moet blijven.
Er zijn verschillende manieren om openbare sleutels te verstrekken. Een veelgebruikte manier is om ze te publiceren op een openbare website of in een openbare directory. Een andere manier is om ze te verstrekken via een beveiligd kanaal, zoals een e-mailbericht of een persoonlijk overhandiging.
Bij het verstrekken van openbare sleutels is het belangrijk om ervoor te zorgen dat ze veilig worden opgeslagen en verspreid. Openbare sleutels kunnen worden gecompromitteerd als ze in verkeerde handen vallen.
Implementatiemaatregel
Voor het verstrekken van openbare sleutels en certificaten MOET in ieder geval:
De identiteit van de aanvrager worden vastgesteld.
De geldigheid (begin en eind) worden vastgesteld.
Het toegestane gebruik van de certificaten worden gedefinieerd en de voorwaarden contractueel worden afgesproken.
De organisatie dient te specificeren wanneer deze het recht heeft om het certificaat te in te trekken (revocatie).
Register van Encryptie-algoritmen
Implementatiemaatregel
De encryptie-algoritmes en bibliotheken die door de organisatie zijn goedgekeurd, MOETEN worden vastgelegd in een specifiek register.
Certificaatbeheer
Aanvragen van certificaten
Een certificaat is een digitaal document dat een koppeling bevat tussen een openbare sleutel en een identiteit, zoals een persoon, organisatie of apparaat. Certificaten worden gebruikt om de authenticiteit en integriteit van gegevens te verifiëren. Er zijn verschillende manieren om certificaten aan te vragen. Een veelgebruikte manier is om ze aan te vragen bij een certificate authority (CA). Een CA is een betrouwbare derde partij die certificaten uitvaardigt en beheert.
Implementatiemaatregel
De organisatie MOET haar certificaten aanvragen doormiddel van een uniform proces met de stappen die garanderen dat:
Aanvragen worden beheerd.
Aanvragen alleen gedaan worden aan instanties die voldoen aan de veiligheidseisen van de organisatie.
Het beheer van overkoepelende certificaten (rootcertificaten)
Een overkoepeld certificaat, ook wel een rootcertificaat genoemd, is een certificaat dat wordt uitgegeven door een betrouwbare derde partij, zoals een certificate authority (CA). Rootcertificaten worden gebruikt om andere certificaten te ondertekenen.
Implementatiemaatregel
De organisatie MOET rootcertificaten op een veilige manier opslaan:
Voor het aantreden moet een beheerder een training volgen die competenties en vaardigheden mbt. het beheer op de volgende aspecten garandeert:
Beheer van sleutels en certificaten
Beheer van soft- en hardware voor cryptografische doeleinden.
Het opslag mechanisme moet worden afgeschermd, deze mag enkel toegankelijk zijn wanneer een nieuw certificaat moet worden aangemaakt.
De toegang tot het opslag mechanisme moet beperkt worden tot een hoofdbeheerder en een groepsgrootte die garandeert dat certificaatbeheer te allen tijde kan worden uitgevoerd zonder dat het certificaat beheer door meerdere beheerders tegelijk wordt uitgevoerd.
Optreden als Certificaat autoriteit (CA)
Het zelf optreden als certificate authority (CA) is een manier om certificaten uit te geven voor uw eigen interne gebruik.
Implementatiemaatregel
Indien de organisatie zelf als certificaat autoriteit handelt, MOET de organisatie een certificaat beleid opstellen waar in ieder geval de volgende aspecten in worden vastgelegd:
Activeer en de activatie tijdstippen
Een hiërarchie van certificaten die garandeert dat onderliggende certificaten geen overlappende periodes van geldigheid kent
Het aanmaken van sleutels op basis van andere sleutels
Het vernietigen van sleutels
Certificaatbeheer
Er MOET een procedure zijn voor het intrekken van certificaten en voor het updaten van OCSP- en CRL-lijsten in de PKI-infrastructuur.
Voor elke applicatie MOETEN unieke sleutels en certificaten worden gebruikt.
RACI-overzicht van de voornaamste rollen en verantwoordelijkheden die van toepassing zijn op het beleid.
Voor meer informatie over rollen en verantwoordelijkheden zie 4. Rollen en verantwoordelijkheden (beleidsvorming en -naleving)
Nog verder uit te werken (als voorbeeld)
Uitvoeder | Aansprakelijke | Raadpleging | Informeren | |
|---|---|---|---|---|
Toepassen van |
Overzicht van controles die gebruikt worden voor de conformiteitstoetsing van het beleid.
Type | Controle |
|---|---|
BESTAAN | Er is een risicoanalyse uitgevoerd en de maatregelen die eruit voortkwamen zijn toegepast. |
BESTAAN | De rol voor het evalueren van encryptiestandaarden is belegd binnen de organisatie |
BESTAAN | Er is een register van toegepaste encryptie |
BESTAAN | In de contracten met externe leveranciers die integreren met de bedrijfsinfrastructuur zijn afspraken gemaakt over encryptie protocollen. |
BESTAAN | Waar de afdeling sleutels beheert: zijn er fysieke en logische maatregelen ingesteld voor het afschermen van sleutels. |
OPZET | Er is procedure voor het aanvragen, genereren, uitgeven en beheren van sleutels en certificaten met:
|
OPZET | Trainings programma: cryptografie |
OPZET | Training en competentie eisen sleutelbeheerder |
BESTAAN | Gevolgde trainingen register sleutel/ certificaat beheer |
OPZET | Procedure ontsleutelen versleutelde informatie gerechtelijke verzoeken |
OPZET BESTAAN | Register sleutels met eigenaar, doel, planning en andere gekoppelde assets. |
OPZET | Procedure sleutel en certificaatbeheer met (veilig): |
OPZET BESTAAN | Register geaccepteerde cryptografische algoritmes en bibliotheken. |
OPZET | De afdeling en/of organisatie heeft een certificaat beleid waar deze certificaten en sleutels beheert. Zodat het vervangen van certificaten en sleutels gepland en volgens cryptografisch beleid verloopt. |
BESTAAN | Veilig overdragen van zeer sensitieve informatie |
OPZET | Indien de afdeling applicaties met cyptografie ontwikkeld: De organisatie heeft procedure voor het verifiëren van correcte implementatie betreffende cryptografie. |
BESTAAN | Indien de afdeling applicaties met cyptografie ontwikkeld: De organisatie heeft een register met testresultaten voor cryptografische functionaliteit inclusief administratie voor gemitigeerde testresultaten. |
Regelgeving en standaarden (L1)
ISO 27001:2022 (Annex A)
Informatieveiligheidsstrategie van de Vlaamse overheid (L2)
Zie 3.1. Minimale maatregelen - Cryptografie voor meer informatie.
Titel | Auteur | Datum | Versie | Status | Opmerkingen |
|---|---|---|---|---|---|
Beleid cryptografie | Philippe Michiels | 22/04/2020 | 1.0 | GEVALIDEERD | |
Beleid sleutelbeheer | Philippe Michiels | 10/06/2021 | 1.0 | GEVALIDEERD | |
Beleid cryptografie | Fabrice Meunier | 1/10/2023 | 2.0 | IN REVIEW | Consolidatie en revisie van beleidsdocumenten |