Introductie
Digitale beveiliging is jarenlang gebaseerd geweest op cryptografie die draait om wiskundige problemen die voor gewone computers zeer moeilijk op te lossen zijn. RSA En elliptische-curve-cryptografie vormen de basis van internetbeveiliging en beschermen zaken als banktransacties en software-updates.
Kwantumcomputers veranderen alles. Als kwantumcomputers krachtig genoeg worden, zouden ze de huidige gangbare encryptie snel kunnen kraken, waardoor gevoelige gegevens die jarenlang veilig leken, gevaar lopen. Een nog grotere zorg is 'nu verzamelen, later decoderen', waarbij aanvallers nu versleutelde gegevens verzamelen en wachten tot kwantumcomputers klaar zijn om ze te decoderen.
Als gevolg hiervan herzien organisaties hun volledige cryptografische infrastructuur en vragen ze zich af of ze er klaar voor zijn. Kunnen ze zonder grote aanpassingen overschakelen naar nieuwe algoritmen wanneer de standaarden veranderen? Dit is waar kwantumveilige paraatheid en cryptografische flexibiliteit van belang zijn, niet alleen bij het gebruik van nieuwe algoritmen, maar ook bij het met vertrouwen beheren en bijwerken van cryptografie in alle systemen.
De rol van TLS 1.3 in veilige communicatie
TLS 1.3 is het belangrijkste protocol dat gevoelige gegevens beschermt tijdens de overdracht via internet. Wanneer u een slotpictogram in uw browser ziet of een beveiligde API-aanroep uitvoert, werkt TLS op de achtergrond. TLS 1.3 is sneller dan oudere versies en maakt gebruik van sterkere standaardinstellingen, waardoor beveiligde verbindingen eenvoudiger op te zetten zijn.
Momenteel maakt TLS 1.3 voornamelijk gebruik van traditionele sleuteluitwisselings- en ondertekeningsalgoritmen, waardoor het nog steeds afhankelijk is van... geheimschrift die kwantumcomputers uiteindelijk zouden kunnen kraken. Om te beschermen tegen toekomstige bedreigingen, zou TLS tijdens de onderhandeling de voorkeur moeten kunnen geven aan kwantumveilige algoritmen. Zonder deze mogelijkheid zouden zelfs systemen die kwantumveilige opties ondersteunen, deze in de praktijk wellicht nooit gebruiken.
Een duidelijke en consistente manier om te zeggen 'gebruik eerst kwantumveilige oplossingen en val alleen terug op kwantumveilige oplossingen als dat nodig is' is belangrijk om implementaties in de praktijk haalbaar te maken.
Introductie van CBOM Secure
CBOM Secure is onze tool voor het volgen en beheren van cryptografische assets. Het helpt organisaties precies te zien hoe cryptografie in hun software en infrastructuur wordt gebruikt. In plaats van te gissen welke algoritmes in gebruik zijn of te hopen dat updates succesvol zijn geweest, creëert CBOM Secure een Crypto Bill of Materials (CBOM) met een overzicht van alle sleutels, certificaten en algoritmes in uw systemen.
Naarmate organisaties overstappen op kwantumveilige beveiliging, stelt CBOM Secure teams in staat te controleren of hun TLS-configuraties daadwerkelijk kwantumveilige voorkeuren gebruiken, te zien waar nog oude algoritmen aanwezig zijn en CBOM-rapporten te ondertekenen voor audits. In plaats van crypto-upgrades als een eenmalige taak te beschouwen, helpt onze tool u een continu overzicht te behouden van de cryptografie van uw systeem. Wanneer u overschakelt naar PQC in OpenSSL of elders, kunt u de wijziging bewijzen, volgen en erop vertrouwen.
Cryptografie en standaarden na het kwantumtijdperk
Inzicht in kwantumbedreigingen
De zorgen over kwantumcomputers zijn niet zomaar hype. Er zit een solide wiskundige basis achter. Beveiligingsexperts maken zich vooral zorgen over het algoritme van Shor, waarmee kwantumcomputers grote getallen kunnen ontbinden in factoren en discrete logaritmen veel sneller kunnen oplossen dan gewone computers. Deze twee problemen vormen de basis voor RSA en elliptische-krommecryptografie.
In het kort:
- RSA blijft veilig omdat het ontbinden van een enorm getal tegenwoordig ontzettend veel tijd kost.
- ECC blijft veilig omdat het oplossen van een discrete logaritme op een normale computer veel te lang zou duren om praktisch uitvoerbaar te zijn.
Maar een krachtige kwantumcomputer die gebruikmaakt van Shor's algoritme zou beide soorten encryptie binnen enkele uren of zelfs minuten kunnen kraken. Dit betekent dat gegevens die momenteel worden beschermd door encryptie, in gevaar kunnen komen. encryptie zou in de toekomst aan het licht kunnen komen.
Wanneer mensen het hebben over "kwantumveilige" systemen, bedoelen ze het gebruik van sleuteluitwisselings- en handtekeningalgoritmen die niet door kwantumcomputers kunnen worden gekraakt. Dit omvat doorgaans nieuwe PQC-schema's gebaseerd op wiskundige problemen zoals roosters, codes of hash-gebaseerde handtekeningen. In TLS heeft "kwantumveilig" specifiek betrekking op twee dingen:
- Sleuteloverdracht: ervoor zorgen dat sessiesleutels later niet meer kunnen worden hersteld
- Digitale handtekeningen: Het bewijzen van identiteit op een manier die een kwantumcomputer niet kan vervalsen.
Een systeem is pas kwantumveilig als het zowel sleuteluitwisseling als digitale handtekeningen omvat.
Normen en voorschriften
Wanneer cryptografie verandert, moeten standaardisatieorganisaties duidelijk definiëren wat is toegestaan, vereist of aanbevolen. Zonder dit zal niemand zijn systemen bijwerken. Dit gebeurt nu met de invoering van kwantumveilige technologie.
NSA CNSA 2.0 (Commerciële suite van nationale veiligheidsalgoritmen)
CNSA 2.0 is de richtlijn van de Amerikaanse overheid voor de bescherming van nationale veiligheidssystemen. Een belangrijk punt is dat instanties en leveranciers de voorkeur moeten geven aan kwantumveilige algoritmen in protocollen zoals TLS, in plaats van ze als optioneel te beschouwen. Dit betekent dat het onderhandelingsproces een keuze moet maken. PQC Ten eerste, waar mogelijk, en niet alleen theoretische steun bieden.
IBM Research heeft actief bijgedragen aan deze verschuiving, onder meer door verbeteringen aan OpenSSL die het mogelijk maken dat TLS 1.3 expliciet de voorkeur geeft aan een kwantumveilige sleuteldeling. Dat praktische voorbeeld laat zien hoe echte engineering aansluit bij de doelstellingen van de CNSA.
NIST PQC-standaardisatie
Ondertussen organiseert het National Institute of Standards and Technology (NIST) al geruime tijd een wereldwijde wedstrijd om kwantumveilige algoritmen voor dagelijks gebruik te selecteren. Deze inspanning heeft de eerste reeks definitieve selecties opgeleverd:
- Kyber voor sleuteluitwisseling (merknaam) ML-KEM)
- Dilithium, Falcon en SPHINCS+ voor handtekeningen
Gestandaardiseerde versies van deze algoritmen zullen naar verwachting op veel plaatsen verschijnen, waaronder in TLS-bibliotheken, browsers, firmware-updates en zelfs kleine IoT-apparaten. Maar de implementatie ervan zal tijd kosten. Organisaties hebben tools nodig om te testen, te verifiëren en te volgen waar en hoe deze nieuwe algoritmen worden gebruikt.
Op dit punt draait de overstap naar kwantumveilige beveiliging minder om de cryptografie zelf en meer om de werking en het inzicht. Hier zijn tools zoals onze CBOM Secure voor ontworpen, zoals later in dit blogartikel wordt besproken.
OpenSSL TLS 1.3 en algoritme-onderhandeling
Hoe TLS 1.3 cryptografische algoritmen kiest
Wanneer een browser, clienttoepassing of service een beveiligde verbinding tot stand wil brengen, TLS 1.3 Het begint met een bericht genaamd ClientHello. In dat bericht somt de client de ondersteunde algoritmen, cipher suites, ondertekeningsschema's en, het belangrijkste voor deze discussie, sleuteldeling op. Sleuteldeling definieert welke opties voor sleuteluitwisseling de client kan gebruiken om een ​​gedeeld geheim met de server te creëren.
De server antwoordt met ServerHello, waarmee een optie uit de lijst wordt geselecteerd en de handshake wordt voortgezet. De optie die de server kiest, vormt de basis voor de sessiesleutels die de verbinding beschermen.
TLS 1.3 bracht een grote verbetering door het aantal communicatierondes te verminderen en de handshake te vereenvoudigen. De manier waarop algoritmen worden gekozen is echter nog steeds eenvoudig: de server selecteert de eerste optie uit de lijst van de client die door beide partijen wordt ondersteund.
Dat klinkt onschuldig, maar het betekent:
- De volgorde waarin de klant belangrijke documenten verstuurt, is van belang.
- De interne ondersteuningslijst van de server is ook belangrijk.
- TLS zal niet automatisch de voorkeur geven aan iets, tenzij de logica daar specifiek voor is ontworpen.
In traditionele systemen werkt deze aanpak omdat alle sleuteluitwisselingsopties typen elliptische-kromme- of eindige-veldalgoritmen zijn. Maar nu er kwantumveilige opties zoals ML-KEM (Kyber) beschikbaar zijn, is de volgorde belangrijker. Zonder een voorkeursregel zou een systeem dat PQC ondersteunt, nog steeds klassieke algoritmen kunnen gebruiken, puur vanwege de volgorde.
Beperkingen in de huidige OpenSSL-onderhandeling
OpenSSL vormt de basis van een groot deel van de TLS-implementaties wereldwijd, direct in applicaties of via tools zoals nginx, Apache, HAProxy, mailservers, VPN's en SDK's. Het toevoegen van kwantumveilige algoritmen aan OpenSSL is belangrijk, maar ondersteuning alleen lost de operationele uitdagingen niet op.
De configuratieopties van OpenSSL bieden u tegenwoordig de volgende mogelijkheden:
- Specifieke sleuteluitwisselingsgroepen in- of uitschakelen
- Stel bestellijsten in voor ondersteunde groepen.
- Compileer OpenSSL met PQC-patches of hybride modi.
Deze controles bieden echter geen duidelijke, afdwingbare voorkeursregel zoals:
"Gebruik eerst kwantumveilige oplossingen en val alleen terug op kwantumveilige oplossingen als de client ze niet aankan."
Het gedrag van TLS is daarentegen sterk afhankelijk van:
- De belangrijkste aandelen in de order worden door de klant vermeld.
- De in de server gecompileerde volgorde, die mogelijk niet overeenkomt met het daadwerkelijke beleid.
- Verborgen standaardinstellingen die gekoppeld zijn aan OpenSSL-builds, niet aan het daadwerkelijke operationele beleid.
Dit betekent dat een organisatie het volgende zou kunnen doen:
- Schakel Kyber (ML-KEM) in OpenSSL in.
- PQC-coderingssuites configureren
- En ik heb PQC nog nooit daadwerkelijk zien gebruiken op live TLS-verkeer.
Dit komt doordat er in het onderhandelingsproces niets is dat een voorkeur afdwingt. Het is eerder een vorm van passieve ondersteuning; PQC wordt alleen gebruikt als beide partijen er toevallig voor kiezen.
Passieve ondersteuning is niet voldoende voor een kwantumveilige transitie. Bedrijven, auditors en compliance-teams moeten bewijzen dat PQC daadwerkelijk wordt gebruikt, en niet alleen maar hopen dat het gebeurt. Deze beperking is de reden waarom kwantumveilige onderhandeling nieuwe technische aanpassingen bovenop OpenSSL vereist.
Waar past CBOM Secure in het plaatje?
Automatisering van CBOM-generatie voor TLS-stacks
Het toevoegen van kwantumveilige functies aan OpenSSL is slechts een deel van de oplossing. Het andere deel is weten waar deze functies daadwerkelijk worden gebruikt. De meeste organisaties kunnen geen antwoord geven op basisvragen zoals:
- Welke servers gebruiken nog steeds alleen RSA?
- Welke OpenSSL-builds bevatten PQC-patches?
- Waarin verschillen TLS-bibliotheken in verschillende omgevingen?
Onze CBOM Secure helpt door automatisch een Crypto-stuklijst (CBOM), wat werkt als een gedetailleerde inventaris van cryptografische componenten binnen uw stack. Het kan systemen, bibliotheken, containers en verpakte binaire bestanden inspecteren om het volgende te identificeren:
- De gebruikte OpenSSL-versie
- Ondersteunde TLS-groepen en mogelijkheden voor sleuteluitwisseling
- Of PQC-algoritmen worden gecompileerd in
- Of PQC nu is ingeschakeld of gewoon aanwezig is.
In plaats van te vertrouwen op spreadsheets of giswerk, levert onze tool een gestructureerde, machinaal leesbare output in JSON-formaat of ondertekende rapporten die de werkelijke cryptografische status van uw TLS-infrastructuur weergeven.
Op deze manier hoeft u niet te wachten tot er problemen optreden om te ontdekken welke cryptografie er in de praktijk wordt gebruikt.
Ondersteuning voor kwantumveilige algoritmen verifiëren
Een van de grootste valkuilen in dit vakgebied is de aanname dat "ondersteuning gelijkstaat aan gebruik". Een server kan Kyber weliswaar gecompileerd hebben, maar er nooit een daadwerkelijke verbinding mee tot stand brengen.
Onze CBOM Secure lost dit probleem op door de configuratie en het gedrag te controleren, en niet alleen de aanwezigheid van software. Het kan:
- Scan OpenSSL-builds om te detecteren of PQC-sleuteldeelgroepen zijn ingeschakeld.
- Controleer de configuratiebestanden en omgevingsvariabelen die van invloed zijn op de TLS-onderhandeling.
- Markeer implementaties waarbij kwantumveilige instellingen bestaan ​​maar niet worden toegepast.
- Ik leg je precies uit welke systemen PQC kunnen gebruiken en welke nog steeds alleen de klassieke methode ondersteunen.
Voor grote organisaties zorgt dit voor onmiddellijke duidelijkheid. In plaats van algemene uitspraken zoals 'we bereiden ons voor op PQC', krijgen teams een duidelijk ja- of nee-antwoord voor elk onderdeel van hun omgeving.
Dit helpt ook bij audits. Wanneer u uw gereedheid moet aantonen, levert onze tool een ondertekend rapport dat bevestigt dat uw TLS-stack aan uw beleid voldoet.
Het volgen van hybride en traditionele algoritmen
Een kwantumveilige uitrol is geen kwestie van één keer omschakelen. Het is een gefaseerd proces waarbij de productie een combinatie kan omvatten van:
- Volledig kwantumveilige algoritmen
- Hybride algoritmen (klassiek + PQC gecombineerd)
- Legacy RSA/ECC is nog steeds actief voor compatibiliteitsdoeleinden.
Onze CBOM Secure registreert deze status duidelijk in plaats van alles op één hoop te gooien. Het kan u het volgende vertellen:
- Welke systemen onderhandelden over zuivere PQC-sessies?
- Welke van de onderhandelde hybride sessies (bijvoorbeeld: ML-KEM + X25519)?
- Welke bleven alleen op de legacy-modus staan?
Dit inzicht helpt teams slimme beslissingen te nemen. Bijvoorbeeld:
- Als hybride nog steeds veel gebruikt wordt, ondersteunen klanten PQC mogelijk nog niet.
- Als de oude systemen dominant blijven, is de migratieplanning niet compleet.
Onze CBOM Secure zet deze punten om in meetbare controlepunten in plaats van aannames. U krijgt inzicht in de voortgang en kunt hierover rapporteren op een manier die zowel het management, de beveiligingsteams als de engineeringteams begrijpen.
Uitdagingen en best practices
Veelvoorkomende valkuilen bij integratie
Overstappen op kwantumveilige algoritmen in TLS klinkt in theorie eenvoudig: ML-KEM inschakelen, configuraties aanpassen en klaar. Maar in de praktijk doen zich vaak diverse problemen voor:
- TLS-proxies verwijderen stilletjes PQC-extensies. Sommige middleware verwijdert onbekende sleuteldelingswaarden, waardoor clients zonder waarschuwing terugvallen op de klassieke methode.
- Variaties in de build kunnen per omgeving verschillen. Een server in de stagingomgeving gebruikt mogelijk een PQC-compatibele OpenSSL-build, terwijl de productieomgeving onbewust een oudere versie gebruikt.
- Verwarring rondom hybride systemen. Ontwikkelteams schakelen hybride cipher suites in, maar gaan ervan uit dat dit betekent dat pure PQC al in gebruik is.
- Gebrek aan inzicht in mislukkingen. Wanneer de PQC-onderhandeling mislukt, wordt er bij veel implementaties niets geregistreerd, waardoor teams ervan uitgaan dat het gelukt is.
De grootste valkuil is denken dat PQC 'ingeschakeld' is, terwijl er in werkelijkheid niets is veranderd in het netwerkverkeer.
Beste praktijken voor gereedschap en onderhoud
De voorbereiding op kwantumveilige TLS betekent dat cryptografie moet worden behandeld als elk ander softwareonderdeel: het moet worden voorzien van versiebeheer, getest en regelmatig gecontroleerd. Hier volgen een paar werkwijzen om dit te beheren:
- Versie vastzetten: Zorg ervoor dat de OpenSSL-builds die in productie worden gebruikt, vastgelegd en bijgehouden worden. Ga er niet vanuit dat de pakketrepository's van het besturingssysteem altijd dezelfde functionaliteiten bevatten.
- Integratietests: Voeg end-to-end toe TLS-handdruk Tests in CI-pipelines. Controleer de daadwerkelijke ClientHello/ServerHello-uitvoer om te bevestigen dat PQC is overeengekomen.
- Automatisering: Gebruik geautomatiseerde tools om builds en omgevingen te scannen in plaats van te vertrouwen op handmatige controles of documentatie.
- Gesigneerde artefacten: Genereer ondertekende CBOM-gebaseerde rapporten, zodat audit- en beveiligingsteams de naleving kunnen aantonen zonder handmatig systemen te hoeven doorzoeken.
- Doorlopende wijzigingen: Introduceer PQC door je te richten op een subset van serBij ondeugden moet je eerst de resultaten meten en dan pas uitbreiden.
Kortom, beschouw PQC-ondersteuning als iets dat je in de loop der tijd moet onderhouden, niet als een eenmalige configuratiewijziging.
Operationele paraatheid en monitoring
Het inschakelen van PQC-ondersteuning is alleen nuttig als je kunt bewijzen dat het daadwerkelijk in productie gebeurt. Dat vereist operationele controles, niet alleen controles tijdens de implementatie.
Teams dienen rekening te houden met het volgende:
- TLS-handshake-telemetrie: Verzamel realtime verbindingsgegevens en houd bij welke sleuteluitwisselingsgroepen worden onderhandeld.
- Waarschuwingsdrempels: Activeer waarschuwingen als het PQC-gebruik onverwacht daalt, wat kan duiden op regressies of configuratieafwijkingen.
- Geplande scans op basis van CBOM: Genereer de crypto-inventarissen automatisch wekelijks of maandelijks om veranderingen in de loop van de tijd te signaleren.
- Vergelijking tussen de verschillende niveaus: Ontwikkeling, testfase en productie moeten vergelijkbare cryptografische eigenschappen vertonen. Als er verschillen zijn, moeten deze worden opgespoord.
Operationele paraatheid betekent dat je het antwoord weet op vragen zoals:
- Gebruiken we PQC tegenwoordig nog wel?
- Zo niet, waardoor is het dan tegengehouden?
- Wie moet het repareren?
Door monitoring en rapportage wordt het gebruik van PQC meetbaar, en wat je kunt meten, kun je verbeteren.
Toekomstige richtingen
Evoluerende standaarden en algoritmesuites
Het vakgebied cryptografie is constant in beweging. NIST heeft zijn eerste reeks post-kwantumalgoritmen afgerond, maar er worden meer updates verwacht, waaronder parameterwijzigingen, nieuwe profielen voor lichtgewicht apparaten en verbeteringen op basis van onderzoek of feedback uit de praktijk.
Aankomende wijzigingen kunnen van invloed zijn op:
- Welke Kyber/ML-KEM-parameterreeksen worden de "standaard" voor openbaar internetverkeer?
- De vraag is of nieuwe handtekeningsystemen Dilithium in bepaalde niches zullen vervangen.
- De hybride vereisten duren langer dan verwacht, met name in sectoren met trage nalevingscycli.
- Profielen voor IoT, mobiele apparaten en apparaten met beperkte mogelijkheden die kleinere toetsen of aangepaste varianten vereisen.
Organisaties die hun aannames nu vastleggen in hun code, kunnen later problemen ondervinden. Het doel zou moeten zijn crypto-behendigheidHierdoor kunnen systemen algoritmes en instellingen wijzigen zonder dat applicaties kapotgaan of dat er downtime ontstaat. De komende jaren zullen organisaties zoals NIST, IETF en NSA naar verwachting duidelijkere implementatieprofielen, handshake-richtlijnen en op PQC gerichte TLS-beleidskaders publiceren.
Onze CBOM Secure uitbreiden voor meer crypto-flexibiliteit
Op dit moment richt onze CBOM Secure-tool zich op inzicht, door te laten zien welke cryptografie er daadwerkelijk in een omgeving aanwezig is. De volgende stap is om organisaties te helpen actie te ondernemen op basis van deze informatie.
De geplande route omvat onder meer:
- Geautomatiseerde herstelprocessen: Wanneer onze CBOM Secure detecteert dat een systeem geen PQC-ondersteuning biedt, kan dit handhavingsworkflows activeren, zoals het markeren van CI-pipelines, het openen van tickets of het implementeren van gepatchte binaire bestanden.
- Cloud-first ondersteuning: Native integraties met AWS ACM, Azure Key Vault en Google Cloud KMS Om de cryptografie in gehoste services in kaart te brengen, aangezien veel TLS-eindpunten tegenwoordig in de cloud eindigen en niet lokaal.
- Handhaving tijdens runtime: Optionele modus waarbij PQC-voorkeursbeleid rechtstreeks in services wordt doorgevoerd, zodat onderhandelingsregels niet ongemerkt in de loop van de tijd kunnen veranderen.
- Feedbackloops voor ontwikkelaars: Waarschuwingen weergeven binnen buildsystemen, zodat engineers fouten in de cryptografische configuratie ontdekken tijdens het vastleggen van wijzigingen in plaats van na de implementatie.
Het doel op lange termijn is simpel: de voorbereiding op kwantumveilige systemen automatiseren, zodat dit onderdeel uitmaakt van reguliere software-updates en niet langer een groot jaarlijks project is.
Conclusie
Kwantumcomputing is niet zomaar een toekomsttheorie; het dwingt organisaties nu al om na te denken over hoe hun certificaten, sleutels en TLS-stacks bestand zijn tegen nieuwe decryptiebedreigingen. Wachten tot deadlines of lastminute wijzigingen van leveranciers is riskant. Teams die nu actie ondernemen, hebben meer controle, een betere planning en soepelere overgangen in plaats van gehaaste oplossingen.
Onze CBOM Secure-tool voor encryptieconsulting speelt een cruciale rol bij de voorbereiding van organisaties. In plaats van te werken met spreadsheets, handmatige OpenSSL-uitvoer of verspreide configuratiebestanden, biedt onze CBOM-tool een helder overzicht van het cryptografische gebruik in verschillende omgevingen. Het laat zien welke algoritmen worden gebruikt, wat er moet veranderen voor beveiliging na de kwantumcomputertijd en of systemen aan de beveiligingsdoelstellingen voldoen. Voor organisaties die zich voorbereiden op bestuursvergaderingen, architectuurkeuzes of complianceplanning, biedt onze tool duidelijkheid en snelheid.
Onze CBOM Secure is meer dan alleen een rapportagetool; het versnelt ook het proces. Het automatiseert cryptografische inventarisaties, controleert TLS-configuraties, valideert algoritmen en stemt beleid af, zodat teams van de ontdekkingsfase direct naar de actiefase kunnen overgaan zonder te hoeven gissen. In toekomstige releases is Encryption Consulting van plan om geautomatiseerde oplossingen, cloud-native integraties en beleidshandhaving toe te voegen om configuraties te allen tijde in lijn te houden met de beveiligingsnormen.
Nu is een uitstekend moment om te beginnen: test PQC Breng in een testomgeving uw huidige cryptogebruik in kaart en begin met het opstellen van interne beleidsregels. Als uw organisatie kwantumveilige projecten wil testen, feedback wil geven of wil meewerken aan de ontwikkeling van nieuwe functies, moedigen wij van Encryption Consulting u aan contact met ons op te nemen. Hoe eerder de teams beginnen, hoe gemakkelijker het werk op de lange termijn zal zijn.
Heeft uw organisatie behoefte aan ondersteuning, gestructureerde assessments of een begeleide aanpak? Encryption Consulting staat klaar om u te helpen met workshops, advies en implementatieondersteuning met behulp van onze CBOM Secure. Neem vandaag nog contact met ons op, zodat u vol vertrouwen de overstap kunt maken in plaats van te wachten tot u daartoe gedwongen wordt.
