Fra blueprint til revisionsklar: Få styr på krav til applikationssikkerhed for ISO 27001, DORA og NIS2

Uroen før revisionen var tydelig. For Maria, CISO i en mellemstor fintech-virksomhed, føltes den kommende DORA-compliancevurdering mindre som en gennemgang og mere som en afgørende eksamen. Hendes team var kompetent, hendes infrastruktur var hærdet, men én tilbagevendende sårbarhed holdt hende vågen om natten: det omfattende og uoverskuelige applikationslandskab.

Den seneste bekymring var en ny kundevendt betalingsportal, der var blevet sendt hurtigt på markedet for at nå kvartalsmålene. Udviklingsteamet, der arbejdede efter en aggressiv agil model, havde opfyldt alle funktionelle krav. Men da Marias team gennemførte en indledende scanning, bekræftede resultaterne hendes bekymringer.

Portalen manglede robuste regler for sessionstimeout, inputfelterne var sårbare over for grundlæggende injektionsangreb, og fejlmeddelelser lækkede følsomme systemoplysninger. Det var ikke avancerede zero-day-payloads; det var grundlæggende designfejl. Rodårsagen var smertefuldt klar: Sikkerhedskrav var aldrig blevet formelt defineret, dokumenteret eller integreret i udviklingssprintene. Teamet havde et uklart mandat om at “gøre den sikker”, men uden et konkret blueprint forblev sikkerhed en utydelig og ofte ignoreret eftertanke.

Dette scenarie er ikke enestående. Det viser det kritiske hul, mange CISO’er og complianceansvarlige står over for: at omsætte intentionen om “vi arbejder med sikkerhed” til eksplicitte, testbare krav til applikationssikkerhed, der er afstemt med grundlæggende standarder som ISO/IEC 27001:2022 og centrale reguleringer som NIS2, DORA og GDPR.

Den høje pris for uklarhed: Hvad compliance faktisk kræver

Kernen i Marias problem ligger i en almindelig organisatorisk fejl: at behandle sikkerhed som en kvalitetsegenskab i stedet for et sæt ufravigelige krav. Et effektivt sikkerhedskrav er specifikt, målbart og testbart. “Applikationen skal være sikker” er et ønske. “Applikationen skal håndhæve sessionstimeout efter 15 minutters inaktivitet, validere alle brugerleverede input mod et foruddefineret tegnsæt og kryptere alle data under overførsel med TLS 1.3” er et krav. Det er denne klarhed, revisorer leder efter, og som udviklere har brug for for at bygge sikker software.

Uden den udløses en kæde af fejl:

• Uensartet implementering: Forskellige udviklere fortolker “sikker” forskelligt, hvilket fører til et kludetæppe af kontroller med uforudsigelige huller.
• Øgede afhjælpningsomkostninger: At finde og rette en designfejl i produktionsmiljøet er eksponentielt dyrere end at håndtere den i designfasen.
• Revisionsafvigelser: Revisorer vil hurtigt identificere fraværet af en struktureret proces til at definere sikkerhedskrav, hvilket fører til væsentlige revisionsbemærkninger.
• Forretningsrisiko: Hvert udefineret krav er en potentiel angrebsvektor, der eksponerer organisationen for brud på persondatasikkerheden, økonomiske tab og omdømmeskade.

På tværs af moderne standarder er forventningen ens: Sikkerhed skal defineres som krav, tidligt i forløbet og koblet til risiko og lovkrav. Vejledningen i ISO/IEC 27002:2022 til kontrol 8.26, krav til applikationssikkerhed, forventer, at organisationer systematisk fastlægger, dokumenterer og godkender sikkerhedskrav baseret på formel risikovurdering og regulatoriske krav.

Dette ene princip er omdrejningspunktet for en bred vifte af compliancekrav. Clarysecs tværgående compliancekortlægning i Zenith Controls: Den tværgående compliance-guide Zenith Controls viser, hvordan konceptet går igen overalt:

• GDPR Artikel 25 og 32 forventer “databeskyttelse gennem design” og “behandlingssikkerhed”.
• NIS2 Artikel 21(2)(d)-(e) fremhæver sikker udvikling og sikkerhed i forsyningskæden.
• DORA Artikel 6(4), 8, 10 og 11 kræver styring af IKT-risiko og sikkerhed gennem design for finansielle enheder.
• NIST SP 800-53 Rev.5 i kontrollerne SA-4 og SA-15 kræver definerede systemsikkerhedskrav og praksis for sikker udvikling.
• COBIT 2019 i processerne BAI03 og DSS05 kræver, at sikkerhedsrelaterede krav afstemmes med forretningen og compliancekrav, før en løsning bygges.

Målet er med ordene fra Zenith Blueprint: En revisors 30-trins køreplan Zenith Blueprint at definere “hvad sikkerhed betyder for jeres applikationer, før en eneste linje kode skrives.”

Hvorfor traditionelle tilgange fejler: Tjeklister, sen test og sikkerhedsteater

De fleste organisationer arbejder allerede i en eller anden form med applikationssikkerhed. Problemet er, at det sjældent er struktureret på en måde, der kan holde til ISO/IEC 27001:2022-certificering eller regulatorisk kontrol.

Almindelige fejlmønstre omfatter:

1. Generiske tjeklister: Teams genbruger en énsides “tjekliste for sikker kodning” til hvert projekt. Den er ikke knyttet til applikationens specifikke risici, datafølsomhed eller regulatoriske kontekst. Når en revisor spørger, hvordan tjeklisten kortlægges til GDPR Artikel 25, findes der ikke noget klart svar.
2. Sikkerhed som sen stopklods: Sikkerhedskrav er ikke indlejret i design eller brugerhistorier. De dukker op til sidst som en anmodning om en penetrationstest. Zenith Blueprint advarer om, at “det ikke virker at basere sig på en sikkerhedstjekliste sidst i projektet; kravene skal forme arkitekturen, påvirke valg af biblioteker og styre prioriteringen af funktioner fra dag ét.”
3. Ingen sporbarhed fra krav til test: Der kan eksistere et krav om at “kryptere data under overførsel”, men der findes ingen tilknyttet testcase, der verificerer håndhævelse af TLS-version, certifikatgyldighed og chifferstyrke. Zenith Blueprint insisterer på, at forventninger skal være målbare og testbare, og at sikkerhedstests skal kortlægges direkte til de tilsvarende krav.
4. Ad hoc-håndtering af tredjepartskode: Moderne applikationer er ofte “sat sammen af intern kode, tredjepartsbiblioteker, API’er og cloud-native tjenester”, som det fremgår af Zenith Blueprint. Uden eksplicitte krav til leverandører og open source-komponenter forbliver forsyningskæderisiko en massiv, ukontrolleret blind vinkel.

Resultatet er sikkerhedsteater: Dokumenter findes, og tests gennemføres, men når en seriøs revisor eller tilsynsmyndighed leder efter en sammenhængende kravhistorik, falder hele processen fra hinanden.

Opbygning af fundamentet: Fra politik til praksis

En disciplineret tilgang til applikationssikkerhed starter med klar styring. Politik er ikke blot bureaukrati; den er den officielle sandhedskilde, der giver teams mandat og giver revisorer en klar hensigtserklæring. Hos Clarysec udformer vi politikker, der både er autoritative og praktiske.

Vores Politik for krav til applikationssikkerhed Politik for krav til applikationssikkerhed fastsætter ufravigelige grundregler. For eksempel kræver klausul 5.2 under “Styringskrav”:

Alle applikationer skal gennemgå validering af sikkerhedskrav under planlægning eller anskaffelse med dokumenteret godkendelse fra teamet for applikationssikkerhed.

Dette enkle krav forhindrer mentaliteten “byg først, gør sikker senere”. Politikken tildeler også klar ansvarlighed. Klausul 4.3.1 under “Roller og ansvar” angiver, at udviklere skal:

Implementere applikationer i overensstemmelse med definerede sikkerhedskrav og standarder.

Det flytter ansvaret for sikkerhed fra et separat og ofte modstående sikkerhedsteam til dem, der skaber softwaren. Desuden forbinder politikken punkterne mellem forskellige sikkerhedsdomæner. Klausul 10.2 henviser til integrationen med andre nøglekontroller:

P4 – Politik for adgangskontrol. Definerer de standarder for identitets- og sessionsstyring, som skal håndhæves af alle applikationer, herunder stærk autentifikation, mindst privilegie-princippet og krav til gennemgang af adgangsrettigheder.

For mindre organisationer sikrer en tilpasset politik som vores Politik for krav til applikationssikkerhed - SMV Politik for krav til applikationssikkerhed - SMV, at principperne kan skaleres. Den anerkender, at selv om risiciene ligner hinanden, skal implementeringen være pragmatisk. Begge versioner sigter i sidste ende mod samme resultat: at sikre, at applikationssikkerhed er fuldt integreret i ISMS og revisionsklar.

En praktisk køreplan: Opbygning af revisionsklare krav til applikationssikkerhed

Politikken fastsætter “hvad” og “hvorfor”, men udviklere og projektledere har brug for “hvordan”. En struktureret implementeringsvejledning er uundværlig for at omsætte overordnede kontroller til konkrete handlinger. Trin 21 i Zenith Blueprint, der fokuserer på ISO/IEC 27002:2022-kontrol 8.26, giver en klar metode i seks trin.

Lad os gennemgå processen med Marias betalingsportal som eksempel.

Trin 1: Start med risiko og regulatorisk kontekst

Med output fra risikovurdering afstemt med ISO/IEC 27005:2024 (risikobehandling) identificerer du først konteksten:

• Applikation: Kundeselvbetjent betalingsportal.
• Data: Personoplysninger (PII), legitimationsoplysninger, betalingstokens.
• Jurisdiktioner: EU, finansielle tjenester, cloud-hostet.
• Reguleringer: GDPR, DORA, PCI DSS.

Baseret på vejledningen til kontrol 8.26 i Zenith Controls og de tilhørende ISO-standarder (27034-1, 27017, 27701) skal dine indledende kravkategorier omfatte identifikation og autentifikation, autorisation, dataklassificering, inputvalidering, logning samt databeskyttelse under overførsel og i hvile.

Trin 2: Opret eller anvend en skabelon for sikkerhedskrav

Zenith Blueprint anbefaler at oprette en standardiseret skabelon for at sikre, at hvert projekt besvarer de samme grundlæggende sikkerhedsspørgsmål. Dokumentet bør indgå i værktøjssættet til projektopstart.

Minimumsafsnit bør omfatte:

• Applikationsnavn, ejer og kritikalitet.
• Datakategorier og følsomhedsniveauer.
• Relevante regulatoriske og kontraktlige krav (GDPR, DORA osv.).
• Input fra trusselslandskabet (afledt af kontrol 5.7 Trusselsintelligens).
• Specifikke sikkerhedskrav efter kategori (autentifikation, logning osv.).
• Sammenhænge til brugerhistorier og acceptkriterier.
• Sammenhænge til testcases (funktionelle tests, sikkerhedstests, penetrationstest).
• Krav til leverandører og tredjepartskomponenter.

Trin 3: Indarbejd kravene i agile artefakter

Sikkerhedskrav skal indarbejdes direkte i brugerhistorier og acceptkriterier. For epikken “kunderegistrering” i Marias portalprojekt betyder det, at en enkel funktionel historie omformes til en sikkerhedsbevidst historie.

• Oprindelig brugerhistorie: “Som ny bruger kan jeg oprette en konto.”
• Sikker brugerhistorie: “Som ny kunde vil jeg oprette en sikker konto, så mine betalingsoplysninger er beskyttet.”
• Acceptkriterier (med indlejret sikkerhed):
  • Systemet skal håndhæve en stærk adgangskodepolitik i overensstemmelse med P4 – Politik for adgangskontrol.
  • Systemet skal kræve e-mailverifikation via et engangslink, før kontoen aktiveres.
  • Formularen til kontooprettelse skal beskyttes med CAPTCHA for at forhindre botangreb.
  • Alle registreringsforsøg skal logges med kilde-IP og enhedsfingeraftryk.
  • Alle data, der indsendes via formularen, skal renses for at forhindre cross-site scripting (XSS).

Dette er ikke separate sikkerhedsopgaver; de er en integreret del af funktionens definition af “færdig”.

Trin 4: Knyt krav til sikkerhedstest

Ved hjælp af kontrol 8.29 Sikkerhedstest under udvikling og accept fra Zenith Controls sikrer du, at hvert krav har en tilknyttet testcase. Det lukker kredsløbet og giver revisionsbevis for kontroleffektivitet.

• Krav: Kryptering under overførsel med TLS 1.3. → Test: Automatiseret scanning for at verificere TLS-håndhævelse, certifikatgyldighed og godkendte chifferpakker.
• Krav: Inputvalidering for at forhindre SQL-injektion. → Test: Automatiseret SAST-/DAST-scanning og manuel fuzzing under QA.
• Krav: Sessionstimeout efter 15 minutters inaktivitet. → Test: Automatiserede og manuelle tests, der bekræfter serverbaseret ugyldiggørelse af sessionen efter 15 minutters inaktivitet.

Trin 5: Udvid kravene til forsyningskæden

Fordi ISO-kontrol 8.26 er knyttet til leverandørsikkerhed (5.19, 5.20) og outsourcet udvikling (8.30) i Zenith Controls, skal processen omfatte tredjepartskode. For SMV’er, der i høj grad er afhængige af eksterne biblioteker, er politikklausulen fra Politik for krav til applikationssikkerhed - SMV kritisk:

Ethvert tredjepartsværktøj, plugin eller eksternt kodebibliotek, der anvendes i en applikation, skal registreres og gennemgås årligt med hensyn til sikkerhedsmæssig påvirkning og patchstatus.

Dette enkle, pragmatiske krav fremtvinger en software bill of materials (SBOM)-tankegang, som er en central forventning under reguleringer som NIS2. For større leverandører skal de samme krav til applikationssikkerhed indgå i kontrakterne med henvisning til ISO/IEC 27036-1 (IKT-sikkerhed i forsyningskæden).

Trin 6: Indfør periodisk revurdering

Når applikationer udvikler sig, ændrer deres risici sig også. Vejledningen i Zenith Blueprint om periodisk revurdering er afgørende. Når du integrerer en ny API eller flytter til en anden cloudtjeneste, ændrer risikokonteksten sig. Det skal udløse en gennemgang af de eksisterende sikkerhedskrav for at sikre, at de fortsat er tilstrækkelige. Dette er afstemt med ISO/IEC 27005:2024 (løbende risikobehandling) og gør applikationssikkerhed til en løbende praksis, ikke et enkeltstående projekt.

Nedbrydning af kontroløkosystemet

En ISO-kontrol eksisterer aldrig i et vakuum. Effektiv sikkerhed bygger på et sammenhængende net af foranstaltninger. Den egentlige styrke i kontrol 8.26 frigøres, når man forstår dens relation til andre kontroller, et perspektiv der er beskrevet i Zenith Controls.

Kontrol 8.26 er klassificeret som en forebyggende kontrol, men fungerer som det centrale knudepunkt for hele den sikre udviklingsproces og forbinder til:

• 8.25 - Sikker udviklingslivscyklus: Dette er det overordnede rammeværk. Kontrol 8.26 leverer det specifikke hvad (kravene), der skal integreres i hvordan (SDLC-processen).
• 8.27 - Sikker systemarkitektur og tekniske principper: Krav driver arkitekturbeslutninger og sikrer, at sikkerhed er grundlæggende.
• 8.28 - Sikker kodning: Når krav er defineret (f.eks. “forhindr SQL-injektion”), giver standarder for sikker kodning udviklerne teknikkerne til at opfylde kravet.
• 8.29 - Sikkerhedstest under udvikling og accept: Denne kontrol validerer, at kravene defineret i 8.26 er korrekt implementeret.
• 5.34 - Privatliv og beskyttelse af PII: Når en applikation behandler personoplysninger, skal kravene fra 8.26 indarbejde principperne for databeskyttelse gennem design.
• 5.19 & 5.20 - Informationssikkerhed i leverandørrelationer: For anskaffede eller outsourcede applikationer fastlægger kontrol 8.26, at jeres sikkerhedskrav skal udvides til forsyningskæden.

Ved at betragte disse kontroller som et økosystem frem for en tjekliste kan du opbygge en flerlaget og juridisk forsvarlig sikkerhedstilstand.

Revisorens perspektiv: Forberedelse på kontrol

Revisorer tænker i revisionsbevis. For at forberede dig skal du forstå de forskellige perspektiver, en revisor kan anlægge. Afsnittet om revisionsmetode i Zenith Controls forudser disse forskellige tilgange.

Når du forstår disse perspektiver, kan du forberede en samlet portefølje af revisionsbevis, der dokumenterer en levende proces indlejret i organisationen.

Det tværgående compliancekompas: Én proces, mange rammeværker

For en virksomhed som Marias er det obligatorisk at opfylde DORA, GDPR og NIS2. Manuel kortlægning af kontroller er en opskrift på dobbeltarbejde og compliancehuller. En centraliseret, tværgående compliancetilgang giver betydelig værdi. Definition af krav til applikationssikkerhed er den praktiske implementering af princippet om sikkerhed gennem design, som ligger til grund for alle disse moderne reguleringer.

Ved at implementere en robust proces for krav til applikationssikkerhed baseret på ISO/IEC 27002:2022 opbygger du samtidig revisionsbevis, der kan opfylde en betydelig del af disse øvrige reguleringer. Du “arbejder” ikke blot med ISO; du bygger et sikkerhedsprogram, der kan dokumentere bred compliance.

Fra kaos til kontrol: Vejen frem

Marias historie ender positivt. Hun brugte hændelsen med betalingsportalen som katalysator for forandring. Med et klart styringsrammeværk fra Clarysec og en praktisk implementeringsvejledning samlede hun udviklings-, sikkerheds- og produktteams. De brugte metoden i Zenith Blueprint til retrospektivt at definere krav til portalen og prioritere afhjælpning baseret på risiko.

Endnu vigtigere etablerede de en ny måde at arbejde på. “Sikkerhedstjeklisten” blev erstattet af samarbejdsbaserede designmøder. Da DORA-revisorerne ankom, kunne Maria ikke blot vise dem en sikker applikation, men også dokumentere en moden, gentagelig proces, der sikrer, at alle fremtidige applikationer bygges på et sikkerhedsfundament.

Forbedring af jeres sikkerhedstilstand for applikationer begynder med ét struktureret trin. Vejen frem er klar:

1. Etablér styring: Implementér en formel politik for definition af krav til applikationssikkerhed. Vores skabeloner, såsom Politik for krav til applikationssikkerhed, giver et revisionsklart udgangspunkt.
2. Anvend et praktisk rammeværk: Brug Zenith Blueprint til at integrere sikkerhedskrav direkte i jeres udviklingslivscyklus, så de bliver handlingsrettede, testbare og sporbare.
3. Forstå den fulde kontekst: Brug Zenith Controls til at se, hvordan denne kritiske kontrol hænger sammen med det bredere sikkerhedsøkosystem og kortlægges på tværs af DORA, NIS2, GDPR og mere.
4. Skalér til porteføljen: Når tilgangen fungerer for én applikation, kan den skaleres på tværs af porteføljen ved at integrere jeres skabelon for sikkerhedskrav i standardtjeklister til projektopstart, agile skabeloner og indkøbsprocesser.

Hvis I vil fremskynde denne transformation, leverer Clarysec færdigbyggede politikker, implementeringskøreplaner og tværgående compliancekortlægninger, der flytter jer fra fragmenterede indsatser til et dokumenterbart modent og revisionsklart program. Stop med at behandle applikationssikkerhed som en afsluttende kontrolport. Begynd at bygge den ind i blueprintet for alt, hvad I skaber.