Hvad hører til i informationssikkerhedspolitikken for softwareudvikling?
En informationssikkerhedspolitik for softwareudvikling er det dokument, hvori du fastlægger, hvordan din organisation håndterer sikring af information, systemer og kode. For en softwarevirksomhed handler det om to ting samtidigt: sikkerheden af det, du bygger, og sikkerheden af det miljø, hvori du bygger det. Begge hører til i samme dokument, selvom de indholdsmæssigt er forskellige emner.
Konkret betyder det, at politikken normalt omhandler omfanget (hvilke systemer og hvilke udviklingsprojekter der omfattes), ansvaret (hvem beslutter, hvem administrerer, hvem kontrollerer), den måde, hvorpå adgang til kildekode og udviklingmiljøer reguleres, hvordan sårbarheder i egen kode opdages og løses, hvordan der håndteres med testmiljøer i forhold til produktionsmiljøer, hvordan hændelser registreres, og hvordan selve politikken vedligeholdes og gennemses. En spørgeskemaopstilling fra en køber spørger ofte efter præcis denne slags dokumenter som bevis, ikke efter en teknisk beskrivelse af din kildekode.
To lag: produktet og udviklingsledelsen
Det første lag handler om produktet: den software, du leverer til kunder. Det omfatter en beskrivelse af, hvordan du håndterer sårbarheder, der opdages efter levering, hvordan opdateringer og rettelser når ud til kunder, og hvem i organisationen der er ansvarlig for at følge op på meddelelser om sikkerhedsproblemer i produktet.
Det andet lag handler om udviklingsledelsen: det miljø, hvori dit team arbejder. Det er versionskontrolmiljøet, build- og testpipelinen og adskillelsen mellem test- og produktionsmiljøer. Her handler det om spørgsmål som hvem der må få adgang til kildekoden, hvordan ændringer kontrolleres før de går i live, og hvordan adgang tilbagekaldes, når nogen forlader teamet. Begge lag kan være i samme dokument, men beskrives ofte separat, fordi risiciene og ejerkredsen er forskellig.
Hvorfor en køber spørger herom
Organisationer, der selv omfattes af pligten til risikostyring, er forpligtet til at vurdere risiciene hos deres leverandører. En softwarevirksomhed, der udvikler for sådan en organisation, får derved spørgsmål, der ikke stammer fra egen forpligtelse, men fra kæden. En informationssikkerhedspolitik er da ofte det første dokument, der anmodes om, fordi det i ét dokument viser, hvor struktureret sikringen er blevet håndteret. Hvis det mangler, skal du forklare det i et spørgeskema spørgsmål for spørgsmål, hvilket tager mere tid og virker mindre overbevisende end et eksisterende dokument.
Hvorvidt din organisation selv er omfattet af pligten til risikostyring, omfattes af kæden, eller ingen af delene, kan ikke ses på et blik. i et par spørgsmål se hvor jeres organisation står giver der en første indikation af, med forklaring hvorfor.
Hvordan denne politik forholder sig til de enkelte foranstaltninger
En informationssikkerhedspolitik står ikke alene. Den beskriver i hovedtræk, hvordan du håndterer sikring, mens de enkelte foranstaltninger — adgangsstyring, sikkerhedskopier, hændelsesregistrering, vurdering af leverandører — er den konkrete gennemførelse af den. Hvis man skriver politikken uden at have de underliggende foranstaltninger i orden, har man et dokument, der ikke stemmer overens med praksis. Omvendt er det også vanskeligt: enkelte foranstaltninger uden overordnet politik virker fragmenteret over for den, der spørger. oversigten over alle emner pr. situation viser, hvordan disse komponenter hænger sammen med hinanden.
Hvad der i praksis ofte mangler
I mange første udgaver af sådan en politik mangler en klar ansvarlig for hver del: hvem er ansvarlig for at holde adgangspolitikken opdateret, hvem for patchpolitikken. Desuden mangler der ofte en fast evalueringsdato, hvilket betyder, at en politik fra for to år siden stadig præsenteres som aktuel, selv om udviklingspipelinen er ændret i mellemtiden. Og et tredje punkt, der ofte mangler: en eksplicit kobling mellem politikken og de bevismaterialer, der viser, at den også bliver gennemført, såsom logfiler over adgangsrettigheder eller et overblik over implementerede patches.
Vurder din egen situation
Præcis hvilke elementer der forventes, afhænger af din organisations rolle i værdikæden og af, hvad en specifik kunde spørger om. Denne artikel beskriver det sædvanlige opbygning, ikke en obligatorisk skabelon, og selve lovteksten foreskriver ingen fast inddeling. For en vurdering af din specifikke situation er en juridisk rådgiver eller den kompetente tilsynsmyndighed den rette part; ofte stillede spørgsmål om denne type dokumenter giver et supplerende overblik over, hvad der ofte bliver spurgt om.
Vil du se, hvordan sådan en politik, sammen med de underliggende foranstaltninger og bevismaterialer, vedligeholdes i en løbende mappe i stedet for som et løst dokument? hvordan secria.eu bygger og vedligeholder informationen viser det. Begynd ellers med den gratis NIS2-check, eller gennemse videnbanken for at se, hvilke emner der er relevante for din organisation.