Mis on ISMS? Siduge turvatöö äriotsustega

Turvatöö võib näida tegus, ilma et see oleks koordineeritud. Arendus paikab süsteeme, personaliosakond tegeleb lahkumistega, hanked vaatavad tarnijaid üle ja juhtkond kiidab erandeid heaks. Infoturbe juhtimissüsteem seob need tegevused ühiste eesmärkide ja selgesõnalise otsustusprotsessiga.

Tegevjuhi jaoks ei ole oluline küsimus see, kas ettevõttel on piisavalt turvadokumente. Oluline on see, kas juhtkond suudab selgitada, mida tuleb kaitsta, millised riskid on olulised, kes vastutab ja miks praegune kaitsetase on vastuvõetav. ISMS muudab need vastused korratavaks ka siis, kui ettevõte muutub.

Mida ISMS tegelikult juhib

Infoturbe juhtimissüsteem on organisatsiooniline süsteem infoturberiskide juhtimiseks. See hõlmab kohustusi, poliitikaid, protsesse, ressursse, meetmeid ja hindamist. Tarkvara võib seda toetada, kuid tarkvara ei ole süsteem. Dokumendikogu võib seda kirjeldada, kuid dokumendid üksi ei tõenda, et see toimib.

Selle eesmärk on kaitsta teabe kolme omadust:

• Konfidentsiaalsus: teave on kättesaadav ainult volitatud inimestele ja süsteemidele.
• Terviklus: teave püsib täpse ja täielikuna ning on kaitstud sobimatu muutmise eest.
• Käideldavus: volitatud kasutajad saavad teavet ja toetavaid teenuseid vajaduse korral kasutada.

Need omadused muutuvad ärilisteks muredeks. Paljastatud kliendikirjed võivad õõnestada usaldust ja tekitada õiguslikke kohustusi. Valed maksejuhised võivad põhjustada rahalist kahju. Kättesaamatu tugiteenuse platvorm võib takistada ettevõttel klientidele antud lubaduste täitmist.

ISO/IEC 27001 annab tunnustatud nõuded kindlaksmääratud ulatusega ISMS-ile. Punktid 4–10 käsitlevad organisatsiooni konteksti, eestvedamist, planeerimist, tuge, toimimist, toimivuse hindamist ja parendamist. Organisatsioon võib ISMS-i välja arendada ja seda käitada enne sertifitseerimise taotlemist.

Juhtimissüsteem loob seose üksikute kaitsemeetmete ja äriotsuste vahel. Varukoopia on meede. Otsustamine, mis peab olema taastatav, taastamisvõimekuse rahastamine, selle testimine ja ebaõnnestunud testide põhjal tegutsemine on juhtimissüsteemi töö.

Miks juhtkond neid seoseid vajab

Turvaotsuseid tehakse kogu ettevõttes juba praegu, olenemata sellest, kas seda nimetatakse ISMS-iks või mitte. Keegi valib SaaS-teenuse osutaja, kiidab heaks privilegeeritud juurdepääsu, aktsepteerib hilinenud paiga või lubab kliendile taastamisnõude täitmist. Ilma ühise protsessita võivad need otsused põhineda erinevatel eeldustel, nii et keegi ei vastuta nende koondmõju eest.

ISMS annab juhtkonnale aluse piiratud ressursside prioriseerimiseks. Samuti aitab see meeskondadel vastata klientide küsimustele ajakohastatud kirjete põhjal, selle asemel et iga müügiülevaatuse ajal oma tavasid uuesti rekonstrueerida. See ei taga edukat hanketulemust; see muudab aluseks olevad väited paremini tõendatavaks.

Seosed peaksid vastama praktilistele küsimustele:

Need seosed on eriti olulised kasvu ajal. Mitteametlikud tavad, mis toimivad siis, kui kõik üksteist tunnevad, muutuvad ebausaldusväärseks, kui lisanduvad uued meeskonnad, asukohad, tarnijad ja klientidele antud lubadused.

Määratlege ulatus, mis kajastab äri

Alustage ärikontekstist, mitte meetmete loetelust. Tehke kindlaks teenused, mida organisatsioon osutab, nende kasutatav teave, huvitatud osapooled ja nende nõuded ning turvalisust mõjutavad sisemised ja välised tingimused.

Ulatus määratleb ISMS-i piiri. See peaks tuvastama hõlmatud tegevused, organisatsiooniüksused, asjakohasel juhul asukohad, tehnoloogia ja liidesed ettevõtte teiste osadega. Kasulik esimene ulatus võib hõlmata kliendile suunatud toodet ja selle tarnimisega seotud tegevust, mitte kõiki ettevõtte tegevusi.

Fokusseeritud ulatus ei saa siiski sõltuvusi eirata. Kui personaliosakond algatab tootele juurdepääsu omavate töötajate lahkumisprotsessi, on see liides oluline. Kui teenust majutab pilveteenuse osutaja, ei kaota allhange sõltuvust. Kui tugiteenus ekspordib kliendiandmeid, kuulub eksportimisprotsess analüüsi.

Kirjutage ulatuse kirjeldus ja seejärel vaidlustage see kolme küsimusega:

• Kas klient saaks aru, mis on hõlmatud ja mis mitte?
• Kas oleme kaasanud sõltuvused, mis on vajalikud hõlmatud teenuse kaitsmiseks?
• Kas nimelised omanikud suudavad süsteemi selles piiris hooldada?

Väikeselt alustamine on praktiline soovitus, mitte luba luua eksitav piir. Selge ulatus vastutavate omanikega on tugevam kui suur register, mida keegi ei uuenda. Laiendage teadlikult, kui uued teenused või sõltuvused seda õigustavad.

Määrake otsused, mitte ainult ülesanded

Kõrgem juhtkond peab ISO 27001 ISMS-ile andma suuna ja toe. Koordineerimise delegeerimine turvajuhile ei kanna üle juhtkonna vastutust prioriteetide, ressursside ja vastuvõetava riski eest.

Eraldage kohustused, mis sageli koondatakse ühe inimese töö alla:

Väike ettevõte võib määrata ühele inimesele mitu kohustust. Siiski peaks olema selge, millist rolli see inimene täidab ja kus on vaja sõltumatut vaidlustamist, eriti siseauditi puhul.

Määratlege eskaleerimise lävendid. Meeskonnajuht võib kokkulepitud piirides heaks kiita lühiajalise tegevusliku erandi; risk, mis ohustab olulisi klientidele antud lubadusi, võib nõuda juhtkonna heakskiitu. Salvestage põhjendus, tingimused, aegumiskuupäev ja ülevaatuse käivitaja. „Juhtkonna poolt aktsepteeritud“ ei ole piisav, kui keegi ei suuda tuvastada otsustajat ega aktsepteeritud riski.

Muutke riskihindamine prioriseerimisprotsessiks

Riskihindamine peaks kirjeldama usutavaid stsenaariume, mitte ainult nimetama varasid või loetlema nõrkusi. „Kliendiandmebaas“ on vara. „Kompromiteeritud administraatorikonto võimaldab kliendikirjete hulgilist väljavõtmist“ on riskistsenaarium, millel on põhjus ja tagajärg.

Kehtestage dokumenteeritud hindamismeetod ja riski aktsepteerimise kriteeriumid. ISO 27001 ei nõua üht konkreetset hindamisvalemit. Praktilise lähenemisviisina määratlege tõenäosuse ja mõju kategooriad keeles, millest teie otsustajad aru saavad, sealhulgas tegevuse häirimine, rahaline kahju, lepingulised tagajärjed ja asjakohasel juhul kahju üksikisikutele.

Iga olulise stsenaariumi kohta salvestage:

• Mõjutatud teenus, teave ja sõltuvused.
• Oht või sündmus ja asjakohased haavatavused.
• Olemasolevad meetmed ja nende teadaolevad piirangud.
• Tõenäosus, mõju ja sellest tulenev prioriteet.
• Riski omanik ja kavandatud käsitlus.

Käsitlus võib hõlmata riski vähendamist meetmete abil, tegevusest loobumist, riski osade jagamist lepingute või kindlustuse kaudu või riski aktsepteerimist heakskiidetud kriteeriumide piires. Kindlustus ei taasta kaotatud teavet ja tarnijaleping ei kõrvalda organisatsiooni kohustusi.

Eristage praegust riski jääkriskist pärast käsitlust. Ärge alandage hinnangut pelgalt seetõttu, et ülesanne on planeeritud. Hinnake uuesti pärast rakendamist ja sobivaid tõendeid toimimise kohta. Hankige käsitluskavale ja jääkriski aktsepteerimisele heakskiit määratletud volituste kaudu.

Tegevusriskide register peaks jääma otsuste kirjeks: mis muutus, miks käsitlus valiti ja millal hindamine vajab ülevaatust.

Valige meetmed ja selgitage nende kohaldatavust

Meetmed on vahendid, mida kasutatakse riski muutmiseks. Need hõlmavad tehnilisi kaitsemeetmeid, nagu mitmikautentimine, korralduslikke protsesse, nagu tarnijate ülevaatused, inimestega seotud meetmeid, nagu koolitus, ning seadmete ja ruumide füüsilist kaitset.

ISO/IEC 27001:2022 A-lisa sisaldab 93 viitemeedet: 37 korralduslikku, 8 inimestega seotud, 14 füüsilist ja 34 tehnoloogilist. Valik on riskipõhine; organisatsioon ei rakenda automaatselt kõiki meetmeid. ISO/IEC 27002 annab rakendusjuhised, mitte eraldi ISMS-i sertifitseerimisnõude.

ISO 27001 puhul tehke kindlaks riskikäsitluseks vajalikud meetmed ja võrrelge neid A-lisaga, et kontrollida, kas vajalikke meetmeid pole välja jäetud. Meetmed võivad olla vajalikud ka õiguslike või lepinguliste nõuete tõttu ega pea piirduma A-lisaga.

Kohaldatavusavaldus salvestab vajalikud meetmed, nende kaasamise põhjenduse, rakendamise oleku ja A-lisa meetmete väljaarvamise põhjenduse. See erineb riskikäsitluskavast: üks selgitab kohaldatavat meetmete kogumit, teine riskide käsitlemiseks vajalikke tegevusi. Selle viitestruktuuri kohta vaadake A-lisa meetmete juhendit.

Määratlege iga valitud meetme jaoks omanik, kavandatud tulemus, toimimisviis ja tõendid, mis näitavad tõhusust. „Juurdepääsukontroll rakendatud“ on vähem kasulik kui selgesõnaline protsess, mis hõlmab heakskiitmist, loomist, ülevaatust ja eemaldamist.

Poliitikad peaksid kehtestama reeglid, mida inimesed saavad järgida. Protseduurid peaksid selgitama täitmist. Kumbki ei tohiks lubada ülevaatusi ega tehnilisi piiranguid, mida organisatsioon tegelikult ei suuda säilitada.

Ehitage tõendid tavapärasesse tegevusse

Tõendid peaksid tekkima töö tegemisest, mitte loo taasloomisest enne auditit. Juurdepääsu ülevaatus võib anda dateeritud kasutajate loetelu, ülevaatajate otsused, eemaldamispiletid ja kinnituse, et muudatused tehti. Taastamisõppus võib anda testitingimused, tulemused, täheldatud piirangud ja järelmeetmed.

Ekraanipilt võib näidata seadet ühel hetkel. See ei tõenda tingimata, et seade hõlmab kõiki asjakohaseid süsteeme või püsis tõhusana kogu perioodi vältel. Ülevaatajad peaksid uurima ulatust, kuupäeva, allikat, täielikkust ja seda, millist järeldust tõend tegelikult toetab.

Praktiline ISMS-i tõendite kogum sisaldab:

Iga rida ei vaja eraldi dokumenti. Väike organisatsioon võib kirjeid kombineerida, kui selgus ja jälgitavus säilivad. Kaitske ka tõendeid endid: kasutajate ekspordid, intsidendikirjed ja ekraanipildid võivad sisaldada tundlikku teavet ning nende jaoks peaks olema asjakohane juurdepääsu- ja säilitamiskord.

Näide: klienditoe platvorm

Vaatleme illustreerivat 30 töötajaga tarkvaraettevõtet, mis kasutab SaaS-klienditoe platvormi. Oletame, et platvorm hoiab klientide nimesid, kontaktandmeid, piletite ajalugu ja aeg-ajalt diagnostilisi manuseid. Töötajad kasutavad isiklikke kontosid, rakendust majutab väline teenuseosutaja ja mõned piletid eksporditakse tõrkeotsinguks. Need on näite eeldused, mitte ette kirjutatud ettevõttemudel.

ISMS-i ulatus hõlmab klienditoe tegevust ja selle sõltuvusi: töötajate identiteet, SaaS-tarnija, lõppseadmete juurdepääs, ekspordid, säilitamine ja taastamiskorraldus. Teenuse omanik on klienditoe juht; IT käitab juurdepääsukontrolli; hanked koordineerivad tarnija ülevaatust; juhtkond kiidab heaks delegeeritud volitusi ületavad riskid.

Esialgne hindamine tuvastab kolm stsenaariumi:

Oletame, et kontode võrdlemisel selgub, et endisel töötajal on endiselt juurdepääs. Kohene tegevus on see eemaldada ja hinnata, kas kontot kasutati sobimatult. Juhtimissüsteemi tegevus on kindlaks teha, miks eemaldamine ebaõnnestus. Võib-olla teavitas personaliosakond IT-d, kuid klienditoe rakendus puudus lahkumise kontroll-loendist.

Parandusmeede ajakohastab seejärel rakenduste inventuuri, lisab klienditoe platvormi lahkumisprotsessi, määrab kinnitamise vastutuse ja kontrollib järgnevaid lahkumisi. Ainult eemaldamispileti sulgemine käsitleks vahetut olukorda, ilma et selle põhjus oleks kõrvaldatud.

Oletame nüüd, et SaaS-tarnija muudab oma alamtöötlejate loetelu. Tarnija omanik vaatab muudatuse üle lepinguliste, turva- ja asjakohaste privaatsusnõuete alusel. Ta salvestab, kas see mõjutab andmete käitlemist, sõltuvusi või aktsepteeritud riski ja kas on vaja eksperdi ülevaatust. Muudatusel on omanik ja ülevaatuse tee, selle asemel et jääda jagatud postkasti lugemata.

Juhtkond saab lahendamata otsused: kas rahastada tugevamat varulahendust, vähendada manustes kogutavat teavet või aktsepteerida määratletud allesjäävat riski. Nii seob ISMS tegevuslikud leiud ärivalikutega.

Hoidke rütmi, mis suudab muutusi tuvastada

Planeerige ülevaatused vastavalt riskile, muudatuste sagedusele ja kohustustele. Iganädalane puudujääkide ülevaatus esialgse juurutamise ajal ja perioodiline juhtkonna ülevaatus võivad olla kasulikud praktilised valikud, kuid need ei ole ISO 27001 kehtestatud üldised intervallid. Standard nõuab siseauditeid ja juhtkonna ülevaatusi plaanitud intervallidega.

Lisage sündmuspõhised käivitajad: intsidendid, suured väljalasked, omandamised, tarnijamuudatused, uued õiguslikud kohustused, olulised klientidele antud lubadused ja auditileiud. Ainult kalender jätab plaaniliste koosolekute vahel olulised muudatused märkamata.

Seire küsib, kas meetmed ja eesmärgid toimivad ettenähtud viisil. Siseaudit hindab, kas ISMS vastab nõuetele ning kas see on tõhusalt rakendatud ja hooldatud. Juhtkonna ülevaatus käsitleb süsteemi sobivust, piisavust ja tõhusust ning teeb otsuseid muudatuste ja ressursside kohta. Need tegevused toetavad üksteist, kuid ei ole omavahel asendatavad.

Juhtkond peaks saama otsustamiseks valmis teavet: olulised riskid, tähtaja ületanud käsitlused, korduvad ebaõnnestumised, auditileiud, muutuvad nõuded ja ressursipiirangud. Lõpetatud ülesannete loendamine tulemusi uurimata võib nõrka toimivust varjata. ISMS-i mõõdikute juhend uurib kasulikke mõõdikuid.

Ka intsidentide haldus kuulub sellesse tsüklisse. Määratlege teatamisteed, hindamiskriteeriumid, reageerimiskohustused, suhtlusvolitused ja taastamiskorraldus. Testige kontaktiteid ja otsuste tegemist õppuste kaudu. Hinnake kohaldatavaid teavitamiskohustusi, selle asemel et eeldada, et üks tähtaeg hõlmab iga intsidenti.

Pärast intsidenti või mittevastavust lahendage kohene probleem, uurige põhjuseid, rakendage parandusmeede ja hinnake selle tõhusust. Korduvad leiud on põhjus protsessi ülesehitus või ressursid uuesti läbi mõelda, mitte lihtsalt sama meeldetuletust korrata.

Eraldage ISMS, sertifitseerimine ja õiguslikud kohustused

ISMS on süsteem, mida organisatsioon käitab. ISO 27001 on standard, mille alusel seda süsteemi saab hinnata. Sertifikaadi väljastab sõltumatu sertifitseerimisasutus, mitte ISO ega Secani, ja see kehtib kirjeldatud ulatuse kohta.

Sertifitseerimine võib olla kasulik kindlustandmise mehhanism, kui kliendid või teised sidusrühmad seda nõuavad. See ei tõenda, et kõik ettevõtte tegevused on hõlmatud, et iga meede toimib alati või et intsidente ei saa juhtuda. Kontrollige ulatust ja olekut, selle asemel et käsitleda sertifikaati kogu ettevõtet hõlmava turvagarantiina.

Õiguslik kohaldatavus nõuab eraldi analüüsi. GDPR-i artikkel 32 nõuab asjakohaste riskide alusel asjakohaseid tehnilisi ja korralduslikke turvameetmeid. NIS2 käsitleb hõlmatud üksuste puhul juhtkonna järelevalvet, riskijuhtimismeetmeid ja intsidentidest teatamist riigisisese rakendamise kaudu.

ISMS võib korraldada selliseid kohustusi toetavaid tõendeid ja vastutust, kuid sertifitseerimine ei tõenda vastavust GDPR-ile ega NIS2-le. Samuti ei ole täpne öelda, et ISMS ei saa kunagi olla seadusega nõutud: kohaldatavaid riiklikke või sektoripõhiseid reegleid tuleb kontrollida.

Vältige kolme ettearvatavat juurutamisviga

Mallide muutmata kasutuselevõtt. Mallid võivad anda struktuuri, kuid omanikud peavad iga kohustuse tegeliku praktika põhjal valideerima. Poliitika, mis nõuab ülevaatusi, mida keegi ei tee, loob juhtimata puudujäägi.

Piiri tõmbamine, mida keegi ei suuda hooldada. Ambitsioonikas inventuur ei ole kasulik, kui omand ja sõltuvused on ebaselged. Alustage põhjendatud teenusepiirist ja laiendage seejärel selgesõnalise kava alusel.

Sertifitseerimise käsitlemine finišijoonena. Süsteem peab jätkuma ka töötajate vahetumise, tarnijamuudatuste, intsidentide ja uute toodete korral. Eelarvestage toimimist, ülevaatust ja parendamist, mitte ainult esialgset dokumenteerimist.

Seotud hoiatus puudutab üle vaatamata automatiseerimist. Automaatselt kogutud kirjed ja tehisintellekti loodud kokkuvõtted võivad tööd toetada, kuid inimesed peavad siiski kindlaks tegema asjakohasuse, hindama puudujääke ja kiitma järeldused heaks.

Muutke esimene juhtkonna otsus konkreetseks

Valige üks esinduslik teenus ja paluge selle omanikul tuua ulatuse kirjeldus, sõltuvuste kaart, esialgsed riskistsenaariumid, praegused meetmed ja lahendamata otsused. Leppige kokku, kes saab riski aktsepteerida, millised ressursid on saadaval ja millal edenemine üle vaadatakse. See loob hallatava lähtepunkti, ilma et teeseldaks, et kogu organisatsioon on juba hõlmatud.

Secani tööruumi mudel toetab seda töövoogu teenuste ja toetavate sihtobjektide modelleerimise, tõendite nõuete, meetmete ja otsustega sidumise ning omanike ja ülevaatuskohustuste määramise kaudu. Meeskonnad saavad muuta puuduvad tõendid või ebaselge omandi ülesanneteks. Tehisintellekti abil tehtud soovitused jäävad mustanditeks, mille inimesed üle vaatavad, ning allikad ja heakskiidud jäävad jälgitavaks.

Järgmine vestlus juhtkonnaga peaks seega olema konkreetne: millist teenust me esimesena kaitseme, milline risk nõuab praegu otsust ja millised tõendid näitavad, et otsus toimis?