Saugumo pažeidimo anatomija: gamintojo ISO 27001 reagavimo į incidentus vadovas

Paryškinta ištrauka

Veiksmingas reagavimas į informacijos saugumo incidentus sumažina saugumo pažeidimų žalą ir užtikrina veiklos atsparumą. Šiame vadove pateikiama ISO 27001 pagrįsta nuosekli sistema, padedanti gamintojams pasirengti realioms kibernetinėms atakoms, į jas reaguoti ir po jų atsikurti, kartu įgyvendinant sudėtingus atitikties reikalavimus, tokius kaip NIS2 ir DORA.

Įvadas

Įspėjimas suveikia 2:17 val. Vidutinio dydžio automobilių dalių gamintojo centrinis serveris nebeatsako, o gamybos linijų monitoriuose rodomas išpirkos reikalaujančios programinės įrangos pranešimas. Kiekviena prastovos minutė kainuoja tūkstančius dėl prarastos produkcijos ir kelia riziką pažeisti griežtus tiekimo grandinės paslaugų lygio susitarimus (SLA). Tai ne pratybos. Vyriausiajam informacijos saugumo vadovui tai momentas, kai metų planavimas, politikos dokumentai ir mokymai patikrinami pačiomis griežčiausiomis sąlygomis.

Turėti reagavimo į incidentus planą serveryje yra viena; įgyvendinti jį esant dideliam spaudimui – visai kas kita. Gamintojams rizika yra ypač didelė. Kibernetinis incidentas ne tik sukelia duomenų kompromitavimą; jis stabdo gamybą, trikdo fizines tiekimo grandines ir gali kelti pavojų darbuotojų saugai.

Šis vadovas peržengia teorinių reagavimo planų ribas ir pateikia praktinį, realiomis sąlygomis taikomą planą, kaip sukurti ir valdyti veiksmingą reagavimo į incidentus programą. Išnagrinėsime reagavimo į saugumo pažeidimą anatomiją, remdamiesi tvirta ISO/IEC 27001 sistema, ir parodysime, kaip sukurti atsparią programą, kuri ne tik padeda atsigauti po atakos, bet ir atitinka auditorių bei reguliavimo institucijų lūkesčius.

Kas rizikuojama: saugumo pažeidimo gamyboje grandininis poveikis

Kai gamintojo sistemos kompromituojamos, poveikis gerokai peržengia vieno serverio ribas. Šiuolaikinės gamybos tarpusavio sąsajos – nuo atsargų valdymo iki robotizuotų surinkimo linijų – reiškia, kad skaitmeninis sutrikimas gali sukelti visišką veiklos sustabdymą. Pasekmės yra rimtos ir daugialypės.

Pirma, finansiniai nuostoliai prasideda iš karto ir būna dideli. Gamybos sustabdymas lemia praleistus terminus, klientų taikomas netesybas ir nedirbančios darbo jėgos sąnaudas. Sistemų atkūrimas, skaitmeninės kriminalistikos ekspertų pasitelkimas ir galimi išpirkos reikalavimai gali reikšmingai paveikti vidutinio dydžio įmonės finansus.

Antra, reputacijos žala gali būti ilgalaikė. B2B aplinkoje patikimumas yra esminis. Vienas reikšmingas incidentas gali sugriauti pagrindinių partnerių, priklausančių nuo pristatymo tiksliai laiku, pasitikėjimą. Kaip pabrėžiama mūsų vidinėse gairėse, pagrindinis incidentų valdymo tikslas yra „sumažinti incidentų poveikį verslui ir finansams bei kuo greičiau atkurti įprastą veiklą“ – gamyboje šis tikslas yra itin svarbus.

Galiausiai, reglamentavimo pasekmės gali būti griežtos. Įsigaliojant tokioms sistemoms kaip ES Tinklų ir informacinių sistemų saugumo direktyva (NIS2) ir Skaitmeninės veiklos atsparumo aktas (DORA), kritiniuose sektoriuose veikiančioms organizacijoms, įskaitant gamybą, taikomi griežti pranešimo apie incidentus reikalavimai ir didelių baudų už neatitiktį rizika. Prastai suvaldytas incidentas yra ne tik techninė nesėkmė; tai reikšminga teisinė ir atitikties rizika.

Kaip atrodo geras rezultatas: nuo chaoso prie kontrolės

Veiksminga reagavimo į incidentus programa krizę iš chaotiško, reaktyvaus skubėjimo paverčia struktūruotu ir kontroliuojamu procesu. Tikslas nėra vien išspręsti techninę problemą; būtina suvaldyti visą įvykį, kad būtų apsaugotas verslas. Tokia siektina būsena grindžiama ISO/IEC 27001 sistemoje apibrėžtais principais, ypač jos informacijos saugumo incidentų valdymo kontrolės priemonėmis.

Brandžią programą apibūdina keli pagrindiniai rezultatai:

• Vaidmenų aiškumas: visi žino, kam skambinti ir kokios yra jų atsakomybės. Reagavimo į incidentus komanda (IRT) apibrėžiama iš anksto, nurodant aiškią vadovavimo struktūrą ir paskirtus IT, teisės, komunikacijos ir vadovybės atstovus.
• Greitis ir tikslumas: organizacija gali greitai aptikti, analizuoti ir suvaldyti grėsmes, neleisdama joms plisti tinkle ir sustabdyti viso gamybos cecho.
• Informacija pagrįstas sprendimų priėmimas: vadovybė laiku gauna tikslią informaciją, leidžiančią priimti kritinius sprendimus dėl veiklos, komunikacijos su klientais ir pranešimo reguliavimo institucijoms.
• Nuolatinis tobulinimas: kiekvienas incidentas, didelis ar mažas, tampa mokymosi galimybe. Išsamus peržiūros po incidento procesas identifikuoja silpnąsias vietas ir grąžina patobulinimus į saugumo programą.

Pasiekti tokią pasirengimo būseną yra pagrindinis ISO/IEC 27002:2022 aprašytų kontrolės priemonių tikslas. Šios kontrolės priemonės padeda organizacijoms planuoti ir pasirengti (A.5.24), vertinti įvykius ir priimti sprendimus dėl jų (A.5.25), reaguoti į incidentus (A.5.26) ir iš jų mokytis (A.5.28). Esmė – sukurti atsparią sistemą, kuri numato nesėkmes ir yra struktūruota jas valdyti kontroliuojamai.

Praktinis kelias: nuoseklus reagavimo į incidentus vadovas

Tvirtam reagavimo į incidentus pajėgumui sukurti būtinas dokumentuotas ir sisteminis požiūris. Jo pagrindas – aiški ir praktiškai taikoma politika, apibrėžianti kiekvieną proceso etapą.

Mūsų P16S Informacijos saugumo incidentų valdymo planavimo ir pasirengimo politika – MVĮ pateikia išsamų modelį, suderintą su ISO 27001 gerąja praktika. Pereikime per pagrindinius žingsnius, naudodami šią politiką kaip gairę.

1 žingsnis: planavimas ir pasirengimas – atsparumo pagrindas

Reagavimo plano neįmanoma sukurti krizės viduryje. Pasirengimas yra būtinas. Šiame etape nustatoma struktūra, priemonės ir žinios, reikalingos ryžtingai veikti įvykus incidentui.

Pagrindinis elementas – Reagavimo į incidentus komandos (IRT) sukūrimas. Kaip nurodyta P16S Informacijos saugumo incidentų valdymo planavimo ir pasirengimo politikos – MVĮ 5.1 skyriuje, politikos tikslas yra „užtikrinti nuoseklų ir veiksmingą informacijos saugumo incidentų valdymą“. Šis nuoseklumas prasideda nuo aiškiai apibrėžtos komandos. Politika nustato, kad IRT turi apimti narius iš pagrindinių sričių:

• IT ir informacijos saugumo
• Teisės ir atitikties
• Žmogiškųjų išteklių
• Viešųjų ryšių / komunikacijos
• Aukščiausiosios vadovybės

Kiekvienas narys turi turėti aiškiai apibrėžtus vaidmenis ir atsakomybes. Kas turi įgaliojimus atjungti sistemas? Kas yra paskirtas atstovas, bendraujantis su klientais ar žiniasklaida? Į šiuos klausimus turi būti atsakyta, o atsakymai dokumentuoti gerokai iki incidento.

2 žingsnis: aptikimas ir pranešimas – jūsų ankstyvojo perspėjimo sistema

Kuo greičiau sužinote apie incidentą, tuo mažiau žalos jis gali padaryti. Tam reikia ir techninės stebėsenos, ir kultūros, kurioje darbuotojai jaučiasi įgalinti bei įpareigoti pranešti apie įtartiną veiklą.

P16S Informacijos saugumo incidentų valdymo planavimo ir pasirengimo politika – MVĮ šiuo klausimu yra aiški. 5.3 skyriuje „Pranešimas apie informacijos saugumo įvykius“ nustatyta:

„Visi darbuotojai, rangovai ir kitos susijusios šalys privalo kuo greičiau pranešti apie pastebėtus ar įtariamus informacijos saugumo įvykius ir silpnąsias vietas paskirtam kontaktiniam asmeniui.“

Šis „paskirtas kontaktinis asmuo“ yra kritiškai svarbus. Tai gali būti IT pagalbos tarnyba arba atskira saugumo pranešimų linija. Procesas turi būti paprastas ir aiškiai iškomunikuotas visam personalui. Darbuotojai turi būti mokomi, į ką atkreipti dėmesį, pavyzdžiui, į duomenų viliojimo el. laiškus, neįprastą sistemų elgseną ar fizinio saugumo pažeidimus.

3 žingsnis: vertinimas ir prioritetizavimas – grėsmės masto nustatymas

Kai apie įvykį pranešama, kitas žingsnis – greitai įvertinti jo pobūdį ir sunkumą. Ar tai klaidingai teigiamas atvejis, nedidelė problema, ar visapusiška krizė? Šis prioritetizavimo procesas nustato reikalingą reagavimo lygį.

Mūsų politika 5.2 skyriuje „Incidentų klasifikavimas“ nustato aiškią klasifikavimo schemą, pagal kurią incidentai skirstomi atsižvelgiant į jų poveikį konfidencialumui, vientisumui ir prieinamumui. Tipinė schema galėtų atrodyti taip:

• Žemas: viena darbo stotis užkrėsta įprasta kenkėjiška programine įranga, kuri lengvai suvaldoma.
• Vidutinis: nepasiekiamas padalinio serveris, darantis poveikį konkrečiai verslo funkcijai, bet nestabdantis visos gamybos.
• Aukštas: plačiai paplitusi išpirkos reikalaujančios programinės įrangos ataka, paveikianti kritines gamybos sistemas ir pagrindinius verslo duomenis.
• Kritinis: incidentas, susijęs su jautrios asmeninės informacijos ar intelektinės nuosavybės duomenų saugumo pažeidimu, turintis reikšmingų teisinių ir reputacinių padarinių.

Ši klasifikacija lemia skubumą, skiriamus išteklius ir eskalavimo vadovybei kelią, užtikrindama, kad reagavimas būtų proporcingas grėsmei.

4 žingsnis: suvaldymas, pašalinimas ir atkūrimas – gaisro gesinimas

Tai aktyvaus reagavimo etapas, kuriame IRT siekia suvaldyti incidentą ir atkurti įprastą veiklą.

• Suvaldymas: neatidėliotinas prioritetas – sustabdyti žalą. Tai gali apimti paveiktų tinklo segmentų izoliavimą, kompromituotų serverių atjungimą arba kenkėjiškų IP adresų blokavimą. Tikslas – neleisti incidentui plisti ir sukelti papildomos žalos.
• Pašalinimas: suvaldžius incidentą, turi būti pašalinta jo pagrindinė priežastis. Tai gali reikšti kenkėjiškos programinės įrangos pašalinimą, išnaudotų pažeidžiamumų ištaisymą ir kompromituotų naudotojų paskyrų išjungimą.
• Atkūrimas: paskutinis žingsnis – atkurti paveiktas sistemas ir duomenis. Tai apima atkūrimą iš švarių atsarginių kopijų, sistemų perrinkimą ir atidžią stebėseną, siekiant įsitikinti, kad grėsmė visiškai pašalinta prieš paslaugas vėl grąžinant į eksploataciją.

P16S Informacijos saugumo incidentų valdymo planavimo ir pasirengimo politikos – MVĮ 5.4 skyrius „Reagavimas į informacijos saugumo incidentus“ pateikia šių veiksmų sistemą, pabrėždamas, kad „reagavimo procedūros turi būti pradėtos informacijos saugumo įvykį klasifikavus kaip incidentą“.

5 žingsnis: veikla po incidento – įgytos patirties panaudojimas

Darbas nesibaigia sistemoms grįžus į veiklą. Po incidento vykdomas etapas, tikėtina, yra svarbiausias ilgalaikiam atsparumui stiprinti. Jis apima dvi pagrindines veiklas: įrodymų rinkimą ir įgytos patirties peržiūrą.

Politikoje pabrėžiama įrodymų rinkimo svarba. 5.5 skyriuje nurodoma, kad „turi būti nustatytos ir taikomos procedūros, skirtos su informacijos saugumo incidentais susijusių įrodymų surinkimui, gavimui ir išsaugojimui“. Tai būtina vidaus tyrimui, teisėsaugai ir galimiems teisiniams veiksmams.

Po to turi būti atlikta formali peržiūra po incidento. Šiame susitikime turėtų dalyvauti visi IRT nariai ir pagrindinės suinteresuotosios šalys, kad būtų aptarta:

• Kas įvyko ir kokia buvo įvykių laiko juosta?
• Kas reagavimo metu pavyko gerai?
• Su kokiais iššūkiais susidurta?
• Ką galima padaryti, kad panašus incidentas ateityje nepasikartotų?

Šios peržiūros rezultatas turėtų būti veiksmų planas su priskirtais atsakingais asmenimis ir įvykdymo terminais, skirtas politikoms, procedūroms ir techninėms kontrolės priemonėms tobulinti. Taip sukuriamas grįžtamojo ryšio ciklas, ilgainiui stiprinantis organizacijos saugumo būklę.

Sąsajų supratimas: kelių reglamentų atitikties įžvalgos

ISO 27001 incidentų valdymo reikalavimų vykdymas ne tik stiprina saugumą; jis suteikia tvirtą pagrindą atitikti vis platesnį tarptautinių ir sektoriui būdingų reglamentų tinklą. Daugeliui šių sistemų būdingi tie patys pagrindiniai pasirengimo, reagavimo ir pranešimo principai.

Kaip paaiškinta mūsų išsamiame kelių reglamentų atitikties vadove Zenith Controls, tvirtas incidentų valdymo procesas yra skaitmeninio atsparumo kertinis akmuo. Pažvelkime, kaip ISO 27001 požiūris dera su kitomis pagrindinėmis sistemomis.

ISO/IEC 27002:2022 kontrolės priemonės: Naujausia ISO/IEC 27002 standarto versija pateikia išsamias incidentų valdymo gaires per specialų kontrolės priemonių rinkinį:

• A.5.24 - Informacijos saugumo incidentų valdymo planavimas ir pasirengimas: nustato apibrėžto ir dokumentuoto požiūrio poreikį.
• A.5.25 - Informacijos saugumo įvykių vertinimas ir sprendimo priėmimas: užtikrina, kad įvykiai būtų tinkamai įvertinti siekiant nustatyti, ar jie yra incidentai.
• A.5.26 - Reagavimas į informacijos saugumo incidentus: apima suvaldymo, pašalinimo ir atkūrimo veiklas.
• A.5.27 - Pranešimas apie informacijos saugumo incidentus: apibrėžia, kaip ir kada apie incidentus pranešama vadovybei ir kitoms suinteresuotosioms šalims.
• A.5.28 - Mokymasis iš informacijos saugumo incidentų: nustato nuolatinio tobulinimo proceso reikalavimą.

Šios kontrolės priemonės sudaro visą gyvavimo ciklą, atsikartojantį ir kituose pagrindiniuose reglamentuose.

NIS2 direktyva: Esminių paslaugų operatoriams, įskaitant daugelį gamintojų, NIS2 nustato griežtus saugumo ir pranešimo apie incidentus įpareigojimus. Zenith Controls nurodo tiesioginį sutapimą:

„NIS2 direktyvos Article 21 reikalauja, kad esminiai ir svarbūs subjektai įgyvendintų tinkamas ir proporcingas technines, operacines ir organizacines priemones tinklų ir informacinių sistemų saugumui kylančioms rizikoms valdyti. Tai aiškiai apima incidentų tvarkymo politikas ir procedūras. Be to, Article 23 nustato kelių etapų pranešimo apie incidentus procesą, pagal kurį per 24 valandas kompetentingoms institucijoms (CSIRT) turi būti pateiktas ankstyvasis perspėjimas, o per 72 valandas – išsami ataskaita.“

Su ISO 27001 suderintas reagavimo į incidentus planas suteikia tikslius mechanizmus, reikalingus šiems griežtiems pranešimo terminams įvykdyti.

Skaitmeninės veiklos atsparumo aktas (DORA): Nors DORA orientuotas į finansų sektorių, jo atsparumo principai tampa etalonu visoms pramonės šakoms. Vadove pabrėžiama ši sąsaja:

„DORA Article 17 įpareigoja finansų subjektus turėti išsamų su IRT susijusių incidentų valdymo procesą, skirtą su IRT susijusiems incidentams aptikti, valdyti ir apie juos pranešti. Article 19 reikalauja klasifikuoti incidentus pagal reglamente detalizuotus kriterijus ir apie reikšmingus incidentus pranešti kompetentingoms institucijoms naudojant suderintus šablonus. Tai atspindi ISO 27001 nustatytus klasifikavimo ir pranešimo reikalavimus.“

Bendrasis duomenų apsaugos reglamentas (GDPR): Bet kokiam incidentui, susijusiam su asmens duomenimis, GDPR reikalavimai yra esminiai. Greitas ir struktūruotas reagavimas nėra pasirenkamas. Kaip aiškina Zenith Controls:

„Pagal GDPR Article 33 duomenų valdytojai privalo be nepagrįsto delsimo ir, kai įmanoma, ne vėliau kaip per 72 valandas nuo sužinojimo apie asmens duomenų saugumo pažeidimą, apie jį pranešti priežiūros institucijai. Article 34 nustato pareigą pranešti apie pažeidimą duomenų subjektui, kai tikėtina, kad jis sukels didelę riziką jo teisėms ir laisvėms. Veiksmingas reagavimo į incidentus planas būtinas norint surinkti informaciją, reikalingą tokiems pranešimams tiksliai ir laiku pateikti.“

Kurdami reagavimo į incidentus programą ISO 27001 pagrindu, tuo pačiu kuriate pajėgumus, reikalingus sudėtingiems šių tarpusavyje susijusių reglamentų reikalavimams įvykdyti.

Pasirengimas patikrai: ko klaus auditoriai

Reagavimo į incidentus planas, kuris niekada nebuvo testuotas ar peržiūrėtas, tėra dokumentas. Auditoriai tai žino, todėl ISO 27001 sertifikavimo audito metu nuodugniai tikrins, ar jūsų programa yra gyva ir veikianti jūsų ISVS dalis.

Pagal mūsų auditorių veiksmų planą Zenith Blueprint, reagavimo į incidentus vertinimas yra kritinis audito proceso žingsnis. „3 etapas: darbas vietoje ir įrodymų rinkimas“ metu auditoriai sistemingai tikrins jūsų pasirengimą.

Remiantis Zenith Blueprint 21 žingsniu „Įvertinti reagavimą į incidentus ir veiklos tęstinumą“, galite tikėtis šių prašymų:

1. „Parodykite savo reagavimo į incidentus planą ir politiką.“ Auditoriai pradės nuo dokumentacijos. Jie vertins politikos išsamumą, tikrins, ar apibrėžti vaidmenys ir atsakomybės, klasifikavimo kriterijai, komunikacijos planai ir kiekvieno incidento gyvavimo ciklo etapo procedūros. Jie patikrins, ar politika formaliai patvirtinta ir iškomunikuota susijusiam personalui.

2. „Parodykite paskutinių trijų saugumo incidentų įrašus.“ Čia paaiškėja, ar planas veikia praktikoje. Auditoriams reikia matyti įrodymus, kad plano iš tikrųjų laikomasi. Jie tikėsis incidentų žurnalų arba užklausų, kuriuose dokumentuota:

   • aptikimo data ir laikas;
   • incidento aprašymas;
   • priskirtas prioritetas arba klasifikavimo lygis;
   • veiksmų, atliktų suvaldymui, pašalinimui ir atkūrimui, žurnalas;
   • išsprendimo data ir laikas.

3. „Parodykite paskutinės peržiūros po incidento protokolą ir veiksmų planą.“ Kaip pabrėžia Zenith Blueprint, nuolatinis tobulinimas yra privalomas.

   „Audito metu ieškosime objektyvių įrodymų, kad peržiūros po incidento atliekamos sistemingai. Tai apima posėdžio protokolo, veiksmų žurnalų ir įrodymų, kad nustatyti patobulinimai buvo įgyvendinti, pavyzdžiui, atnaujintos procedūros ar naujos techninės kontrolės priemonės, peržiūrą. Be šio grįžtamojo ryšio ciklo ISVS negali būti laikoma „nuolat tobulinama“, kaip reikalaujama standarte.“

4. „Parodykite įrodymus, kad testavote savo planą.“ Auditoriai nori matyti, kad pajėgumus testuojate proaktyviai, o ne tik laukiate realaus incidento. Tokie įrodymai gali būti įvairūs – nuo stalo pratybų su vadovybe iki plataus masto techninių simuliacijų. Jie norės matyti šių testų ataskaitą, kurioje aprašytas scenarijus, dalyviai, rezultatai ir įgyta patirtis.

Pasirengimas pateikti šiuos įrodymus parodo, kad jūsų reagavimo į incidentus programa nėra vien deklaratyvi, o yra tvirtas, operacinis ir veiksmingas jūsų ISVS komponentas.

Dažnos klaidos, kurių reikia vengti

Net turėdamos gerai dokumentuotą planą, daugelis organizacijų suklumpa realaus incidento metu. Toliau pateikiamos dažniausios klaidos, į kurias reikia atkreipti dėmesį:

1. „Plano lentynoje“ sindromas: dažniausia nesėkmė – turėti puikiai parašytą planą, kurio niekas neperskaitė, nesuprato ar nepraktikavo. Reguliarūs mokymai ir testavimas yra vienintelė veiksminga priemonė.
2. Neapibrėžti įgaliojimai: krizės metu neapibrėžtumas yra priešas. Jei IRT neturi iš anksto patvirtintų įgaliojimų imtis ryžtingų veiksmų, pavyzdžiui, atjungti kritinę gamybos sistemą, reagavimą paralyžiuos neapsisprendimas, o žala plis.
3. Prasta komunikacija: komunikacijos nesuvaldymas yra tiesus kelias į nesėkmę. Tai apima vadovybės neinformavimą, neaiškių pranešimų teikimą darbuotojams arba netinkamą komunikaciją su klientais ir reguliavimo institucijomis. Iš anksto patvirtintas komunikacijos planas su šablonais yra būtinas.
4. Įrodymų išsaugojimo ignoravimas: skubėdama atkurti paslaugą, techninė komanda gali netyčia sunaikinti svarbius skaitmeninės kriminalistikos įrodymus. Dėl to gali tapti neįmanoma nustatyti pagrindinės priežasties, išvengti pasikartojimo ar pagrįsti teisinius veiksmus.
5. Nesugebėjimas mokytis: laikyti incidentą „baigtu“ vos sistemai grįžus į veiklą – praleista galimybė. Be griežtos paskesniosios peržiūros organizacija pasmerkta kartoti tas pačias klaidas.

Tolesni žingsniai

Perėjimas nuo teorijos prie praktikos yra svarbiausias žingsnis. Tvirta reagavimo į incidentus programa yra nuolatinio tobulinimo kelionė, o ne galutinis taškas. Pradėti galite taip:

1. Formalizuokite savo požiūrį: jei neturite formalios reagavimo į incidentus politikos, dabar laikas ją sukurti. Naudokite mūsų P16S Informacijos saugumo incidentų valdymo planavimo ir pasirengimo politiką – MVĮ kaip šabloną išsamiai sistemai sukurti.
2. Supraskite savo atitikties aplinką: susiekite savo reagavimo į incidentus procedūras su konkrečiais tokių reglamentų kaip NIS2, DORA ir GDPR reikalavimais. Mūsų vadovas Zenith Controls pateikia kryžmines nuorodas, reikalingas visai aprėpčiai užtikrinti.
3. Pasirenkite auditui: naudokite auditoriaus perspektyvą savo programai patikrinti esant spaudimui. Zenith Blueprint suteikia vidinį vaizdą, ko reikalaus auditoriai, kad galėtumėte surinkti įrodymus ir būti pasirengę pagrįsti veiksmingumą.

Išvada

Šiuolaikiniam gamintojui reagavimas į informacijos saugumo incidentus nėra vien IT klausimas; tai pagrindinė veiklos tęstinumo funkcija. Skirtumą tarp nedidelio sutrikimo ir katastrofiškos nesėkmės lemia pasirengimas, praktika ir įsipareigojimas laikytis struktūruoto, pakartojamo proceso.

Grįsdami savo programą visame pasaulyje pripažinta ISO 27001 sistema, kuriate ne tik gynybinį pajėgumą, bet ir atsparią organizaciją. Sukuriate sistemą, kuri gali atlaikyti saugumo pažeidimo smūgį, suvaldyti krizę kontroliuojamai ir tiksliai bei po jos tapti stipresnė ir saugesnė. Pasirengti reikia dabar, dar prieš tai, kai 2:17 val. įspėjimas taps jūsų realybe.