Dansk Tally- & Kontrolselskab A/S

Software Audit / Security Audit

Teknisk gennemgang af software, webapplikationer, API’er og digitale platforme med fokus på arkitektur, kode, afhængigheder, konfiguration, adgangsstyring, dataflows, logning, deployment og relevante sikkerhedskontroller.

Ingeniør & Digitale ydelser

Teknisk review af løsning og udviklingsgrundlag

Et brugbart software- og sikkerhedsreview tager udgangspunkt i den faktiske løsning, dens anvendelse og de risici, den skal håndtere. Derfor vurderes ikke kun enkeltstående sårbarheder, men også sammenhængen mellem arkitektur, kode, konfiguration, brugerroller, integrationer, data og driftsmiljø.

Reviewet kan afgrænses til en bestemt komponent eller følge løsningen på tværs af frontend, backend, API, database, eksterne tjenester, build- og deploymentflow. Afhængigt af formålet kan arbejdet omfatte softwarekvalitet, applikationssikkerhed, konfigurationssikkerhed, udviklingsproces eller en kombination.

Automatiserede analyser kan anvendes som støtte, men resultaterne vurderes i den konkrete tekniske og forretningsmæssige kontekst. Fund dokumenteres med grundlag, berørt komponent, observation eller teknisk bevis samt forslag til håndtering.

Opgaver og leverancer

  • Gennemgang af arkitektur, komponenter, tillidsgrænser, dataflows, integrationer og systemets samlede angrebsflade.
  • Review af kildekode, afhængigheder, konfiguration, secrets, build- og deploymentflow samt relevante udviklings- og driftsprocedurer.
  • Teknisk test af webapplikationer og API’er, herunder autentifikation, autorisation, sessioner, inputhåndtering, forretningslogik, fejltilstande og logning.
  • Dokumenteret gap-analyse eller auditrapport med afgrænsning, metode, dækningsgrad, tekniske fund, prioritering, anbefalinger og mulighed for retest.

Teknisk grundlag

Teknisk afgrænsning

Ydelsen er et teknisk review af et aftalt system, miljø, version og opgavegrundlag. Den er ikke en formel certificering eller en garanti for, at løsningen er fri for fejl eller sårbarheder.

Alle opgaver udføres på grundlag af et skriftligt opdrag og en tydelig systemafgrænsning. Aktiv test mod et kørende system kræver desuden et udtrykkeligt godkendt testmandat med tilladte mål, metoder, tidsrum, datarammer, kontaktvej og stopkriterier.

Udnyttelse af sårbarheder, passwordangreb, social engineering, belastnings- eller DoS-test, ændring af produktionsdata og test af tredjepartssystemer indgår kun, når det er særskilt aftalt og godkendt af de relevante ejere. NIST fremhæver, at testplanen bør beskrive både tilladte aktiviteter, risici, datahåndtering og de konkrete grænser, som testteamet skal overholde.

Et review er en dokumenteret vurdering på et bestemt tidspunkt. Resultatet gælder derfor for det undersøgte system, den angivne version, de tilgængelige oplysninger og den aftalte testdybde.

Relevant grundlag
  • Systemets egne sikkerheds-, kvalitets- og acceptkrav samt arkitektur, risikoprofil og anvendelse.
  • OWASP ASVS og WSTG ved review og test af webapplikationers tekniske sikkerhedskontroller.
    Relevante OWASP-guides for eksempelvis API’er, mobile løsninger, trusselsmodellering og softwareudviklingsprocesser.
  • NIST SP 800-115 ved planlægning og afgrænsning af tekniske sikkerhedsvurderinger.
  • NIST Secure Software Development Framework og OWASP SAMM ved review af udviklings-, leverance- og sårbarhedsprocesser.
  • CVSS, CWE eller andre aftalte modeller til klassifikation og formidling af tekniske fund.

OWASP ASVS giver et kravbaseret grundlag for verifikation af applikationskontroller, mens WSTG beskriver testområder og testmetoder. OWASP SAMM og NIST SSDF er bredere rammer for vurdering af sikkerhed gennem softwareudviklingens livscyklus.

OWASP Top 10 kan indgå som en risikoreference, men bør ikke stå alene som audit- eller testprogram. OWASP beskriver selv Top 10 som et opmærksomheds- og awareness-dokument, mens ASVS er udviklet som et egentligt verifikationsgrundlag

Kontrolpunkter

  • Om arkitektur, tillidsgrænser, komponenter, eksterne afhængigheder og dataflows er identificeret og beskyttet i forhold til systemets anvendelse.
  • Om autentifikation, autorisation, sessioner, brugerroller og eventuel tenant-adskillelse håndhæves konsekvent i frontend, backend og API’er.
  • Om input, output, filhåndtering, integrationer, fejltilstande og forretningslogik modstår relevante fejl- og misbrugsscenarier.
  • Om secrets, nøgler, certifikater, kryptering, konfiguration og tekniske standardindstillinger håndteres forsvarligt.
  • Om tredjepartskomponenter, pakker, containere og andre afhængigheder er identificeret, opdateret og omfattet af en praktisk sårbarhedsproces.
  • Om build, test, release, deployment, adgang til produktionsmiljøer og ændringsstyring har relevante tekniske kontroller.
  • Om logning, overvågning og hændelsesspor giver tilstrækkeligt grundlag for fejlsøgning, sikkerhedsopfølgning og efterprøvelse.
  • Om dokumentation, implementering og faktisk systemadfærd stemmer overens med de aftalte krav.

Opgavegrundlag

  • Formålet med reviewet og de beslutninger eller ændringer, leverancen skal understøtte.
  • Systemer, komponenter, domæner, API’er, versioner og miljøer, som indgår eller udtrykkeligt er undtaget.
  • Arkitektur, dataflow, kildekode, repository, afhængigheder, konfiguration og relevant driftsdokumentation.
  • Testbrugere, brugerroller, API-dokumentation, integrationsbeskrivelser og nødvendig teknisk adgang.
  • Tilladte testmetoder, testvindue, trafik- og datarestriktioner, kontaktpersoner og stopkriterier.
  • Regler for håndtering, opbevaring, overførsel og sletning af kildekode, logs, credentials og øvrigt følsomt testmateriale.
  • Ønsket rapportformat, risikomodel, målgruppe og eventuelt behov for teknisk workshop eller retest.

Opgaveeksempler

Fra afgrænset kodereview til samlet sikkerhedsvurdering

Reviewet kan rette sig mod en bestemt funktion, et nyt API, en større release eller en samlet platform. Metode og dokumentationsniveau vælges efter formålet, systemets risikoprofil og den adgang, der er til kode, konfiguration og testmiljø.

Arbejdet kan udføres før lancering, efter væsentlige ændringer, ved overtagelse af en eksisterende løsning eller som grundlag for teknisk afhjælpning og videreudvikling.

Applikation, API og adgang

Applikationens faktiske adfærd undersøges gennem aftalte brugerroller og scenarier. Reviewet kan omfatte login, sessioner, adgang til funktioner og data, objekt- og funktionsbaseret autorisation, inputvalidering, filhåndtering, fejltilstande, tredjepartsintegrationer og relevante misbrugsscenarier.

For API’er vurderes blandt andet endpoint- og objektadgang, autentifikation, dataeksponering, rate- og ressourcebegrænsning, fejlkonfiguration, API-inventar og anvendelse af eksterne API’er. Det konkrete program fastlægges efter API’ets funktion og eksponering; en generisk Top 10-liste erstatter ikke forståelsen af den faktiske forretningslogik. OWASP’s aktuelle API-risikokatalog omfatter blandt andet objektbaseret autorisation, autentifikation, ressourceforbrug, funktionsadgang og usikker anvendelse af eksterne API’er.

Kode, arkitektur og udviklingsflow

Kildekode, komponentstruktur og tekniske afhængigheder gennemgås i forhold til systemets arkitektur og sikkerhedskrav. Automatiseret statisk analyse, dependency scanning og secret scanning kan kombineres med manuel gennemgang af sikkerhedskritiske områder.

Reviewet kan desuden følge udviklingsflowet fra krav og kodeændring til build, test, release og deployment. Formålet er både at identificere konkrete fund og at afdække tilbagevendende årsager, eksempelvis manglende sikkerhedskrav, utilstrækkelige reviewkontroller, sårbare afhængigheder eller uensartet konfiguration. NIST SSDF og OWASP SAMM lægger netop vægt på, at software security integreres i udviklingsprocessen frem for alene at blive kontrolleret ved sluttesten.

Leveranceforløb

Afgrænsning, review og dokumenteret resultat

Når software eller en digital platform skal vurderes før lancering, efter større ændringer, ved teknisk overtagelse eller som grundlag for prioriteret sikkerheds- og kvalitetsarbejde. Opgavegrundlag

System, version, miljøer, arkitektur, kode- og testadgang, relevante krav, tilladte metoder, datahåndtering og ønsket testdybde fastlægges før arbejdet påbegyndes.

En dokumenteret rapport med afgrænsning, metode, dækningsgrad, tekniske beviser, fund, vurdering, anbefalinger og relevante begrænsninger. Workshop, tekniske opgaver og retest kan indgå efter aftale.

Rapporten kan opdeles i en ledelsesrettet sammenfatning og en teknisk del til udviklere og systemansvarlige. NIST anbefaler, at rapporteringen knytter fund til afhjælpning og tilpasses de personer, der skal anvende resultatet.

Få afklaret det rette review

Er I i tvivl om, hvorvidt opgaven kræver kodegennemgang, arkitekturreview, applikationstest eller et bredere sikkerhedsaudit, hjælper vi med at afgrænse system, metode, testdybde og nødvendigt dokumentationsgrundlag.