Cyber- og kvantesikkerhed

På grund af “høst nu, dekrypter senere”. Trafik, der opsnappes i dag, kan dekrypteres, når der findes en tilstrækkeligt kraftig kvantecomputer, så data, der skal forblive hemmelige i årevis, er allerede i fare. Migreringen tager også år i et stort IT-landskab, og nationale køreplaner for overgangen til PQC fastsætter tidsfrister for den.

Læs mere: Postkvantekryptografi og kvantesikker krypteringLink til dette spørgsmål

En CBOM viser alle kryptografiske algoritmer, nøgler og certifikater i dine systemer, og hvor hver af dem bruges, ligesom en softwarestykliste viser komponenter. Den viser, hvad der skal ændres, og den lader dig bevise over for en revisor, at intet sårbart er tilbage.

Læs mere: Postkvantekryptografi og kvantesikker krypteringLink til dette spørgsmål

Ikke hvis ændringen sker i etaper. Postkvantenøgler og -signaturer er større, og nogle ældre enheder og partnere kan ikke håndtere dem endnu. Vi bruger hybride tilstande og en PKI med dobbelt stak under overgangen, tester hvert system mod dets partnere og bevarer muligheden for tilbagerulning.

Læs mere: Postkvantekryptografi og kvantesikker krypteringLink til dette spørgsmål

NISTs postkvantestandarder: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) og FIPS 205 (SLH-DSA), anvendt i protokoller som TLS 1.3. Vi afstemmer planen med de nationale PQC-køreplaner og de sektorregler, der gælder for dig i Mellemøsten, Europa og Asien.

Læs mere: Postkvantekryptografi og kvantesikker krypteringLink til dette spørgsmål

En ikke-menneskelig identitet er enhver konto, nøgle eller token, der bruges af software i stedet for en person: servicekonti, API-nøgler og nu AI-agenter. De er nemme at oprette og nemme at glemme, og mange udløber aldrig. En AI-agent, der handler på egen hånd med en sådan nøgle, kan gøre stor skade, hvis den vildledes, eller nøglen bliver stjålet.

Læs mere: Sikkerhed for agentisk AI og identitet for AI-agenterLink til dette spørgsmål

Et angreb, der skjuler instruktioner i indhold, som en AI-model læser, fx en e-mail, et dokument eller en webside, så modellen følger angriberen i stedet for sin bruger. Det kan ikke forhindres af modellen alene. Forsvaret kombinerer guardrails på input og output, agenter med begrænset adgang og menneskelig godkendelse af følsomme handlinger.

Læs mere: Sikkerhed for agentisk AI og identitet for AI-agenterLink til dette spørgsmål

I stedet for en permanent nøgle beder agenten om adgang, når en opgave begynder. Den får adgangsoplysninger, der er begrænset til den opgave og det tidsrum, og de udløber, når opgaven slutter. Hver anmodning logges, så du kan se, hvilken agent der gjorde hvad, og på hvis vegne.

Læs mere: Sikkerhed for agentisk AI og identitet for AI-agenterLink til dette spørgsmål

Vi aftaler omfanget og reglerne og angriber derefter dine modeller og agenter, som en modstander ville: jailbreaks, prompt-injektion, værktøjsforgiftning og forsøg på at trække data ud. Du får hvert fund med trinene til at genskabe det, prioriteret efter risiko, og vi tester igen efter rettelserne.

Læs mere: Sikkerhed for agentisk AI og identitet for AI-agenterLink til dette spørgsmål

Det afhænger af udbyderens vilkår, den region, modellen kører i, og hvad du sender til den. Vi gennemgår de tre ting, tilføjer kontroller mod læk foran modellen og anbefaler i stedet en suveræn eller privat model, hvor dataene ikke må forlade din jurisdiktion.

Læs mere: Sikkerhed for agentisk AI og identitet for AI-agenterLink til dette spørgsmål

Ikke med det samme. Nultillid indføres i etaper, som regel begyndende med de mest følsomme applikationer og administratoradgangen. VPN’en kan blive til det, der stadig har brug for den, og udfases, når intet længere afhænger af den.

Læs mere: Afhjælpning af eksponering, nultillid og DevSecOpsLink til dette spørgsmål

En softwarestykliste viser hver komponent og hvert bibliotek i et stykke software med versionsnummer. Når en ny sårbarhed offentliggøres, fortæller den dig hurtigt, om og hvor du er ramt. Regler som EU’s forordning om cyberrobusthed (CRA) og mange kunder kræver nu en.

Læs mere: Afhjælpning af eksponering, nultillid og DevSecOpsLink til dette spørgsmål

Hver ingeniør har en navngiven konto med kun de rettigheder, opgaven kræver, og logger ind med en hardwaresikkerhedsnøgle. Hvor du har en proces for administratoradgang, følger vi den. Sessioner logges, og adgangen fjernes, når arbejdet slutter, eller nogen forlader projektet.

Læs mere: Afhjælpning af eksponering, nultillid og DevSecOpsLink til dette spørgsmål

Et fast program i stedet for en årlig test. Det fører en aktuel liste over, hvad en angriber kan nå, prioriterer hver eksponering efter, hvor sandsynligt det er, at den udnyttes, og hvad den vil koste dig, og følger hver rettelse, indtil den er lukket. Scanningen kører løbende, og der testes efter hver væsentlig ændring.

Læs mere: Afhjælpning af eksponering, nultillid og DevSecOpsLink til dette spørgsmål

En øvelse under virkelige forhold. Et red team angriber dine systemer inden for aftalte regler, mens dit blue team, de folk, der opdager og reagerer, forsvarer dem. Bagefter gennemgår begge sider, hvad der blev fundet, hvad der blev overset, og hvor lang tid hvert trin tog, og du får de ændringer, der lukker hullerne.

Læs mere: Afhjælpning af eksponering, nultillid og DevSecOpsLink til dette spørgsmål

Ja. Overvågningen designes sammen med dine automationsingeniører, så den observerer styringstrafikken i stedet for at ændre den, og enhver ændring på anlægssystemer følger dine ændrings- og sikkerhedsprocedurer. Sikkerhed og oppetid kommer først.

Læs mere: Konvergeret SOC/NOC, cybermodstandsdygtighed og OT/IoT-forsvarLink til dette spørgsmål

At gendanne systemerne i et isoleret miljø først, kontrollere, at de gendannede systemer og data er fri for angriberen, og først derefter sætte dem i drift igen. Det forhindrer, at en gendannelse geninficerer netværket.

Læs mere: Konvergeret SOC/NOC, cybermodstandsdygtighed og OT/IoT-forsvarLink til dette spørgsmål

Begynd med de systemer, der ville gøre mest skade, hvis de blev angrebet: som regel dem, der rummer kunde- eller betalingsdata, flytter penge eller holder forretningen kørende. En fokuseret vurdering af dem viser de svagheder, der betyder noget, og giver dig en prioriteret plan. Hvis du bruger AI-agenter eller har data, der skal forblive hemmelige i årevis, er revisionen af postkvante- og agentsikkerhed det naturlige første skridt.

Læs mere: Cyber og kvanteLink til dette spørgsmål

Vi påberåber os ingen egne certifikater. Vores drift, vores kildekode og de cloudworkloads, vi kører for kunder, ligger på infrastruktur, hvis udbydere har disse attesteringer, og vi udvikler dine systemer, så de består de revisioner, du står over for. Vores side om sikkerhed og tillid forklarer hvordan.

Læs mere: Cyber og kvanteLink til dette spørgsmål

Ja. Vi sammenligner dine kontroller med den standard eller regulering, du skal opfylde, som DORA, NIS2, Saudi-Arabiens NCA ECC eller SAMA’s regler, viser hullerne og hjælper dig med at lukke dem. Du har dokumentation, som en revisor kan kontrollere. Vi certificerer dig ikke selv: certificeringen udstedes af et akkrediteret organ, og vi hjælper dig med at forberede dig til dets revision.

Læs mere: Cyber og kvanteLink til dette spørgsmål

En vurdering gennemgår, hvordan dine systemer er designet, konfigureret og drevet, og finder hullerne i forhold til anerkendt god praksis. En penetrationstest angriber systemerne inden for aftalte regler for at vise, hvad en angriber reelt kan nå. De to virker bedst sammen: vurderingen viser problemernes bredde, testen deres dybde.

Læs mere: Cyber og kvanteLink til dette spørgsmål

Vi planlægger testen, så den undgår skade. Systemer, tidspunkter og metoder aftales på forhånd. Vi tester i et miljø uden for produktion, når det ligner produktionen tilstrækkeligt, og undgår forstyrrende test, medmindre du godkender dem. En navngiven kontaktperson hos dig kan stoppe testen når som helst.

Læs mere: Cyber og kvanteLink til dette spørgsmål