top of page
Search

Uge 42: App Security

  • Writer: Kenneth H Sørensen
    Kenneth H Sørensen
  • Oct 18
  • 10 min read

Updated: Oct 28


ree


Modern Application Security


Jeg har gennemført "Complete Guide to Application Security" på LinkedIn Learning. (ikke mobil/AI)


Kurset viser, hvordan moderne applikationssikkerhed handler om at tænke sikkerhed ind i krav, design og udvikling, ikke som et separat trin efter kodning.


Fokus ligger på at designe systemer, hvor sikkerhed er en del af arkitekturen, processerne og kulturen, og kommer til udtryk gennem trusselsmodellering, sikre designmønstre og automatiseret test i CI/CD.


Sikkerhed bliver dermed et kontinuerligt ansvar, ikke et afsluttende trin.



Indhold





Applikationssikkerhed


Handler om at beskytte software mod angreb, fejl og misbrug gennem hele dets levetid.

Fokus er på selve applikationen og dens kode, ikke kun infrastrukturen omkring den.



Grundlæggende begreber


Threats (Trusler)

Aktører eller metoder, der forsøger at udnytte en sårbarhed.

Kan være eksterne (hackere, automatiserede angreb) eller interne (fejl, misbrug).


Vulnerabilities (Sårbarheder)

Svagheder i systemet, der kan udnyttes af trusler.

Opstår ofte i kode, konfiguration eller arkitektur.


Attack Vectors (Angrebsflader)

De punkter, hvor en angriber kan få adgang til eller påvirke systemet.

Eksempler: inputfelter, API-endpoints, netværksporte, tredjepartskomponenter.


Impact (Konsekvens)

Resultatet af et angreb, f.eks. tab af fortrolighed, integritet eller tilgængelighed (CIA-triaden).

Bruges sammen med sandsynlighed til at vurdere risiko.


Risiko = sandsynlighed x konsekvens



Sammenhæng mellem begreberne

  • Threats er angriberen eller metoden

  • Vulnerabilities er svagheden, der gør angrebet muligt

  • Attack vectors er vejene ind i systemet

  • OWASP Top 10 viser, hvor sårbarheder oftest opstår og udgør størst risiko

  • Core Security Concepts beskriver kontrollerne, der forebygger eller afbøder dem



Udvikling - klassisk it-sikkerhed til applikationssikkerhed


Med de centrale begreber på plads kan fokus flyttes til, hvordan applikationssikkerhed adskiller sig fra traditionel it-sikkerhed og, hvordan den integreres i udviklingsprocessen.


  • Traditionel it-sikkerhed

    • Fokus på netværk, firewalls, antivirus og adgangskontrol

    • Sikkerhed blev håndteret som et separat trin efter udvikling

    • Målet var at beskytte infrastrukturen, ikke selve applikationen


  • Applikationssikkerhed i dag

    • Angrebsfladen i selve applikationerne

    • Sikkerhed flyttes tættere på udviklingen

    • Webapps, cloud og API'er øger kompleksiteten og risikoen for databrud


For at håndtere den stigende kompleksitet anvendes en moderne tilgang, hvor sikkerhed integreres i hele udviklingsprocessen.


Moderne tilgang


  • Shift-left  - Sikkerhedsaktiviteter flyttes til venstre i udviklingsfaserne (hvor i proces)

    • Faser - krav, design, kodning, test, udrulning, vedligehold

    • Formål  - opdage og håndtere fejl og sårbarheder tidligt


  • Security by design  - at bygge sikkerhed ind i arkitekturen og designet fra starten  (hvordan)

    • Fokus på arkitektur, designprincipper og sikre standarder

    • Eks: inputvalidering, adgangskontrol, mindst privilegium, kryptering


  • DevSecOps  - Udvikling, drift og sikkerhed deler ansvar (hvem / hvornår)

    • Automatisering af test og kontroller i CI/CD-pipelines

    • Sikkerhed bliver en kontinuerlig del af hele livscyklussen


Målet er at skabe robuste applikationer, der kan modstå både kendte og nye trusler.



Security by design


Betyder, at sikkerhed bygges ind i systemets arkitektur og design fra starten.

Fokus på forebyggelse frem for reaktion.


Konceptet hænger tæt sammen med shift-left, hvor sikkerhedsaktiviteter flyttes tidligt i processen.


Centrale principper


  • Pre-code fase

    • trusselsmodellering og dataflow-analyse

    • identificér: aktiver, trusler, sårbarheder og konsekvenser

  • Samarbejde - udvikler, sikkerhedsfolk og PO's arbejder sammen om trusselsbilleder

  • Dokumentation - kortlæg dataflow og brugerflows for at finde potentielle svagheder

  • Misuse cases - overvej hvordan systemet kan misbruges (ikke kun korrekt brug)

  • Designmønstre - opbyg bibliotek af sikre designløsninger som teamet kan genbruge

  • Kultur - sikkerhed bliver en naturlig del af udviklingskulturen (ikke et pålagt krav)

  • Formål - reducer fejl, bygge modstandsdygtige systemer og sikkerhed som fælles ansvar


Kernen i security by design

At forstå systemet inden angreb sker, hvordan data bevæger sig, hvor risici opstår, og hvordan de kan lukkes, allerede på tegnebrættet.



Helhedsorienteret applikationssikkerhed


Efter at sikkerhed er bygget ind i designet, skal den også forankres i hele stacken fra frontend til infrastruktur


I tidligere indlæg blev CIA-triaden og applikationssikkerhedens rolle i informationssikkerhed introduceret. Her udvides perspektivet til hele stacken, hvordan sikkerhed indbygges i hvert lag for at skabe et samlet forsvar.


Sikkerhed skal tænkes som et samlet økosystem, hvor hvert lag beskytter mod fejl i de øvrige lag.

Det kaldes lagdelt forsvar (defense in depth).


Centrale principper


Helhedssyn 

  • Sikkerhed dækker applikation, infrastruktur, data og brugere (sammenhængende)

  • Risiko skal vurderes på tværs af grænseflader - f.eks hvordan fejl i API kan påvirke DB


Lagdelt forsvar  - flere uafhængige kontroller reducerer risikoen for fejl i et enkelt lag

  • Frontend - beskyt brugerinteraktioner og input

    • valider og sanitér alt input, sanitér eller encode alt output (injection og XSS)

    • brug sikker sessionhåndtering og CSRF-beskyttelse (sessionmisbrug)

    • undgå at eksponere interne fejlmeddelelser / stack traces (hjælper fjenden)


  • API-lag  - beskyt adgang og dataudveksling mellem systemer

    • kræv AuthN og AuthZ for hver forespørgsel (broken access control)

    • brug RBAC / ABAC (Role- eller Attribute Based Access Control)

    • implementér rate limiting og throttling (DoS-angreb)

    • valider og sanitér alt input igen (injection og XSS)

    • brug tokens, adgangskontrol - f.eks JWT, OAuth eller sikre cookies

    • log / overvåg API-brug for uautoriserede mønstre


  • Applikationslag  - beskyt forretningslogik og domæneregler

    • sørg for, regler og domæneinvarianter ikke kan omgås via API eller UI (BOLA)

    • kontroller dataflow og transaktioner for logisk konsistens

    • log kritiske hændelser og beslutninger i applikationslaget


  • Databaselag  - beskyt data

    • krypter følsomme data - f.eks persondata, kortoplysninger, e-mails

    • hash data - f.eks adgangskoder

    • brug princip om least privilege

    • brug parameteriseret queries (injection)

    • log / overvåg forespørgsler


  • Infrastruktur  - beskyt systemets fundament / miljø som systemet kører i

    • containers - brug minimale base-images, opdater jævnligt og scan for kendte sårbarheder (CVE-database, image-scannere)

    • netværk  - begræns kommunikation ml. services med firewall-regler og private netværk (princip om "deny by default")

    • secrets  - opbevar nøgler, tokens og adgangskoder i et sikkert vault (f.eks Azure Key Vault, HashiCorp Vault) i stedet for i kode eller miljøfiler

    • least privilege  - kør containere og services med lavest mulige rettigheder og uden root-adgang

    • patch løbende  - hold OS-, containere, og packages opdateret gennem automatiserede sikkerhedsopdateringer

    • log / overvåg unormal trafik, adgangsforsøg og konfigurationsændringer i realtid


  • Cloud-sikkerhed  - beskyt tjenester og ressourcer i skyen

    • IAM (Identity and Access Management) - least privilege for brugere, services og applikationer. Adskil roller for drift, udvikling og sikkerhed

    • konfigurationer - audit konfig, f.eks offentlige buckets og porte med Azure Security Center

    • Netværk og adgang - beskyt cloud netværk, kun bestemt trafik ind/ud

    • Secrets og nøgler - key vaults, secret managers, KMS til credentials og krypteringsnøgler

    • Storage-sikkerhed - krypter data i hvile og transit.

    • log / overvåg - transaktioner og auto alarm på cloud ressourcer (misbrug og fejl konfig)


  • Supply chain  - beskyt mod sårbarheder i tredjepartskode og afhængigheder

    • Afhængighedsscanning - brug SCA-værktøjer til at opdage sårbare pakker

    • Versionsstyring - brug lock files undgå uforudsete ændringer i build

    • Kildekontrol - hent kode fra pålidelige kilder, verificér checksums eller digitale signaturer

    • Build-integritet - brug CI/CD pipelines, auto valider builds og artifacts

    • Licensstyring - vurder licenser for at undgå juridiske risici


  • Kontinuerlig monitorering 

    • logning, alarmering og respons på hændelser


Målet er ikke at eliminere risiko, men at begrænse konsekvensen af fejl og sikre, at ét brud ikke kompromitterer hele systemet.


Lagdelt forsvar gør software robust, selv når enkeltdele fejler



Vigtigheden af tidlig trusselsforståelse og kultur


At bygge sikker software handler ikke kun om værktøjer og processer, men om at skabe en kultur hvor udviklere, drift og sikkerhedsfolk forstår truslerne tidligt og arbejder sammen om at forebygge dem.


  • Formål - opbygge en fælles forståelse af hvordan applikationer kan angribes og beskyttes

  • Tidlig bevidsthed - introducér trusselsforståelse allerede før kodning starter

  • Trusselsmodellering

    • visualisér hvordan data bevæger sig gennem systemet og hvor risici opstår

    • Anvend modeller som STRIDE eller PASTA til systematisk id af trusler

  • Praktiske aktiviteter

    • workshops - udvikler, sikkerhedsfolk og POs for at kortlægge trusler

    • threat reviews - i backlog eller design sessioner

  • Kommunikation

    • del viden om fejl og trusler uden skyldkultur, skaber læringsmiljø

    • træning - målrettede sessioner for udviklere om angrebsveje

    • KPI'er og feedback - til løbende forbedring

  • Løbende læring - opdater trusselsmodeller og processer når systemet ændres

  • Gevinst

    • Mindre modstand mod sikkerhedskrav, hurtigere og bedre beslutninger, færre kritiske fejl i produktion

    • Sikkerhed integreret i teams’ måde at tænke og arbejde på, fra design til drift.


Målet er at skabe en organisation, hvor alle tænker som forsvarere - ikke kun sikkerhedsteamet.



OWASP Top 10 (kort reference)


Fungerer som en fælles ramme for at forstå og prioritere de mest kritiske risici i applikationssikkerhed. (ikke alle)

Men giver et praktisk udgangspunkt for at vurdere og forebygge de mest udbredte problemer.


Den danner grundlag for mange moderne værktøjer, standarder og sikkerhedstests.


Jeg har tidligere gennemgået dem i to blogindlæg:


Dette kursus bygger videre på OWASP Top 10 ved at vise, hvordan man omsætter principperne til praksis. Sikker arkitektur, trusselsmodellering, sikre kodningsprincipper og kontinuerlig test i hele udviklingslivscyklussen.


OWASP fungerer dermed som et anker / fælles referencepunkt i applikationssikkerhed.



Core Security Concepts


De grundlæggende sikkerhedsprincipper udgør fundamentet for applikationssikkerhed.


De anvendes på tværs af alle OWASP-risikokategorier og beskytter identitet, data og systemets integritet.


  • Autentifikation - sikrer at brugeren er den, de udgiver sig for at være

    A07: Identification and Authentication Failures

  • Autorisation  - styrer adgange og rettigheder ud fra princippet om mindst privilegium

    A01: Broken Access Control

  • Kryptering  - beskytter data i hvile og under transport

    A02: Cryptographic Failures

  • Hashing  - bruges til at sikre adgangskoder og dataintegritet

    A02: Cryptographic Failures og Credential Theft

  • Inputvalidering  - kontrollerer og renser alt brugerinput

    A03: Injection

    A10: Server-Side Request Forgery (SSRF)

  • Fejlhåndtering  - undgår at eksponere interne oplysninger i fejlmeddelelser

    A05: Security Misconfiguration og Information Leakage

  • Logning og overvågning  - registrerer og opdager angreb tidligt

    A09: Security Logging and Monitoring Failures

  • Session management  - beskytter aktive sessioner mod hijacking og uautoriseret adgang

    A07: Identification and Authentication Failures

  • Automatisering  - integrerer scanning, analyse og secrets management i CI/CD-pipelines (reducerer risiko for menneskelige fejl og kendte sårbarheder)

    A06: Vulnerable and Outdated Components

    A08: Software and Data Integrity Failures

  • (dækket tidligere gennem kultur og design)

    A04: Insecure Design


Disse principper hænger direkte sammen med OWASP Top 10, fordi de hver især reducerer en eller flere af de mest almindelige risici.


De fungerer som grundlæggende kontroller, der understøtter sikker arkitektur, kodning og drift.



Threat Modeling


Trusselsmodellering hjælper udviklingsteamet med at forstå, hvordan et system kan blive angrebet, før det sker.


Formålet er at identificere svagheder i designet, vurdere risiko og konsekvens, og planlægge hvordan de kan håndteres.


  • Formål - finde og håndtere trusler før de bliver udnyttet

  • Fokus - forstå hvordan en angriber tænker, og hvor systemet er sårbart

  • Output - trusselsdiagrammer, prioriterede risici og konkrete tiltag


  • Metoder

    • STRIDE - klassisk model med seks trusselsklasser Spoofing, Tampering, Repudiation, Info Disclosure, DoS, Elevation of Privilege

    • PASTA - fokus på forretningsmål og realistiske angrebsscenarier

    • DREAD - vurderer risiko efter Damage, Reproducibility, Exploitability, Affected Users, Discoverability

    • Trike og OCTAVE til løbende risikovurdering i større organisationer


  • Proces

    1. Definér scope og aktiver

    2. Kortlæg dataflow og grænseflader

    3. Identificér trusler og sårbarheder

    4. Vurder risiko og konsekvens

    5. Planlæg og dokumentér afværgeforanstaltninger

    6. Gentag løbende, når systemet ændres eller udvides


  • Værktøjer

    • OWASP Threat Dragon

    • Microsoft Threat Modeling Tool

    • IriusRisk


Trusselsmodellering gør sikkerhed mere systematisk og fremadskuende.

Det hjælper teams med at opdage problemer tidligt, tage bedre beslutninger og bygge sikrere software.



Security Testing


Sikkerhedstest bruges til at finde sårbarheder i både kode og det kørende system.

Den udføres løbende gennem hele udviklingsprocessen for at opdage fejl tidligt og forhindre, at sårbarheder når produktionen.


Formål

  • Validér, at kontroller og sikkerhedsmekanismer fungerer efter hensigten

  • Reducér risiko - opdage fejl, før systemet udrulles

  • Dokumentation - sikkerhed indgår som en del af kvalitetssikringen


Testtyper

  • SAST - statisk test

    Analyserer koden uden at køre den

    white box, build-time

  • DAST - dynamisk test

    Tester applikationen udefra (efterligner reelle angreb)

    black box, runtime

  • IAST - interaktiv test

    Kombinerer statisk og dynamisk test for mere præcise resultater

    Observerer app indefra mens den kører

    grey box, runtime

  • SCA - Software Composition Analysis

    Scanner tredjepartsbiblioteker for kendte sårbarheder

    white box, build-time

  • Manuel test

    Udføres med OWASP Web Security Testing Guide som struktur

    Ofte brugt til validering af automatiserede resultater og komplekse flows


Standarder og integration

  • Brug OWASP ASVS som reference for verifikationsniveauer (App Sec Verification Standard)

  • Integrér test i CI/CD-pipelines for løbende kontrol og hurtig feedback

  • Automatisér scanninger og generér rapporter som dokumentation


Resultat

  • Tidlig opdagelse af fejl

  • Hurtigere reaktion på sårbarheder

  • Kontinuerlig forbedring af sikkerhedsniveauet gennem hele livscyklussen


Sikkerhedstest er en løbende proces, ikke en afsluttende aktivitet.

Giver udviklingsteams mulighed for at reagere hurtigt og holde/øge sikkerhedsniveauet over tid.




Governance, Compliance og Maturity Models


Governance og modenhed handler om at skabe struktur, overblik og ansvar i sikkerhedsarbejdet.

Det sikrer, at sikkerhed ikke afhænger af enkeltpersoner, men er en fast del af organisationens praksis og kultur.


Formål

  • Etabler klare rammer for, hvordan sikkerhed måles, styres og forbedres

  • Skab gennemsigtighed og ansvar i processer og roller

  • Sikr, at sikkerhed bliver en kontinuerlig proces, ikke et enkeltprojekt


Governance

  • Udarbejd politikker og retningslinjer for sikker udvikling

  • Definér roller og ansvar på tværs af udvikling, drift og ledelse

  • Etabler change management og review-processer for ændringer i systemer

  • Brug risikovurderinger til at prioritere indsatsområder


Compliance

  • Efterlev relevante standarder og lovkrav

    • GDPR  - beskyttelse af persondata

    • ISO 27001 - informationssikkerhedsstyring

    • NIST SP 800-serien  - tekniske retningslinjer for cybersikkerhed

  • Brug compliance som vejledning, ikke som erstatning for reel sikkerhed


Maturity Models

  • OWASP SAMM  - Software Assurance Maturity Model

    Måler modenhed i sikker udvikling og hjælper med at planlægge forbedringer

  • BSIMM  - Building Security In Maturity Model

    Empirisk model baseret på observationer af virkelige organisationer

  • NIST CSF  - Cybersecurity Framework

    Opdelt i Identify, Protect, Detect, Respond, Recover


Kontinuerlig forbedring - brug modenhedsmålinger til at planlægge næste udviklingstrin

  • Brug modenhedsmålinger til at spore fremgang og identificere svagheder

  • Integrér feedback fra audits og hændelser i næste iteration

  • Gør sikkerhed til en del af kultur og kvalitetssikring, ikke blot compliance


Resultat

  • Ensartede processer på tværs af teams

  • Forudsigelige og målbare forbedringer

  • En bæredygtig sikkerhedspraksis, hvor ansvar deles og modnes over tid


Målet med governance og modenhed er at gøre sikkerhed bæredygtig, ikke afhængig af enkeltprojekter, men en naturlig del af organisationens måde at arbejde på.



Afslutning - fra princip til praksis


Applikationssikkerhed

  • Et samlet system af principper, processer og mennesker, der arbejder mod samme mål:

    at bygge modstandsdygtig software


Helhedsforståelse

  • Sikkerhed skal indgå i alle faser

  • Hvert lag i stacken har sikkerhed


Samarbejde og kultur

  • sikkerhed integreres i teamets arbejdsform

  • Udviklere, drift og sikkerhedsfolk deler ansvar og lærer af hinanden løbende


Kontinuerlig forbedring

  • Automatisering, måling og modenhedsmodeller sikrer, at sikkerhed kan udvikles, måles og gentages

  • Målet er ikke perfektion, men at reducere risiko og reagere hurtigt, når noget fejler


Sikkerhed er kvalitet.

  • Når software bygges sikkert, bliver det samtidig mere stabilt, skalerbart og pålideligt

    både teknisk og organisatorisk





Refleksion


Kurset har givet et klart billede af, hvordan moderne applikationssikkerhed handler om mere end blot at reagere på sårbarheder.

Sikkerhed skal bygges ind fra starten som en del af design, udvikling og drift.


Det mest værdifulde har været at se, hvordan principperne kan anvendes i praksis.

Jeg har fået en bedre forståelse af, hvordan trusselsmodellering, sikre designmønstre og automatiseret test kan understøtte en løbende sikkerhedsproces.


Emnet er særdeles relevant i dag, hvor cybertrusler er udbredte og konstant udvikler sig.

Jeg tror, mange organisationer anvender de tekniske kontroller og standarder, men jeg er mere usikker på, hvor mange der arbejder aktivt med kultur, trusselsmodellering og løbende læring på samme strukturerede måde.


Selv små fremskridt mod security by design og DevSecOps kan øge både kvaliteten og robustheden af software.



Videre plan

  • Jeg vil undersøge, hvordan udvalgte principper fra kurset kan anvendes i Trackunit-projektet.

  • Fokus bliver på at forstå, hvor sikkerhed naturligt kan indgå i design og udvikling.

  • Jeg vil især se på enkle forbedringer som bedre håndtering af data, adgangskontrol og sikker konfiguration.





Ressourcer


LinkedIn Learning


Evt. videre læsning

Utrolig mange ressourcer er nævnt under ovenstående kursus



bottom of page