Säker utvecklingslivscykel i cybersäkerhetslagen
Säkerhet ska vara bra, effektivt och inbyggt, det uppnås med säkerhet genom utveckling, Security By Design. Det har järnväg och flyg sysslat med i hundra år.
Cybersäkerhetslagen ställer krav på säkerhet vid förvärv, utveckling och underhåll. Security By Design, säkerhet genom utveckling gör säkerhetsarbetet till en del av designarbetet. Security By Design är ett säkerhetspaket påhängt den normala processen för design och utveckling där risk och åtgärdsanalys är en central del i arbetet.
Ta bort möligheteter till fel vid design
Säkerhetskraven, hur du tar bort vid designfram dem och när kan sammanfattas i enlighet med den rosa boxen.
Den här artikeln riktar sig till dig som vill förstå kraven som cybersäkerhetslagen ställer på säkerhet vid förvärv, utveckling och underhåll.
Jag har kopplat de krav som finns i förordningen för implementation av NIS2-direktivet till punkter i ISO 27001 Bilaga A. På detta sätt hoppas jag du hittar vad du skall göra för att efterleva cybersäkerhetslagen.
Upphandling av IKT
6.1 Säkerhet vid upphandling av IKT-tjänster eller IKT-produkter
Processer ska finnas för hantering av risker från anskaffning IKT-tjänster och produkter kritiska för säkerhet baserad riskanalys genomförd av leverantörna. Processerna ska innefatta:
(a) säkerhetskrav för IKT-tjänster och produkter;
(b) krav på säkerhetsuppdateringar;
(c) beskrivning av använd hård- och mjukvara;
(d) beskrivning av cybersäkerhetsfunktioner och dess konfiguration som krävs för säker drift;
(e) säkerställande att säkerhetskraven uppfylls
(f) metoder för validering av överensstämmelse säkerhetskraven , och dokumentation av resultat.
Processerna ska granskas och uppdateras med planerade intervall och vid betydande incidenter.
ISO 27001 Bilaga A 5.21 säkerhet vid upphandling av IKT-tjänster och produkter
IKT, eller informations- och kommunikationsteknik, är infrastrukturen. IKT inkluderar både hårdvara (som datorer, servrar och nätverksutrustning) och mjukvara (som operativsystem, applikationer och plattformar för kommunikation), samt nätverk.
Syftet med säkerhet vid upphandling av IKT-tjänster och produkter är att du upprätthåller en överenskommen nivå av informationssäkerhet i leverantörsrelationer.
Definition av säkerhet vid upphandling av IKT-tjänster och produkter bilaga A 5.21: Processer och procedurer ska definieras och implementeras för att hantera de informationssäkerhetsrisker som är kopplade till leveranskedjan för IKT-produkter och -tjänster.
Säker utvecklingslivscykel
6.2 Säker utvecklingslivscykel
Regler för säker IT-utveckling ska finnas, alla faser ingår, inklusive specifikation, design, utveckling, implementation och test. Aktörerna ska:
(a) analysera säkerhetskrav under specifikations- och designfaserna;
(b) tillämpa principer för säker utveckling, t ex cybersäkerhet genom design och zero trust;
(c) fastställa säkerhetskrav för utvecklingsmiljöer;
(d) upprätta/genomföra processer säkerhetstest.
(e) välja, skydda och hantera säkerhetstestdata
(f) riskbedömma, rensa & anonymisera testdata
Reglerna ska tillämpas vid egen och utkontrakterd av utveckling. Inklusive policys och förfaranden i 5 och 6.1. Aktörerna ska granska och uppdatera reglerna med planerade intervall.
ISO 27001 Bilaga A 8.25 Säker utvecklingslivscykel
Säker utvecklingslivscykel ska säkerställa att informationssäkerhet designas och implementeras i en säker utvecklingslivscykel.
Säker tvecklingslivscykel definieras i bilaga A 8.25: Regler för säker utveckling av programvara och system ska upprättas och tillämpas.
ISO 27001 Bilaga A 8.26 Säkerhetskrav för applikationer
Säkerhetskrav för applikationer kräver att vi identifierar, specificerar och godkänner informationssäkerhetskrav när vi utvecklar eller införskaffar applikationer.
Definition: Informationssäkerhetskrav ska identifieras, specificeras och godkännas vid utveckling eller införskaffning av applikationer.
ISO 27001 Bilaga A 8.27 Principer för säker systemarkitektur och designprinciper
Principer för säker systemarkitektur och designprinciper kräver att säkerhet byggs in i alla arkitekturlager under utvecklingslivscykeln. Syftet är att säkerställa att informationssystem är säkert designade, implementerade och drivs inom utvecklingslivscykeln.
Definitionen i bilaga A 8.27 är: Principer för att konstruera säkra system ska fastställas, dokumenteras, upprätthållas och tillämpas på alla aktiviteter för utveckling av informationssystem.
ISO 27001 Bilaga A 8.28 Principer för säker kodning
Säker kodning kräver att vi utvecklar kod, programvara och system med informationssäkerhet inbyggd från början.
Målet är att minska antalet potentiella säkerhetsbrister i programvaran. Definition enligt bilaga A 8.28: Principer för säker kodning ska tillämpas vid utveckling av programvara.
Ensions metod för säker utvecklingslivscykel cybersäkerhetslagen
IISO 61508 används en övergripande säkerhetslivscykel för att strukturera säkerhetsskapande aktiviteter.
Realiseringsdelen beskrivs i IEC 61508-2. Mjukvarans säkerhetslivscykel detaljeras i IEC 61508-3.
Iteration är en viktig ocbh nödvändig del av utvecklingen genom systemets och mjukvarans säkerhetslivscykel.
Genomförandeförordningen kräver att säkerhet integreras i alla faser av utvecklingen – från specifikation till testning. Här ser du hur Ensions ingenjörsmässiga ansats skiljer sig från traditionella metoder för att uppnå inbyggd cybersäkerhet.
| Krav i Genomförandeförordningen (6.2.2) | Andra (Traditionell IT/MSB-metod) | Ensions Metod (Safety & Security) | Varför Ension uppfyller kraven bättre |
|---|---|---|---|
| (a) Analys av säkerhetskrav i specifikations- och utformningsfaserna. | Säkerhet läggs ofta till som en kontrollista efter att funktionaliteten är spikad. | V-modellens vänstra sida: Säkerhetskrav identifieras i HAZID och mappas direkt mot systemets specifikation. | Vi säkerställer att säkerhet är en funktionell egenskap, inte ett påhäng. Det minskar teknisk skuld dramatiskt. |
| (b) Tillämpa principer för säkra system och säker kodning (Inbyggd cybersäkerhet & Nolltillit). | Fokus på yttre skydd (brandväggar) och generiska kodningsregler (t.ex. OWASP). | Safety by Design-principer och Zero Trust-arkitektur implementerad på komponentnivå. | Vi bygger systemet med "cockpit-filosofi" – robust inifrån och ut, där varje del verifierar nästa. |
| (c) Fastställa säkerhetskrav för utvecklingsmiljöer. | Grundläggande IT-skydd för kontorsmiljön där utvecklare sitter. | Härdade utvecklingspipelines (CI/CD) med strikt kontroll av kodintegritet och verktygskedjor. | Vi skyddar själva "fabriken" för att förhindra Supply Chain-attacker innan koden ens når drift. |
| (d) Fastställa och genomföra processer för säkerhetstester under utvecklingscykeln. | Penetrationstestning utförs ofta som en sista punkt innan produktionssättning. | Kontinuerlig verifiering mot de krav som fastställdes i HAZID/specifikationen (V-modellens högra sida). | Vi upptäcker sårbarheter löpande. Att hitta ett fel i designfasen är 100 gånger billigare än i drift. |
| (e) Välja ut, skydda och förvalta säkerhetstestdata. | Användning av kopior från produktionsdata, vilket skapar risker för integritetsläckage. | Styrd hantering av syntetiska eller strikt kontrollerade testmiljöer frikopplade från känslig data. | Vi eliminerar risken att testning i sig blir en säkerhetsrisk för organisationen. |
| (f) Sanera och anonymisera testdata enligt utförd riskbedömning (2.1). | Enkel "maskning" av fält utan djupare analys av återidentifieringsrisker. | Anonymisering baserad på den allriskansats som identifierat känsliga flöden och personalkategorier. | Vi säkerställer efterlevnad av både NIS2 och GDPR genom att riskbedöma datans livscykel i test. |
Konfigurationshantering
6.3 Konfigurationshantering
Åtgärder för att fastställa, dokumentera, implementera och övervaka konfiguration av hårdvara, mjukvara, tjänster och nätverk ska finans. Aktörerna ska fastställa och säkerställa :
(a) säkra konfigurationer av hårdvara, mjukvara, tjänster och nätverk;
(b) processer och verktyg för upprätthållande av fastställda konfigurationerna.
Konfigurationerna ska granskas och uppdateras med planerade intervall, vid betydande incidenter och vid väsentliga verksamhetsförändringar.
ISO 27001 Bilaga A 8.9 Konfigurationshantering
Konfigurationshantering, säkerställer att mjukvara och hårdvara är korrekt konfigurerade, dokumenterade, övervakade och granskade.
Syftet med konfigurationshantering är att säkerställa att hårdvara, mjukvara, tjänster och nätverk fungerar korrekt med nödvändiga säkerhetsinställningar och att konfigurationerna skyddas från obehöriga eller felaktiga ändringar.
Bilaga A 8.9 definition av konfigurationshantering: Konfigurationer, inklusive säkerhetskonfigurationer, av hårdvara, mjukvara, tjänster och nätverk ska fastställas, dokumenteras, implementeras, övervakas och granskas.
Ändringshantering
6.4 Ändringshantering, reparationer och underhåll
Procedurer för ändringshantering ska finnas för kontroll av förändring i IT-system.
Procedurerna ska tillämpas vid all förändring av mjukvara och hårdvara och säkerställa dokumentation och test innan implementation.
Om de ordinarie procedurer för ändringshantering inte kunde följas på grund av nöd, ska resultatet av ändringen dokumentera samt förklaringen till varför procedurerna inte kunde följas.
Procedurerna ska granskas uppdateras vid planerade intervaller, vid betydande incidenter och väsentliga verksamhetsförändringar.
ISO 27001 Bilaga A 8.32 Ändringsshantering
Ändringshantering kräver att vi hanterar ändringar både i informationssäkerhetshanteringssystemet (ISMS) och i informationsbehandlingsanläggningar.
Syftet med ändringshantering är att bevara informationssäkerheten vid genomförande av ändringar.
Definition av ändringshantering i bilaga A 8.32: Ändringar i informationsbehandlingsanläggningar och informationssystem ska vara föremål för ändringshanteringsprocedurer.
Säkerhetstestning
6.5 Säkerhetstestning
Policy och procedurer för säkerhetstestning ska finnas. Aktörerna ska:
(a) baserat på riskanalysen fastställa behov, omfattning, frekvens och typ av säkerhetstester;
(b) genomföra säkerhetstester för komponenter identifierde som relevanta för säker drift enligt dokumenterad testmetodik;
(c) dokumentera typ, omfattning, tidpunkt och resultat av testerna;
(d) vidta åtgärder för att mildra risker i händelse av kritiska upptäckter.
Aktörerna ska granska och uppdatera sina policys för säkerhetstestning vid planerade intervaller.
ISO 27001 Bilaga A 8.8 Säkerhetstestning i Utveckling och acceptans.
Säkerhetstestning i utveckling och acceptans kräver att programvara testas innan den sätts i produktion för att säkerställa att informationssäkerhetskraven är uppfyllda.
Syftet med säkerhetstestning i utveckling och vid acceptans är att verifiera om informationssäkerhetskrav är uppfyllda när applikationer eller kod implementeras i produktionsmiljön.
Definition av säkerhetstestning i utveckling och acceptans i bilaga A 8.29: Processer för säkerhetstestning ska definieras och implementeras i utvecklingslivscykeln.
Hantering av säkerhetspatchar
6.6 Hantering av säkerhetspatchar
Procedurer ska finnas som säkerställer att säkerhetspatchar:
(a) tillämpas i rimlig tid efter att de är tillgängliga;
(b) testas innan de appliceras i produktion;
(c) kommer från betrodda källor och kontrolleras för integritet;
Undantagsvis kan när nackdelarna överväger cybersäkerhetsfördelarna säkerhetspatchar väljas att inte tillämpas . Skälen beslutet ska noggrant dokumenteras och motiveras.
I de fall där en patch inte är tillgänglig eller inte appliceras ska ytterligare åtgärder genomföras och kvarvarande risker accepteras.
ISO 27001 Bilaga A 8.8 Hantering av tekniska sårbarheter
ISO 27001 Bilaga A 8.8 Hantering av tekniska sårbarheter är en ISO 27001-kontroll som säkerställer att du förstår vilka sårbarheter som finns i din teknik och gör informerade beslut för att hantera dem.
Syftet med Hantering av Tekniska Sårbarheter är att skydda information och andra associerade tillgångar från utnyttjande av tekniska sårbarheter.
Nätverkssäkerhet
6.7 Nätverkssäkerhet
Åtgärder ska vidtas för att skydda aktörens IT-system från cyberhot. Aktörerna ska:
(a) dokumentera nätverksarkitekturen på ett begripligt och uppdaterat sätt;
(b) fastställa och tillämpa kontroller som skyddar interna nätverksdomäner från obehörig åtkomst;
(c) konfigurera kontroller som hindrar obehörig åtkomst och nätverkskommunikation.
(d) fastställa och tillämpa kontroller för fjärråtkomst till IT-system;
(e) inte använda system för administration av säkerhetspolicy för andra ändamål;
(f) uttryckligen förbjuda eller inaktivera onödiga anslutningar och tjänster;
(g) när det är lämpligt endast tillåta åtkomst till IT-system för enheter som är godkända av aktören;
(h) endast tillåta anslutning av tjänsteleverantörer efter godkännande och under en bestämd tid;
(i) etablera kommunikation mellan system via betrodda kanaler isolerade logiskt, kryptografiskt eller fysiskt från andra kanaler med säker identifiering av ändpunkter samt skydd av kanaldata mot modifiering eller avslöjande;
(j) ha en plan för övergång till nästa generations säkra kommunikationsprotokoll för nätverkslager, samt fastställa åtgärder för att påskynda planen;
(k) anta en plan för att införa standarder för säker kommunikation av e-post samt fastställa åtgärder för att påskynda implementering;
(l) tillämpa bästa praxis för säker DNS samt för Internetrouting och routinghygien för trafik som härstammar från och är avsedd för nätverket.
ISO 27001 Bilaga A 8.20 nätverkssäkerhet
ISO 27001 Bilaga A 8.20 Nätverkssäkerhet är en ISO 27001-kontroll som kräver att vi säkrar våra nätverk och dokumenterar att vi gör det.
Syfte ISO 27001 Bilaga A 8.20 är en förebyggande och upptäckande kontroll för att skydda information i nätverk och dess stödsystem för informationsbehandling från att komprometteras via nätverket.
Definition ISO 27001-standarden definierar ISO 27001 Bilaga A 8.20 som: Nätverk och nätverksenheter ska säkras, hanteras och kontrolleras för att skydda information i system och applikationer.
ISO 27001 Bilaga A 8.21 säkerhet för nätverkstjänster
ISO 27001 Bilaga A 8.21 Säkerhet för Nätverkstjänster är en ISO 27001-kontroll som kräver att vi säkrar våra nätverk samt har servicenivåer och tjänstekrav implementerade, övervakade och identifierade.
Syfte ISO 27001 Bilaga A 8.21 är en förebyggande kontroll för att säkerställa säkerhet vid användning av nätverkstjänster.
Definition ISO 27001-standarden definierar ISO 27001 Bilaga A 8.21 som: Säkerhetsmekanismer, servicenivåer och tjänstekrav för nätverkstjänster ska identifieras, implementeras och övervakas.
Nätverkssegmentering
6.8 Nätverkssegmentering
System ska segmenteras i nätverk eller zoner i enlighet med riskanalysen. Systemen och nätverk ska segmenteras från tredje parts system och nätverk. Aktörerna ska:
(a) beakta den funktionella, logiska och fysiska relationen, mellan betrodda system och tjänster;
(b) bevilja åtkomst till ett nätverk eller en zon baserat på en bedömning av dess säkerhetskrav;
(c) hålla system kritiska för verksamhet eller säkerhet i säkrade zoner;
(d) införa en demilitariserad zon (DMZ) skapande säker kommunikation till och från eget nätverk;
(e) begränsa åtkomst och kommunikation mellan och inom zoner till de som är nödvändiga för de berörda aktörernas verksamhet eller säkerhet.
(f) separera nätverket för administration av IT-system från operativa nätverk;
(g) segregera nätverksadministrationskanaler från annan nätverkstrafik;
(h) separera produktionssystem tjänster från system som används för utveckling och testning.
Nätverkssegmenteringen ska granskas och uppdateras vid planerade intervaller och när betydande incidenter eller vid väsentliga förändringar i verksamheten eller risker.
ISO 27001 Bilaga A 8.22 Segregering av nätverk
ISO 27001 Bilaga A 8.22 Segregering av nätverk är en ISO 27001-kontroll som kräver att vi grupperar informationstjänster och placerar dessa grupper på olika nätverk. Idealiskt sett innebär detta att informationstjänster, användare och informationssystem placeras på separata nätverk, men det finns en del nyanser i denna strategi.
Syfte ISO 27001 Bilaga A 8.22 är en förebyggande kontroll för att dela upp nätverket i säkerhetsgränser och styra trafiken mellan dem baserat på affärsbehov.
Definition ISO 27001-standarden definierar ISO 27001 Bilaga A 8.22 som: Säkerhetsmekanismer, servicenivåer och tjänstekrav för nätverkstjänster ska identifieras, implementeras och övervakas.
Skydd mot skadlig progrmvara
6.9 Skydd mot skadlig och obehörig programvara
Informationssystem ska skyddas mot skadlig och obehörig programvara. För detta ändamål ska det införas åtgärder som upptäcker eller förhindrar användning av skadlig eller obehörig programvara. Där det är lämpligt ska det säkerställas att aktörens IT-system är utrustade med detektions- och svarsmjukvara som uppdateras regelbundet i enlighet med riskanalysen och avtalet med leverantörerna.
ISO 27001 Bilaga A 8.7 Skydd mot skadlig programvara är en ISO 27001-kontroll som säkerställer att organisationen förstår skadlig programvara i alla dess former och tar ett helhetsgrepp för att skydda sig mot den.
Syfte Syftet med ISO 27001 Bilaga A 8.7 Skydd mot skadlig programvara är att säkerställa att information och andra tillhörande tillgångar skyddas mot skadlig programvara.
Definition ISO 27001-standarden definierar ISO 27001 Bilaga A 8.7 som: Skydd mot skadlig programvara ska implementeras och stödjas av lämplig användarmedvetenhet.
Sårbarhetshantering
6.10 Sårbarhetshantering och upplysningar
Information om tekniska sårbarheter i IT-system, ska inhämtas, utvärderas och åtgärder ska vidtas för att hantera dem. Aktörerna ska:
(a) övervaka information om sårbarheter via lämpliga kanaler.
(b) utföra sårbarhetsskanningar vid planerade intervaller;
(c) åtgärda identifierade för verksamheten kritiska sårbarheter utan oskäligt dröjsmål
(d) hantera sårbarheter enligt processer för ändringshantering, säkerhetspatchar, riskhantering och incidenthantering;
(e) ha en procedur för att upplysa om sårbarheter enligt med nationella policyn för samordnat avslöjande av sårbarheter.
När det är motiverat av den potentiella påverkan av sårbarheten, ska de berörda aktörerna skapa och genomföra en plan för att mildra sårbarheten. I andra fall ska de berörda aktörerna dokumentera och motivera skälen till varför sårbarheten inte kräver åtgärder.
De berörda aktörerna ska granska och, där det är lämpligt, uppdatera de kanaler de använder för att övervaka sårbarhetsinformation vid planerade intervaller.
ISO 27001 Bilaga A 8.8 Hantering av tekniska sårbarheter
Lämplig kanaler kan vara CSIRTs, behöriga myndigheter eller leverantörer;
procedurer för ändringshantering, hantering av säkerhetspatchar, riskhantering och incidenthantering