InfoSec bez stresa

ISO/IEC 27031:2025 u praksi — deo 9 od 9 Testiranje, zatvaranje MBCO jaza i pregled rukovodstva Prethodni deo je dao Zelenom Hmelju runbook za SCADA i pisanu workaround proceduru za porudžbine — dokumente koji postoje na papiru, ali još nisu bili stvarno isprobani zajedno, pod kontrolisanim uslovima. Ovaj poslednji deo serije zatvara ceo IRBC ciklus: planirana vežba koja testira runbook iz dela 8, formalna odluka šta se radi sa preostalim jazovima (zatvoriti ih ili svesno prihvatiti kao rizik), i godišnji pregled pred rukovodstvom koji ceo sistem vraća na početak — tačku u kojoj se ciklus ponavlja. 11.1–11.2 — Program testiranja i planiranje vežbe Standard razlikuje kvalitativne kriterijume performansi (ankete, povratne informacije učesnika — jeftinije i pogodnije za manje firme) od kvantitativnih, i traži da se testiranje sprovodi postepeno — od upoznavanja sa procedurom do pune simulacije. Svaka vežba treba unapred definisan opseg, cilj i „term of reference" koji potpisu...

ISO/IEC 27031:2025 u praksi — deo 8 od 9 ICT recovery planovi po komponenti i workaround procedure Prethodni deo je definisao ko aktivira IRBC i kojim redosledom. Ovaj deo silazi na najkonkretniji nivo standarda — sam runbook koji neko zaista prati tokom incidenta, korak po korak, plus formalne workaround procedure koje su do sada pominjane usput (MBCO u delu 4), a sada se prvi put pišu kao samostalan dokument koji operater može da otvori i sprovede bez čekanja na Dragana. 10.3.1–10.3.4 — Recovery plan po komponenti Standard traži da RTO/RPO planovi budu dostupni na više lokacija i u više formata, tako da osoba sa odgovarajućom ovlašćenju uvek ima pristup uputstvu kada zatreba — ne samo jedan fajl na Draganovom računaru. Plan takođe mora precizirati tehnički pristup implementacije: hot/warm/cold standby ili kombinaciju, usklađenu sa strategijom izabranom u delu 5. Primer: za SCADA sistem, Zeleni Hmelj je napisao prvi kompletan recovery plan — dokument dovoljno detaljan da ga ...

ISO/IEC 27031:2025 u praksi — deo 7 od 9 ICT plan kontinuiteta: organizacija oporavka i aktivacija Prethodni deo je zatvorio klauzulu 9 formalizacijom odnosa sa AutomatikaPro i otkrivenim failback problemom. Klauzula 10 sada pretvara sve dosadašnje strategije u operativan plan — ko ima ovlašćenje da ga aktivira, kojim redosledom se donose odluke, i koji su formalni resursi i uloge iza IRBC-a. Ovo je prvi put da Zeleni Hmelj piše dokument koji će neko zaista otvoriti usred incidenta, ne posle njega. 10.1.3–10.1.4 — Resursi, uloge i kompetencije Standard traži da rukovodstvo formalno imenuje osobu odgovornu za IRBC politiku, jednog ili više ljudi koji je sprovode, i tim koji operativno izvršava zadatke. Ovo se razlikuje od popisa kompetencija iz dela 1 — tamo je zabeleženo ko šta zna, ovde se to formalizuje kao imenovanje sa jasnim ovlašćenjem, uz obavezu redovne obuke. Primer: Vladimir Nikolić je formalnom odlukom imenovao IRBC strukturu — do sada je Dragan de facto obavljao o...

ISO/IEC 27031:2025 u praksi — deo 6 od 9 Strategije za tehnologiju, podatke, procese i dobavljače Prethodni deo je izabrao primarnu i dopunsku strategiju po ICT elementu i pokrio strategiju za prostor. Standard u nastavku klauzule 9.2 traži da se posebno razrade još četiri sloja — tehnološka arhitektura, kontinuitet podataka, procesi koji strategiju čine izvodljivom, i, možda najvažnije za firmu veličine Zelenog Hmelja, formalizacija odnosa sa dobavljačima. Ovaj deo zatvara klauzulu 9 pre nego što serija pređe na sam plan kontinuiteta. 9.2.4 — Tehnološka razmatranja Standard traži da se pri izboru strategije eksplicitno razmotri niz tehničkih faktora — udaljenost između lokacija, broj lokacija, udaljeni pristup, zahtevi hlađenja i napajanja, nivo automatizacije, i priroda „failback" procesa (da li je povratak na normalno stanje ručan ili automatski). Ovo poslednje je često zanemareno — firme planiraju kako da pređu na rezervni sistem, ali ne i kako se vraćaju nazad. Prim...

ISO/IEC 27031:2025 u praksi — deo 5 od 9 IRBC strategije: izbor pristupa oporavku Prethodni deo je formalno potvrdio ciljeve — RTO, RPO i MBCO za sva tri kritična ICT elementa. Ovaj deo bira kako se do tih ciljeva stiže. Standard nudi paletu strateških opcija koje se mogu kombinovati po sistemu — Zeleni Hmelj ne bira jednu strategiju za ceo IT, nego pravi izbor za svaki element posebno, prema onome što je realno za njegovu veličinu i budžet. 9.1–9.2.1 — Faktori izbora i osnovni scenariji Standard traži da izbor strategije uzme u obzir interna ograničenja — budžet, dostupnost resursa, apetit prema riziku, tehnološka ograničenja — i da razmotri šest osnovnih scenarija: nedostupnost ICT prostora, gubitak fizičkog hardvera, kompromitovan softver, kompromitovani podaci, kompromitovan lanac snabdevanja, i nedostupnost kompetentnog osoblja. Primer: Zeleni Hmelj je za svaki od tri ICT elementa proverio koji od šest scenarija je realno primenjiv, pre nego što je birao strategiju. ...

ISO/IEC 27031:2025 u praksi — deo 4 od 9 Ciljni RTO, RPO i MBCO za ICT usluge Prethodni deo je otkrio da SCADA sistem nema rezervni PLC kontroler, da restart proces nije dokumentovan, i da bekap logova nije potvrđen. Ovaj deo koristi te nalaze da konačno formalno potvrdi ili revidira predložene RTO/RPO brojeve iz dela 2 — ne kao slobodnu procenu, nego kao dokument koji uvodi i treći pojam standarda: MBCO, minimalnu konfiguraciju usluge koja mora ostati dostupna dok se pun oporavak ne završi. 8.2 — Odnos RTO, RPO i MBCO Standard razdvaja tri pojma koji se u praksi često mešaju. RTO (Recovery Time Objective) je vreme od trenutka prekida do trenutka kada je usluga ponovo dostupna — jedan RTO po proizvodu ili aktivnosti, iako se ispod njega može kriti nekoliko ICT komponenti sa sopstvenim, kraćim RTO ciljevima koje moraju da ispune da bi ukupan cilj bio ostvaren. RPO (Recovery Point Objective) meri koliko podataka firma sme da izgubi, izraženo u vremenu — ne u vrednosti, nego u tom...

ISO/IEC 27031:2025 u praksi — deo 3 od 9 Preduslovi za IRBC: kapaciteti oporavka i redundansa opreme Prethodni deo je otvorio tri jaza — cloud platforma nikad nije testirana, SCADA oporavak zavisi od jednog spoljnog konsultanta, a ERP nema definisan poslovni RTO. Klauzula 8 standarda traži da se ti jazovi sada zatvore konkretnim preduslovima: kojim kapacitetom oporavka firma raspolaže, kakva je redundansa opreme, i koji su ključni elementi (ljudi, prostor, tehnologija, procesi, dobavljači) potrebni da IRBC uopšte proradi. 8.1.2–8.1.4 — Kapaciteti oporavka i osnovni scenariji incidenata Standard traži da organizacija prvo popiše poznate scenarije incidenata i za svaki odredi vreme detekcije i vreme odgovora — pre nego što se uopšte priča o strategijama oporavka. Bez ovog koraka, IRBC plan bi reagovao na uopštene pretnje umesto na konkretne, već viđene obrasce kvarova. Primer: Dragan je za tri ključna ICT sistema popisao poznate scenarije incidenata na osnovu iskustva poslednje...

ISO/IEC 27031:2025 u praksi — deo 2 od 9 Poslovna očekivanja od ICT-ja: kritične usluge, RTO/RPO i ugovorne zavisnosti Prvi deo serije zatvorio se procenom jaza — nijedan od tri ključna ICT sistema Zelenog Hmelja nije mogao sa sigurnošću da potvrdi da ispunjava poslovni cilj kontinuiteta. Ovaj deo taj jaz pretvara u formalan, dokumentovan popis kritičnih ICT usluga sa sopstvenim RTO/RPO ciljevima, i uvodi praćenje pretnji koje standard traži u klauzuli 7.1. 7.1 — Praćenje, detekcija i analiza pretnji Standard traži da organizacija uspostavi proces praćenja pojave ICT bezbednosnih pretnji — ne samo reaktivno, nego kontinuirano, kroz nekoliko oblasti: zadržavanje osoblja i znanja, upravljanje prostorom u kojem je ICT oprema, promene u tehnologiji, budžet, i efikasnost spoljnih dobavljača. Monitoring ICT sistema je prva linija odbrane koja omogućava detekciju neobičnih situacija pre nego što prerastu u incident. Primer: Dragan je uspostavio mesečni pregled ovih oblasti, umesto d...