Cryptografie juist en doeltreffend gebruiken in overeenstemming met wet- en regelgeving 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
|
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.
Dit document gebruikt TLS, SSL en SSL/TLS door elkaar, maar zijn om praktische redenen, tenzij daar waar expliciet vermeld, synoniemen van elkaar.
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/...)
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).
Volgens NIST is AES-128 bit versleuteling de minimale norm om sensitieve data te gaan beveiligen tot en met 2030.
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
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. Afhankelijk van de informatieklasse en de toekomstbestendigheid van de te beschermen informatie en de vereiste performantie, dient er vanuit een security architectuur oogpunt een weloverwogen beslissing genomen te worden of een RSA-sleutel groter dan 2048 bit aangewezen is.
HTTP Encryptie
HTTP (Hypertext Transfer Protocol) 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 automatische interactie tussen twee machines over het netwerk mogelijk te maken.
Het probleem bij HTTP is dat standaard gegevens niet worden versleuteld en dat deze door derden kunnen worden onderschept wanneer gegevens worden doorgegeven tussen verschillende 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 aangegeven in de adresbalk van de browser, door bijvoorbeeld een hangslot en de aanduiding https:// aan het begin van de URL (Uniform Resource Locator).
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 dat 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
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 gebruik maakt, wordt steeds de zo hoog mogelijkste cipher suite onderhandeld 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.
Een aantal hulpmiddelen die gebruikt kunnen worden om beveiligingsstatus van Cipher Suites te raadplegen zijn: 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 bij het tot stand brengen van de verbinding de client 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 = Internet Key Exchange):
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 certificaat.IKE phase 2
Nadat IKE fase 1 succesvol is afgerond en de VPN-tunnel beveiligd en geauthentiseerd 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 informatieklasse 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 informatieklasse 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. 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 industrie best practices en technische baselines 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 Digitale werkplek)
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 meerdere 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’ versleutelt, 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.
Om ‘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 informatieklasse worden toegepast.
Informatieklasse 3 (vertrouwelijkheid) in een onbeschermde omgeving (d.w.z. veiligheidsbeheer van omgeving niet onder Vo-controle)
Vanaf informatieklasse 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 informatieklasse:
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.
Bij het testen van de herstelbaarheid van back-ups, dient de bruikbaarheid van sleutels en certificaten getest te worden (door sleutelrotatie kan het voorkomen dat sleutels niet meer werken).
Sleutelbeheer
Om encryptie effectief te kunnen gebruiken, moeten de encryptiesleutels minstens 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 cryptografische (PKI) 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 de publieke sleutel
Het distribueren van sleutels naar de 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 verlopen, ingetrokken of gedeactiveerde sleutels (bijvoorbeeld wanneer sleutels zijn aangetast of wanneer sleutels het einde van hun levensduur bereiken)
Het herstellen van sleutels die verloren of beschadigd tijdens calamiteiten dient opgevangen te zijn in 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 een zo klein als mogelijk aantal 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 (decryptie) worden opgesteld, inclusief procedure voor de nodige goedkeuringen voor ontsleuteling. 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 informatieasset worden beschouwd en als zodanig worden geclassificeerd en 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 en geteste werkende procedure zijn voor het vervangen en vernieuwen van certificaten en sleutels, gebaseerd op een gekende levensduur van het certificaat.
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 een 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 malware / patching beleid en het kwetsbaarhedenbeheer beleid.
Verstrekken van publieke sleutels en certificaten
Publieke sleutels worden gebruikt voor het versleutelen van gegevens die alleen toegankelijk moeten zijn voor de ontvanger. De publieke sleutel is beschikbaar voor iedereen, terwijl de private sleutel geheim moet blijven.
Er zijn verschillende manieren om publieke sleutels te verstrekken. Een veelgebruikte manier is om ze te publiceren op een publieke website of in een publieke directory. Een andere manier is om ze te verstrekken via een beveiligd kanaal, zoals een e-mailbericht of een persoonlijke overhandiging.
Bij het verstrekken van publieke sleutels is het belangrijk om ervoor te zorgen dat ze veilig worden opgeslagen en verspreid. Publieke sleutels kunnen worden gecompromitteerd als ze in verkeerde handen vallen.
Implementatiemaatregel
Voor het verstrekken van publieke 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 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 door middel 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 met betrekking tot het beheer op de volgende aspecten garandeert:
Beheer van sleutels en certificaten
Beheer van soft- en hardware voor cryptografische doeleinden.
Het opslagmechanisme moet worden afgeschermd, dit mag enkel toegankelijk zijn wanneer een nieuw certificaat (bijvoorbeeld een subordinate CA) moet worden aangemaakt.
De toegang tot het opslagmechanisme moet beperkt worden tot een hoofdbeheerder en een groepsgrootte die garandeert dat certificaatbeheer te allen tijde kan worden uitgevoerd zonder dat het certificaatbeheer 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 eigen (intern) gebruik. Dit zijn zogenaamde “self-signed certificates”.
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 kennen
Het aanmaken van sleutels op basis van andere sleutels
Het vernietigen van sleutels
Onder welke voorwaarden wildcard certificaten gebruikt mogen worden
Hoe om te gaan met certificaten in verschillende omgevingen (ontwikkel, test, productie)
Certificaatbeheer
Implementatiemaatregel
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 in een productieomgeving MOETEN unieke sleutels en certificaten worden gebruikt.
Regelgeving en standaarden (L1)
ISO 27001:2022 (Annex A)
Informatieclassificatieraamwerk 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 |
Beleid cryptografie | Fabrice Meunier | 17/06/2024 | 2.0 | FINAAL CONCEPT |