Risikovurderingen er det dokument, ISO 27001 bygger alt andet på, og det, der oftest købes som en regnearksskabelon med en andens risici i. Punkt 6.1.2 kræver ikke en skabelon; det kræver en proces, der frembringer fem ting: risikokriterier, både for at acceptere risici og for at udføre vurderinger; en identifikation af informationssikkerhedsrisiciene med deres ejere; en analyse af de mulige konsekvenser og den realistiske sandsynlighed, som giver et niveau; en evaluering mod kriterierne med risiciene prioriteret til behandling; og resultater, der er konsistente, gyldige og sammenlignelige fra én vurdering til den næste. Punkt 6.1.3 fortsætter med behandlingen: mulighederne, de nødvendige foranstaltninger, sammenligningen med anneks A, så intet nødvendigt er udeladt, erklæringen om anvendelighed og risikobehandlingsplanen godkendt af risikoejerne med deres accept af restrisikoen. Denne artikel læser de to punkter for en softwarevirksomhed og beskriver den metode, den gratis side bruger til at skrive registret og planen, mod de 93 foranstaltninger, som pakken holder som data, og de startrisici, som produktet lægger ind den første dag.

En metode, som standarden overlader til jer

ISO 27001 kræver kriterier og en gentagelig proces; den kræver ikke en bestemt skala, et varmekort eller en formel, og ISO/IEC 27005 giver vejledning snarere end regler. StandardOS' metode, angivet på det dokument, den skriver, er bevidst lille: sandsynlighed scoret fra 1 til 5, konsekvens scoret fra 1 til 5, niveauet som deres produkt fra 1 til 25, fire bånd (lav op til 4, middel op til 9, høj op til 15, kritisk derover) og en accepttærskel, som virksomheden vælger, som standard 4, så en risiko på eller under den beholdes med en navngivet ejer, og en risiko over den behandles. En fempunktsskala er nok til, at en auditor kan se, at to vurderinger af den samme risiko med et års mellemrum er sammenlignelige, og lille nok til, at et team på ti mennesker scorer tyve risici på en time. Det, der gør metoden forsvarlig, er ikke tallene, men konsistensen: de samme kriterier skrevet ned, den samme skala for hver risiko, den samme tærskel og den samme ejers underskrift på restrisikoen.

De startrisici, en softwarevirksomhed bærer

Identifikationstrinnet er der, hvor en skabelon vildleder mest, fordi en skabelons risici er en andens. En softwarevirksomheds risici er alligevel i vidt omfang kendt før den første workshop, og den gratis side begynder med det sæt, produktet lægger ind: phishing, der kompromitterer en loginoplysning, en mistet eller stjålet bærbar, utilgængelighed af en kritisk cloudtjeneste, en backup, der ikke kan gendannes, en fratrådt medarbejder, hvis adgang forbliver åben, udstyr bortskaffet med data på, et brud hos en leverandør eller cloudleverandør, en hændelse, der ikke opdages eller rapporteres i tide, et overset lovkrav eller kontraktkrav, sikkerhedsansvar uden ejer, mennesker, der kommer eller går uden sikkerhedsgrundlaget, information delt usikkert; og, hvor svarene siger det, en sårbarhed indført i virksomhedens egen software, leverandørskrevet kode, der når produktion uden gennemgang, en uautoriseret videregivelse af personoplysninger og uautoriseret fysisk adgang til lokaler. Fem svar vælger sættet: hvor mange mennesker, om virksomheden udvikler software, om den outsourcer udvikling, om den har lokaler, om den behandler kunders personoplysninger. Hver startrisiko kommer med en sandsynlighed, en konsekvens og de foranstaltninger i anneks A, der behandler den, alt redigerbart, og en risiko, der ikke gælder, fjernes; en risiko, sættet mangler, tilføjes med sine egne foranstaltninger.

Fra planen til erklæringen om anvendelighed

Punkt 6.1.3 gør registret til beslutninger. For hver risiko over tærsklen vælger virksomheden en mulighed: at ændre risikoen med foranstaltninger, at beholde den, at undgå aktiviteten eller at dele den med et forsikringsselskab eller en leverandør; for en ændret risiko navngiver den foranstaltningerne, og foreningen af de foranstaltninger er det, erklæringen om anvendelighed derefter fører som anvendeligt. Derfor skal de to dokumenter skrives i denne rækkefølge: en erklæring, der nævner A.8.13 som anvendelig uden en risiko for, at en backup ikke kan gendannes, har ingen begrundelse for rækken, og et register, der behandler den risiko uden A.8.13, har ingen foranstaltning til den. Den gratis side skriver begge retninger: planen opregner de foranstaltninger, hver behandlet risiko nævner, og dokumentets sidste afsnit opregner hver foranstaltning, planen nævner, hvilket er indgangen til erklæringen om anvendelighed, der skrives på den næste side, foranstaltning for foranstaltning.

Ejere, accept og intervallet

To ting, en auditor læser før scorerne, er ejerkolonnen og accepten. Hver risiko har en ejer (punkt 6.1.2 c) 2)), og hver restrisiko accepteres af sin ejer (6.1.3 f)), og derfor holder siden et ejerfelt pr. række og skriver "endnu ikke navngivet", hvor det er tomt, i stedet for at lade cellen stå blank. Accepttærsklen er en ledelsesbeslutning, og en virksomhed, der hæver den fra 4 til 9 for at gøre planen kortere, bør forvente spørgsmålet om, hvorfor en risiko med høj sandsynlighed og moderat konsekvens beholdes. Punkt 8.2 lader derefter vurderingen gentage med planlagte intervaller, eller når væsentlige ændringer foreslås eller indtræffer: en ny produktflade, en ny hostingregion, en ny underdatabehandler, et nyt team. Det link, siden skriver, bærer svarene, tærsklen og hver startrisikos scorer i adressen, så en version er et link, der kan gemmes og sammenlignes med det næste.

Hvad I skal gøre med det

Besvar de fem spørgsmål og læs startrisiciene mod jeres eget produkt, fjern dem, der ikke gælder, og tilføj dem, sættet mangler. Giv hver en score med fempunktsskalaen, sæt tærsklen, navngiv en ejer pr. række og vælg muligheden for hver risiko over linjen. Kopiér dokumentet, datér det, lad ejerne acceptere restrisiciene, og tag listen over foranstaltninger til sidst i det med ind i erklæringen om anvendelighed. StandardOS lægger de samme startrisici ind den første dag, holder scoren, ejeren og gennemgangsdatoen på hver og gør hver behandling til en position i erklæringen; omkostningssiden siger, hvor mange auditordage omfanget køber, og guiden til foranstaltningerne, hvad hver foranstaltning, planen nævner, kræver.