Cybersikkerhet og kvanteteknologi

På grunn av «høst nå, dechiffrer senere». Trafikk som tas opp i dag, kan dechiffreres når en kapabel kvantedatamaskin finnes, så data som må holdes hemmelige i årevis, er allerede i risiko. Migrering tar også år i et stort systemlandskap, og nasjonale veikart for PQC-overgang setter frister for den.

Les mer: Postkvantekryptografi og kvantesikker krypteringLenke til dette spørsmålet

En CBOM lister opp hver kryptografisk algoritme, nøkkel og sertifikat i systemene dine og hvor hver brukes, omtrent som en programvarefortegnelse lister opp komponenter. Den viser hva som må endres, og lar deg bevise for en revisor at ingenting sårbart står igjen.

Les mer: Postkvantekryptografi og kvantesikker krypteringLenke til dette spørsmålet

Ikke hvis endringen gjøres trinnvis. Postkvantenøkler og postkvantesignaturer er større, og enkelte eldre enheter og partnere kan ennå ikke håndtere dem. Vi bruker hybridmoduser og en tostacket PKI i overgangen, tester hvert system mot partnerne og holder en tilbakerullingsvei åpen.

Les mer: Postkvantekryptografi og kvantesikker krypteringLenke til dette spørsmålet

NIST-standardene for postkvantekryptografi: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) og FIPS 205 (SLH-DSA), brukt i protokoller som TLS 1.3. Vi tilpasser planen til de nasjonale PQC-veikartene og sektorreglene som gjelder for deg, i Midtøsten, Europa og Asia.

Les mer: Postkvantekryptografi og kvantesikker krypteringLenke til dette spørsmålet

En ikke-menneskelig identitet er enhver konto, nøkkel eller token som brukes av programvare i stedet for en person: tjenestekontoer, API-nøkler og nå KI-agenter. De er enkle å opprette og enkle å glemme, og mange utløper aldri. En KI-agent som handler på egen hånd med en slik nøkkel, kan gjøre stor skade hvis den blir villedet eller nøkkelen blir stjålet.

Les mer: Sikkerhet for agentisk KI og KI-agenters identitetLenke til dette spørsmålet

Et angrep som skjuler instruksjoner i innhold en KI-modell leser, for eksempel en e-post, et dokument eller en nettside, slik at modellen følger angriperen i stedet for brukeren. Det kan ikke forhindres av modellen alene. Forsvaret kombinerer verneregler på inndata og utdata, agenter med begrenset tilgang og menneskelig godkjenning av sensitive handlinger.

Les mer: Sikkerhet for agentisk KI og KI-agenters identitetLenke til dette spørsmålet

I stedet for en permanent nøkkel ber agenten om tilgang når en oppgave starter. Den får en legitimasjon begrenset til den oppgaven og det tidsrommet, og legitimasjonen utløper når oppgaven er ferdig. Hver forespørsel logges, slik at du kan se hvilken agent som gjorde hva og på vegne av hvem.

Les mer: Sikkerhet for agentisk KI og KI-agenters identitetLenke til dette spørsmålet

Vi avtaler omfang og regler, og angriper deretter modellene og agentene dine slik en motstander ville gjort: jailbreaks, promptinjeksjon, verktøyforgiftning og forsøk på å hente ut data. Du får hvert funn med trinnene for å gjenskape det, rangert etter risiko, og vi tester på nytt etter utbedringene.

Les mer: Sikkerhet for agentisk KI og KI-agenters identitetLenke til dette spørsmålet

Det avhenger av leverandørens vilkår, regionen den kjører i og hva du sender den. Vi gjennomgår disse tre, legger inn lekkasjekontroller foran modellen og anbefaler en suveren eller privat modell der dataene ikke kan forlate jurisdiksjonen din.

Les mer: Sikkerhet for agentisk KI og KI-agenters identitetLenke til dette spørsmålet

Ikke med en gang. Nulltillit innføres trinnvis, vanligvis med de mest sensitive applikasjonene og administratortilgang først. VPN-en kan bli for det som fortsatt trenger den, og avvikles når ingenting er avhengig av den.

Les mer: Utbedring av eksponering, nulltillit og DevSecOpsLenke til dette spørsmålet

En programvarefortegnelse (SBOM) lister opp hver komponent og hvert bibliotek i en programvare, med versjon. Når en ny sårbarhet kunngjøres, viser den raskt om du er berørt og hvor. Regelverk som EUs cyberresiliensforordning (CRA), og mange kunder, krever nå en.

Les mer: Utbedring av eksponering, nulltillit og DevSecOpsLenke til dette spørsmålet

Hver ingeniør har en navngitt konto med bare de rettighetene oppgaven krever, og logger på med en maskinvarebasert sikkerhetsnøkkel. Der du har en prosess for administratortilgang, følger vi den. Økter logges, og tilgangen fjernes når arbeidet er ferdig eller noen forlater prosjektet.

Les mer: Utbedring av eksponering, nulltillit og DevSecOpsLenke til dette spørsmålet

Et fast program i stedet for en årlig test. Det holder en oppdatert liste over hva en angriper kan nå, rangerer hver eksponering etter hvor sannsynlig det er at den brukes og hva den ville koste deg, og følger opp hver utbedring til den er lukket. Skanning kjøres kontinuerlig, og testing følger hver vesentlig endring.

Les mer: Utbedring av eksponering, nulltillit og DevSecOpsLenke til dette spørsmålet

En generalprøve under reelle forhold. Et rødt team angriper systemene dine innenfor avtalte regler, mens det blå teamet ditt, de som oppdager og responderer, forsvarer dem. Etterpå går begge sider gjennom hva som ble funnet, hva som ble oversett og hvor lang tid hvert steg tok, og du får endringene som lukker gapene.

Les mer: Utbedring av eksponering, nulltillit og DevSecOpsLenke til dette spørsmålet

Ja. Overvåkingen utformes sammen med kontrollingeniørene dine for å observere kontrolltrafikk, ikke endre den, og alle endringer i anleggssystemer følger dine endrings- og sikkerhetsprosedyrer. Sikkerhet og oppetid kommer først.

Les mer: Konvergert SOC/NOC, motstandsdyktighet i cybersikkerheten og forsvar av OT/IoTLenke til dette spørsmålet

Systemene gjenopprettes først i et isolert miljø, man kontrollerer at de gjenopprettede systemene og dataene er fri for angriperen, og først da settes de i drift igjen. Det hindrer at en gjenoppretting smitter nettverket på nytt.

Les mer: Konvergert SOC/NOC, motstandsdyktighet i cybersikkerheten og forsvar av OT/IoTLenke til dette spørsmålet

Start med systemene der et angrep ville gjort mest skade: vanligvis de som har kunde- eller betalingsdata, flytter penger eller holder driften i gang. En målrettet vurdering av dem viser svakhetene som betyr noe og gir deg en rangert plan. Hvis du bruker KI-agenter eller har data som må holdes hemmelige i årevis, er revisjonen av postkvante- og agentsikkerhet det naturlige første steget.

Les mer: Cybersikkerhet og kvanteteknologiLenke til dette spørsmålet

Vi hevder ikke å ha egne sertifikater. Driften vår, kildekoden og skyarbeidsbelastningene vi kjører for kunder, ligger på infrastruktur der leverandørene har slike attesteringer, og vi bygger systemene dine slik at de består revisjonene du står overfor. Siden vår om sikkerhet og tillit forklarer hvordan.

Les mer: Cybersikkerhet og kvanteteknologiLenke til dette spørsmålet

Ja. Vi sammenligner kontrollene dine med standarden eller regelverket du må oppfylle, som DORA, NIS2, de saudiarabiske NCA ECC-reglene eller SAMA-reglene, viser avvikene og hjelper deg med å lukke dem. Du beholder revisjonsbevis som en revisor kan kontrollere. Vi sertifiserer deg ikke selv: sertifisering gis av et akkreditert organ, og vi hjelper deg med å forberede deg for revisjonen.

Les mer: Cybersikkerhet og kvanteteknologiLenke til dette spørsmålet

En vurdering går gjennom hvordan systemene dine er utformet, konfigurert og driftet, og finner avvik mot anerkjent god praksis. En penetrasjonstest angriper systemene innenfor avtalte regler, for å vise hva en angriper faktisk kan nå. De to fungerer best sammen: vurderingen viser bredden i problemene, testen viser dybden.

Les mer: Cybersikkerhet og kvanteteknologiLenke til dette spørsmålet

Vi planlegger testingen for å unngå skade. Systemer, tidspunkter og metoder avtales på forhånd. Vi tester i et testmiljø når det ligner produksjon godt nok, og unngår forstyrrende tester med mindre du godkjenner dem. En navngitt kontakt hos deg kan stoppe testen når som helst.

Les mer: Cybersikkerhet og kvanteteknologiLenke til dette spørsmålet