Cryptografische ontdekking: een complete gids voor het vinden van verborgen cryptografie binnen uw bedrijf.

Snel antwoord: Cryptografische ontdekking is het geautomatiseerde proces waarbij elke sleutel, elk certificaat, elk algoritme en elk protocol in een omgeving wordt gevonden, ongeacht of dit zich in de cloud, op hardware, in databases, mappen, bestandssystemen of broncode bevindt. CBOM Secure Het automatiseert het hele proces, van PKCS#11-objectenumeratie op HSM's tot diepgaande Active Directory-analyse, en produceert één enkele, ontdubbelde en van een risicoscore voorziene cryptografische materiaallijst. 

Key afhaalrestaurants 

• Het succes of falen van de detectie hangt af van de randvoorwaarden: de HSM-sleuf (Hardware Security Module) die niemand controleert, het krbtgt-record in Active Directory, het PEM-blok in een YAML-bestand. 
• CBOM Secure dekt de oppervlakken die certificaattools nooit bereiken: KMIP-servers, TDE-weergaven van databases, LDAP-attributen, GPG-sleutelringen en de broncode van applicaties. 
• Ondersteuning voor op standaarden gebaseerde protocollen betekent dat één platform complete ecosystemen van leveranciers bestrijkt: PKCS#11 v2.x voor HSM's, KMIP 1.0 tot en met 2.1 voor sleutelbeheerders, RFC 4523 voor LDAP-directory's. 
• Het feit dat dezelfde sleutel opduikt in een cloudkluis, een HSM en een gedeelde map wordt automatisch gedetecteerd, waardoor hergebruik van sleutels een bevinding wordt in plaats van onzichtbaar te blijven. 
• Het materiaal van de privésleutel wordt nooit gelezen of verplaatst; het platform registreert alleen metadata en vermeldingen van het bestaan ​​ervan. 
• De resultaten van het ontdekkingsproces dienen tevens als bewijs van naleving: De vereisten voor cryptografische inventarisatie van PCI DSS 4.0, de algoritmerichtlijnen van NIST en de kwantumgereedheidsmonitoring van CNSA 2.0 zijn allemaal gebaseerd op dezelfde continu bijgewerkte CBOM. 

Wat is cryptografische ontdekking? 

Cryptografische ontdekking is het geautomatiseerde identificeren en catalogiseren van cryptografische activa in een IT-omgeving. Een volledig ontdekkingsproces inventariseert sleutels met hun algoritmen en opslaglocaties, certificaten met hun ketens en vervaldatum, de protocolversies en cipher suites die actief worden onderhandeld, en de cryptografische aanroepen in de applicatiecode. Het is een voorwaarde voor bewijsmateriaal voor naleving, incidentrespons en post-kwantummigratieOmdat geen van die opties mogelijk is voor activa die je niet kunt zien.

Ontdekking heeft de afgelopen tijd om drie redenen hoger op de prioriteitenlijst gestaan. NIST heeft zijn eerste post-kwantumstandaarden afgerond (FIPS 203, 204 en 205) in augustus 2024, en de CNSA 2.0-richtlijnen van de NSA verwachten volledige invoering van kwantumveilige cryptografie in 2030. Daarom moet elke organisatie nu precies weten waar haar kwantumkwetsbare cryptografie zich bevindt. PCI DSS Versie 4.0 heeft een gedocumenteerde inventaris van cryptografische cipher suites en protocollen expliciet verplicht gesteld, een vereiste die vanaf 31 maart 2025 van kracht is. Aanvallen waarbij gegevens nu worden verzameld en later worden gedecodeerd, betekenen dat gevoelige gegevens met een lange levensduur nu al gevaar lopen, en niet pas op een of andere toekomstige datum.

Het lastige is de dekking. Een inventaris die 80 procent van uw cryptografie omvat, is niet voor 80 procent bruikbaar, omdat audits, datalekken en migraties worden bepaald door de activa in de resterende 20 procent. Deze handleiding beschrijft waar u zich op moet richten. geheimschrift welke locaties zich daadwerkelijk verbergen en hoe CBOM Secure elke verborgen locatie bereikt.

Wat moet een cryptografische ontdekkingstool allemaal kunnen?

Een praktische checklist, gebaseerd op de bronnen waar daadwerkelijke bevindingen vandaan komen. Als een tool die u evalueert een van deze bronnen niet kan bereiken, dan is dat de bron waar uw auditbevinding of incident uiteindelijk vandaan zal komen. 

• TLS-eindpunten, inclusief protocolversies en volledige opsomming van de cipher suites, niet alleen het certificaat. 
• Hardwarebeveiligingsmodules en tokens over PKCS#11, met inzicht in elk object in elke sleuf. 
• Sleutelpersonen binnen de onderneming over KMIP, waar opslagproducten en hypervisors hun sleutels vandaan halen. 
• Transparante gegevensversleuteling voor databases, waar de hoofdsleutels ter bescherming van gereguleerde gegevens zich bevinden. 
• Active Directory- en LDAP-directory's, die veel meer belangrijke informatie bevatten dan gebruikerscertificaten. 
• Bestandssystemen en ontwikkelaarssleutelringen, waarbij sleutels zich ophopen in PEM-bestanden, sleutelarchieven en GnuPG-ringen. 
• Cloud KMS voor alle gebruikte providers. met belangrijke specificaties en beveiligingsniveaus voor elke sleutel. 
• Applicatiebroncode, waarbij algoritmekeuzes en vastgelegde geheimen buiten het bereik van alle andere toolcategorieën vallen. 
• Gecompileerde binaire bestanden, die cryptografische bibliotheken en versies bevatten die nooit voorkomen in broncodeanalyses of infrastructuurinventarissen. 

Containerimages worden al gedekt door binaire analyse, en de dekking wordt steeds verder uitgebreid: Kubernetes-geheimen, CI/CD-pijplijn Integratie en cloudgeheimbeheerders staan ​​vervolgens op de roadmap van CBOM Secure. 

Hoe werkt TLS-eindpuntdetectie? 

CBOM Secure geeft een live optreden. TLS Analyse in plaats van certificaatverzameling. Voor elke host en poort identificeert het elke protocolversie en cipher suite die het eindpunt daadwerkelijk onderhandelt, markeert het verouderde protocollen, spoort het hybride suites van na Quantum op waar servers deze al aanbieden, en registreert het de volledige certificaatketen. Typische bevindingen zijn onder andere dat TLS 1.0 of 1.1 nog steeds is ingeschakeld. coderingssuites zonder forward secrecy, verlopen of niet-overeenkomende tussenliggende certificaten en zelfondertekende certificaten in productie. 

Waarom dit onderscheid belangrijk is: een perfect geldig, recent vernieuwd certificaat op een server die nog steeds TLS 1.0 met zwakke suites onderhandelt, is een compliance-bevinding volgens PCI DSS 4.0 en de NIST SP 800-52-richtlijnen, en is onzichtbaar voor tools die alleen naar het certificaat kijken. Dezelfde analyse is van toepassing op elk TLS-wrapped protocol, inclusief HTTPSLDAPS, SMTPS, IMAPS, POP3S en FTPS, op elke poort. 

Hoe werkt HSM-detectie via PKCS#11? 

CBOM Secure maakt verbinding met elke PKCS#11 v2.x-compatibele module en inventariseert elk certificaat en elke sleutel in elke sleuf: wat het is, welk algoritme en welke sleutelgrootte het gebruikt, wat het mag doen en of het kan worden geëxtraheerd. U krijgt een volledig en actueel overzicht van wat er zich daadwerkelijk in uw module bevindt. HSM Het landgoed wordt doorzocht en elke vondst wordt vergeleken met de rest van de inventaris, zodat hergebruikte sleutels direct aan het licht komen.

Omdat PKCS#11 een OASIS-standaardinterface is, dekt één platform het hele hardware-ecosysteem in plaats van dat er per leverancier een connector nodig is. De geteste dekking omvat drie groepen:

• Commerciële HSM's: Entrust nCipher en nShield, Thales Luna en SafeNet Luna, Utimaco SecurityServer en CryptoServer, IBM 4767, 4768 en 4769 cryptokaarten, Securosys Primus, Marvell LiquidSecurity en Atos Trustway Proteccio. 
• Cloud HSM's: AWS CloudHSM, Azure Dedicated HSM en Google Cloud HSM. 
• Ontwikkel en test HSM's en tokens: Yubico YubiHSM 2 en YubiKey PIV applets, Nitrokey HSM 2, smartcards via OpenSC inclusief PIV en CAC, en SoftHSM2 voor ontwikkeling en testen. 

Veelgebruikte leveranciersbibliotheken worden automatisch gedetecteerd, waardoor de dekking zich over de gehele omgeving uitstrekt met minimale configuratie. Operationeel gezien levert dit de bevindingen op die er echt toe doen: achtergebleven sleutels waarnaar geen enkele applicatie verwijst, inactieve objecten die nooit zijn gebruikt, uitneembare sleutels die volgens het beleid hardwaregebonden zouden moeten zijn, en duplicaten die op verschillende partities worden hergebruikt.

Hoe werkt de detectie van sleutelbeheerders via KMIP? 

CBOM Secure ondersteunt alle versies van het OASIS Key Management Interoperability Protocol, van 1.0 tot en met 2.1, met behulp van standaardconforme berichten. Het platform inventariseert daarom Thales CipherTrust Manager, Entrust KeyControl, IBM Security Key Lifecycle Manager, Fortanix Data Security Manager, Utimaco ESKM, Oracle Key Vault, Fornetix VaultCore, HashiCorp Vault in KMIP-modus, Cryptomathic CKMS, QuintessenceLabs qCrypt en elke andere conforme server, zonder leverancierspecifieke configuratie. 

Elke sleutel, certificaat en geheim op die servers wordt in de inventaris opgenomen met de volledige levenscyclusstatus. Een sleutel die is gedeactiveerd of als gecompromitteerd is gemarkeerd, wordt dus op die manier weergegeven in plaats van als een actief item. Zwakke en kwantumkwetsbare algoritmen worden gemarkeerd wanneer de server ze beschikbaar stelt. 

Een architectonisch aspect dat beoordelaars vaak over het hoofd zien: de gangbare encryptietoepassingen voor bedrijven, zoals VMware vSphere VM- en vSAN-encryptie, NetApp ONTAP-volume-encryptie, Nutanix en Dell EMC PowerProtect, maken gebruik van KMIP-clients, niet van servers. Hun sleutels bevinden zich op de KMIP-server, en dat is precies waar ze zich bevinden. CBOM Secure inventariseert ze. Het raadplegen van de gezaghebbende bron is zowel eenvoudiger als beter dan elke consument afzonderlijk te benaderen.

Hoe werkt de TDE-detectie in databases? 

CBOM Secure leest transparante metadata voor gegevensversleuteling rechtstreeks uit elke database-engine en levert zo het bewijs waar auditors om vragen: sleutelalgoritmen, beschermingscertificaten en vervaldatum. Het raakt nooit het sleutelmateriaal aan en verstoort de database niet. Waar de engine sleutelversies beschikbaar stelt, zoals MySQL en MariaDB doen voor InnoDB-tablespace-versleuteling, worden de metadata voor sleutelversies vastgelegd, zodat verouderde hoofdsleutels zichtbaar zijn in plaats van dat ze worden verondersteld.

Database	What You Get
SQL Server 2012+	Het TDE-sleutelalgoritme en de lengte ervan, de versleutelingsstatus en het beschermingscertificaat met de vingerafdruk en de vervaldatum.
Oracle 11g+	Status van de hoofdsleutel, status van Oracle Wallet en details over de versleuteling per tablespace en per kolom.
MySQL 5.7+ / MariaDB 10.1+	Status van de tablespace-encryptie, het en het versiebeheer van de sleutels.

Wat vindt CBOM Secure in Active Directory? 

De meeste tools beschouwen Active Directory als een container voor gebruikerscertificaten. CBOM Secure voert een diepgaande analyse in meerdere fasen uit over de gehele directory (meerdere forests en meerdere domeinen), en de informatie die het naar boven haalt gaat veel verder dan alleen certificaten.

• Gebruikers- en computercertificaten Aan de andere kant van het bos. Verlopen of zwakke certificaten zorgen hier voor problemen met de authenticatie en creëren een risico op identiteitsfraude. 
• SSH-publieke sleutels zijn Gepubliceerd in de map. Niet beheerd. SSH-sleutels Verleen permanente toegang die door niemand wordt gecontroleerd. 
• Windows Hello voor Bedrijven-sleutelsDit zijn de primaire inloggegevens, en onbeheerde of achtergebleven gegevens verzwakken de authenticatie zonder wachtwoord. 
• gMSA-rootsleutelsAls deze sleutels in gevaar komen, kan een aanvaller wachtwoorden voor serviceaccounts binnen het hele domein achterhalen. 
• krbtgt ondertekeningssleutelrecords en domeinvertrouwenssleutels, vastgelegd als louter bestaande gegevens. Verouderde krbtgt-sleutels maken golden-ticket-aanvallen mogelijk, en vertrouwenssleutels zijn doelwitten voor domeinovernames. 
• DPAPI-back-upsleutelsDeze sleutels kunnen gebruikers- en servicegeheimen domeinbreed decoderen. 
• BitLocker-herstelinformatieIedereen die herstelsleutels kan lezen, kan de beveiligde schijven decoderen. 
• De volledige hiërarchie van AD Certificate Services. Verkeerd geconfigureerde sjablonen en CA's vormen een goed gedocumenteerde manier om privileges te escaleren. 

De bevindingen worden aangevuld met de meest recente intrekkingsstatus, voor zover de uitgevende certificeringsinstantie deze publiceert. De gevoelige items worden geregistreerd als bestaansgegevens, nooit als sleutelmateriaal.

En hoe zit het met mappen die niet van Microsoft zijn? 

CBOM Secure dekt ook de rest van de directorywereld: OpenLDAP, 389 Directory Server en Red Hat Directory Server, FreeIPA, Samba4, Oracle Directory Server en Oracle Unified Directory, NetIQ eDirectory, IBM Security Directory Server, Apache Directory Server, OpenDJ en ForgeRock en PingDS, en elke RFC 4523-compatibele LDAP v3-server.

Wat u uit elke directory haalt: elk opgeslagen certificaat met een nauwkeurige intrekkingsstatus, elke gepubliceerde SSH-sleutel, S/MIME-materiaal en alles wat een applicatieteam in een aangepast attribuut heeft opgeslagen. Het platform detecteert dit automatisch voor alle gangbare sleutel- en certificaatformaten. Eén controle omvat alle leveranciers, in plaats van een connectorproject per directory. De zakelijke waarde: certificaten in verouderde directory's, vaak de oudste en minst gebruikte cryptografie binnen het bedrijf, verschijnen eindelijk in dezelfde inventaris en beleidscontroles als alle andere certificaten.

Waar passen mappen en sleutelhangers? 

Bestandsysteemdetectie doorloopt mappen recursief en analyseert de formaten waarin sleutelmateriaal daadwerkelijk wordt aangeleverd: PEM- en DER-certificaten en -ketens, CSR's, PKCS#7- en PKCS#12-containers, PKCS#8-sleutels, Java-sleutelarchieven in JKS- en JCEKS-formaat en OpenSSH-sleutels. Cruciaal is dat het ook PEM-blokken leest die zijn ingebed in YAML-, JSON- en applicatieconfiguratiebestanden, waar een opmerkelijke hoeveelheid productiesleutelmateriaal zich in stilte bevindt. 

Keyring discovery inventariseert GnuPG 1.x en 2.x keyrings in gebruikersmappen op Windows, Linux en macOS, inclusief RSA in alle gangbare formaten, DSA, ElGamal en moderne ECC, zoals Ed25519 en Curve25519. Wanneer de privésleutel zich daadwerkelijk op hardware bevindt, zoals een YubiKey 5 OpenPGP-applet of een Nitrokey, wordt de keyring stub geregistreerd als een publieke sleutel plus een record voor het bestaan ​​van de privésleutel. De inventaris geeft dus aan waar de ondertekeningssleutel zich bevindt zonder gegevens te hoeven extraheren. Typische bevindingen zijn onder andere verlopen ondertekeningssleutels die nog steeds worden vertrouwd door build-pipelines, verouderde 1024-bits DSA-sleutels, sleutels zonder ingestelde vervaldatum en privésleutels op schijf die volgens het beleid op hardware moeten staan. 

Hoe ver reikt de dekking van cloud- en vaultsystemen? 

Cloud discovery gaat verder dan het tellen van sleutels: 

• AWS: ACM-certificaten, asymmetrische KMS-sleutels met exacte sleutelspecificaties tot op secp256k1-niveau, en certificaten voor oudere IAM-servers. 
• Azuur: Key Vault-sleutels en -certificaten, Managed HSM en de TLS-koppelingen tussen App Service, Application Gateway, Front Door en API Beheergegevens worden gelijktijdig opgehaald voor snelheid. 
• Google Cloud: Cloud KMS-sleutelringen met rotatieperiode en beveiligingsniveau, waarmee HSM-ondersteunde sleutels worden onderscheiden van softwarematige sleutels. 
• HashiCorp-kluis: de PKI-engine inclusief uitgeversketens, de Transit-engine via RSA, ECDSAEd25519-, AES-GCM- en ChaCha20-Poly1305-sleutels, en KV v1 en v2 met namespace-ondersteuning. 

Native CertSecure Manager De integratie haalt de volledige certificaatinventaris op, inclusief de levenscyclusstatus. En omdat elke provider dezelfde gegevens aanlevert. CBOMMulticloudbeheer wordt één beleid dat overal wordt toegepast: hetzelfde algoritme en dezelfde rotatieregels worden geëvalueerd voor AWS, Azure en Google Cloud, en dubbele sleutels tussen clouds worden zichtbaar in plaats van verborgen te blijven in de consoles van elke provider.

Wat voegen broncode en binaire bestanden toe aan de ontdekking van nieuwe informatie?

Broncode is het ontdekkingsoppervlak dat alle andere tools overslaan, en het is de plek waar algoritmebeslissingen en hardgecodeerde geheimen zich bevinden. CBOM Secure analyseert statisch code in zeven talen: C en C++, Python, Java, Go, JavaScript en TypeScript, Rust en C#, in meer dan 70 cryptografische bibliotheken. De belangrijkste resultaten: hardgecodeerde sleutels, IV's en wachtwoorden die als KRITIEK worden gemarkeerd voordat ze incidenten worden, de daadwerkelijk gebruikte algoritmen die worden vastgesteld in plaats van geraden, en elke kwantumkwetsbare aanroep die wordt gemarkeerd voor migratieplanning. Scans worden uitgevoerd op lokale mappen, archieven en GitHub-repositories, volledig offline, zodat de code uw omgeving nooit verlaat. Typische bevindingen: hardgecodeerde AES-sleutels die in repositories zijn opgeslagen, verouderde SHA-1 die nog steeds wordt gebruikt voor handtekeningen of tokens, en hergebruik van statische IV's die stilletjes een anders sterke encryptie ondermijnen. 

Binaire analyse richt zich op de gecompileerde kant: welke cryptografische bibliotheken uw uitvoerbare bestanden daadwerkelijk bevatten, welke versies overeenkomen met bekende CVE's en of de binaire bestanden zijn ondertekend en geverifieerd. Elke bevinding heeft een betrouwbaarheidsniveau. Samen dichten bron- en binaire analyse de kloof tussen wat uw infrastructuur aangeeft en wat uw software daadwerkelijk doet. Ze vormen ook een natuurlijke aanvulling op een SBOM: de SBOM geeft aan welke bibliotheken u levert, de cryptografische weergave geeft aan welke algoritmen en sleutelverwerking die bibliotheken daadwerkelijk uitvoeren, en beide kunnen worden weergegeven in CycloneDX.

Agentloos of agentgebaseerd: welke ontdekkingsmethode wanneer? 

Agentloze detectie wordt door het platform geïnitieerd en vereist geen software op de doelsystemen; het omvat cloud-API's, KMIP-servers, databases, HSM's en TLS-eindpunten. Agentgebaseerde detectie maakt gebruik van lichtgewicht hostagents met kortstondige, beperkte referenties en omvat bestandssystemen, broncode, binaire bestanden en vertrouwensarchieven van het besturingssysteem. De meeste productieomgevingen combineren beide methoden, en detectietaken kunnen worden gepland en gekoppeld, zodat een scan op hostniveau een bestandssysteemanalyse activeert op basis van de gevonden gegevens. 

Aspect	Agentloos	Agent-gebaseerd
Hoe het werkt	Platformgestuurd; geen software geïnstalleerd op de doelapparaten.	Lichtgewicht hostagents met kortstondige, beperkte bevoegdheden.
Wat het omvat	Cloud-API's, KMIP-servers, databases, HSM's en TLS-eindpunten.	Bestandssystemen, broncode, binaire bestanden en vertrouwensarchieven van het besturingssysteem.
Opstartinspanning	Inloggegevens per doelapparaat; niets te installeren.	Agentimplementatie per host.
Best voor	Gecentraliseerde, via API bereikbare infrastructuur.	Hostgebonden materiaal dat niet toegankelijk is voor API's.

Hoe bevindingen tot één inventaris worden samengevoegd 

Elk ontdekkingsoppervlak voedt één pipeline: bevindingen worden genormaliseerd, ontdubbeld, gecorreleerd van certificaat naar sleutel, risicogescoord van 0 tot 100 en getagd voor beleid en kwantumveiligheid. Ontdubbeling zorgt ervoor dat dezelfde sleutel niet voorkomt in een cloudkluis, op een HSM-partitie en in een PEM-bestand – sleutelhergebruik dat geen enkele tool met één bron kan detecteren. Het resultaat is één CBOM, doorzoekbaar op algoritme, uitgever, sleutelgrootte of opslaglocatie, en exporteerbaar in CycloneDX.

Een praktisch voorbeeld: dezelfde RSA-2048-sleutel duikt op in een cloudkluis, op een HSM-partitie en in een PEM-bestand in een configuratieopslagplaats. Drie bronnen melden dit, deduplicatie reduceert het tot één item met drie locaties, en de bevinding van hergebruik van de sleutel wordt beoordeeld aan de hand van de meest blootgestelde kopie: het bestand. 

Test het op een rommelig subnet. 

De snelste evaluatie is een scan van de omgeving waarvan u vermoedt dat deze het meest kwetsbaar is. Kies een subnet, een directory of een repository, en we zullen samen bekijken wat er dan nodig is. CBOM Secure retourzendingen. Contact [e-mail beveiligd]. 

Wat onthult een eerste ontdekking doorgaans? 

Wanneer je voor het eerst een detectietest uitvoert in een echte omgeving, volgen de resultaten een vast patroon. De inventaris is groter dan wie dan ook had voorspeld, meestal aanzienlijk, omdat niemand de sleutels in pipelines, de door interne CA's uitgegeven certificaten of de cryptografie in applicatieafhankelijkheden had meegeteld. Bij geanonimiseerde eerste tests is het patroon consistent: inventarissen zijn doorgaans twee tot vier keer groter dan de schatting vooraf, ruim 90 procent van het asymmetrische materiaal is kwetsbaar voor kwantumcomputing en een klein percentage is al verouderd en moet nu worden aangepakt. Het aandeel kwantumcomputing is geen verrassing: RSA en elliptische-curve-cryptografie zijn nog steeds de standaard in elke gangbare stack. Het deel dat verouderd is, is het gevaarlijkst: MD5 en SHA-1 worden nog steeds gebruikt voor hashing, DES en RC4 nog steeds voor onderhandeling, en verouderde TLS-versies zijn nog steeds ingeschakeld voor achterwaartse compatibiliteit.

Die splitsing is belangrijk voor de planning. Het verouderde deel is klein maar urgent; het is het herstelwerk van dit kwartaal, ongeacht de tijdlijnen voor kwantumbeveiliging. Het veel grotere, kwantumkwetsbare deel betreft de migratieomvang. CBOM Secure rapporteert beide continu, zowel het aantal kwantumveilige als niet-kwantumveilige systemen, ondersteund door vastgestelde KPI's, zodat de gereedheid een meetbaar getal wordt in plaats van een schatting.

Discovery brengt ook de cryptografie aan het licht die niemand gebruikt, maar die iedereen wel levert: meerdere versies van dezelfde TLS-bibliotheek op één serverimage, keystores die zijn achtergelaten door verouderde applicaties, en overgebleven sleutels waarnaar geen enkele service verwijst. Slapend materiaal vormt een onopgemerkt aanvalsoppervlak en een stille migratieschuld. Omdat CBOM Secure slapende cryptografie scheidt van materiaal dat actief in productie wordt gebruikt, voorkomt het dat de omvang van uw migratie onnodig wordt vergroot. Dezelfde test detecteert hergebruik van sleutels, de ene sleutel die stilletjes wordt gedeeld tussen een cloudkluis, een HSM en een buildserver.

De laatste consistente bevinding is eerder organisatorisch dan technisch van aard. Certificaten worden aangemaakt door ontwikkelaars, pipelines en integraties met derden zonder dat de levenscyclus ervan wordt bijgehouden. Bovendien is er geen enkel team dat verantwoordelijk is voor het gehele systeem, waardoor onverwachte vervaldatums en beleidsschendingen pas worden ontdekt bij een storing of door een auditor. Daarom is het duurzame resultaat van deze ontdekking niet het eerste rapport, maar het operationele model dat het mogelijk maakt: continue inventarisatie, duidelijke verantwoordelijkheid en een beleidsevaluatie voor elk afzonderlijk onderdeel.

De inzet is asymmetrisch. Gegevens met een lange geheimhoudingsperiode, zoals medische dossiers, financiële gegevens en intellectueel eigendom, kunnen nu worden verzameld en later worden gedecodeerd, zodra er een voldoende krachtige kwantumcomputer beschikbaar is. Handtekeningen die vandaag de dag betrouwbaar zijn, kunnen later worden vervalst als het onderliggende algoritme faalt. Deze twee risico's, plus de inventarisatievereisten van PCI DSS 4.0 en de implementatiehorizon van CNSA 2.0, verklaren waarom een ​​eerste verkenningsronde doorgaans wordt gevolgd door een permanent programma.

Veelgestelde vragen 

Wat is cryptografische ontdekking?

De geautomatiseerde identificatie en catalogisering van alle cryptografische activa, sleutels, certificaten, algoritmen en protocollen binnen een omgeving, inclusief infrastructuur en applicatiecode. Het vormt de basis voor cryptografische compliance, incidentrespons en post-quantummigratie.

Wat is het verschil met certificaatdetectie?

Certificaatdetectie vindt X.509-certificaten, meestal op netwerkeindpunten. Cryptografische detectie inventariseert ook sleutels in HSM's en sleutelbeheerders; TDE-materiaal in databases; sleutels die in mappen zijn opgeslagen; bestanden en sleutelringen; en het gebruik van algoritmen in broncode.

Is het nodig om overal agents te installeren voor de detectie van beveiligingsproblemen?

Nee. Cloud-API's, KMIP-servers, databases, HSM's en TLS-eindpunten worden agentloos gescand. Lichtgewicht agents dekken bestandssystemen, broncode en vertrouwensarchieven van het besturingssysteem.

Kan het SSH-sleutels vinden?

Ja, op meerdere plaatsen: OpenSSH-bestanden op de schijf, openbare SSH-sleutels die zijn gepubliceerd in AD- en LDAP-directory's, en hardware-residentie sleutels via hun sleutelring-stubs.

Kan het sleutels vinden in configuratiebestanden?

Ja. Bestandsysteemdetectie analyseert PEM-blokken die zijn ingesloten in YAML-, JSON- en applicatieconfiguratiebestanden tijdens recursieve doorloopacties.

Wordt privésleutelmateriaal ooit openbaar gemaakt?

Nee. In alle HSM's, databases, directory's en hardwaretokens worden privésleutels alleen als metadata en bestaansgegevens vastgelegd.

Hoe vaak wordt de ontdekkingsfunctie uitgevoerd? 

Volgens het schema dat u instelt. Ontdekkingstaken worden georkestreerd, ingepland en aan elkaar gekoppeld, zodat de inventaris continu actueel blijft in plaats van afhankelijk te zijn van audits.

Wat gebeurt er met de bevindingen?

Ze worden genormaliseerd, ontdubbeld, gecorreleerd, voorzien van een risicoscore van 0 tot 100, geëvalueerd aan de hand van beleid en op aanvraag geëxporteerd in CycloneDX.

Wat ontdekken organisaties doorgaans tijdens een eerste onderzoek?

Meer cryptografie dan verwacht, waarvan het grootste deel kwetsbaar is voor kwantumaanvallen, een klein deel al verouderd is (MD5, SHA-1, DES) en onmiddellijk moet worden aangepakt, slapende bibliotheken en overgebleven sleutels die het aanvalsoppervlak vergroten, en certificaten zonder duidelijke eigenaar. De blijvende waarde zit hem in het omzetten van dit beeld in een traceerbaar, continu beheersysteem.

Kan cryptografische ontdekking post-kwantummigratie ondersteunen?

Ja. Kwantumgevoelige algoritmen worden automatisch gemarkeerd in sleutels, certificaten, protocollen en broncode, en kwantumveilige versus niet-kwantumveilige KPI's zetten de voortgang van de migratie om in een getal dat u kunt volgen ten opzichte van de CNSA 2.0-tijdlijnen.

Hoe lang duurt een eerste verkenningsscan?

Het hangt af van de omvang. Ontdekkingsruns worden per doelgebied afgebakend en ingepland, dus een eerste ronde wordt meestal gefaseerd, oppervlak voor oppervlak, uitgevoerd; in fusie- en overnamescenario's heeft het platform een ​​complete inventaris van een overgenomen omgeving gegenereerd, met prioriteitsbepaling. risico Resultaten binnen enkele uren. Na de eerste ronde draait de detectie continu volgens het door u ingestelde schema. 

Heeft de ontdekkingsfase invloed op productiesystemen?

Nee. Discovery is alleen-lezen: het vraagt ​​metadata op, nooit sleutelmateriaal, en wijzigt nooit een doelobject. Databases, HSM's en endpoints blijven dus gewoon productieverkeer verwerken terwijl ze worden gescand.

Kan detectie verouderde algoritmen opsporen?

Ja. DES, RC4, MD5, SHA-1, RSA-1024 en verouderde TLS-versies worden direct herkend en krijgen elk een ernstclassificatie, waardoor de wachtrij voor herstelwerkzaamheden zichzelf opbouwt.

Kan data-analyse schendingen van het cryptografische beleid aan het licht brengen?

Ja. Elk ontdekt actief wordt continu geëvalueerd aan de hand van het gekozen nalevingsbeleid, en overtredingen komen aan het licht als bevindingen met een trend van geslaagd/niet geslaagd in de loop van de tijd.

Start

Alle functionaliteiten die in deze handleiding worden beschreven, zijn momenteel in productieomgevingen beschikbaar. Neem contact op met Encryption Consulting om te zien wat CBOM Secure in uw omgeving detecteert. [e-mail beveiligd] of ga naar www.encryptionconsulting.com.