Från ritning till revisionsredo: bemästra säkerhetskrav för applikationer för ISO 27001, DORA och NIS2

Oron inför revisionen var påtaglig. För Maria, informationssäkerhetschef på ett medelstort fintechbolag, kändes den kommande DORA-bedömningen mindre som en granskning och mer som ett bokslut över allt som ännu inte var under kontroll. Hennes team var kompetent och infrastrukturen var härdad, men en återkommande sårbarhet höll henne vaken om nätterna: den omfattande och svåröverskådliga applikationsmiljön.

Den senaste oron gällde en ny kundexponerad betalningsportal som hade skyndats ut på marknaden för att uppfylla kvartalsmålen. Utvecklingsteamet, som arbetade enligt en aggressiv agil modell, hade uppfyllt alla funktionella krav. Men när Marias team genomförde en inledande skanning bekräftade resultatet hennes farhågor.

Portalen saknade robusta regler för tidsgränser för sessioner, dess indatafält var sårbara för grundläggande injektionsattacker och felmeddelanden läckte känslig systeminformation. Det handlade inte om sofistikerade zero-day-angrepp, utan om grundläggande designbrister. Grundorsaken var smärtsamt tydlig. Säkerhetskrav hade aldrig definierats formellt, dokumenterats eller integrerats i utvecklingssprintarna. Teamet hade fått ett vagt uppdrag att “göra den säker”, men utan en konkret ritning förblev säkerhet en otydlig och ofta ignorerad efterhandsfråga.

Detta scenario är inte unikt. Det visar den kritiska lucka som många informationssäkerhetschefer och ansvariga för regelefterlevnad står inför: att omvandla intentionen “vi arbetar med säkerhet” till explicita, testbara säkerhetskrav för applikationer som är anpassade till centrala standarder som ISO/IEC 27001:2022 och centrala regelverk som NIS2, DORA och GDPR.

Den höga kostnaden för otydlighet: vad efterlevnad faktiskt kräver

Kärnan i Marias problem ligger i ett vanligt organisatoriskt misslyckande: att behandla säkerhet som en kvalitetsegenskap i stället för som en uppsättning icke förhandlingsbara krav. Ett effektivt säkerhetskrav är specifikt, mätbart och testbart. “Applikationen ska vara säker” är en önskan. “Applikationen ska tillämpa tidsgränser för inaktiva sessioner på 15 minuter, validera all indata från användare mot en fördefinierad teckenuppsättning och kryptera all data under överföring med TLS 1.3” är ett krav. Det är denna tydlighet som revisorer söker och som utvecklare behöver för att bygga säker programvara.

Utan den bjuder man in en kedja av brister:

• Inkonsekvent införande: Olika utvecklare tolkar “säker” på olika sätt, vilket leder till ett lapptäcke av kontroller med oförutsägbara luckor.
• Ökade kostnader för åtgärdande: Att hitta och åtgärda en designbrist i produktion är exponentiellt dyrare än att hantera den i designfasen.
• Avvikelser vid revision: Revisorer identifierar snabbt avsaknaden av en strukturerad process för att definiera säkerhetskrav, vilket leder till större avvikelser.
• Verksamhetsrisk: Varje odefinierat krav är en potentiell angreppsvektor som exponerar organisationen för personuppgiftsincidenter, finansiella förluster och anseendeskada.

I moderna standarder är förväntningen konsekvent: säkerhet ska definieras som krav, tidigt, och kopplas till risk och lagkrav. Vägledningen i ISO/IEC 27002:2022 för kontroll 8.26, Säkerhetskrav för applikationer, förväntar sig att organisationer systematiskt fastställer, dokumenterar och godkänner säkerhetskrav baserat på formell riskbedömning och regulatoriska krav.

Denna enda princip är navet för en lång rad krav på regelefterlevnad. Clarysecs tvärgående efterlevnadsmappning i Zenith Controls: The Cross-Compliance Guide Zenith Controls visar hur konceptet återkommer överallt:

• GDPR Article 25 och Article 32 förväntar sig ”dataskydd genom design” och ”säkerhet i behandlingen”.
• NIS2 Article 21(2)(d)-(e) betonar säker utveckling och säkerhet i leveranskedjan.
• DORA Article 6(4), Article 8, Article 10 och Article 11 kräver IKT-riskhantering och säkerhet genom design för finansiella entiteter.
• NIST SP 800-53 Rev.5 kräver i kontrollerna SA-4 och SA-15 definierade systemkrav för säkerhet och säker utvecklingspraxis.
• COBIT 2019 kräver i processerna BAI03 och DSS05 att säkerhetsrelaterade krav anpassas till verksamhets- och efterlevnadskrav innan en lösning byggs.

Målet är att definiera, med orden i Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, ”vad säkerhet innebär för era applikationer innan en enda kodrad skrivs.”

Varför traditionella angreppssätt misslyckas: checklistor, sen testning och säkerhetsteater

De flesta organisationer arbetar redan med någon form av applikationssäkerhet. Problemet är att arbetet sällan är strukturerat på ett sätt som håller för ISO/IEC 27001:2022-certifiering eller regulatorisk granskning.

Vanliga mönster för misslyckanden är:

1. Generiska checklistor: Team återanvänder en ensidig “checklista för säker kodning” för varje projekt. Den är inte kopplad till applikationens specifika risker, datans känslighet eller regulatoriska sammanhang. När en revisor frågar hur checklistan mappar mot GDPR Article 25 finns inget tydligt svar.
2. Säkerhet som en sen grind: Säkerhetskrav byggs inte in i design eller användarberättelser. De dyker upp i slutet som en begäran om penetrationstestning. Zenith Blueprint varnar för att ”det inte fungerar att förlita sig på en säkerhetschecklista i slutet av projektet; dessa krav måste forma arkitekturen, påverka val av bibliotek och styra prioritering av funktioner från dag ett.”
3. Ingen spårbarhet från krav till test: Ett krav kan finnas om att ”kryptera data under överföring”, men det finns inget kopplat testfall som verifierar krav på TLS-version, certifikatets giltighet och chiffersviternas styrka. Zenith Blueprint framhåller att förväntningar måste vara mätbara och testbara, med säkerhetstester direkt mappade till motsvarande krav.
4. Ad hoc-hantering av tredjepartskod: Moderna applikationer är ofta ”sammanfogade av intern kod, tredjepartsbibliotek, API:er och molnbaserade tjänster”, som Zenith Blueprint konstaterar. Utan explicita krav för leverantörer och komponenter med öppen källkod förblir risker i leveranskedjan en stor, okontrollerad blind fläck.

Resultatet blir säkerhetsteater: dokument finns och tester genomförs, men när en seriös revisor eller tillsynsmyndighet söker en sammanhängande kravkedja faller hela processen isär.

Bygg grunden: från policy till praktik

Ett disciplinerat angreppssätt för applikationssäkerhet börjar med tydlig styrning. Policy är inte bara byråkrati; den är den auktoritativa källan som ger team mandat och ger revisorer en tydlig avsiktsförklaring. På Clarysec utformar vi policyer som är både auktoritativa och praktiska.

Vår Policy för applikationssäkerhetskrav Policy för applikationssäkerhetskrav fastställer icke förhandlingsbara grundregler. Till exempel anger klausul 5.2 under ”Styrningskrav” följande:

Alla applikationer ska genomgå validering av säkerhetskrav under planering eller upphandling, med dokumenterat godkännande från teamet för applikationssäkerhet.

Denna enkla instruktion förhindrar mentaliteten “bygg först, säkra senare”. Policyn tilldelar även tydligt ansvar. Klausul 4.3.1 under ”Roller och ansvar” anger att utvecklare ska:

Implementera applikationer i enlighet med definierade säkerhetskrav och standarder.

Det flyttar ansvaret för säkerhet från ett separat, ofta motstående, säkerhetsteam till dem som skapar programvaran. Dessutom kopplar policyn samman olika säkerhetsdomäner. Klausul 10.2 hänvisar till integrationen med andra centrala kontroller:

P4 – Åtkomstkontrollpolicy. Definierar standarder för identitets- och sessionshantering som ska tillämpas av alla applikationer, inklusive stark autentisering, principen om minsta privilegium och krav på åtkomstgranskning.

För mindre organisationer säkerställer en anpassad policy som vår Policy för applikationssäkerhetskrav – små och medelstora företag Policy för applikationssäkerhetskrav – små och medelstora företag att principerna är skalbara. Den erkänner att även om riskerna är likartade måste genomförandet vara pragmatiskt. Båda versionerna syftar i slutänden till samma resultat: att säkerställa att applikationssäkerhet är fullt integrerad i ISMS och är revisionsredo.

En praktisk färdplan: bygg revisionsredo säkerhetskrav för applikationer

Policyn anger “vad” och “varför”, men utvecklare och projektledare behöver “hur”. En strukturerad vägledning för genomförande är nödvändig för att översätta övergripande kontroller till konkreta steg. Steg 21 i Zenith Blueprint, som fokuserar på ISO/IEC 27002:2022 kontroll 8.26, ger en tydlig metodik i sex steg.

Låt oss gå igenom processen med Marias betalningsportal som exempel.

Steg 1: utgå från risk och regulatoriskt sammanhang

Med hjälp av resultat från riskbedömning i linje med ISO/IEC 27005:2024 (riskbehandling) identifierar du först sammanhanget:

• Applikation: Självbetjäningsportal för kundbetalningar.
• Data: Personuppgifter (PII), autentiseringsuppgifter, betalningstoken.
• Jurisdiktioner: EU, finansiella tjänster, i molnmiljö.
• Regelverk: GDPR, DORA, PCI DSS.

Baserat på vägledningen för kontroll 8.26 i Zenith Controls och dess relaterade ISO-standarder (27034-1, 27017, 27701) ska de inledande kravkategorierna omfatta identifiering och autentisering, auktorisation, dataklassificering, indatavalidering, loggning samt dataskydd under överföring och i vila.

Steg 2: skapa eller anta en mall för säkerhetskrav

Zenith Blueprint rekommenderar att en standardiserad mall tas fram för att säkerställa att varje projekt besvarar samma grundläggande säkerhetsfrågor. Dokumentet bör bli en del av verktygslådan vid projektstart.

Minimiavsnitt bör omfatta:

• Applikationens namn, ägare och kritikalitet.
• Datakategorier och känslighetsnivåer.
• Tillämpliga regulatoriska och avtalsmässiga skyldigheter (GDPR, DORA osv.).
• Underlag om hotlandskapet (härlett från kontroll 5.7 Hotinformation).
• Specifika säkerhetskrav per kategori (autentisering, loggning osv.).
• Kopplingar till användarberättelser och acceptanskriterier.
• Kopplingar till testfall (funktionella tester, säkerhetstester, penetrationstestning).
• Krav på leverantörer och tredjepartskomponenter.

Steg 3: bygg in kraven i agila artefakter

Säkerhetskrav ska byggas in direkt i användarberättelser och acceptanskriterier. För epiken “kundregistrering” i Marias portalprojekt innebär det att en enkel funktionell berättelse omvandlas till en säkerhetsmedveten berättelse.

• Ursprunglig användarberättelse: “Som ny användare kan jag skapa ett konto.”
• Säker användarberättelse: “Som ny kund vill jag skapa ett säkert konto så att min betalningsinformation skyddas.”
• Acceptanskriterier (med inbyggd säkerhet):
  • Systemet ska tillämpa en stark lösenordspolicy i linje med P4 – Åtkomstkontrollpolicy.
  • Systemet ska kräva e-postverifiering via en engångslänk innan kontot aktiveras.
  • Formuläret för kontoskapande ska skyddas med CAPTCHA för att förhindra botattacker.
  • Alla registreringsförsök ska loggas med käll-IP och enhetsfingeravtryck.
  • Alla data som skickas via formuläret ska saneras för att förhindra cross-site scripting (XSS).

Detta är inte separata säkerhetsuppgifter; de är en integrerad del av kriterierna för när funktionen är klar.

Steg 4: koppla krav till säkerhetstestning

Med kontroll 8.29 Säkerhetstestning från Zenith Controls säkerställer du att varje krav har ett tillhörande testfall. Det sluter kretsen och ger revisionsbart underlag för kontrolleffektivitet.

• Krav: Kryptering under överföring med TLS 1.3. → Test: Automatiserad skanning för att verifiera TLS-krav, certifikatets giltighet och godkända chiffersviter.
• Krav: Indatavalidering för att förhindra SQL-injektion. → Test: Automatiserad SAST/DAST-skanning och manuell fuzzning under kvalitetssäkring (QA).
• Krav: Tidsgräns på 15 minuter för inaktiv session. → Test: Automatiserade och manuella tester för att bekräfta att sessionen ogiltigförklaras på serversidan efter 15 minuters inaktivitet.

Steg 5: utvidga kraven till leveranskedjan

Eftersom ISO-kontroll 8.26 är kopplad till leverantörssäkerhet (5.19, 5.20) och outsourcad utveckling (8.30) i Zenith Controls måste processen omfatta tredjepartskod. För små och medelstora företag som är starkt beroende av externa bibliotek är policyklausulen från Policy för applikationssäkerhetskrav – små och medelstora företag kritisk:

Alla tredjepartsverktyg, insticksprogram eller externa kodbibliotek som används i en applikation ska registreras och granskas årligen avseende säkerhetspåverkan och patchstatus.

Detta enkla, pragmatiska krav driver ett arbetssätt med software bill of materials (SBOM), vilket är en central förväntan enligt regelverk som NIS2. För större leverantörer ska samma säkerhetskrav för applikationer inkluderas i avtal, med hänvisning till ISO/IEC 27036-1 (säkerhet i IKT-leveranskedjan).

Steg 6: inför periodisk omprövning

När applikationer utvecklas förändras även deras risker. Vägledningen i Zenith Blueprint om periodisk omprövning är avgörande. När du integrerar ett nytt API eller flyttar till en annan molntjänst förändras risksammanhanget. Det ska utlösa en granskning av befintliga säkerhetskrav för att säkerställa att de fortfarande är tillräckliga. Detta ligger i linje med ISO/IEC 27005:2024 (löpande riskbehandling) och gör applikationssäkerhet till en kontinuerlig praxis, inte ett engångsprojekt.

Nedbrytning av kontrollekosystemet

En ISO-kontroll existerar aldrig i ett vakuum. Effektiv säkerhet bygger på ett sammanlänkat nät av åtgärder. Den verkliga styrkan i kontroll 8.26 frigörs när man förstår dess relation till andra kontroller, ett perspektiv som beskrivs i Zenith Controls.

Kontroll 8.26 klassificeras som en förebyggande kontroll, men den fungerar som navet för hela den säkra utvecklingsprocessen och kopplar till:

• 8.25 - Livscykeln för säker utveckling: Detta är det övergripande ramverket. Kontroll 8.26 anger det specifika vad (kraven) som ska integreras i hur (SDLC-processen).
• 8.27 - Säker systemarkitektur och tekniska principer: Krav styr arkitekturbeslut och säkerställer att säkerhet är grundläggande.
• 8.28 - Säker kodning: När kraven har definierats (t.ex. “förhindra SQL-injektion”) ger standarder för säker kodningspraxis utvecklare teknikerna för att uppfylla kravet.
• 8.29 - Säkerhetstestning vid utveckling och acceptans: Denna kontroll validerar att kraven som definierats i 8.26 har införts korrekt.
• 5.34 - Integritet och skydd av PII: När en applikation hanterar personuppgifter ska kraven från 8.26 omfatta principerna för integritetsskydd genom design.
• 5.19 och 5.20 - Informationssäkerhet i leverantörsrelationer: För anskaffade eller outsourcade applikationer innebär kontroll 8.26 att era säkerhetskrav ska utsträckas till leveranskedjan.

Genom att se dessa kontroller som ett ekosystem snarare än en checklista kan du bygga ett flerskiktat och försvarbart säkerhetsläge.

Revisorns perspektiv: förberedelse för granskning

Revisorer tänker i termer av underlag. För att förbereda dig måste du förstå de olika perspektiv en revisor kan ha. Avsnittet om revisionsmetodik i Zenith Controls förutser dessa olika angreppssätt.

Genom att förstå dessa perspektiv kan du förbereda en heltäckande portfölj av underlag som visar en levande process inbyggd i organisationen.

Kompassen för tvärgående efterlevnad: en process, många ramverk

För ett företag som Marias är det obligatoriskt att uppfylla DORA, GDPR och NIS2. Manuell mappning av kontroller är ett recept på dubbelarbete och efterlevnadsluckor. Ett centraliserat, tvärgående angreppssätt för efterlevnad ger stort värde. Att definiera säkerhetskrav för applikationer är det praktiska genomförandet av principen om “säkerhet genom design” som ligger till grund för alla dessa moderna regelverk.

Genom att införa en robust process för säkerhetskrav för applikationer baserad på ISO/IEC 27002:2022 bygger du samtidigt underlag som uppfyller en betydande del av dessa andra regelverk. Du “gör” inte bara ISO; du bygger ett säkerhetsprogram med bred regelefterlevnad.

Från kaos till kontroll: vägen framåt

Marias berättelse fick ett positivt utfall. Hon använde incidenten med betalningsportalen som en katalysator för förändring. Med ett tydligt policyramverk från Clarysec och en praktisk vägledning för genomförande samlade hon utvecklings-, säkerhets- och produktteamen. De använde metodiken i Zenith Blueprint för att i efterhand definiera krav för portalen och prioritera åtgärder utifrån risk.

Ännu viktigare var att de etablerade ett nytt arbetssätt. “Säkerhetschecklistan” ersattes av samarbetsbaserade designsessioner. När DORA-revisorerna kom kunde Maria inte bara visa upp en säker applikation, utan också visa en mogen, repeterbar process för att säkerställa att alla framtida applikationer byggs på en säker grund.

Att förändra ert säkerhetsläge för applikationer börjar med ett enda strukturerat steg. Vägen framåt är tydlig:

1. Etablera styrning: Inför en formell policy för att definiera säkerhetskrav för applikationer. Våra mallar, till exempel Policy för applikationssäkerhetskrav, ger en revisionsredo utgångspunkt.
2. Anta ett praktiskt ramverk: Använd Zenith Blueprint för att integrera säkerhetskrav direkt i utvecklingslivscykeln och göra dem åtgärdbara, testbara och spårbara.
3. Förstå hela sammanhanget: Använd Zenith Controls för att se hur denna kritiska kontroll kopplar till det bredare säkerhetsekosystemet och mappas mot DORA, NIS2, GDPR med flera.
4. Skala till hela portföljen: När arbetssättet fungerar för en applikation skalar du det till hela portföljen genom att integrera mallen för säkerhetskrav i standardiserade checklistor för projektstart, agila mallar och upphandlingsprocesser.

Om du vill påskynda denna transformation tillhandahåller Clarysec färdiga policyer, färdplaner för genomförande och tvärgående efterlevnadsmappningar som hjälper dig att gå från fragmenterade insatser till ett bevisbart moget och revisionsredo program. Sluta behandla applikationssäkerhet som en slutkontroll. Börja bygga in den i ritningen för allt ni skapar.