Mi az IBIR? A biztonsági munka összekapcsolása az üzleti döntésekkel

A biztonsági munka tűnhet mozgalmasnak anélkül, hogy összehangolt lenne. A fejlesztés javítja a rendszereket, a HR kezeli a kilépéseket, a beszerzés átvizsgálja a beszállítókat, a vezetés pedig jóváhagyja a kivételeket. Az információbiztonsági irányítási rendszer (IBIR) ezeket a tevékenységeket közös célokhoz és egy egyértelmű döntési folyamathoz kapcsolja.

Egy vezérigazgató számára nem az a fontos kérdés, hogy van-e elég biztonsági dokumentuma a vállalatnak. Hanem az, hogy a vezetés el tudja-e magyarázni, mit kell védeni, mely kockázatok számítanak, ki a felelős, és miért elfogadható a védelem jelenlegi szintje. Az IBIR megismételhetővé teszi ezeket a válaszokat, ahogy az üzlet változik.

Mit irányít valójában az IBIR

Az információbiztonsági irányítási rendszer az információbiztonsági kockázatok kezelésére szolgáló szervezeti rendszer. Magában foglalja a felelősségeket, a szabályzatokat, a folyamatokat, az erőforrásokat, a kontrollokat és az értékelést. Szoftver támogathatja, de a szoftver nem maga a rendszer. Egy dokumentumtár leírhatja, de a dokumentumok önmagukban nem bizonyítják, hogy működik.

Célja az információk három tulajdonságának védelme:

• Bizalmasság: az információ csak a jogosult személyek és rendszerek számára érhető el.
• Sértetlenség: az információ pontos, teljes marad, és védett a nem megfelelő módosítással szemben.
• Rendelkezésre állás: a jogosult felhasználók szükség esetén hozzáférnek az információkhoz és használhatják a támogató szolgáltatásokat.

Ezek a tulajdonságok üzleti szempontokká alakulnak. A kiszivárgott ügyféladatok alááshatják a bizalmat és jogi kötelezettségeket keletkeztethetnek. A hibás fizetési utasítások pénzügyi veszteséget okozhatnak. Egy elérhetetlen ügyfélszolgálati platform megakadályozhatja, hogy a vállalat teljesítse ügyfelei felé vállalt kötelezettségeit.

Az ISO/IEC 27001 elismert követelményeket határoz meg egy meghatározott alkalmazási területű IBIR számára. A 4–10. fejezet a szervezet környezetével, a vezetéssel, a tervezéssel, a támogatással, a működtetéssel, a teljesítményértékeléssel és a fejlesztéssel foglalkozik. Egy szervezet a tanúsítás megszerzése előtt is kialakíthat és működtethet IBIR-t.

Az irányítási rendszer teremti meg a kapcsolatot az egyes védőintézkedések és az üzleti döntések között. Egy biztonsági mentés kontroll. Annak eldöntése, hogy mit kell helyreállíthatóvá tenni, a helyreállítási képesség finanszírozása, tesztelése és a sikertelen tesztek nyomán tett intézkedések viszont az irányítási rendszer munkájához tartoznak.

Miért van szüksége a vezetésnek ezekre a kapcsolatokra

Biztonsági döntések már most is születnek a vállalat egészében, akár IBIR-nek nevezik ezt, akár nem. Valaki kiválaszt egy SaaS-szolgáltatót, jóváhagy egy kiemelt jogosultságú hozzáférést, elfogad egy késleltetett javítást, vagy vállal egy ügyfél által megkövetelt helyreállítási követelményt. Közös folyamat nélkül ezek a döntések eltérő feltételezésekre épülhetnek, és senki sem lesz elszámoltatható az együttes hatásukért.

Az IBIR alapot ad a vezetésnek a korlátozott erőforrások rangsorolásához. Abban is segít a csapatoknak, hogy az ügyfelek kérdéseire karbantartott nyilvántartások alapján válaszoljanak, ahelyett hogy minden értékesítési átvizsgálás során újra összeraknák a gyakorlataikat. Ez nem garantálja a sikeres beszerzési eredményt; de jobban alátámaszthatóvá teszi a mögöttes állításokat.

A kapcsolatoknak gyakorlati kérdésekre kell választ adniuk:

Ezek a kapcsolatok különösen a növekedés idején számítanak. Azok az informális gyakorlatok, amelyek működnek, amíg mindenki ismer mindenkit, megbízhatatlanná válnak, amikor új csapatok, telephelyek, beszállítók és ügyfélkötelezettségek jelennek meg.

Határozzon meg az üzletet tükröző alkalmazási területet

Az üzleti környezetből induljon ki, ne egy kontrollistából. Azonosítsa a szervezet által nyújtott szolgáltatásokat, az általuk használt információkat, az érdekelt feleket és azok követelményeit, valamint a biztonságot befolyásoló belső és külső körülményeket.

Az alkalmazási terület határozza meg az IBIR határát. Azonosítania kell a lefedett tevékenységeket, a szervezeti egységeket, adott esetben a helyszíneket, a technológiát és az üzlet más részeivel való kapcsolódási pontokat. Egy hasznos első alkalmazási terület lefedhet egy ügyfeleknek szóló terméket és annak szolgáltatási működését, ahelyett hogy a vállalat minden tevékenységére kiterjedne.

Egy szűkített alkalmazási terület azonban nem hagyhatja figyelmen kívül a függőségeket. Ha a HR indítja el a kilépési folyamatot a termékhez hozzáféréssel rendelkező munkavállalóknál, ez a kapcsolódási pont számít. Ha egy felhőszolgáltató üzemelteti a szolgáltatást, a kiszervezés nem szünteti meg a függőséget. Ha az ügyfélszolgálat ügyféladatokat exportál, az exportálási folyamat az elemzés része.

Írjon alkalmazásiterület-nyilatkozatot, majd tegye próbára három kérdéssel:

• Megértené-e egy ügyfél, mi tartozik bele és mi nem?
• Bevontuk-e a lefedett szolgáltatás védelméhez szükséges függőségeket?
• Képesek-e a megnevezett gazdák e határon belül fenntartani a rendszert?

A kis lépésekkel való kezdés gyakorlati ajánlás, nem engedély egy félrevezető határ kialakítására. Egy világos, elszámoltatható gazdákkal rendelkező alkalmazási terület erősebb, mint egy nagy nyilvántartás, amelyet senki sem frissít. Tudatosan bővítsen, amikor új szolgáltatások vagy függőségek ezt indokolják.

Döntéseket osszon ki, ne csak feladatokat

Az ISO 27001 szerinti IBIR esetében a felső vezetésnek kell irányt mutatnia és támogatást nyújtania. Ha a koordinációt egy biztonsági vezetőre delegálják, azzal a vezetés elszámoltathatósága a prioritásokért, az erőforrásokért és az elfogadható kockázatért nem száll át.

Válassza szét azokat a felelősségeket, amelyeket gyakran egyetlen személy munkakörébe sűrítenek:

Egy kis vállalat több felelősséget is egy személyre bízhat. Ekkor is azonosítania kell, melyik szerepet tölti be az adott személy, és hol van szükség független kontrollra, különösen a belső auditnál.

Határozzon meg eszkalációs küszöböket. Egy csapatvezető jóváhagyhat egy rövid ideig érvényes operatív kivételt az egyeztetett keretek között; egy jelentős ügyfélkötelezettségeket veszélyeztető kockázat felső vezetői jóváhagyást igényelhet. Rögzítse az indoklást, a feltételeket, a lejárati dátumot és a felülvizsgálatot kiváltó eseményt. Az „a vezetés elfogadta” nem elég, ha senki sem tudja azonosítani a döntéshozót vagy az elfogadott kitettséget.

Alakítsa a kockázatértékelést rangsorolási folyamattá

A kockázatértékelésnek valószerű forgatókönyveket kell leírnia, nem csupán eszközöket megnevezni vagy gyengeségeket felsorolni. Az „ügyféladatbázis” egy eszköz. „Egy kompromittált adminisztrátori fiók lehetővé teszi az ügyféladatok tömeges kinyerését” pedig egy kockázati forgatókönyv okkal és következménnyel.

Alakítson ki dokumentált értékelési módszert és kockázatelfogadási kritériumokat. Az ISO 27001 nem ír elő egy konkrét pontozási képletet. Gyakorlati megközelítésként a valószínűségi és hatáskategóriákat olyan nyelven határozza meg, amelyet a döntéshozók megértenek, beleértve az operatív zavarokat, a pénzügyi veszteséget, a szerződéses következményeket és adott esetben az egyéneknek okozott kárt.

Minden lényeges forgatókönyvnél rögzítse:

• Az érintett szolgáltatást, információkat és függőségeket.
• A fenyegetést vagy eseményt és a releváns sérülékenységeket.
• A meglévő kontrollokat és azok ismert korlátait.
• A valószínűséget, a hatást és az ebből adódó prioritást.
• A kockázatgazdát és a javasolt kockázatkezelést.

A kockázatkezelés jelentheti a kitettség csökkentését kontrollokkal, egy tevékenység elkerülését, a kockázat egyes elemeinek megosztását szerződésekkel vagy biztosítással, vagy a kockázat elfogadását a jóváhagyott kritériumokon belül. A biztosítás nem állítja helyre az elveszett információkat, és egy beszállítói szerződés sem szünteti meg a szervezet felelősségét.

Különböztesse meg a jelenlegi kockázatot a kockázatkezelés utáni maradványkockázattól. Ne csökkentse a besorolást csak azért, mert egy feladatot beütemeztek. A megvalósítás és a működés megfelelő bizonyítéka után értékelje újra. A kockázatkezelési tervet és a maradványkockázat elfogadását a meghatározott döntési jogkörrel hagyassa jóvá.

Az operatív kockázatnyilvántartásnak döntési nyilvántartásnak kell maradnia: mi változott, miért választottak egy adott kockázatkezelést, és mikor kell az értékelést felülvizsgálni.

Válassza ki a kontrollokat, és magyarázza el az alkalmazhatóságukat

A kontrollok a kockázat módosítására használt intézkedések. Ide tartoznak a műszaki védőintézkedések, például a többtényezős hitelesítés, a szervezeti folyamatok, például a beszállítói felülvizsgálatok, a személyi intézkedések, például a képzés, valamint az eszközök és helyiségek fizikai védelme.

Az ISO/IEC 27001:2022 A melléklete 93 referenciakontrollt tartalmaz: 37 szervezeti, 8 személyi, 14 fizikai és 34 technológiai kontrollt. A kiválasztás kockázatalapú; egy szervezet nem valósít meg automatikusan minden kontrollt. Az ISO/IEC 27002 megvalósítási útmutatást ad, nem különálló IBIR-tanúsítási követelményt.

Az ISO 27001 esetében határozza meg a kockázatkezeléshez szükséges kontrollokat, és vesse össze őket az A melléklettel, hogy ellenőrizze, nem maradt-e ki szükséges kontroll. Kontrollokra jogi vagy szerződéses követelmények miatt is szükség lehet, és ezek nem korlátozódnak az A mellékletre.

Az alkalmazhatósági nyilatkozat rögzíti a szükséges kontrollokat, bevonásuk indoklását, a megvalósítás állapotát és az A melléklet kontrolljainak kizárására vonatkozó indoklást. Elkülönül a kockázatkezelési tervtől: az egyik az alkalmazandó kontrollkészletet magyarázza el, a másik a kockázatok kezeléséhez szükséges intézkedéseket. A referenciastruktúrát az A melléklet kontrolljairól szóló útmutató mutatja be.

Minden kiválasztott kontrollhoz határozzon meg gazdát, a kívánt eredményt, a működés módját és azt, milyen bizonyíték igazolja a hatékonyságot. A „hozzáférés-szabályozás megvalósítva” kevésbé hasznos, mint egy egyértelmű folyamat, amely kiterjed a jóváhagyásra, a jogosultságok kiosztására, a felülvizsgálatra és a visszavonásra.

A szabályzatoknak olyan szabályokat kell rögzíteniük, amelyeket az emberek követni tudnak. Az eljárásoknak a végrehajtást kell elmagyarázniuk. Egyik sem ígérhet olyan felülvizsgálatokat vagy műszaki korlátozásokat, amelyeket a szervezet ténylegesen nem tud fenntartani.

Építse be a bizonyítékokat a szokásos működésbe

A bizonyítékoknak a munka elvégzéséből kell keletkezniük, nem pedig abból, hogy egy audit előtt újra összerakják a történetet. Egy hozzáférési felülvizsgálat eredménye lehet egy dátummal ellátott felhasználólista, az ellenőr döntései, a visszavonási jegyek és annak megerősítése, hogy a változtatások megtörténtek. Egy helyreállítási gyakorlat eredménye lehet a tesztkörülmények leírása, az eredmények, a megfigyelt korlátok és a nyomon követési teendők.

Egy képernyőkép egy beállítást egy adott pillanatban mutathat. Nem feltétlenül bizonyítja, hogy a beállítás minden releváns rendszerre kiterjed, vagy hogy egy teljes időszakon át hatékony maradt. Az ellenőröknek meg kell vizsgálniuk a hatókört, a dátumot, a forrást, a teljességet, és azt, hogy a bizonyíték ténylegesen milyen következtetést támaszt alá.

Egy gyakorlati IBIR-bizonyítékkészlet a következőket tartalmazza:

Nem minden sorhoz kell külön dokumentum. Egy kis szervezet összevonhatja a nyilvántartásokat, amennyiben az áttekinthetőség és a nyomon követhetőség megmarad. Magukat a bizonyítékokat is védje: a felhasználói exportok, az incidensnyilvántartások és a képernyőképek érzékeny információkat tartalmazhatnak, ezért megfelelő hozzáférési és megőrzési szabályokra van szükségük.

Kidolgozott példa: ügyfélszolgálati platform

Vegyünk egy szemléltető, 30 fős szoftvervállalatot, amely SaaS-alapú ügyfélszolgálati platformot használ. Tegyük fel, hogy a platform ügyfélneveket, elérhetőségeket, jegyelőzményeket és alkalmanként diagnosztikai mellékleteket tárol. A munkatársak egyéni fiókokat használnak, az alkalmazást külső szolgáltató üzemelteti, és egyes jegyeket hibaelhárítás céljából exportálnak. Ezek a példához tartozó feltételezések, nem előírt vállalati modell.

Az IBIR alkalmazási területe kiterjed az ügyfélszolgálati működésre és annak függőségeire: a munkatársak identitására, a SaaS-beszállítóra, a végponti hozzáférésre, az exportokra, a megőrzésre és a helyreállítási megoldásokra. A szolgáltatás gazdája az ügyfélszolgálati vezető; a hozzáférés-szabályozást az IT működteti; a beszállítói felülvizsgálatot a beszerzés koordinálja; a delegált hatáskört meghaladó kockázatokat a vezetés hagyja jóvá.

Az első értékelés három forgatókönyvet azonosít:

Tegyük fel, hogy egy fiókegyeztetés során kiderül, hogy egy volt munkavállalónak még mindig van hozzáférése. Az azonnali teendő a hozzáférés megszüntetése és annak vizsgálata, hogy a fiókot nem használták-e nem megfelelő módon. Az irányítási rendszer szintjén az a teendő, hogy kiderítsék, miért nem sikerült a visszavonás. Lehet, hogy a HR értesítette az IT-t, de az ügyfélszolgálati alkalmazás hiányzott a kilépési ellenőrzőlistáról.

A korrekciós intézkedés ezután frissíti az alkalmazásleltárt, felveszi az ügyfélszolgálati platformot a kilépési folyamatba, kijelöli a megerősítésért felelős személyt, és ellenőrzi a későbbi kilépéseket. Ha csak a visszavonási jegyet zárnák le, azzal az azonnali helyzetet kezelnék, de az okát nem szüntetnék meg.

Most tegyük fel, hogy a SaaS-beszállító megváltoztatja a további adatfeldolgozóinak listáját. A beszállító gazdája a változást a szerződéses, biztonsági és releváns adatvédelmi követelmények alapján vizsgálja felül. Rögzíti, hogy érinti-e az adatkezelést, a függőségeket vagy az elfogadott kockázatot, és hogy szükség van-e szakértői felülvizsgálatra. A változásnak van gazdája és felülvizsgálati útja, ahelyett hogy olvasatlanul maradna egy közös postafiókban.

A vezetés megkapja a nyitott döntéseket: finanszírozzon-e erősebb tartalékmegoldást, csökkentse-e a mellékletekben gyűjtött információk körét, vagy fogadjon el egy meghatározott fennmaradó kitettséget. Így kapcsolja össze az IBIR az operatív megállapításokat az üzleti döntésekkel.

Olyan ütemezést működtessen, amely észleli a változást

A felülvizsgálatokat a kockázat, a változások gyakorisága és a kötelezettségek szerint ütemezze. A kezdeti megvalósítás alatti heti hiányosság-felülvizsgálat és az időszakos vezetőségi átvizsgálás hasznos gyakorlati választás lehet, de nem az ISO 27001 által előírt egységes időközök. A szabvány tervezett időközönként végzett belső auditokat és vezetőségi átvizsgálásokat követel meg.

Egészítse ki ezt eseményekhez kötött kiváltó pontokkal: incidensek, jelentős kiadások, felvásárlások, beszállítói változások, új jogi kötelezettségek, jelentős ügyfélkötelezettségek és auditmegállapítások. Egy naptár önmagában nem veszi észre az ütemezett megbeszélések között bekövetkező fontos változásokat.

A monitorozás azt vizsgálja, hogy a kontrollok és a célkitűzések a szándéknak megfelelően teljesítenek-e. A belső audit azt értékeli, hogy az IBIR megfelel-e a követelményeknek, és hatékonyan valósították-e meg és tartják-e fenn. A vezetőségi átvizsgálás a rendszer alkalmasságát, megfelelőségét és hatékonyságát vizsgálja, és döntéseket hoz a változásokról és az erőforrásokról. Ezek a tevékenységek egymást informálják, de nem cserélhetők fel.

A vezetésnek döntésre kész információkat kell kapnia: lényeges kockázatokat, késedelmes kockázatkezeléseket, ismétlődő hibákat, auditmegállapításokat, változó követelményeket és erőforráskorlátokat. Ha csak az elvégzett feladatokat számolják az eredmények vizsgálata nélkül, az elfedheti a gyenge teljesítményt. Az IBIR-mutatókról szóló útmutató hasznos mérőszámokat mutat be.

Az incidenskezelés is ebbe a ciklusba tartozik. Határozza meg a bejelentési utakat, az értékelési szempontokat, a reagálási felelősségeket, a kommunikációs jogköröket és a helyreállítási megoldásokat. Gyakorlatokkal tesztelje a kapcsolattartási utakat és a döntéshozatalt. Értékelje az alkalmazandó bejelentési kötelezettségeket, ahelyett hogy feltételezné, hogy egyetlen határidő minden incidensre vonatkozik.

Egy incidens vagy nemmegfelelőség után kezelje az azonnali problémát, vizsgálja ki az okokat, hajtsa végre a korrekciós intézkedést, és értékelje annak hatékonyságát. Az ismétlődő megállapítások okot adnak a folyamat kialakításának vagy az erőforrásoknak az újragondolására, nem pedig arra, hogy egyszerűen megismételjék ugyanazt az emlékeztetőt.

Különítse el az IBIR-t, a tanúsítást és a jogi kötelezettségeket

Az IBIR az a rendszer, amelyet a szervezet működtet. Az ISO 27001 egy szabvány, amely alapján ez a rendszer értékelhető. A tanúsítványt független tanúsító szervezet állítja ki, nem az ISO vagy a Secani, és a megadott alkalmazási területre vonatkozik.

A tanúsítás hasznos bizonyossági mechanizmus lehet, ha az ügyfelek vagy más érdekelt felek megkövetelik. Nem bizonyítja azonban, hogy a vállalat minden tevékenysége le van fedve, hogy minden kontroll mindig működik, vagy hogy incidensek nem fordulhatnak elő. Ellenőrizze az alkalmazási területet és az állapotot, ahelyett hogy egy tanúsítványt az egész vállalatra kiterjedő biztonsági garanciának tekintene.

A jogi alkalmazhatóság külön elemzést igényel. A GDPR 32. cikke a releváns kockázatokon alapuló megfelelő technikai és szervezési biztonsági intézkedéseket követel meg. A NIS2 a nemzeti átültetés révén foglalkozik a vezetői felügyelettel, a kockázatkezelési intézkedésekkel és az incidensek bejelentésével az érintett szervezetek esetében.

Egy IBIR rendszerezheti az ilyen kötelezettségeket alátámasztó bizonyítékokat és felelősségeket, de a tanúsítás nem igazolja a GDPR-nak vagy a NIS2-nek való megfelelést. Az sem pontos, hogy egy IBIR soha nem lehet jogszabályi követelmény: az alkalmazandó nemzeti vagy ágazatspecifikus szabályokat ellenőrizni kell.

Kerülje el a három előre látható megvalósítási hibát

Sablonok változtatás nélküli átvétele. A sablonok vázlatot adhatnak, de a gazdáknak minden vállalást a tényleges gyakorlattal kell összevetniük. Egy szabályzat, amely olyan felülvizsgálatokat ír elő, amelyeket senki sem végez el, kezeletlen hiányosságot teremt.

Olyan határ meghúzása, amelyet senki sem tud fenntartani. Egy ambiciózus leltár nem hasznos, ha a felelősségek és a függőségek nem egyértelműek. Kezdjen egy megalapozott szolgáltatási határral, majd egy kifejezett terv alapján bővítsen.

A tanúsítás célvonalként kezelése. A rendszernek a személyi változások, a beszállítói változások, az incidensek és az új termékek során is működnie kell. Ne csak a kezdeti dokumentációra, hanem a működtetésre, a felülvizsgálatra és a fejlesztésre is tervezzen költségvetést.

Kapcsolódó figyelmeztetés az át nem vizsgált automatizálás. Az automatikusan gyűjtött nyilvántartások és a mesterséges intelligencia által generált összefoglalók támogathatják a munkát, de továbbra is embereknek kell meghatározniuk a relevanciát, értékelniük a hiányosságokat és jóváhagyniuk a következtetéseket.

Tegye konkréttá az első vezetői döntést

Válasszon ki egy reprezentatív szolgáltatást, és kérje meg a gazdáját, hogy hozzon alkalmazásiterület-nyilatkozatot, függőségi térképet, kezdeti kockázati forgatókönyveket, a jelenlegi kontrollokat és a nyitott döntéseket. Egyezzenek meg abban, ki fogadhat el kockázatot, milyen erőforrások állnak rendelkezésre, és mikor vizsgálják felül az előrehaladást. Ez kezelhető kiindulópontot teremt anélkül, hogy úgy tennének, mintha az egész szervezet már le lenne fedve.

A Secani munkaterület-modellje azzal támogatja ezt a munkafolyamatot, hogy modellezi a szolgáltatásokat és a támogató célobjektumokat, összekapcsolja a bizonyítékokat a követelményekkel, a kontrollokkal és a döntésekkel, valamint kijelöli a gazdákat és a felülvizsgálati felelősségeket. A csapatok a hiányzó bizonyítékokból vagy a tisztázatlan felelősségekből feladatokat hozhatnak létre. A mesterséges intelligenciával támogatott javaslatok emberi átvizsgálásra váró vázlatok maradnak, a források és a jóváhagyások nyomon követhetők.

A következő vezetői megbeszélésnek ezért konkrétnak kell lennie: melyik szolgáltatást védjük elsőként, milyen kitettség igényel most döntést, és milyen bizonyíték mutatja majd meg, hogy a döntés működött?