3.1.1.2. Minimale maatregelen - Sleutelbeheer 3.0

PAS TOE

Klasse 1 en Klasse 2 kennen dezelfde maatregelen:

• Generatie: in een veilige omgeving: fysieke en logische toegangsbeveiliging + gebruik van standaard cryptomodules (softwarebibliotheken, API’s, hardware modules, ...);

• Distributie sleutels: via een geschikt protocol en/of via een geschikte datamedia of via communicatieverbindingen in een vorm die de vertrouwelijkheid, integriteit, en authenticiteit ervan waarborgt;

• Registratie van alle in omloop zijnde sleutels en certificaten;

• Bescherming opslag sleutelmateriaal: geëncrypteerde opslag of hardware token;

• Verschillende sleutels per omgeving (test- vs. productieomgeving)/ toepassing/ organisatie/ finaliteit (encryptie vs. digitale handtekening);

• Sleutelsterkte afgestemd op informatieklasse;

• Geldigheidsduur van cryptografische sleutels wordt afgestemd op het beoogde gebruik en is vastgelegd in het cryptografische beleid;

• Gebruik en beheer sleutels: stringente toegangscontrole (Identity and Access Management of IAM en principe van Least privilege) met sterke garanties op vlak van traceerbaarheid (zie ook volgende pagina’s: 5.1. Minimale maatregelen - Identity en Access Management (IAM) en 3.2.3.8. Logging ICT-systemen 3.0)

• De authenticiteit van publieke sleutels wordt gegarandeerd d.m.v. van een PKI (naargelang de use case: intern, Vo-PKI of commerciële erkende CA);

• Het beheer van certificaten binnen de entiteit wordt vastgelegd (wie-wat-hoe);

• Geen certificaten delen tussen verschillende omgevingen (bv. test versus productie);

• OV- of EV-certificaten worden aangeraden indien de site ontsloten wordt naar een onbeveiligd netwerk (internet); en

• Sensibilisering medewerkers (zorgvuldig omgaan met encryptie en sleutelbeheer).

Klasse 3 en Klasse 4 kennen dezelfde maatregelen: 

Alle maatregelen van Klasse 1 / Klasse 2

• Functiescheiding: 

  • Toegangsbeheer; 

  • Applicatiebeheer; 

  • Sleutelbeheer; en 

  • Sleutelgebruik. 

PAS TOE OF LEG UIT

Alle maatregelen van Klasse 1 + Klasse 2 + Klasse 3 + Klasse 4 +

• Generatie: crypto module = FIPS 140-2 level 2 hardware;

• Sleutelceremonie voor nieuwe mastersleutels;

• FIPS 140-2 level 2 hardware voor bewaren geheime sleutels, minimaal:

  • Root CA private-sleutel; en

  • Master keys of mastersleutels;

• Controle functiescheiding: sleutelbeheer (4-ogenprincipe); en

• Jaarlijkse periodieke herziening van de toegangen m.b.t. sleutelbeheer. 

PAS TOE

Klasse 1 + Klasse 2 kennen dezelfde maatregelen:

• Indien herstel van versleutelde informatie nodig is, overweeg dan een beveiligde back-up van sleutels en sleutelparen.

• Noot: gebruik van een back-up-omgeving voor sleutelparen voor digitale handtekening kan de legitimiteit en dus de bruikbaarheid van de handtekening ondermijnen.

Klasse 3 + Klasse 4 en klasse 5 kennen dezelfde maatregelen

Alle maatregelen van Klasse 1 + Klasse 2 +

• Maak gebruik van een KMS (Key Management System) met aandacht voor de beschikbaarheid van sleutels en sleutelparen.

Er zijn geen maatregelen voor Klasse 1, Klasse 2, Klasse 3 en Klasse 4

Klasse 5 kent volgende maatregelen

• Code Signing

  • Op alle code van klasse 5 dient code signing te gebeuren 

Klasse 1 t/m Klasse 5 kennen dezelfde maatregelen: 

• Een formeel beleid voor het gebruik, bescherming en levensduur van cryptografische sleutels voor de ganse levenscyclus opzetten, valideren, communiceren en onderhouden. Hierbij moet ze gebruik maken van de ‘Richtlijnen rond het sleutel beheer’ zoals opgesomd in de bijlage D van de beleidslijn ‘vercijferen’(Ref. KSZ 5.7.1). 

• KSZ Bijlage D “richtlijnen rond het sleutelbeheer”: 

  • De organisatie is verantwoordelijk voor effectief sleutelbeheer. Specifieke processen en procedures gerelateerd aan sleutelbeheer moeten opgesteld, gevalideerd, gecommuniceerd worden aan alle betrokken actoren en ook regelmatig onderhouden worden. Het sleutelbeheer moet minimaal de volgende thema’s omvatten:  

    • Aanvragen/genereren van sleutels  

    • Opslag van (privé)sleutels 

    • Transport van (privé)sleutels 

    • Gebruik van sleutels 

    • Vervangen en vernietigen van sleutels 

    • Archiveren van sleutels 

    • Omgaan met gecompromitteerde sleutels  

  • De volgende minimale richtlijnen moeten gelden voor het aanvragen/genereren van sleutels:  

    • Er moet gekozen worden voor de sterkste cryptografische maatregel die in de praktijk werkbaar is. 

    • Sleutels moeten een activatie- en verloopdatum hebben. 

    • De geldigheidsduur moet afhankelijk zijn van het beoogde doel en de tijd die het zou kosten om de sleutel te kraken.  

    • Elke sleutel moet uniek zijn.  

    • Een sleutel moet alleen voor een specifiek doel en omgeving gegenereerd worden.  

    • Sleutels moeten door een erkende partij geleverd worden die werkt volgens een goede praktijk. De volgende minimale richtlijnen moeten gelden voor de opslag van (privé)sleutels:  

    • Sleutels moeten op zo weinig mogelijk locaties opgeslagen worden.  

    • Systemen moeten de door het systeem gebruikte sleutels afschermen voor gebruikers.  

    • Sleutels moeten beschermd worden tegen verlies of wijzigingen (bv. door een kopie bij te houden). Toegang tot sleutels moet tot een minimum beperkt zijn (tot de verantwoordelijke van de sleutel).  

    • Sleutels zijn alleen toegankelijk voor de technische experten  

    • Bij gevoelige of kritieke data zijn er minimaal twee beheerders.  

    • Sleutels moeten minimaal even goed beschermd worden als de betrokken data. 

  • De volgende minimale richtlijnen moeten gelden voor het transport van (privé)sleutels:  

    • Wanneer sleutels leesbaar overgedragen worden, moet dit in persoon gebeuren of via een alternatief betrouwbaar kanaal gebeuren.  

    • Deze middelen en methodes om sleutels te communiceren moeten eerst goedgekeurd worden door de informatieveiligheidsconsulent (CISO) / functionaris van gegevensbescherming (DPO).  

    • Minimaal de volgende richtlijnen moeten gelden voor het gebruik van sleutels:  

      • Elke sleutel moet alleen voor het toegewezen doel en omgeving ingezet worden. 

      • Een sleutel die gebruikt wordt in productiesystemen mag niet gebruikt worden in niet productie systemen. 

      • Binnen de organisatie is het belangrijkste gebruik van cryptografie van toepassing op:

        • Beveiliging van data op mobiele apparatuur 

        • Opslag van wachtwoorden 

        • Beveiliging van toepassingen  

        • Beveiliging van communicatie van niet-publieke data over publieke netwerken (zoals VPN verbindingen). o Opslag en beveiliging van communicatie van kritieke data op het interne netwerk.  

  • De volgende minimale richtlijnen moeten gelden voor het vervangen en vernietigen van sleutels:  

    • Alle sleutels moeten na de verloopdatum overal waar deze opgeslagen of toegepast werden verwijderd worden.  

    • Zo nodig moet een nieuwe sleutel met dezelfde eisen gegenereerd worden.  

  • De volgende minimale richtlijnen moeten gelden voor het archiveren van sleutels:  

    • Sleutels die gebruikt werden door gebruikers die de organisatie verlaten hebben, moeten versleuteld en gearchiveerd worden.  

  • De volgende minimale richtlijnen moeten gelden voor gecompromitteerde sleutels:  

    • Elke sleutel die gecompromitteerd is of waarvan de verwachting bestaat dat deze gecompromitteerd is, moet direct vervangen worden.  

    • Er moet een procedure zijn vastgesteld voor elk type maatregel waarin is bepaald hoe gehandeld moet worden wanneer een sleutel mogelijk gecompromitteerd is of wanneer een kwetsbaarheid bekend wordt.  

    • Een gecompromitteerde sleutel mag geen data verschaffen die gebruikt kan worden om de vervangende sleutel te bepalen. Voor elke sleutel moet een interne medewerker verantwoordelijk zijn.  

  • Er moet een overzicht bijgehouden worden van alle verantwoordelijken voor sleutels  

  • Er moeten maatregelen toegepast worden om ongeautoriseerde pogingen tot verspreiding, ontcijfering, toegang, gebruik, wijziging of vervanging van sleutels of versleutelde data te detecteren. In overeenkomsten met leveranciers van cryptografische diensten of producten moeten deze richtlijnen ingesloten zijn.  

  • Er moeten procedures opgesteld worden die bepalen hoe omgegaan moet worden met de aanvragen voor toegang tot versleutelde data (zoals in het geval van een rechtszaak of in geval van een klacht die ingediend is bij de organisatie). 

  • Toegang tot of het gebruik van privésleutels moeten gelogd worden volgens de procedures in het document “BLD Logbeheer”. 

• KSZ Beleidslijn Logbeheer: Elke organisatie onderschrijft de volgende beleidslijnen van informatieveiligheid en privacy voor alle informatie en informatiesystemen onder de verantwoordelijkheid van de organisatie:

1. De organisatie dient een formele procedure van logbeheer op te zetten, te valideren, te communiceren en te onderhouden.  

2. De organisatie moet transacties, controlewerkzaamheden, activiteiten van gebruikers, uitzonderingen en informatieveiligheid- en privacy-gebeurtenissen/incidenten gestructureerd vastleggen in afzonderlijke logbestanden, zodat iedere handeling naar de brondocumenten herleid kan worden of uitgevoerde bewerking(en) gecontroleerd kan worden.  

3. Logbeheer moet meegenomen worden vanaf het design tijdens de ontwikkeling of bij de bepalingen van aankoopcriteria van toepassingen of systemen om “security/privacy by design” te realiseren.  

4. Elke toegang tot gegevens met gevoeligheidsklasse vertrouwelijk of hoger, moet gelogd worden in overeenstemming met de toepasselijke wetgeving en regelgeving.  

5. De interne klokken van alle informatiesystemen van de organisatie dienen gesynchroniseerd te worden met een overeengekomen nauwkeurige tijdsbron dat een betrouwbare analyse van logbestanden op verschillende informatiesystemen altijd mogelijk is.  

6. De noodzakelijke tools moeten beschikbaar zijn of ontwikkeld worden om log gegevens te kunnen uit te baten en te laten analyseren door de geautoriseerde personen. Via de tools moet het mogelijk zijn om de logs snel, glashelder en eenvoudig te kunnen raadplegen.  

7. Zoveel als mogelijk wordt systeemgebruik automatisch gelogd, als dit niet mogelijk is kan ook gebruik gemaakt worden van een manueel logboek door systeembeheerders.  

8. Logbestanden dienen beschermd te worden tegen inzage door onbevoegden, wijzigingen en verwijderingen.  

9. De logbestanden moeten gedurende een overeengekomen periode worden bewaard, ten behoeve van toekomstig onderzoeken en controles en in overeenstemming met wetgeving en regelgeving . In het bijzonder dienen de privacy logs minstens 10 jaar bewaard worden.  

10. De kwaliteit van de privacy log dient een gepast antwoord te bieden om het gebruik te rechtvaardigen (al dan niet gebaseerd op een voorafgaandelijke autorisatie of machtiging). De log dient per verwerking een aanduiding te bevatten van wie wanneer over wie welke persoonsgegevens heeft verwerkt voor welke doeleinden en met welk resultaat (OK,NOK).  

11. De raadpleging van logbestanden is altijd het voorwerp van een georganiseerde procedure binnen de organisatie met een historiek van de verzoeken die werden goedgekeurd/uitgevoerd of die werden afgekeurd.  

12. Het resultaat van logbeheer moet regelmatig geanalyseerd, gerapporteerd en beoordeeld worden.