Het beleid voor cryptografie beperkt de inzet van cryptografische technologieën tot alleen die algoritmen die zowel krachtig als efficiënt zijn en bestand zijn tegen bekende aanvallen. Dit beleid is bedoeld om gegevens en informatieprocessen te beschermen. De gebruikte componenten en algoritmen zijn gebaseerd op publiekelijk geteste en bewezen veilige richtlijnen. Het beleid zorgt ook voor naleving van alle wettelijke en contractuele eisen met betrekking tot cryptografie.

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.

Dit document gebruikt TLS, SSL en SSL/TLS door elkaar, maar zijn om praktische redenen, tenzij daar waar expliciet vermeld, synoniemen van elkaar.

Implementatiemaatregel

De versleuteling zoals aangegeven in onderstaande tabel MOET worden toegepast op basis van de informatieklasse van de te beschermen gegevens.

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 (Rivest Cipher 4)

  • 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 (Wired Equivalent Privacy) om Wi-Fi 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. 

Implementatiemaatregel

De versleuteling zoals aangegeven in onderstaande tabel MOET worden toegepast op basis van de informatieklasse 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 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 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. 

Implementatiemaatregel

De volgende verouderde protocollen MOGEN NIET worden gebruikt en MOETEN worden gedeactiveerd en verwijderd daar waar mogelijk:

• 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 wordt aangeraden en MOET worden gebruikt waar technisch mogelijk.

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)

Implementatiemaatregel

Het gebruik van Perfect Forward Secrecy is altijd AANGEWEZEN.

Implementatiemaatregel

Vanaf informatieklasse 3 (vertrouwelijkheid) MOET Perfect Forward Secrecy worden gebruikt.

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.

Implementatiemaatregel

De beveiliging van IKE zoals aangegeven in onderstaande tabel MOET worden toegepast op basis van de informatieklasse van de te beschermen gegevens.

Implementatiemaatregel

Het is AANGEWEZEN om IKEv2 te gebruiken boven IKEv1.

Implementatiemaatregel

SFTP en FTPS MOETEN volgens best practices worden geconfigureerd om de beveiligingsrisico's te beperken.

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 /wiki/spaces/ISMS/pages/6330811307)

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.

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

1. 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.

2. Soorten: Er zijn verschillende soorten sleutels zoals publieke en private sleutels in asymmetrische cryptografie, en gedeelde sleutels in symmetrische cryptografie.

3. Eigenschappen: Sleutels zijn in essentie lange reeksen cijfers en letters die volgens specifieke algoritmen zijn gegenereerd.

4. Beheer: Sleutels moeten zorgvuldig worden beheerd en opgeslagen. Ze mogen niet zomaar worden gedeeld of verspreid.

5. Levensduur: Sleutels hebben vaak een beperkte levensduur en dienen periodiek te worden vernieuwd om de veiligheid te behouden.

Digitale Certificaten

1. 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.

2. Soorten: Certificaten worden meestal uitgegeven door een certificeringsautoriteit (CA), die de identiteit van de certificaathouder verifieert voordat een certificaat wordt uitgegeven.

3. Eigenschappen: Een certificaat bevat een publieke sleutel en extra informatie zoals de naam van de houder, de uitgevende instantie, en de geldigheidsperiode.

4. 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).

5. 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.

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.

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.

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 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

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.

Implementatiemaatregel

Elk certificaat en elke sleutel MOET als een informatieasset 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 en geteste werkende procedure zijn voor het vervangen en vernieuwen van certificaten en sleutels, gebaseerd op een gekende levensduur van het certificaat.

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.

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).

Implementatiemaatregel

De encryptie-algoritmes en bibliotheken die door de organisatie zijn goedgekeurd, MOETEN worden vastgelegd in een specifiek register.

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.

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.

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)

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. (moeten/kunnen we hier dieper op ingaan wat dit in de praktijk betekent voor dev/test/prod omgevingen en het gebruik van wildcard en Subject Alternative Name (SAN)?)

Document status

status opties: