Typer av säkerhetsgranskningar

Alla granskningar är inte likadana. Beroende på vad ni behöver skydda, vilken mognadsnivå er säkerhetsorganisation har och vilka regulatoriska krav ni möter, krävs olika ansatser. Här är de fem viktigaste typerna vi arbetar med dagligen:

Penetrationstestning på djupet

Penetrationstest är den granskningsform som ger mest realistisk bild av er faktiska riskexponering. En sårbarhetsskanning hittar kända brister — ett penetrationstest visar vad en angripare faktiskt kan göra med dem.

Vi skiljer på tre ansatser:

• Black box — testaren har ingen förkunskap om systemet och agerar som en extern angripare. Realistiskt, men kan missa interna attackvägar.
• Grey box — testaren har begränsad åtkomst, exempelvis en vanlig användares inloggning. Simulerar en komprometterad medarbetare eller leverantör.
• White box — testaren har full insyn i källkod, arkitektur och nätverkstopologi. Ger djupast möjliga analys men är mest resurskrävande.

I praktiken rekommenderar vi grey box som standardansats för de flesta organisationer. Den ger bäst balans mellan realism och djup — och den speglar det vanligaste scenariot vi ser i verkligheten: en angripare som redan tagit sig förbi första försvarslinjen.

Konfigurationsgranskning — den underskattade hjälten

Enligt Datadogs State of Cloud har felkonfigurationer konsekvent varit bland de mest exploaterade attackvektorerna i molnmiljöer. Det här stämmer med vad vi observerar i Opsios SOC: de flesta säkerhetsincidenter vi hanterar beror inte på avancerade zero-day-exploits, utan på publikt exponerade S3-buckets, för breda IAM-roller eller säkerhetsgrupper som tillåter obegränsad inkommande trafik.

En konfigurationsgranskning kontrollerar att era molnresurser, servrar, nätverkskomponenter och brandväggar är härdade enligt etablerade ramverk — exempelvis CIS Benchmarks eller AWS Well-Architected Framework. Det här arbetet kan till stor del automatiseras med verktyg som AWS Config, Azure Policy eller tredjepartsverktyg som Prowler och ScoutSuite.

Molnsäkerhet med Opsio

Säkerhetsgranskning i molnmiljöer — specifika utmaningar

Att granska en traditionell on-premise-miljö och en modern molnmiljö kräver helt olika ansatser. I molnet förändras infrastrukturen konstant — nya resurser skapas via Terraform eller CloudFormation, containrar startas och stoppas inom sekunder, och den traditionella nätverksperimetern existerar inte längre.

Infrastructure as Code (IaC) som granskningsobjekt

I en modern DevOps-organisation definieras infrastrukturen i kod. Det skapar en fantastisk möjlighet för säkerhetsgranskning: istället för att bara granska den körande miljön kan ni granska koden som skapar miljön. Verktyg som Checkov, tfsec och Snyk IaC kan integreras i CI/CD-pipelinen och fånga felkonfigurationer innan de når produktion.

Det här är en av de mest kostnadseffektiva säkerhetsåtgärderna en organisation kan implementera. Att åtgärda en felkonfiguration i en Terraform-modul tar minuter. Att upptäcka och åtgärda samma felkonfiguration i produktion — efter att den redan exponerats — kan ta veckor och kosta mångdubbelt mer.

Delade ansvarsmodellen — er blinda fläck

AWS, Azure och Google Cloud är alla tydliga med att säkerhet i molnet är ett delat ansvar. Molnleverantören ansvarar för säkerheten av molnet (fysisk infrastruktur, hypervisor, nätverk). Ni ansvarar för säkerheten i molnet (data, åtkomstkontroll, applikationer, konfigurationer).

I praktiken ser vi att många organisationer underskattar sin del av ansvaret. En säkerhetsgranskning av er molnmiljö bör därför specifikt adressera:

• IAM-konfiguration — Följer ni principen om minsta möjliga behörighet? Har ni MFA på alla root-konton? Roteras nycklar regelbundet?
• Nätverkssegmentering — Är era VPC:er korrekt segmenterade? Exponeras interna tjänster mot internet?
• Kryptering — Krypteras data både i vila och under transport? Hanteras nycklar via KMS med lämpliga rotationsintervall?
• Loggning och övervakning — Är CloudTrail/Activity Log aktiverat? Loggas alla API-anrop? Övervakas loggarna aktivt?

Managerade molntjänster

Så genomför ni en säkerhetsgranskning — steg för steg

1. Definiera scope och mål

Börja med att avgränsa vad som ska granskas. En granskning av "allt" utan tydlig avgränsning ger diffusa resultat och sprängd budget. Identifiera era mest kritiska tillgångar (crown jewels) och börja där. Vanliga scopedefinitioner:

• Extern perimeter (publikt exponerade tjänster)
• Intern nätverkssegmentering
• Specifik applikation eller API
• Molnmiljö (AWS-konton, Azure-prenumerationer)
• Hela organisationen (inklusive fysisk säkerhet och processer)

2. Samla information och kartlägg tillgångar

Ni kan inte skydda det ni inte vet att ni har. Använd asset discovery-verktyg för att kartlägga alla servrar, tjänster, domäner, API:er och molnresurser. I molnmiljöer är AWS Config, Azure Resource Graph eller GCP Asset Inventory naturliga utgångspunkter.

3. Genomför teknisk granskning

Kör sårbarhetsskanning, penetrationstestning och konfigurationsgranskning enligt det scope ni definierat. Dokumentera alla fynd med:

• Beskrivning av sårbarheten
• Allvarlighetsgrad (vi rekommenderar CVSS v4.0 som bas, kompletterad med affärskontextuell bedömning)
• Bevis (screenshots, loggar, PoC-kod)
• Rekommenderad åtgärd med konkreta steg

4. Analysera och prioritera

Alla sårbarheter är inte lika kritiska. En SQL-injection i en publik webbapplikation som hanterar kunddata är oändligt mycket viktigare än en saknad HTTP-header på en intern testserver. Prioritera baserat på:

• Sannolikhet för exploatering (finns det publika exploits?)
• Affärspåverkan vid lyckad attack
• Hur enkel åtgärden är (quick wins först)

5. Rapportera och åtgärda

Rapporten bör ha två delar: en exekutiv sammanfattning för ledningen och en teknisk detaljrapport för IT-teamet. Varje fynd ska ha en tidsram för åtgärd. Vi rekommenderar:

6. Verifiera åtgärder

När åtgärderna är implementerade — verifiera att de faktiskt fungerar. Kör en rescan eller ett riktat retest. Det här steget hoppas ofta över, och det är ett misstag.

NIS2 och regulatoriska krav på säkerhetsgranskning

NIS2-direktivet, som Sverige implementerar genom den nya cybersäkerhetslagen, ställer uttryckliga krav på riskhantering och systematiskt säkerhetsarbete för organisationer som klassas som väsentliga eller viktiga. Artikel 21 i direktivet kräver bland annat:

• Riskanalys och säkerhetspolicyer
• Incidenthantering
• Driftkontinuitet och krishantering
• Säkerhet i leverantörskedjan
• Säkerhet vid förvärv, utveckling och underhåll av nätverks- och informationssystem

Regelbundna säkerhetsgranskningar är ett av de mest konkreta sätten att påvisa efterlevnad av dessa krav. Integritetsskyddsmyndigheten (IMY) och den nya tillsynsmyndigheten under NIS2 kan begära dokumentation på ert systematiska säkerhetsarbete — och böterna vid bristande efterlevnad är betydande.

Även GDPR:s artikel 32 kräver "lämpliga tekniska och organisatoriska åtgärder" — och en regelbunden säkerhetsgranskning är IMY:s förväntade miniminivå för att uppfylla det kravet.

Molnsäkerhet och compliance

Vad Opsios SOC ser i praktiken

Från vår 24/7-drift i Karlstad och Bangalore har vi identifierat återkommande mönster i de organisationer vi granskar:

De tre vanligaste fynden:

1. Överprivilegierade IAM-roller — Tjänstekonton med administratörsbehörigheter som skapades "tillfälligt" för tre år sedan och aldrig stramades åt. Det här är den enklaste vägen till eskalering vid ett intrång.

2. Saknad eller bristfällig loggning — Organisationer som inte kan svara på frågan "vad hände de senaste 30 dagarna i vår miljö?" har i praktiken inget detektionsförmåga. Utan loggar finns det inget att granska.

3. Ouppdaterade beroenden i applikationskod — Gamla versioner av npm-paket, Java-bibliotek eller Python-moduler med kända sårbarheter. Ofta trivialt att åtgärda med Dependabot eller Snyk, men konsekvent bortprioriterat.

Vad som skiljer organisationer med god säkerhetsmognad: De har inte nödvändigtvis fler verktyg eller större budget. De har en process — en dokumenterad cykel av granskning, åtgärd, verifiering och förbättring. Och de har ledningens engagemang, inte bara IT-avdelningens.

Managerad DevOps och säkerhet

Verktyg vi rekommenderar

Verktygen är bara en del av lösningen. Utan kompetens att tolka resultaten och prioritera åtgärderna är de värdelösa. Det är skillnaden mellan att ha en brandvarnare och att faktiskt ha en evakueringsplan.

Bygg en hållbar granskningsrutin

En enskild säkerhetsgranskning ger en ögonblicksbild. Värdet ligger i att göra det till en vana. Här är den cykel vi rekommenderar för de flesta medelstora organisationer:

• Kontinuerligt: Automatiserad sårbarhetsskanning och IaC-scanning i CI/CD-pipelinen
• Månadsvis: Genomgång av skanningsresultat, patching av kritiska sårbarheter
• Kvartalsvis: Penetrationstestning av prioriterade system, konfigurationsgranskning av molnmiljö
• Årligen: Fullständig säkerhetsrevision inklusive processer, policyer och leverantörsgranskning
• Vid förändring: Granskning vid större infrastrukturförändringar, nya applikationer eller förvärv

Cloud FinOps — optimera säkerhetsinvesteringar

Vanliga frågor

Hur ofta bör ett företag genomföra en säkerhetsgranskning?

Automatiserad sårbarhetsskanning bör köras minst månadsvis, medan penetrationstest rekommenderas kvartalsvis eller efter större förändringar i infrastrukturen. Verksamheter som omfattas av NIS2 behöver kunna visa en dokumenterad granskningscykel. I praktiken ser vi att organisationer med kontinuerlig scanning och kvartalsvisa manuella tester har betydligt kortare upptäcktstider vid incidenter.

Vad kostar en säkerhetsgranskning?

Kostnaden varierar kraftigt beroende på scope. En automatiserad sårbarhetsskanning av ett begränsat antal system kan kosta från tiotusentals kronor, medan en fullskalig penetrationstest med kodgranskning och konfigurationsanalys av en komplex molnmiljö kan hamna på flera hundra tusen kronor. Räkna dock alltid kostnaden mot vad ett intrång faktiskt kostar — då blir kalkylen enkel.

Vad är skillnaden mellan sårbarhetsskanning och penetrationstest?

Sårbarhetsskanning är automatiserad och hittar kända svagheter mot en databas av sårbarheter. Penetrationstest utförs av säkerhetsexperter som manuellt försöker utnyttja svagheterna och kedja ihop attackvägar, precis som en verklig angripare. Skanningen ger bredd, penetrationstestet ger djup. Du behöver båda.

Omfattas mitt företag av NIS2-direktivets krav på säkerhetsgranskning?

NIS2 omfattar organisationer inom 18 sektorer som klassas som väsentliga eller viktiga — däribland energi, transport, hälso- och sjukvård, digital infrastruktur och offentlig förvaltning. Även leverantörer till dessa sektorer kan omfattas indirekt genom krav på leverantörskedjan. Kontakta din jurist eller MSP för en formell bedömning.

Kan vi genomföra säkerhetsgranskning själva eller behöver vi extern hjälp?

Grundläggande sårbarhetsskanning kan skötas internt med verktyg som Nessus eller OpenVAS. Men för penetrationstestning och oberoende granskning rekommenderar vi alltid extern expertis. Interna team har blind spots — de har byggt systemen och känner inte igen sina egna felkonfigurationer. En extern granskare ser vad ni missar.