Vad ska ingå i informationssäkerhetspolicyn för mjukvaruutveckling?
En informationssäkerhetspolicy för mjukvaruutveckling är det dokument där du fastställer hur din organisation hanterar säkerheten för information, system och kod. För ett mjukvaruföretag handlar det om två saker samtidigt: säkerheten för vad du bygger och säkerheten för miljön där du bygger det. Båda ska ingå i samma dokument, även om de innehållsmässigt är olika ämnen.
I praktiken innebär detta att policyn vanligtvis behandlar omfattningen (vilka system och vilka utvecklingsprojekt som omfattas), ansvaret (vem beslutar, vem administrerar, vem kontrollerar), hur åtkomsten till källkod och utvecklingsmiljöer är organiserad, hur sårbarheter i egen kod identifieras och åtgärdas, hur testmiljöer jämfört med produktionsmiljöer hanteras, hur incidenter dokumenteras och hur policyn själv uppdateras och granskas. En checklista från en köpare frågar ofta efter just denna typ av dokument som bevis, inte efter en teknisk beskrivning av din källkod.
Två nivåer: produkten och utvecklingsmiljön
Den första nivån handlar om produkten: den mjukvara du levererar till kunder. Det innefattar en beskrivning av hur du hanterar sårbarheter som upptäcks efter leverans, hur uppdateringar och patchar når kunderna, och vem inom organisationen som är ansvarig för att följa upp rapporter om säkerhetsproblem i produkten.
Den andra nivån handlar om utvecklingsmiljön: den miljö där ditt team arbetar. Det är versionskontrollmiljön, build- och testpipelinen, och separationen mellan test- och produktionsmiljöer. Här handlar det om frågor som vem som får åtkomst till källkoden, hur ändringar granskas innan de körs live, och hur åtkomsten återkallas när någon lämnar teamet. Båda nivåerna kan ingå i samma dokument, men beskrivs ofta separat eftersom riskerna och de ansvariga för dem skiljer sig.
Varför en köpare frågar efter detta
Organisationer som själva omfattas av säkerhetskraven är skyldiga att bedöma riskerna hos sina leverantörer. Ett mjukvaruföretag som utvecklar för en sådan organisation får därmed frågor som inte härrör från eget ansvar utan från försörjningskedjan. En informationssäkerhetspolicy blir då ofta det första dokumentet som efterfrågas, eftersom det i ett dokument visar hur systematiskt säkerheten har åtgärdats. Om det saknas måste du förklara det i en checklista fråga för fråga, vilket tar mer tid och verkar mindre övertygande än ett befintligt dokument.
Huruvida din organisation själv omfattas av säkerhetskraven, omfattas genom försörjningskedjan, eller ingetdera, är inte möjligt att se på ett ögonblick. i några få frågor ser du var din organisation står ger där en första indikation, med förklaring till varför.
Hur denna policy förhåller sig till de enskilda åtgärderna
En informationssäkerhetspolicy står inte för sig själv. Den beskriver i huvuddrag hur du hanterar säkerhet, medan de enskilda åtgärderna — åtkomstkontroll, säkerhetskopior, incidentdokumentation, leverantörsbedömning — är den konkreta genomförandet av den. Om du skriver policyn utan att ha de underliggande åtgärderna i ordning har du ett dokument som inte motsvarar praktiken. Omvänt är det också svårt: enskilda åtgärder utan övergripande policy verkar fragmenterad för den som frågar. överblicken över alla ämnen per situation visar hur dessa delar hänger ihop.
Vad som ofta saknas i praktiken
I många första versioner av en sådan policy saknas en tydlig ägare för varje del: vem ansvarar för att hålla åtkomstpolicyn uppdaterad, vem ansvarar för patchpolicyn. En fastställd utvärderingsdatum saknas också ofta, vilket gör att en policy från två år sedan fortfarande presenteras som aktuell trots att utvecklingsvägen har förändrats. Och en tredje punkt som ofta saknas: en explicit koppling mellan policyn och de bevis som visar att den också tillämpas i praktiken, såsom loggar över åtkomsträttigheter eller en översikt över genomförda uppdateringar.
Bedöma er egen situation
Exakt vilka komponenter som förväntas beror på er organisations roll i leverantörskedjan och på vad en specifik köpare kräver. Den här artikeln beskriver den vanliga strukturen, inte en obligatorisk mall, och lagstiftningen själv föreskriver ingen fast indelning. För att bedöma er specifika situation är en jurist eller den behörig tillsynsmyndighet den lämpligaste parten; de vanliga frågorna om sådana här dokument ger en kompletterande översikt över vad som ofta frågas.
Vill ni se hur en sådan policy, tillsammans med de underliggande åtgärderna och bevisen, upprätthålls i en löpande dossier istället för som ett separat dokument? hur secria.eu bygger upp och upprätthåller informationen visar det. Börja i stället med den kostnadsfria NIS2-kontrollen, eller bläddra genom kunskapsbanken för att se vilka ämnen som är relevanta för er organisation.