Vereenvoudiging van de audit en het herstel van sleutels en certificaten

Gepubliceerd: december 2023. Bijgewerkt: augustus 2026. Beoordeeld door het PKI- en sleutelbeheeradviessteam van Encryption Consulting.

Waarom ontstaat er überhaupt een auditschuld voor sleutels en certificaten?

Cryptografische activa stapelen auditschuld op omdat ze sneller worden aangemaakt dan dat ze worden bijgehouden. Een ontwikkelaar vraagt ​​een TLS-certificaat aan voor een testserver en het wordt vervolgens in productie genomen. Een team genereert een SSH-sleutelpaar om een ​​implementatie te scripten en vervangt het nooit. Een cloudservice genereert een nieuwe encryptiesleutel en het beveiligingsteam komt daar pas achter tijdens de volgende compliancecyclus, of helemaal niet. Geen van deze gevallen is opzettelijk kwaadwillig; het zijn de gebruikelijke problemen die ontstaan ​​wanneer gedistribueerde teams sneller cryptografie implementeren dan de governance kan bijhouden.

Het resultaat is een kloof tussen wat uw certificaat- en sleutelinventaris aangeeft en wat er daadwerkelijk in productie aanwezig is. Die kloof is wat een auditor ontdekt en wat een aanvaller misbruikt: een achtergebleven sleutel met te veel privileges, een verlopen certificaat dat stilletjes een intrekkingscontrole uitschakelt, of een zelfondertekend certificaat dat iemand drie jaar geleden "tijdelijk" vertrouwde. Het dichten van deze kloof is geen eenmalige klus. Het is een cyclus van ontdekking, classificatie, herstel en verificatie die continu moet plaatsvinden, omdat de onderliggende omgeving voortdurend verandert.

Wie is verantwoordelijk voor de levenscyclus van een sleutel versus een certificaat?

Eigendom moet per type asset worden toegewezen, omdat sleutels en certificaten op verschillende manieren falen en aan verschillende belanghebbenden verantwoording verschuldigd zijn. Een sleutel zonder benoemde eigenaar kan niet veilig worden geroteerd, omdat niemand kan controleren wat er misgaat als deze wordt gewijzigd. Een certificaat zonder benoemde eigenaar verlengt zichzelf, wat leidt tot een storing op de dag dat niemand merkt dat het is verlopen.

Levenscyclusfase	cryptografische sleutels	Certificaten
Generatie	Sleutelbeheerder of beveiligingsteam, binnen een HSM of goedgekeurd sleutelbeheersysteem, nooit op een laptop van een ontwikkelaar	Aangevraagd door een applicatie-/service-eigenaar, uitgegeven door een goedgekeurde interne of openbare CA.
Registratie	Een sleutelinventaris met algoritme, lengte, eigenaar en beoogd gebruik is vastgelegd.	Een certificaatinventaris is geregistreerd met SAN, uitgevende CA, geldigheidsperiode en implementatielocatie.
Actief gebruik	Toegang beperkt door rol; geen directe beheerderstoegang tot onbewerkt sleutelmateriaal.	Geïmplementeerd op de exacte eindpunten die het nodig hebben; detectiescans bevestigen dat de implementatie overeenkomt met de inventaris.
Rotatie/vernieuwing	Wordt geroteerd aan het einde van de gedefinieerde cryptoperiode of bij een triggerende gebeurtenis.	Verlenging vóór de vervaldatum, steeds vaker via geautomatiseerde inschrijving (ACME/EST) naarmate de geldigheidsperioden korter worden.
Pensioen	Vernietigd of gearchiveerd volgens een gedocumenteerde procedure voor het vernietigen van sleutels, met vermelding in het auditlogboek.	Ingetrokken indien gecompromitteerd of vervangen; verwijderd uit de opslag en inventaris van het trustfonds.
Typische eigenaar	Beveiligings-/cryptografieteam (sleutelbeheermodel)	Applicatie- of infrastructuureigenaar, met een centraal PKI/CLM-team als beheersautoriteit.

De praktische oplossing is om voor elke sleutel en elk certificaat een verantwoordelijke eigenaar aan te wijzen op het moment van uitgifte, en niet pas achteraf. Platformen voor certificaatlevenscyclusbeheer en sleutelbeheersystemen ondersteunen eigenaarsmetadata als een volwaardig veld, juist omdat "wie is de eigenaar?" de meest voorkomende tekortkoming is die auditors signaleren.

Wat is nu precies de aanleiding voor een sleutelrotatie of certificaatvernieuwing?

De rotatie van certificaten mag nooit puur op de kalender gebaseerd zijn. Een degelijk programma combineert tijdslimieten met gebeurtenisgestuurde triggers, en voor certificaten een externe beperking die snel verandert: de steeds korter wordende maximale geldigheidsperiode van het CA/Browser Forum.

Tijdsgebonden rotatie

NIST SP 800-57 Deel 1, Revisie 5 definieert de cryptoperiode als de tijdsspanne waarin een specifieke sleutel geautoriseerd is voor gebruik. Hierbij wordt het risico dat een sleutel gecompromitteerd raakt naarmate deze langer actief blijft, afgewogen tegen de operationele kosten van het roteren ervan. Er is geen eenduidig ​​correct getal; NIST laat het exacte interval over aan de risicobeoordeling, het algoritme en de sleutelsterkte van de organisatie, maar het principe is vast: elke sleutel moet een vooraf vastgestelde maximale levensduur hebben, die niet onbeperkt mag zijn.

Op gebeurtenissen gebaseerde rotatie

Een sleutel of certificaat moet onmiddellijk, buiten het normale schema, worden vervangen wanneer:

• Een beheerder met toegang tot de privésleutel verandert van rol of verlaat de organisatie.
• Een vermoedelijke of bevestigde inbreuk vindt ergens in de keten plaats, inclusief bij de uitgevende certificeringsinstantie.
• Een algoritme of sleutellengte wordt afgekeurd op grond van NIST-richtlijnen of intern beleid.
• Een leverancier, cloudprovider of externe certificeringsinstantie meldt een incident dat mogelijk cruciale informatie aan het licht heeft gebracht.
• Een audit wijst uit dat het actief buiten de goedgekeurde procedure is uitgegeven (een zelfondertekend of schaduwcertificaat, een niet-geregistreerde sleutel).

De certificaatspecifieke trigger: verkorting van de maximale geldigheidsduur

Certificaten hebben een extra, extern opgelegde rotatietrigger die sleutels niet hebben: het CA/Browser Forum- voorstel SC-081v3 verlaagt de maximale geldigheidsduur van openbare TLS-certificaten volgens een vast schema.

Ingangsdatum	Maximale geldigheidsduur van het TLS-certificaat
Tot en met 14 maart 2026	398 dagen
15 maart 2026 tot en met 14 maart 2027	200 dagen
15 maart 2027 tot en met 14 maart 2029	100 dagen
15 maart 2029 en verder	47 dagen

De periodes waarin domeincertificaten opnieuw geldig zijn, worden steeds korter, uiteindelijk tot 10 dagen. Dit betekent dat een audit- en herstelprogramma gebaseerd op jaarlijkse of zelfs driemaandelijkse handmatige certificaatcontroles niet meer toereikend is. Tegen 2029 zal een certificaat dat vandaag is uitgegeven, ongeveer acht keer per jaar vervangen moeten worden in plaats van één keer. We gaan dieper in op de operationele gevolgen van deze overgang in het artikel ' Voorbereiding op 47-daagse TLS-certificaten'.

Wie moet de bevoegdheid hebben om sleutels en certificaten te controleren en te herstellen?

De bevoegdheid tot controle en correctie moet gescheiden zijn van de bevoegdheid tot dagelijkse uitgifte, anders is de controle niet echt onafhankelijk. Een werkbaar toegangsmodel ziet er als volgt uit:

• Belangrijkste beheerders Zij dragen de operationele verantwoordelijkheid voor specifieke sleutels, maar hebben geen onbeperkte toegang tot het ruwe sleutelmateriaal; dubbele controle en gedeelde kennis zijn van toepassing op elke handeling die een sleutel zou kunnen blootleggen of misbruiken.
• Certificaat-/CA-beheerders Ze kunnen certificaten uitgeven en intrekken binnen het beleid, maar kunnen het auditlogboek van hun eigen acties niet wijzigen.
• auditors (Interne beveiliging of externe QSA/beoordelaar) hebben alleen leesrechten tot de volledige inventaris, uitgiftelogboeken en beleidsconfiguratie, zonder de mogelijkheid om te wijzigen wat ze bekijken.
• Goedkeurders Het uitvoeren van herstelmaatregelen (zoals het intrekken van een certificaat of het vernieuwen van een productiesleutel) is een aparte taak van de persoon die de bevinding heeft vastgesteld. Niemand kan dus in zijn eentje een kritiek probleem signaleren én oplossen zonder dat een tweede persoon ernaar kijkt.

Beheerders mogen nooit onbelemmerde, directe toegang hebben tot privésleutels buiten een beheerd systeem, en elke uitzondering moet worden vastgelegd en een tijdslimiet krijgen. Dit model van functiescheiding is ook wat PCI DSS 4.0- en SOC 2-auditors gedocumenteerd verwachten, en niet als vanzelfsprekend beschouwd.

Welk bewijsmateriaal willen auditors nu eigenlijk zien?

Dit is de kern van het probleem waar de meeste teams de mist in gaan: ze beschouwen "we hebben een beleid" als bewijs. Auditors willen bewijs dat het beleid wordt nageleefd, actueel is en wordt gehandhaafd. Voor een audit van cryptografische activa valt dat bewijs over het algemeen in vier categorieën uiteen.

Een complete, actuele inventaris

PCI DSS 4.0-vereiste 4.2.1.1 vereist dat organisaties die kaartgegevens verwerken, een actuele inventaris bijhouden van alle cryptografische sleutels en certificaten, inclusief algoritme, sleutelsterkte, vervaldatum en de specifieke gegevens die elk ervan beschermt. Een inventaris die correct was tijdens de laatste audit, maar sindsdien niet is vergeleken met een live scan, is niet actueel. Auditors vragen steeds vaker naar de scandatum, niet alleen naar het spreadsheet.

Gedocumenteerde, gedateerde beleidsevaluatie

PCI DSS-vereiste 12.3.3 vereist dat organisaties hun gebruikte cryptografische cipher suites en protocollen minstens jaarlijks documenteren en beoordelen, inclusief een gedocumenteerde rechtvaardiging voor het voortgezet gebruik van een verouderd algoritme en een plan om daarvan af te stappen. Auditors willen een gedateerd document, een benoemde beoordelaar en een wijzigingslogboek, geen beleid dat sinds de opstelling ervan niet meer is aangepast.

Toegangs- en bedieningslogboeken

Elke gebeurtenis met betrekking tot het genereren, roteren, exporteren en vernietigen van sleutels, en elke uitgifte, verlenging en intrekking van certificaten, vereist een veilige, fraudebestendige logboekvermelding: wie de actie heeft uitgevoerd, wanneer en met welke goedkeuring. Bij SOC 2-audits is dit logboek vaak het enige bewijsstuk dat bepaalt of een controle als effectief wordt beoordeeld of als een tekortkoming in het rapport.

Gesloten-lus herstelregistraties

Een bevinding zonder gedocumenteerde datum voor herstel en herverificatie is een openstaande bevinding, ongeacht hoe oud deze is. Auditors zoeken specifiek naar bewijs dat een eerder gesignaleerd probleem (een verlopen certificaat dat nog steeds in een vertrouwensopslag staat, een sleutel waarvan de cryptoperiode is verlopen) daadwerkelijk is opgelost en dat de oplossing is bevestigd, en niet alleen in een spreadsheet is genoteerd en vervolgens vergeten.

Hoe ziet een praktische audit- en herstelworkflow eruit?

Doorloop dezelfde cyclus van vijf stappen, ongeacht of de aanleiding een geplande interne audit, een aanstaande PCI DSS-beoordeling of een SOC 2-verlenging is.

1. Inventariseer en ontdek. Voer netwerk- en endpointscans uit om alle gebruikte sleutels en certificaten te vinden en vergelijk de resultaten vervolgens met de bestaande inventaris. Stel een gedefinieerd proces op voor het registreren van sleutels of certificaten die niet door de scans worden gevonden, zoals die welke zijn ingebed in offline systemen of hardwareapparaten.
2. Classificeer op risico. Beoordeel elk actief op basis van wat het beschermt, waar het zich bevindt (productie versus niet-productie, internetgericht versus intern), hoe dicht het bij de vervaldatum of het einde van de cryptoperiode is, en of het algoritme of de sleutellengte nog steeds voldoet aan het huidige beleid.
3. Herstellen. Pak eerst de meest risicovolle bevindingen aan: trek zwakke of ongeautoriseerde certificaten in of vervang ze, roteer sleutels na hun cryptoperiode, corrigeer ontbrekende eigendomsgegevens en verwijder test- of niet-productiesleutels en -certificaten die naar productieomgevingen zijn gemigreerd.
4. Verifiëren. Controleer of de oplossing daadwerkelijk in de productieomgeving is doorgevoerd, en niet alleen in de beheerconsole. Een certificaat met de aanduiding 'vernieuwd' dat nooit opnieuw naar de load balancer is geïmplementeerd, is nog steeds een bevinding.
5. Rapporteren. Stel een gedateerd rapport op waarin staat wat er is gevonden, wat er is verholpen, wat er nog openstaat met een streefdatum, en wie elke herstelmaatregel heeft goedgekeurd. Dit rapport is het document dat een auditor beoordeelt, dus het moet op zichzelf staan.

Twee extra controles horen in elke cyclus thuis, ongeacht het type asset: het voorkomen van migratie van niet-productiesleutels en -certificaten naar productie door het gebruik van test-CA's te beperken tot niet-productiesystemen, en het bijhouden van een gedocumenteerd reactieplan voor CA-compromissen waarin wordt beschreven wie welke certificaten vervangt en in welke volgorde, mocht een vertrouwde root- of intermediaire CA ooit worden gecompromitteerd.

Handmatige spreadsheetcontroles of geautomatiseerde tools voor opsporing en inventarisatie?

Het eerlijke antwoord hangt af van de schaal, maar het omslagpunt ligt eerder dan de meeste teams verwachten.

Factor	Handmatige/spreadsheet-audit	Geautomatiseerde tools voor opsporing en inventarisatie
Discovery-verslaggeving	Beperkt tot wat teams zelf rapporteren; mist verborgen en achtergebleven activa.	Continue scans van netwerken, endpoints en cloud-API's vinden assets die niemand heeft gemeld.
Valuta van gegevens	Alleen accuraat tot en met de laatste handmatige controle.	Wordt volgens een vast schema of continu vernieuwd, conform de verwachtingen van de auditors op grond van paragraaf 4.2.1.1.
Scale	Beheersbaar tot enkele honderden activa; daarboven loopt het mis.	Schaalbaar tot tienduizenden sleutels en certificaten in hybride en multi-cloudomgevingen.
47 dagen geldigheidsduur gereed	Kan het tempo van 8+ verlengingen per certificaat per jaar tegen 2029 niet bijhouden.	Geautomatiseerd verlengings- en inschrijfproces (ACME/EST) ontworpen voor frequente cycli.
Integriteit van het auditlogboek	Afhankelijk van handmatige discipline; het is makkelijk om achterop te raken of achteraf aanpassingen te maken.	Door het systeem gegenereerde, fraudebestendige logboeken die aan elke actie zijn gekoppeld.
Kostenprofiel	Lage gereedschapskosten, hoge en stijgende arbeidskosten naarmate de voorraad groeit.	Lagere platformkosten vooraf, aanzienlijk lagere doorlopende arbeidskosten bij schaalvergroting

Een spreadsheet is een redelijk uitgangspunt voor een kleine, grotendeels statische omgeving. Het is echter niet langer redelijk zodra de frequentie van certificaatvernieuwingen verdrievoudigt door de verkorte geldigheidsduur, of zodra een auditor vraagt ​​om een ​​datum voor een scan in plaats van een zelfgerapporteerde lijst. Platforms zoals CBOM Secure zijn specifiek ontworpen om dit probleem op te lossen door continu cryptografische activa te ontdekken en te inventariseren, inclusief sleutels en certificaten die met een handmatig proces nooit gevonden zouden worden.

Wat gebeurt er als een audit een kritieke bevinding aan het licht brengt?

Niet elke bevinding is routine. Wanneer een audit iets aan het licht brengt dat lijkt op een actieve inbreuk, een frauduleus certificaat dat buiten de goedgekeurde CA is uitgegeven, of een privésleutel die is blootgesteld in een openbare opslagplaats of logbestand, moet de bovenstaande herstelprocedure worden overgedragen aan de incidentrespons in plaats van in de normale herstelwachtrij te blijven staan.

1. containers Trek het betreffende certificaat onmiddellijk in of schakel de betreffende sleutel uit; wacht niet tot het normale vernieuwingsvenster.
2. Scope. Bepaal alles waarmee de gecompromitteerde sleutel of het certificaat in aanraking kon komen: wat ermee werd geverifieerd, wat ermee werd versleuteld en wat erop vertrouwde.
3. Informeer. Betrek het incidentresponsteam erbij en, indien de bevinding een inbreuk op CA-niveau of een gereguleerd gegevenstype betreft, de compliance- en juridische belanghebbenden die de openbaarmakingsverplichtingen bepalen.
4. Vervangen. Geef de vervangende sleutel of het certificaat uit en implementeer deze, nadat deze in de productieomgeving is geverifieerd, voordat u de bevinding sluit.
5. De oorzaak achterhalen en herhaling voorkomen. Bepaal hoe het activum aan de normale controle is ontsnapt (niet-geregistreerde uitgifte, ontbrekende scandekking, een hiaat in de polis) en los het proceshiaat op, niet alleen het betreffende activum.

Dit is precies de reden waarom een ​​gedocumenteerd plan voor de reactie op een CA-compromis, met een onderhouden back-up CA-relatie, belangrijker is dan een incident zich voordoet vóór het plaatsvindt. Beslissen wie een vertrouwde root uit de productietruststore mag verwijderen, is geen beslissing die je voor het eerst onder druk moet nemen.

Beslissingsgids: waar moet je je als eerste op richten?

Uw huidige status	Prioriteitsactie
Er bestaat geen volledig overzicht van sleutels en certificaten.	Voer eerst een detectiescan uit; u kunt immers niet classificeren of herstellen wat u niet hebt gevonden.
Er is wel inventaris aanwezig, maar deze is niet gekoppeld aan specifieke eigenaren.	Wijs voor elk actief een verantwoordelijke eigenaar toe vóór de volgende auditcyclus.
Certificaten worden handmatig verlengd bij vervaldatummeldingen.	Ga nu over op geautomatiseerde inschrijving (ACME/EST), vóór het verstrijken van de geldigheidsperiodes van 100 en 47 dagen.
Sleutels hebben geen vastgestelde cryptoperiode.	Stel maximale levensduurwaarden in volgens de risicorichtlijnen van NIST SP 800-57 en handhaaf deze in het sleutelbeheersysteem.
Bevindingen worden gecorrigeerd, maar niet opnieuw geverifieerd.	Voeg een verificatiestap toe aan het herstelproces voordat een bevinding als afgesloten kan worden gemarkeerd.
Voorbereiding op een PCI DSS- of SOC 2-beoordeling binnen 90 dagen	Geef prioriteit aan het genereren van bewijsmateriaal: actualiteit van de inventaris, data van beleidsherzieningen en toegangslogboeken.

Beperkingen

Geen enkel audit- en herstelprogramma sluit risico's volledig uit. Detectiescans kunnen niet alle assets vinden; sleutels die zijn ingebed in offline hardware, systemen zonder internetverbinding of verouderde apparaten vereisen nog steeds een handmatig registratieproces, en dat proces is afhankelijk van de aanwezigheid van mensen die het volgen. Geautomatiseerde tools verminderen, maar elimineren niet de noodzaak van gedefinieerde rollen en functiescheiding; een platform kan een aangewezen sleutelbeheerder of goedkeurder niet vervangen. En geen enkele cryptoperiode of geldigheidsschema beschermt tegen een sleutel of certificaat dat onjuist is behandeld voordat de rotatieperiode aanbrak. Daarom zijn toegangsbeleid en auditregistratie net zo belangrijk als het schema zelf.

Wat zou Encryption Consulting aanbevelen?

Beschouw sleutels en certificaten als twee verbonden, maar afzonderlijke auditsporen en stem de tools af op elk spoor. Voor cryptografische detectie en inventarisatie van uw volledige IT-omgeving, inclusief sleutels, biedt CBOM Secure u een continue, voor auditors geschikte inventarisatie die een spreadsheet op grote schaal niet kan bijhouden. Hiermee wordt precies de lacune gedicht waar PCI DSS 4.2.1.1 om vraagt. Specifiek voor certificaten, met name nu de geldigheidsperioden steeds korter worden (naar 47 dagen), automatiseert CertSecure Manager de detectie, uitgifte, verlenging en intrekking, inclusief de implementatieverificatie en auditregistratie die auditors verwachten.

Wanneer een programma een externe beoordeling nodig heeft vóór de volgende evaluatie, evalueren onze Encryption Advisory-diensten het bestaande sleutel- en certificaatlandschap van een organisatie, verfijnen ze het cryptografische en sleutelbeheerbeleid aan de hand van de huidige standaarden en helpen ze bij het opbouwen van het bewijsmateriaal dat auditors en beoordelaars daadwerkelijk verwachten. Dit alles wordt ondersteund door onze ISO/IEC 27001:2022 en SOC 2 gecertificeerde werkwijze.

Conclusie

Het controleren en corrigeren van sleutels en certificaten is niet langer een eenmalige jaarlijkse compliance-oefening. Het is een continue cyclus van ontdekking, classificatie, correctie en verificatie, die urgenter is geworden door de steeds korter wordende geldigheidsduur van certificaten van het CA/Browser Forum en strenger door wat PCI DSS 4.0 en SOC 2 nu van auditors verwachten. Organisaties die dit beschouwen als een doorlopende operationele discipline, met benoemde verantwoordelijkheden, gedefinieerde rotatietriggers en bewijsmateriaal dat als bijproduct van de workflow wordt gegenereerd in plaats van onder tijdsdruk te worden verzameld, zijn de organisaties die een audit ingaan zonder dat ze zich zorgen hoeven te maken.

Veelgestelde vragen

Hoe vaak moeten we onze sleutels en certificaten controleren?
Gezien de snelheid waarmee niet-geregistreerde activa verschijnen, moeten de inventarisatie en afstemming continu of minimaal maandelijks plaatsvinden. Een formele beleidsherziening is ten minste jaarlijks vereist volgens PCI DSS-vereiste 12.3.3, maar organisaties die zich voorbereiden op een SOC 2-audit voeren doorgaans elk kwartaal een volledige herstelcyclus uit om het bewijsmateriaal actueel te houden tussen de beoordelingsperioden.

Wat is het verschil tussen het controleren van sleutels en het controleren van certificaten?
Sleutels worden beheerd door cryptoperiodes, algoritme- en lengtebeleid en strikte toegangscontrole volgens NIST SP 800-57; de kernvraag is wie toegang heeft tot het sleutelmateriaal en hoe lang het geldig blijft. Certificaten worden beheerd door CA/Browser Forum-geldigheidslimieten, uitgiftebeleid en implementatieverificatie; de ​​kernvraag is of het certificaat dat in de productieomgeving wordt gepresenteerd, overeenkomt met wat daadwerkelijk is uitgegeven en waar het hoort te zijn.

Hebben we geautomatiseerde tools nodig, of kunnen we dit ook met spreadsheets afhandelen?
Spreadsheets kunnen prima werken voor een kleine, grotendeels statische inventaris, maar ze kunnen de continue behoefte aan certificaatvernieuwing of de versnelde vernieuwingsfrequentie van certificaten, veroorzaakt door de overstap van het CA/Browser Forum naar een geldigheidsduur van 47 dagen, niet bijbenen. De meeste organisaties bereiken het punt waarop geautomatiseerde tools voor certificaatvernieuwing en -inventarisatie zichzelf terugverdienen door bespaarde arbeidskosten en het voorkomen van storingen, ruim voordat ze tegen dat punt aanlopen.

Wat is de grootste fout die organisaties maken bij audits?
Niet-beheerde activa. Een sleutel of certificaat zonder aangewezen eigenaar kan niet met zekerheid worden overgedragen, verlengd of ingetrokken, omdat niemand kan bevestigen wat ervan afhangt. Door de eigendom direct bij uitgifte vast te stellen, en niet achteraf, worden de meeste problemen die bij een eerste audit aan het licht komen, opgelost.

Wat moeten we als eerste doen als een audit een gecompromitteerde sleutel of certificaat aan het licht brengt?
Begin met het inperken van de schade: trek het certificaat onmiddellijk in of deactiveer de sleutel in plaats van te wachten op een gepland rotatievenster. Breng vervolgens in kaart wat er is aangetast, informeer de betrokkenen bij incidentrespons en compliance, vervang en verifieer het nieuwe systeem in de productieomgeving en herstel de proceslacune waardoor het gecompromitteerde systeem onopgemerkt is gebleven.

Referenties

• NIST-onderzoek SP 800-57 Deel 1, Revisie 5, Aanbeveling voor sleutelbeheer: Deel 1, Algemeen
• CA/Browserforum, Stemming SC-081v3: Introductie van een schema voor het verkorten van de geldigheidsduur en de periodes voor hergebruik van gegevens.
• DigiCert, De officiële geldigheidsduur van TLS-certificaten wordt verkort tot 47 dagen.
• Rode zeef, Uw gids voor de cryptografische vereisten van PCI DSS 4.0