Applikationssäkerhet kontra nätverkssäkerhet – varför båda behövs men skyddar olika saker

Många organisationer investerar tungt i nätverkssäkerhet och antar att det räcker. Det gör det inte. Här är den fundamentala skillnaden:

En brandvägg stoppar inte en SQL-injektion som utnyttjar bristfällig indatavalidering i er egen kod. Omvänt skyddar SAST-skanning inte mot en DDoS-attack mot ert nätverk. Båda lagren behövs, och de behöver samverka.

OWASP Top 10: er grundläggande checklista

OWASP (Open Worldwide Application Security Project) uppdaterar regelbundet sin Top 10-lista – den mest refererade sammanställningen av webbapplikationssårbarheter. Den senaste versionen lyfter bland annat:

A01: Broken Access Control

Den vanligaste sårbarhetskategorin. Användare kan agera utanför sin behörighet – exempelvis komma åt andra kunders data genom att ändra en parameter i URL:en. I vår SOC ser vi detta regelbundet i kundmiljöer där auktoriseringslogiken testas bristfälligt.

A02: Cryptographic Failures

Felaktig eller obefintlig kryptering av känslig data. Vanliga misstag inkluderar hårdkodade nycklar i källkod, användning av föråldrade algoritmer (MD5, SHA-1 för lösenordshashning) och avsaknad av TLS.

A03: Injection

SQL-injektion, NoSQL-injektion, OS-kommandoinjektion. Trots att det är en välkänd attackkategori dyker det fortfarande upp i produktionskod – särskilt i äldre applikationer och intern tooling som "ingen attackerar ändå".

A07: Security Misconfiguration

Standardlösenord, onödigt exponerade endpoints, verbose felmeddelanden i produktion. I molnmiljöer på AWS (eu-north-1) och Azure (Sweden Central) ser vi detta ofta i form av öppna S3-buckets eller felkonfigurerade IAM-policyer. Molnsäkerhet

OWASP Top 10 är en startpunkt, inte ett slutmål. Den täcker de vanligaste sårbarheterna men ersätter inte en dedikerad hotmodellering för er specifika arkitektur och affärslogik.

DevSecOps: säkerhet integrerad i utvecklingsflödet

DevSecOps är inte ett buzzword – det är ett driftsmönster som flyttar säkerhetsansvar till vänster i utvecklingscykeln ("shift left"). Istället för att testa säkerhet efter release, bäddas kontroller in i varje steg av CI/CD-pipelinen.

Så ser en praktisk DevSecOps-pipeline ut

1. Kodfas – Pre-commit hooks som skannar efter hemligheter (API-nycklar, lösenord) med verktyg som GitLeaks eller TruffleHog

2. Byggfas – SAST (Static Application Security Testing) skannar källkoden. SCA (Software Composition Analysis) inventerar tredjepartsberoenden mot kända CVE:er

3. Testfas – DAST (Dynamic Application Security Testing) testar den körande applikationen utifrån, som en extern angripare

4. Stagingfas – IAST (Interactive Application Security Testing) kombinerar statisk och dynamisk analys under integrationstester

5. Releasefas – Policy-as-code validerar att inga kritiska sårbarheter (CVSS ≥ 9.0) går vidare till produktion

6. Driftfas – Runtime Application Self-Protection (RASP), loggning till SIEM, kontinuerlig övervakning i SOC

Det avgörande: skanningsresultaten måste nå utvecklarna direkt i deras arbetsflöde – som kommentarer i pull requests, inte som en PDF tre veckor senare. Friktionsfri feedback är skillnaden mellan säkerhet som faktiskt används och säkerhet som ignoreras.

Managerad DevOps

Verktygsval: pragmatik framför perfektion

Ni behöver inte köpa en dyr enterprise-plattform dag ett. Börja med:

Viktigare än verktyget är att ni faktiskt agerar på resultaten. En backlog med 2 000 obesvarade SAST-fynd är värre än ingen skanning alls – det skapar en falsk trygghet.

GDPR och NIS2: regulatoriska krav på applikationsnivå

GDPR – dataskydd genom design

GDPR artikel 25 ("Data protection by design and by default") kräver att ni bygger in dataskydd i era system redan vid designstadiet. Artikel 32 specificerar tekniska och organisatoriska åtgärder, inklusive:

• Kryptering och pseudonymisering av personuppgifter
• Förmåga att säkerställa konfidentialitet, integritet och tillgänglighet
• Processer för att regelbundet testa och utvärdera skyddsåtgärdernas effektivitet

Integritetsskyddsmyndigheten (IMY) har utfärdat sanktionsavgifter mot svenska organisationer för bristande tekniska skyddsåtgärder – inklusive fall där otillräcklig åtkomstkontroll i applikationer exponerat personuppgifter.

NIS2 – utökade krav för fler sektorer

NIS2-direktivet, nu implementerat i svensk lag, utvidgar kretsen av organisationer som omfattas och ställer skärpta krav på riskhantering, incidentrapportering (inom 24 timmar för tidiga varningar) och leveranskedjans säkerhet. För applikationssäkerhet innebär det konkret:

• Riskanalys av applikationer som behandlar data inom väsentliga eller viktiga sektorer
• Incidenthanteringsplaner som inkluderar applikationslager-incidenter
• Supply chain-säkerhet – ni ansvarar för att tredjepartskomponenter i er applikation inte introducerar sårbarheter

Managerade molntjänster

Prioriteringsramverk: riskbaserad säkerhet i praktiken

Alla applikationer förtjänar inte samma säkerhetsnivå. En intern wiki och ett kundvänt betalningssystem har fundamentalt olika riskprofiler. Använd ett riskbaserat ramverk:

Steg 1: Klassificera era applikationer

• Kritisk – behandlar betalningsdata, personuppgifter, hälsodata. Exponerad mot internet.
• Hög – intern applikation med tillgång till känsliga system. Begränsad exponering.
• Medium – stödsystem utan direkt tillgång till känslig data.
• Låg – statiska sidor, intern dokumentation.

Steg 2: Anpassa kontrollnivå

Det här ramverket låter er rikta resurser dit de gör mest nytta. En vanlig fälla vi ser hos kunder är att behandla alla applikationer lika – vilket antingen ger för lite skydd för kritiska system eller orimliga kostnader för lågrisksystem.

Molnspecifika överväganden

Applikationssäkerhet i molnet skiljer sig från on-premise på flera sätt. I AWS, Azure och GCP delar ni ansvaret med leverantören enligt shared responsibility model – men applikationslagret är alltid ert ansvar.

Konkreta åtgärder för molnbaserade applikationer:

• Secrets management – använd AWS Secrets Manager, Azure Key Vault eller HashiCorp Vault. Aldrig miljövariabler i klartext.
• Container-säkerhet – skanna containerimages med Trivy eller Snyk innan deployment. Kör inte som root.
• API-säkerhet – implementera rate limiting, autentisering (OAuth 2.0/JWT) och indatavalidering för alla API-endpoints. API:er är den nya attackytan.
• Infrastructure as Code – skanna Terraform- och CloudFormation-templates med Checkov eller tfsec för att fånga felkonfigurationer innan de provisioneras.

Molnmigrering

Vad vi ser i Opsios SOC: vanliga misstag

Från vår 24/7 SOC/NOC i Karlstad och Bangalore ser vi återkommande mönster hos organisationer som råkar ut för applikationsrelaterade incidenter:

1. Exponerade admin-gränssnitt – /admin, /wp-admin, interna API-dokumentationssidor utan autentisering

2. Föråldrade beroenden – Log4Shell (CVE-2021-44228) dyker fortfarande upp i produktionsmiljöer

3. Överdrivna IAM-behörigheter – applikationsservicekonton med administratörsrättigheter "för att det fungerade"

4. Avsaknad av loggning – när incidenten väl inträffar finns det inget att analysera

5. Testhemligheter i produktion – API-nycklar till testmiljöer som av misstag hamnat i produktionskonfigurationen

Dessa misstag är inte komplicerade att åtgärda. De uppstår när säkerhet behandlas som en eftertanke snarare än en del av utvecklingsprocessen.

Komma igång: en 90-dagarsplan

Vecka 1–2: Inventera era applikationer. Klassificera dem enligt riskramverket ovan. Identifiera era tre mest kritiska.

Vecka 3–6: Implementera automatiserad SAST och SCA i CI/CD-pipelinen för de kritiska applikationerna. Börja med Semgrep + Trivy om ni inte har budget för kommersiella verktyg.

Vecka 7–10: Genomför hotmodellering för era kritiska applikationer. Engagera utvecklare, arkitekter och driftspersonal. Dokumentera attackytor och prioritera åtgärder.

Vecka 11–12: Beställ penetrationstest av en oberoende part för era mest exponerade tjänster. Skapa en åtgärdsplan med tidsatta aktiviteter.

Löpande: Inför säkerhets-champions i varje utvecklingsteam. Koppla skanningsresultat till teamets sprint-backlog. Mät trend, inte absoluta tal – det viktiga är att antalet kritiska fynd minskar över tid.

Cloud FinOps

Vanliga frågor

Vad är skillnaden mellan applikationssäkerhet och nätverkssäkerhet?

Nätverkssäkerhet skyddar infrastruktur och trafik – brandväggar, segmentering, IDS/IPS. Applikationssäkerhet fokuserar på koden och logiken i själva applikationen: indatavalidering, autentisering, auktorisering och kryptering. Båda behövs, men en brandvägg stoppar inte en SQL-injektion i er affärslogik.

Hur integrerar vi säkerhet utan att bromsa utvecklingstakten?

Genom DevSecOps: automatisera SAST- och DAST-skanningar i CI/CD-pipelinen, definiera säkerhetspolicyer som kod (policy-as-code) och ge utvecklare snabb feedback i pull requests. Rätt uppsatt adderar det minuter, inte dagar, till en release.

Vilka regelverk kräver applikationssäkerhet i Sverige?

GDPR artikel 25 (dataskydd genom design) och artikel 32 (tekniska skyddsåtgärder) är direkt tillämpliga. NIS2-direktivet, som nu är implementerat i svensk lag, ställer ytterligare krav på riskhantering och incidentrapportering för organisationer inom väsentliga och viktiga sektorer.

Vad är OWASP Top 10 och varför ska vi bry oss?

OWASP Top 10 är en branschstandard som listar de tio vanligaste sårbarhetskategorierna i webbapplikationer – från Broken Access Control till Server-Side Request Forgery. Den fungerar som en grundläggande checklista, men ersätter inte en fullständig hotmodellering anpassad till er specifika arkitektur.

Räcker det med penetrationstest en gång per år?

Nej. Årliga penetrationstest fångar ögonblicksbilder, men er kodbas förändras varje sprint. Kombinera automatiserade skanningar i varje CI/CD-körning med riktade manuella penetrationstest vid större releaser eller arkitekturförändringar. Kontinuerlig övervakning i produktion kompletterar bilden.