
Varnostno delo je lahko videti zaposleno, ne da bi bilo usklajeno. Razvoj nameša popravke na sisteme, kadrovska služba skrbi za odhode, nabava pregleduje dobavitelje, vodstvo pa odobrava izjeme. Sistem upravljanja informacijske varnosti (ISMS) te dejavnosti poveže s skupnimi cilji in izrecnim postopkom odločanja.
Za izvršnega direktorja pomembno vprašanje ni, ali ima podjetje dovolj varnostnih dokumentov. Pomembno je, ali zna vodstvo pojasniti, kaj je treba zaščititi, katera tveganja so pomembna, kdo je odgovoren in zakaj je trenutna raven zaščite sprejemljiva. ISMS te odgovore naredi ponovljive tudi, ko se poslovanje spreminja.
Sistem upravljanja informacijske varnosti je organizacijski sistem za upravljanje tveganj za informacijsko varnost. Vključuje odgovornosti, politike, procese, vire, kontrole in vrednotenje. Programska oprema ga lahko podpira, vendar programska oprema ni sistem. Knjižnica dokumentov ga lahko opisuje, vendar dokumenti sami ne dokazujejo, da deluje.
Njegov namen je zaščititi tri lastnosti informacij:
Te lastnosti se prevedejo v poslovne skrbi. Razkriti zapisi strank lahko spodkopljejo zaupanje in ustvarijo pravne obveznosti. Napačna plačilna navodila lahko povzročijo finančno izgubo. Nedosegljiva platforma za podporo lahko podjetju prepreči izpolnjevanje zavez do strank.
ISO/IEC 27001 določa priznane zahteve za ISMS z opredeljenim obsegom. Točke 4–10 obravnavajo kontekst organizacije, voditeljstvo, planiranje, podporo, delovanje, vrednotenje izvedbe in izboljševanje. Organizacija lahko ISMS razvije in upravlja, še preden se odloči za certifikacijo.
Sistem upravljanja zagotavlja povezavo med posameznimi zaščitnimi ukrepi in poslovnimi odločitvami. Varnostna kopija je kontrola. Odločanje o tem, kaj mora biti mogoče obnoviti, financiranje zmogljivosti obnove, njeno testiranje in ukrepanje ob neuspešnih testih pa je delo sistema upravljanja.
Varnostne odločitve se v podjetju že sprejemajo, ne glede na to, ali to imenuje ISMS. Nekdo izbere ponudnika SaaS, odobri privilegiran dostop, sprejme zamujen popravek ali se stranki zaveže k zahtevi glede obnove. Brez skupnega procesa lahko te odločitve temeljijo na različnih predpostavkah, za njihov skupni učinek pa ni odgovoren nihče.
ISMS vodstvu daje podlago za določanje prednosti pri omejenih virih. Ekipam pomaga tudi odgovarjati na vprašanja strank na podlagi vzdrževanih zapisov, namesto da bi pri vsakem prodajnem pregledu znova rekonstruirale svoje prakse. To ne zagotavlja uspešnega izida nabave; naredi pa osnovne trditve bolje utemeljene.
Povezave naj odgovarjajo na praktična vprašanja:
| Povezava | Vprašanje, na katero odgovarja |
|---|---|
| Storitev z informacijami in odvisnostmi | Kaj mora ostati zaščiteno, da storitev deluje? |
| Storitev s tveganjem | Kaj bi jo lahko prekinilo ali kompromitiralo? |
| Tveganje s kontrolo | Kako zmanjšujemo to izpostavljenost? |
| Kontrola z odgovorno osebo | Kdo vzdržuje izvedbo? |
| Kontrola z dokazilom | Kaj kaže, da deluje? |
| Ugotovitev z odločitvijo | Kaj se spremeni naslednje in kdo to odobri? |
Te povezave so še posebej pomembne med rastjo. Neformalne prakse, ki delujejo, ko se vsi poznajo, postanejo nezanesljive, ko pridejo nove ekipe, lokacije, dobavitelji in zaveze strankam.
Začnite s poslovnim kontekstom, ne s seznamom kontrol. Opredelite storitve, ki jih organizacija zagotavlja, informacije, ki jih uporabljajo, zainteresirane strani in njihove zahteve ter notranje in zunanje okoliščine, ki vplivajo na varnost.
Obseg določa mejo ISMS. Opredeliti mora zajete dejavnosti, organizacijske enote, po potrebi lokacije, tehnologijo in vmesnike z drugimi deli podjetja. Uporaben prvi obseg lahko zajema izdelek za stranke in njegovo izvajanje, ne pa vseh dejavnosti podjetja.
Osredotočen obseg pa ne more prezreti odvisnosti. Če kadrovska služba začne postopek odhoda za zaposlene z dostopom do izdelka, je ta vmesnik pomemben. Če storitev gosti ponudnik storitev v oblaku, zunanje izvajanje odvisnosti ne odpravi. Če podpora izvaža informacije o strankah, proces izvoza sodi v analizo.
Napišite izjavo o obsegu in jo nato preizkusite s tremi vprašanji:
Začeti z majhnim obsegom je praktično priporočilo, ne pa dovoljenje za zavajajočo mejo. Jasen obseg z odgovornimi osebami je močnejši od velikega registra, ki ga nihče ne posodablja. Obseg širite premišljeno, ko to upravičujejo nove storitve ali odvisnosti.
Najvišje vodstvo mora ISMS po ISO 27001 usmerjati in podpirati. Prenos usklajevanja na vodjo varnosti ne prenese odgovornosti vodstva za prednostne naloge, vire in sprejemljivo tveganje.
Ločite odgovornosti, ki se pogosto združijo v delo ene osebe:
| Odgovornost | Tipična odločitev ali dejavnost |
|---|---|
| Izvršni pokrovitelj | Odobri prednostne naloge in razrešuje spore glede virov |
| Koordinator ISMS | Vzdržuje proces in odpira nerazrešena vprašanja |
| Skrbnik storitve ali tveganja | Oceni poslovni vpliv in v okviru pooblastil odobri obravnavo |
| Skrbnik kontrole | Izvaja in vzdržuje zaščitni ukrep |
| Pregledovalec | Preverja dokazila in izpodbija sklepe |
Majhno podjetje lahko več odgovornosti dodeli eni osebi. Še vedno pa mora opredeliti, v kateri vlogi ta oseba deluje in kje je potrebno neodvisno preverjanje, zlasti pri notranji presoji.
Določite pragove eskalacije. Vodja ekipe lahko v dogovorjenih mejah odobri kratkotrajno operativno izjemo; tveganje, ki ogroža pomembne zaveze strankam, pa lahko zahteva odobritev vodstva. Zapišite utemeljitev, pogoje, datum poteka in sprožilec pregleda. „Vodstvo je sprejelo“ ne zadošča, če nihče ne zna opredeliti, kdo je odločil ali katera izpostavljenost je bila sprejeta.
Ocena tveganj naj opisuje verjetne scenarije, ne le poimenuje sredstev ali našteje slabosti. „Podatkovna baza strank“ je sredstvo. „Kompromitiran administratorski račun omogoči množično pridobitev zapisov strank“ je scenarij tveganja z vzrokom in posledico.
Vzpostavite dokumentirano metodo ocenjevanja in merila za sprejemljivost tveganj. ISO 27001 ne zahteva določene formule za točkovanje. Kot praktičen pristop opredelite kategorije verjetnosti in vpliva v jeziku, ki ga razumejo odločevalci, vključno z motnjami poslovanja, finančno izgubo, pogodbenimi posledicami in, kjer je relevantno, škodo za posameznike.
Za vsak pomemben scenarij zapišite:
Obravnava lahko vključuje zmanjšanje izpostavljenosti s kontrolami, opustitev dejavnosti, delitev vidikov tveganja s pogodbami ali zavarovanjem ali sprejetje tveganja v okviru odobrenih meril. Zavarovanje ne obnovi izgubljenih informacij, pogodba z dobaviteljem pa organizaciji ne odvzame njenih odgovornosti.
Ločite trenutno tveganje od preostalega tveganja po obravnavi. Ocene ne znižajte samo zato, ker je naloga načrtovana. Ponovno jo ocenite po izvedbi in ustreznih dokazilih o delovanju. Načrt obravnave in sprejetje preostalega tveganja odobrite prek določenega pooblastila.
Operativni register tveganj naj ostane zapis o odločitvah: kaj se je spremenilo, zakaj je bila izbrana obravnava in kdaj je treba oceno pregledati.
Kontrole so ukrepi, s katerimi spreminjamo tveganje. Vključujejo tehnične zaščitne ukrepe, kot je večfaktorska avtentikacija, organizacijske procese, kot so pregledi dobaviteljev, ukrepe, povezane z ljudmi, kot je usposabljanje, in fizično zaščito naprav in prostorov.
Dodatek A standarda ISO/IEC 27001:2022 vsebuje 93 referenčnih kontrol: 37 organizacijskih, 8 kadrovskih, 14 fizičnih in 34 tehnoloških. Izbira temelji na tveganjih; organizacija ne uvede samodejno vsake kontrole. ISO/IEC 27002 daje smernice za izvedbo, ne pa ločene certifikacijske zahteve za ISMS.
Pri ISO 27001 določite kontrole, potrebne za obravnavo tveganj, in jih primerjajte z Dodatkom A, da preverite, da niste izpustili nobene potrebne kontrole. Kontrole so lahko potrebne tudi zaradi zakonskih ali pogodbenih zahtev in ni nujno, da so omejene na Dodatek A.
Izjava o uporabnosti beleži potrebne kontrole, utemeljitev njihove vključitve, stanje izvedbe in utemeljitev izključitve kontrol iz Dodatka A. Razlikuje se od načrta obravnave tveganj: prva pojasnjuje uporabni nabor kontrol, drugi pa ukrepe, potrebne za obravnavo tveganj. Za to referenčno strukturo glejte vodnik po kontrolah iz Dodatka A.
Za vsako izbrano kontrolo opredelite odgovorno osebo, nameravani izid, način delovanja in dokazila, ki bodo pokazala učinkovitost. „Kontrola dostopa je izvedena“ je manj uporabno kot izrecen proces, ki zajema odobritev, dodelitev, pregled in odvzem.
Politike naj določajo pravila, ki jim ljudje lahko sledijo. Postopki naj pojasnjujejo izvedbo. Nobeni ne smejo obljubljati pregledov ali tehničnih omejitev, ki jih organizacija dejansko ne more vzdrževati.
Dokazila naj nastajajo z opravljanjem dela, ne z obnavljanjem zgodbe pred presojo. Pregled dostopov lahko ustvari datiran seznam uporabnikov, odločitve pregledovalcev, zahtevke za odvzem in potrditev, da so se spremembe zgodile. Vaja obnove lahko ustvari pogoje testa, rezultate, opažene omejitve in nadaljnje ukrepe.
Posnetek zaslona lahko pokaže nastavitev v enem trenutku. Ne dokazuje nujno, da nastavitev zajema vse relevantne sisteme ali da je bila učinkovita skozi celotno obdobje. Pregledovalci naj preučijo obseg, datum, vir, popolnost in sklep, ki ga dokazilo dejansko podpira.
Praktičen nabor dokazil ISMS vključuje:
| Zapis | Kaj naj izkazuje |
|---|---|
| Obseg in kontekst | Mejo, odvisnosti in relevantne zahteve |
| Politika in cilji | Odobreno usmeritev in merljive nameravane izide |
| Zapisi o oceni in obravnavi tveganj | Prednostne naloge, odločitve, odgovornosti in napredek |
| Izjava o uporabnosti | Potrebne kontrole in utemeljitev uporabnosti |
| Operativni zapisi | Izvedene kontrole in obravnavane izjeme |
| Zapisi o kompetencah | Ljudje lahko opravljajo dodeljene odgovornosti |
| Rezultati spremljanja in presoj | Ocenjeno delovanje in ugotovljene slabosti |
| Vodstveni pregled in korektivni ukrepi | Odločitve vodstva in preverjene izboljšave |
Vsaka vrstica ne potrebuje ločenega dokumenta. Majhna organizacija lahko zapise združi, če ostaneta jasnost in sledljivost. Zaščitite tudi sama dokazila: izvozi uporabnikov, zapisi o incidentih in posnetki zaslona lahko vsebujejo občutljive informacije in potrebujejo ustrezno ureditev dostopa in hrambe.
Vzemimo ponazoritveno programsko podjetje s 30 zaposlenimi, ki uporablja platformo SaaS za podporo. Predpostavimo, da platforma hrani imena strank, kontaktne podatke, zgodovino zahtevkov in občasne diagnostične priloge. Zaposleni uporabljajo osebne račune, aplikacijo gosti zunanji ponudnik, nekatere zahtevke pa izvozijo za odpravljanje težav. To so predpostavke primera, ne predpisan model podjetja.
Obseg ISMS zajema delovanje podpore strankam in njegove odvisnosti: identitete zaposlenih, dobavitelja SaaS, dostop s končnih naprav, izvoze, hrambo in ureditev obnove. Vodja podpore je skrbnik storitve; IT upravlja kontrole dostopa; nabava usklajuje pregled dobavitelja; vodstvo odobri tveganja, ki presegajo prenesena pooblastila.
Začetna ocena opredeli tri scenarije:
| Scenarij | Obravnava in dokazila |
|---|---|
| Zaposleni, ki odhaja, obdrži dostop | Obvestila o odhodu povežite z odvzemom; hranite potrditev odvzema in uskladite aktivne račune |
| Diagnostični izvozi razkrijejo informacije o strankah | Omejite izvoze, določite odobreno shranjevanje in brisanje ter vzorčno preverjajte upoštevanje |
| Izpad dobavitelja onemogoči obravnavo zahtevkov | Preglejte ureditev obnove in preizkusite rezervni proces komunikacije |
Recimo, da usklajevanje računov pokaže, da ima nekdanji zaposleni še vedno dostop. Takojšnji ukrep je odvzem dostopa in ocena, ali je bil račun neustrezno uporabljen. Ukrep sistema upravljanja pa je ugotoviti, zakaj odvzem ni uspel. Morda je kadrovska služba obvestila IT, vendar aplikacije za podporo ni bilo na kontrolnem seznamu za odhode.
Korektivni ukrep nato posodobi popis aplikacij, platformo za podporo doda v proces odhoda, dodeli odgovornost za potrditev in preveri naslednje odhode. Zaprtje zahtevka za odvzem bi samo odpravilo takojšnje stanje, ne pa njegovega vzroka.
Recimo zdaj, da dobavitelj SaaS spremeni seznam podobdelovalcev. Skrbnik dobavitelja pregleda spremembo glede na pogodbene, varnostne in relevantne zahteve glede zasebnosti. Zapiše, ali vpliva na ravnanje s podatki, odvisnosti ali sprejeto tveganje in ali je potreben strokovni pregled. Sprememba ima odgovorno osebo in pot pregleda, namesto da bi ostala neprebrana v skupnem poštnem predalu.
Vodstvo prejme nerazrešene odločitve: ali financirati močnejšo rezervno rešitev, zmanjšati količino informacij, zbranih v prilogah, ali sprejeti opredeljeno preostalo izpostavljenost. Tako ISMS povezuje operativne ugotovitve s poslovnimi izbirami.
Preglede načrtujte glede na tveganje, pogostost sprememb in obveznosti. Tedenski pregled vrzeli med začetno uvedbo in periodični vodstveni pregled sta lahko uporabni praktični izbiri, nista pa splošna intervala, ki bi ju predpisoval ISO 27001. Standard zahteva notranje presoje in vodstvene preglede v načrtovanih presledkih.
Dodajte sprožilce na podlagi dogodkov: incidente, večje izdaje, prevzeme, spremembe dobaviteljev, nove pravne obveznosti, pomembne zaveze strankam in ugotovitve presoj. Sam koledar bo med načrtovanimi sestanki spregledal pomembne spremembe.
Spremljanje preverja, ali kontrole in cilji delujejo, kot je bilo predvideno. Notranja presoja oceni, ali je ISMS skladen z zahtevami ter učinkovito izveden in vzdrževan. Vodstveni pregled obravnava primernost, ustreznost in učinkovitost sistema ter sprejme odločitve o spremembah in virih. Te dejavnosti se med seboj dopolnjujejo, niso pa zamenljive.
Vodstvo naj prejme informacije, pripravljene za odločanje: pomembna tveganja, zamujene obravnave, ponavljajoče se napake, ugotovitve presoj, spreminjajoče se zahteve in omejitve virov. Štetje dokončanih nalog brez preučevanja izidov lahko prikrije slabo delovanje. Vodnik po metrikah ISMS obravnava uporabna merila.
V ta cikel sodi tudi upravljanje incidentov. Opredelite poti prijave, merila ocenjevanja, odgovornosti za odziv, pooblastila za komunikacijo in ureditev obnove. Kontaktne poti in odločanje preizkusite z vajami. Ocenite veljavne obveznosti obveščanja, namesto da bi domnevali, da en rok velja za vse incidente.
Po incidentu ali neskladnosti odpravite takojšnjo težavo, raziščite vzroke, izvedite korektivni ukrep in ocenite njegovo učinkovitost. Ponavljajoče se ugotovitve so razlog za ponoven premislek o zasnovi procesa ali virih, ne pa za ponavljanje istega opomnika.
ISMS je sistem, ki ga organizacija upravlja. ISO 27001 je standard, po katerem je ta sistem mogoče oceniti. Certifikat izda neodvisen certifikacijski organ, ne ISO ali Secani, in velja za navedeni obseg.
Certifikacija je lahko uporaben mehanizem zagotovila, kadar jo zahtevajo stranke ali druge zainteresirane strani. Ni pa dokaz, da je zajeta vsaka dejavnost podjetja, da vsaka kontrola vedno deluje ali da incidenti niso mogoči. Preverite obseg in status, namesto da bi certifikat obravnavali kot varnostno jamstvo za celotno podjetje.
Pravna uporabnost zahteva ločeno analizo. Člen 32 Splošne uredbe o varstvu podatkov (GDPR) zahteva ustrezne tehnične in organizacijske varnostne ukrepe na podlagi relevantnih tveganj. Direktiva NIS 2 prek nacionalnega prenosa za zajete subjekte obravnava nadzor vodstva, ukrepe za obvladovanje tveganj in poročanje o incidentih.
ISMS lahko organizira dokazila in odgovornosti, ki podpirajo takšne obveznosti, vendar certifikacija ne pomeni skladnosti z GDPR ali NIS2. Prav tako ni točno, da ISMS nikoli ne more biti zakonsko zahtevan: preveriti je treba veljavna nacionalna ali sektorska pravila.
Nespremenjeno prevzemanje predlog. Predloge lahko dajo okvir, vendar morajo odgovorne osebe vsako zavezo preveriti glede na dejansko prakso. Politika, ki zahteva preglede, ki jih nihče ne izvaja, ustvari neupravljano vrzel.
Meja, ki je nihče ne more vzdrževati. Ambiciozen popis ni uporaben, če odgovornosti in odvisnosti niso jasne. Začnite z zagovorljivo mejo storitve in jo nato širite po izrecnem načrtu.
Certifikacija kot ciljna črta. Sistem mora delovati naprej ob kadrovskih spremembah, spremembah dobaviteljev, incidentih in novih izdelkih. Proračun namenite delovanju, pregledom in izboljšavam, ne le začetni dokumentaciji.
Povezano opozorilo velja za nepregledano avtomatizacijo. Samodejno zbrani zapisi in povzetki, ki jih ustvari UI, lahko podprejo delo, vendar morajo ljudje še vedno določiti relevantnost, oceniti vrzeli in odobriti sklepe.
Izberite eno reprezentativno storitev in prosite njenega skrbnika, naj prinese izjavo o obsegu, zemljevid odvisnosti, začetne scenarije tveganj, trenutne kontrole in nerazrešene odločitve. Dogovorite se, kdo lahko sprejme tveganje, kateri viri so na voljo in kdaj se bo pregledal napredek. Tako nastane obvladljivo izhodišče, ne da bi se pretvarjali, da je celotna organizacija že zajeta.
Secanijev model delovnega prostora ta potek dela podpira z modeliranjem storitev in podpornih ciljnih objektov, povezovanjem dokazil z zahtevami, kontrolami in odločitvami ter dodeljevanjem odgovornosti za skrbništvo in preglede. Ekipe lahko manjkajoča dokazila ali nejasne odgovornosti spremenijo v naloge. Predlogi s pomočjo UI ostanejo osnutki za človeški pregled, viri in odobritve pa ostanejo sledljivi.
Naslednji pogovor vodstva naj bo zato konkreten: katero storitev bomo zaščitili najprej, katera izpostavljenost zahteva odločitev zdaj in katera dokazila bodo pokazala, da je odločitev delovala?
Secani povezuje obsege, dokazila, naloge in agente UI v enem skupnem delovnem prostoru.
Oblikujte verodostojen poslovni primer na podlagi zagotovil za stranke, manj usklajevanja, odpornosti in boljših odločitev, ne da bi obljubljali zajamčene donose.
Razjasnite odgovornosti za varnost in zasebnost, vključno z zunanjo podporo DPO, odločitvami ob incidentih in neodvisnim svetovanjem.
Politike pišite okoli jasnih pravil, odgovornih oseb, uporabnih postopkov, izjem in dokazil o delovanju.