Cyber- och kvantsäkerhet

På grund av avlyssna nu, dekryptera senare. Trafik som spelas in i dag kan dekrypteras när en tillräckligt kapabel kvantdator finns, så data som måste förbli hemliga i åratal är redan i riskzonen. Migreringen tar dessutom år i ett stort systemlandskap, och nationella färdplaner för PQC sätter tidsfrister för den.

Läs mer: Postkvantkryptografi och kvantsäker krypteringLänk till den här frågan

En CBOM listar varje kryptografisk algoritm, nyckel och certifikat i dina system och var var och en används, ungefär som en komponentförteckning för programvara listar komponenter. Den visar vad som måste ändras och låter dig bevisa för en revisor att inget sårbart finns kvar.

Läs mer: Postkvantkryptografi och kvantsäker krypteringLänk till den här frågan

Inte om ändringen sker i etapper. Postkvantnycklar och signaturer är större, och vissa äldre enheter och partner klarar dem ännu inte. Vi använder hybridlägen och en dubbelstackad PKI under övergången, testar varje system mot dess partner och håller en väg tillbaka.

Läs mer: Postkvantkryptografi och kvantsäker krypteringLänk till den här frågan

NIST:s postkvantstandarder: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) och FIPS 205 (SLH-DSA), tillämpade i protokoll som TLS 1.3. Vi anpassar planen till de nationella PQC-färdplaner och sektorregler som gäller för dig, i Mellanöstern, Europa och Asien.

Läs mer: Postkvantkryptografi och kvantsäker krypteringLänk till den här frågan

En icke-mänsklig identitet är varje konto, nyckel eller token som används av programvara i stället för av en människa: tjänstekonton, API-nycklar och nu även AI-agenter. De är lätta att skapa och lätta att glömma, och många upphör aldrig. En AI-agent som agerar på egen hand med en sådan nyckel kan göra stor skada om den vilseleds eller nyckeln stjäls.

Läs mer: Säkerhet för agentisk AI och identitet för AI-agenterLänk till den här frågan

Ett angrepp som gömmer instruktioner i innehåll som en AI-modell läser, som ett e-postmeddelande, ett dokument eller en webbsida, så att modellen följer angriparen i stället för sin användare. Det kan inte förhindras enbart av modellen. Försvaret kombinerar skyddsräcken för indata och utdata, agenter med begränsad åtkomst och mänskligt godkännande av känsliga åtgärder.

Läs mer: Säkerhet för agentisk AI och identitet för AI-agenterLänk till den här frågan

I stället för en permanent nyckel begär agenten åtkomst när en uppgift börjar. Den får en autentiseringsuppgift begränsad till den uppgiften och den tiden, och behörigheten upphör när uppgiften är klar. Varje begäran loggas, så att du kan se vilken agent som gjorde vad och på vems vägnar.

Läs mer: Säkerhet för agentisk AI och identitet för AI-agenterLänk till den här frågan

Vi kommer överens om omfattning och regler och angriper sedan dina modeller och agenter som en motståndare skulle göra: jailbreaks, promptinjektion, verktygsförgiftning och försök att komma åt data. Du får varje fynd med stegen för att återskapa det, rangordnat efter risk, och vi testar igen efter åtgärderna.

Läs mer: Säkerhet för agentisk AI och identitet för AI-agenterLänk till den här frågan

Det beror på leverantörens villkor, vilken region modellen körs i och vad du skickar till den. Vi granskar de tre, lägger kontroller mot dataläckage framför modellen och rekommenderar en suverän eller privat modell i stället där datan inte får lämna din jurisdiktion.

Läs mer: Säkerhet för agentisk AI och identitet för AI-agenterLänk till den här frågan

Inte på en gång. Zero trust införs i etapper, vanligen med början i de känsligaste applikationerna och administratörsåtkomsten. VPN:en kan vara kvar för det som fortfarande behöver den och avvecklas när inget längre är beroende av den.

Läs mer: Åtgärd av exponering, zero trust och DevSecOpsLänk till den här frågan

En komponentförteckning för programvara listar varje komponent och bibliotek i en programvara, med version. När en ny sårbarhet tillkännages säger den snabbt om du är påverkad och var. Regelverk som EU:s Cyber Resilience Act (CRA) och många kunder efterfrågar nu en sådan.

Läs mer: Åtgärd av exponering, zero trust och DevSecOpsLänk till den här frågan

Varje ingenjör har ett namngivet konto med bara de rättigheter uppgiften kräver och loggar in med en hårdvarusäkerhetsnyckel. Där det finns en process för administratörsåtkomst följer vi den. Sessionerna loggas och åtkomsten tas bort när arbetet avslutas eller någon lämnar projektet.

Läs mer: Åtgärd av exponering, zero trust och DevSecOpsLänk till den här frågan

Ett stående program i stället för ett årligt test. Det håller en aktuell lista över vad en angripare kan nå, rangordnar varje exponering efter hur sannolikt den används och vad den skulle kosta dig samt följer varje åtgärd tills den är stängd. Skanningen körs löpande och testningen följer varje betydande ändring.

Läs mer: Åtgärd av exponering, zero trust och DevSecOpsLänk till den här frågan

En repetition under verkliga förhållanden. Ett red team angriper dina system inom överenskomna regler medan ditt blue team, de som upptäcker och agerar, försvarar dem. Efteråt går båda sidor igenom vad som hittades, vad som missades och hur lång tid varje steg tog, och du får de ändringar som stänger luckorna.

Läs mer: Åtgärd av exponering, zero trust och DevSecOpsLänk till den här frågan

Ja. Övervakningen utformas med dina styringenjörer för att observera styrtrafiken i stället för att ändra den, och varje ändring i anläggningssystemen följer dina ändrings- och säkerhetsrutiner. Säkerhet och drifttid går först.

Läs mer: Konvergerat SOC/NOC, motståndskraft och OT/IoT-försvarLänk till den här frågan

Att först återställa systemen i en isolerad miljö, kontrollera att de återställda systemen och datan är fria från angriparen och först därefter ta dem i drift igen. Det hindrar en återställning från att smitta nätverket på nytt.

Läs mer: Konvergerat SOC/NOC, motståndskraft och OT/IoT-försvarLänk till den här frågan

Börja med de system som skulle skada mest om de angreps: oftast de som håller kund- eller betaldata, flyttar pengar eller håller verksamheten igång. En fokuserad bedömning av dem visar de svagheter som betyder något och ger en rangordnad plan. Om du använder AI-agenter eller har data som måste hållas hemlig i många år är granskningen av postkvantkryptografi och agentsäkerhet det naturliga första steget.

Läs mer: Cyber & QuantumLänk till den här frågan

Vi gör inte anspråk på egna certifikat. Vår verksamhet, vår källkod och de molnarbetsbelastningar vi driver för kunder vilar på infrastruktur vars leverantörer har dessa intyg, och vi utvecklar dina system så att de klarar de revisioner du möter. Vår sida om säkerhet och förtroende förklarar hur.

Läs mer: Cyber & QuantumLänk till den här frågan

Ja. Vi jämför dina kontroller med den standard eller regel du måste uppfylla, som DORA, NIS2, Saudi NCA ECC eller SAMA:s regler, visar gapen och hjälper dig att stänga dem. Du behåller underlag som en revisor kan kontrollera. Vi certifierar dig inte själva: certifiering ges av ett ackrediterat organ, och vi hjälper dig att förbereda dess revision.

Läs mer: Cyber & QuantumLänk till den här frågan

En bedömning granskar hur dina system är utformade, konfigurerade och drivna och hittar gapen mot erkänd god praxis. Ett penetrationstest angriper systemen inom överenskomna regler för att visa vad en angripare faktiskt skulle kunna nå. De två fungerar bäst tillsammans: bedömningen visar problemens bredd, testet visar deras djup.

Läs mer: Cyber & QuantumLänk till den här frågan

Vi planerar testningen för att undvika skada. System, tider och metoder avtalas i förväg. Vi testar i en miljö som inte är produktionsmiljö när den matchar produktionen tillräckligt väl och undviker störande tester om du inte godkänner dem. En namngiven kontakt hos dig kan stoppa testet när som helst.

Läs mer: Cyber & QuantumLänk till den här frågan