Zakonodavni okvir Ruske Federacije. Upravljanje incidentima i problemima

Dva su pojma u ITSM rječniku koji često stvaraju zabunu među IT stručnjacima i korisnicima: incident i problem. Obje su povezane s procesom rješavanja kvara koji se dogodio i evidentiraju se kreiranjem tiketa u Service Desk sustavu. Međutim, u svojoj srži oni se dosta razlikuju jedni od drugih i imaju različita rješenja. Pogledajmo primjer koji jednostavno objašnjava razliku između ovih pojmova.

Kotlić se pokvario!

Jutro. Za doručak odlučite napraviti šalicu jakog čaja kako biste se oraspoložili prije radnog dana. Uliješ vodu u kuhalo za vodu, uključiš ga u struju, pritisneš prekidač, ali on se ne pali. Stalno okrećete prekidač, provjeravate ima li struje u kući, uključujete kuhalo za vodu u drugu utičnicu, ali i dalje ne radi. Desio se INCIDENT!

Razočarani ste i ljuti. Ne znate zašto kuhalo za vodu ne radi, ali ipak jako želite piti čaj. Razumijete da vodu možete prokuhati na različite načine: zagrijati kipuću vodu u aparatu za kavu, staviti posudu s vodom na plin, izvaditi kamp bojler iz smočnice - sve su to načini da postignete svoj cilj. Na jedan način, voda se zagrije, čaj se skuha i ulije u šalicu - incident je završen, upotrijebili ste zaobilazno rješenje da dovršite zadatak.

Sada ćete svako jutro na jedan od navedenih načina grijati vodu sve dok ne nađete vremena otići u radionicu kako bi vam električar otklonio PROBLEM zbog kojeg kuhalo za vodu ne radi. Problem je razlog zašto se čajnik pokvario. Električar će otkriti da je osigurač pregorio zbog strujnog udara, zamijeniti osigurač i moći ćete ponovno zakuhati vodu u kuhalu - problem riješen.

Kakve veze ima čajnik s IT-om?

Ako se incidenti ponavljaju u IT infrastrukturi, tada je potrebno otkriti temeljni uzrok njihovog nastanka. Ako IT stručnjaci kategoriziraju incidente koji se dogode i analiziraju što uzrokuje njihovo ponavljanje, mogu doći do dna problema koji ih uzrokuje. Rješavanje problema oslobađa vrijeme i resurse IT odjela za rješavanje drugih incidenata umjesto da "svako jutro zagrijava vodu bojlerom umjesto da popravlja kuhalo za vodu".

Jednostavno je, ali vrlo učinkovito!

Uvođenje procesa upravljanja problemima omogućuje promjenu pristupa rješavanju incidenata s reaktivnog na proaktivni. To znači da IT počinje ne samo otklanjati incidente i baviti se uzrokom njihovog nastanka, već i poduzima mjere da do njih uopće ne dođe. Nakon što se riješe svi incidenti i problemi koji do njih dovode, IT stručnjaci imaju vremena potražiti uska grla u infrastrukturi koja se još ne manifestiraju. Dobra organizacija upravljanja incidentima, prioriteta i klasifikacije stvara lančani učinak za poboljšanje rada ostalih IT područja tvrtke.

Vrijeme je da popijete ukusan čaj i provjerite osigurače u ostalim kućanskim aparatima!

veličina fonta

NACIONALNI STANDARD RUSKE FEDERACIJE - INFORMACIJSKA TEHNOLOGIJA - METODE I SREDSTVA SIGURNOSTI - UPRAVLJANJE... Relevantno u 2018.

6 Primjeri incidenata informacijske sigurnosti i njihovi uzroci

Incidenti informacijske sigurnosti mogu biti namjerni ili slučajni (na primjer, rezultat neke ljudske pogreške ili prirodnih pojava) i uzrokovani tehničkim i netehničkim sredstvima. Njihove posljedice mogu uključivati ​​događaje kao što je neovlašteno otkrivanje ili izmjena informacija, njihovo uništavanje ili druge događaje koji ih čine nedostupnima, kao i oštećenje ili krađu imovine organizacije. Incidenti informacijske sigurnosti koji nisu prijavljeni, ali su identificirani kao incidenti, ne mogu se istražiti i ne mogu se primijeniti zaštitne mjere kako bi se spriječilo ponavljanje tih incidenata.

U nastavku su neki primjeri incidenata informacijske sigurnosti i njihovi uzroci, koji su navedeni samo u svrhu pojašnjenja. Važno je napomenuti da ovi primjeri nisu iscrpni.

6.1 Uskraćivanje usluge

Uskraćivanje usluge je široka kategorija incidenata informacijske sigurnosti koji imaju jednu zajedničku stvar.

Takvi incidenti informacijske sigurnosti dovode do nemogućnosti sustava, usluga ili mreža da nastave funkcionirati s istim performansama, najčešće uz potpunu uskraćivanje pristupa ovlaštenim korisnicima.

Postoje dvije glavne vrste incidenata informacijske sigurnosti povezane s uskraćivanjem usluge uzrokovanih tehničkim sredstvima: uništenje resursa i iscrpljivanje resursa.

Neki tipični primjeri takvih namjernih incidenata "uskraćivanja usluge" tehničke informacijske sigurnosti su:

Ispitivanje mrežnih adresa emitiranja kako bi se propusnost mreže u potpunosti ispunila prometom poruka odgovora;

Prijenos podataka u nenamjernom formatu sustavu, usluzi ili mreži u pokušaju da se poremeti ili poremeti njihov normalan rad;

Otvaranje više sesija istovremeno za određeni sustav, uslugu ili mrežu u pokušaju iscrpljivanja njegovih resursa (tj. usporavanje, blokiranje ili uništavanje).

Neki incidenti "uskraćivanja usluge" u vezi s tehničkom informacijskom sigurnošću mogu se dogoditi slučajno, na primjer kao rezultat konfiguracijske pogreške koju je napravio operater ili zbog nekompatibilnosti aplikacijskog softvera, dok drugi mogu biti namjerni. Neki tehnički informacijsko-sigurnosni incidenti "uskraćivanja usluge" inicirani su namjerno s ciljem uništavanja sustava, usluge i smanjenja performansi mreže, dok su drugi samo nusproizvodi drugih zlonamjernih aktivnosti.

Na primjer, neke od najčešćih tajnih metoda skeniranja i identifikacije mogu dovesti do potpunog uništenja starih ili pogrešno konfiguriranih sustava ili usluga kada se skeniraju. Treba napomenuti da se mnogi namjerni tehnički incidenti uskraćivanja usluge često pokreću anonimno (to jest, izvor napada je nepoznat) jer napadač obično nema saznanja o mreži ili sustavu koji se napada.

IS incidenti "uskraćivanje usluge" stvoreni netehničkim sredstvima i dovodeći do gubitka informacija, usluge i (ili) uređaja za obradu informacija mogu biti uzrokovani, na primjer, sljedećim čimbenicima:

Kršenje sustava fizičke sigurnosti koje dovodi do krađe, namjernog oštećenja ili uništavanja opreme;

Slučajno oštećenje opreme i (ili) njezine lokacije uzrokovano vatrom ili vodom/poplavom;

Ekstremni uvjeti okoline, kao što su visoke temperature (zbog kvara klimatizacijskog sustava);

Neispravno funkcioniranje ili preopterećenje sustava;

Nekontrolirane promjene u sustavu;

Neispravan rad softvera ili hardvera.

6.2 Prikupljanje informacija

Općenito govoreći, incidenti informacijske sigurnosti "prikupljanje informacija" podrazumijevaju radnje povezane s identificiranjem potencijalnih ciljeva napada i stjecanjem razumijevanja usluga koje se izvode na identificiranim ciljevima napada. Takvi incidenti informacijske sigurnosti zahtijevaju izviđanje kako bi se utvrdilo:

Prisutnost cilja, stjecanje razumijevanja topologije mreže koja ga okružuje i s kim je cilj obično povezan razmjenom informacija;

Potencijalne ranjivosti cilja ili njegovog neposrednog okruženja mrežnog okruženja koje se mogu iskoristiti za napad.

Tipični primjeri napada čiji je cilj prikupljanje podataka tehničkim sredstvima su:

Poništavanje DNS (Domain Name System) zapisa za ciljnu internetsku domenu (prijenos DNS zone);

Slanje testnih zahtjeva na nasumične mrežne adrese kako bi se pronašli radni sustavi;

Ispitivanje sustava radi identifikacije (na primjer, kontrolnim zbrojem datoteke) glavnog operativnog sustava;

Skeniranje dostupnih mrežnih priključaka za sustav protokola za prijenos datoteka kako bi se identificirale odgovarajuće usluge (na primjer, e-pošta, FTP, mreža itd.) i softverske verzije ovih usluga;

Skeniranje jedne ili više usluga s poznatim ranjivostima na nizu mrežnih adresa (horizontalno skeniranje).

U nekim slučajevima prikupljanje tehničkih informacija proširuje se na neovlašteni pristup ako, na primjer, napadač pokuša dobiti neovlašteni pristup dok traži ranjivost. To se obično provodi automatiziranim alatima za hakiranje koji ne samo da traže ranjivosti, već i automatski pokušavaju iskoristiti ranjive sustave, usluge i (ili) mreže.

Incidenti prikupljanja obavještajnih podataka stvoreni netehničkim sredstvima rezultiraju:

Izravno ili neizravno otkrivanje ili izmjena informacija;

Krađa intelektualnog vlasništva pohranjenog u elektroničkom obliku;

Povreda evidencije, na primjer, prilikom registracije računa;

Zlouporaba informacijskih sustava (na primjer, kršenjem zakona ili organizacijske politike).

Incidenti mogu biti uzrokovani, na primjer, sljedećim čimbenicima:

Kršenje fizičke sigurnosne zaštite koje dovodi do neovlaštenog pristupa informacijama i krađe uređaja za pohranu koji sadrže osjetljive podatke, kao što su ključevi za šifriranje;

Loše i/ili krivo konfigurirani operativni sustavi zbog nekontroliranih promjena u sustavu ili neispravnog softvera ili hardvera koji rezultira neovlaštenim pristupom organizacijskog osoblja ili neovlaštenog osoblja informacijama.

6.3 Neovlašteni pristup

Neovlašteni pristup kao vrsta incidenta uključuje incidente koji nisu uključeni u prve dvije vrste. Uglavnom se ova vrsta incidenta sastoji od neovlaštenih pokušaja pristupa sustavu ili zlouporabe sustava, usluge ili mreže. Neki primjeri neovlaštenog pristupa tehničkim sredstvima uključuju:

Pokušaji izdvajanja datoteka s lozinkama;

Napadi prekoračenja međuspremnika radi dobivanja privilegiranog (na primjer, na razini administratora sustava) pristupa mreži;

Iskorištavanje ranjivosti protokola za presretanje veza ili krivo usmjeravanje legitimnih mrežnih veza;

Pokušaji povećanja privilegija pristupa resursima ili informacijama izvan onih koje zakonito posjeduju korisnik ili administrator.

Incidenti neovlaštenog pristupa stvoreni netehničkim sredstvima koji rezultiraju izravnim ili neizravnim otkrivanjem ili izmjenom informacija, kršenjem računovodstvenih pravila ili zlouporabom informacijskih sustava mogu biti uzrokovani sljedećim čimbenicima:

Uništavanje sredstava fizičke zaštite s naknadnim neovlaštenim pristupom informacijama;

Neuspješna i/ili netočna konfiguracija operativnog sustava zbog nekontroliranih promjena u sustavu ili neispravnosti softvera ili hardvera koja dovodi do rezultata sličnih onima opisanim u zadnjem paragrafu 6.2.

Primjeri zrakoplovnih nesreća i incidenata.

Bilo je nekoliko incidenata i nesreća visoke razine uzrokovanih ljudskim čimbenicima. Internetska stranica ljudskih čimbenika u održavanju i inspekciji zrakoplovstva (HFAMI) sadrži 24 NTSB izvješća o incidentima koji uključuju ljudske čimbenike. U Velikoj Britaniji dogodilo se nekoliko nesreća i incidenata. Pojedinosti o njima nalaze se na web stranici AAIB-a. Neki od tih incidenata navedeni su u nastavku:

• Incident s Boeingom 737 (Aloha let 243), Maui, Havaji, travanj 1988.;
• Incident BAC 1-11, G-BJRT (British Airways let 5390), Didcot, Oxfordshire, 10. lipnja 1990.
• Incident s A-320, G-KMAM u londonskoj zračnoj luci Gatwick 26. kolovoza 1993.;
• Incident s Boeingom 737, G-OBMM blizu Davintreeja 23. veljače 1995.

Incident koji se dogodio na Alohinom letu 243 u travnju 1988. uključivao je 18 stopa kože gornjeg dijela kabine koja je otrgnuta tijekom leta. Zrakoplov su prije leta prema zahtjevima SAD-a pregledala dva zrakoplovna inspektora. Jedan inspektor imao je 22 godine staža, a drugi, najstariji, 33 godine staža. Tijekom pregleda nisu pronađene nikakve pukotine. Testovi nakon incidenta otkrili su preko 240 pukotina na oplati zrakoplova u vrijeme pregleda. Iz toga proizlaze mnogi problemi vezani uz ljudski faktor koji dovode do neadekvatnih inspekcija.

Kao rezultat incidenta s letom Aloha, Sjedinjene Države razvile su program istraživanja ljudskih faktora s naglaskom na inspekcije.

10. lipnja 1990. godine U Velikoj Britaniji, BAC 1-11 (British Airways let 5390) poletio je iz zračne luke Birmingham. Nakon penjanja na 17.300 stopa, lijevo vjetrobransko staklo je pritisnuto prema van u kokpitu. Ovo staklo je zamijenjeno prije leta. Pokazalo se da su od 90 vijaka za pričvršćivanje 84 bila manjeg promjera od potrebnog. Kapetan broda napola je izvučen iz kokpita kroz prozorski otvor i držan od strane članova posade dok kopilot nije sigurno sletio u zračnu luku Southampton.

Voditelj smjene (SMM), zbog manjka osoblja tijekom noćne smjene, odlučio je sam zamijeniti vjetrobransko staklo. Pogledao je Upute (MM) i zaključio da je to jednostavan posao. Odlučio je zamijeniti pričvrsne vijke i uzeo jedan kao uzorak (7D)

počeo birati druge koje će zamijeniti. Skladištar mu je rekao da su za zamjenu potrebni vijci (8D), ali zbog nedostatka istih u skladištu, šef smjene je odlučio da će poslužiti vijci (7D). (Pošto su prije stajali). Međutim, vizualno je usporedio i dodirnuo vijke i pogrešno odabrao vijke 8C, koji su duži i tanji. Također nije primijetio da je tijekom ugradnje udubljenje za glavu vijka (upušteno) dublje nego što je potrebno. Posao je obavio sam i potpisao otpustnicu. Postupak nije zahtijevao dubinski ili sekundarni pregled. Nekoliko ljudskih čimbenika bilo je uključeno u ovaj incident, uključujući pogrešno dimenzioniranje vijaka od strane nadzornika smjene, loše osvjetljenje u skladištu, nenošenje naočala, radnu praksu i moguće čimbenike dizajna i upravljanja radom.

Zrakoplov A-320 u Velikoj Britaniji u kolovozu 1993. U prvom letu nakon zamjene zakrilca došlo je do oštrog zastoja u desno odmah nakon polijetanja. Zrakoplov se vratio na Gatwick i sigurno sletio. Istraga je otkrila da su tijekom održavanja, radi zamjene desnog poklopca, spojleri stavljeni u režim održavanja i pomaknuti dok postupak nije bio dovršen; sukladno tome, prirubnice i zastavice nisu ugrađene. Inženjeri nisu dobro razumjeli svrhu prirubnica i spojlera.

Ovaj nesporazum djelomično je uzrokovan familijarnošću i poznavanjem tuđeg zrakoplova

tipa (Boeing 757) i izraženo je u nedovoljnoj indikaciji stanja spojlera tijekom primopredaje smjene. Zaključani spojler nije otkriven tijekom rutinskih provjera pilota.

U veljači 1995. god Na zrakoplovu Boeing 757-400 detektiran je gubitak tlaka ulja na oba motora. Zrakoplov se okrenuo i sigurno sletio u zračnu luku Luton. Istragom je utvrđeno da je letjelica prošle noći podvrgnuta boroskopskom pregledu oba motora te da kućišta pogona visokotlačnog rotora nisu ugrađena nakon završetka radova. Zbog toga je gotovo svo ulje iz oba motora izgubljeno tijekom leta. Inženjer linijskog održavanja je prvotno trebao obaviti ovaj posao, ali je iz različitih razloga delegirao posao nadzorniku održavanja baze. Kontrolor nije imao potrebne dokumente za rad s njim. Inspektor i mehaničar su dovršili radove, unatoč brojnim prekidima, ali nisu ugradili kućišta rotora. Motori nisu testirani na zemlji u praznom hodu kako bi se otkrilo curenje ulja. Prijavljeno je da su radovi završeni.

U sva tri incidenta u Ujedinjenom Kraljevstvu, tvrtke su ocijenile inženjere uključene u održavanje kao visoko vješte, kompetentne i pouzdane. Svi incidenti su okarakterizirani na sljedeći način:

• nije bilo dovoljno osoblja;
• postojao je vremenski pritisak;
• Sve su se pogreške dogodile noću;
• Izvršene su primopredaje smjena;
• Sve uključene osobe obavljale su duge ručne zadatke;
• Postojao je element stava "mogu znači hoću";
• Bilo je prekida u radu;
• Propust korištenja provjerenih informacija ili postupaka;
• Upute su bile nedosljedne;
• Nije napravljeno dovoljno predplaniranja, opreme i rezervnih dijelova.

Incidenti i nesreće - Narušavanje ljudskog faktora.

U svim gore navedenim primjerima, nesreće ili incidenti mogli su se spriječiti da je jedna od mnogih stvari učinjena drugačije. U nekim slučajevima, kada je uključeno više radnika, rezultat njihovog rada može se poboljšati ako je jedan od njih ispravno odgovorio ili pitao za određenu radnju. U bilo kojoj datoj situaciji, međutim, radnici ne uspijevaju prepoznati i reagirati na znakove potencijalne opasnosti, ne reagiraju prema očekivanjima ili dopuštaju da ih ruke ometu, ostavljajući se otvorenima za pogrešku.

Kao i kod mnogih drugih incidenata i nesreća, gore navedeni primjeri uključuju niz problema uzrokovanih ljudskim čimbenicima lanac grešaka(Pogledajte sliku 3). Ako se jedna karika u tom lancu prekine poduzimanjem mjera koje mogu spriječiti problem u jednoj ili više faza njegovog razvoja, incident se može spriječiti.

Slika 3. Lanac pogrešaka.

Pr Procesi upravljanja incidentima i upravljanja problemima u mnogočemu su slični, ali imaju i značajne razlike. Opisat ćemo svaki od procesa zasebno, a zatim ih usporediti s različitih gledišta, raspravljajući o metodama implementacije.

Upravljanje incidentima

Glavni cilj procesa upravljanja incidentima je vratiti normalnu funkcionalnost sustava što je brže moguće i minimizirati negativan utjecaj na poslovanje koje koristi usluge koje su poremećene. "Normalni rad usluga" znači rad u skladu s ugovorom o razini usluge (SLA).

Incidenti ne mogu uključivati ​​događaje koji se ne odnose na kvalitetu pružene IT usluge, kao ni one koji, iako umanjuju tu kvalitetu, ne izlaze izvan opsega navedenog u SLA. Posebno mjesto zauzimaju slučajevi kada klijent nije osjetio prisutnost incidenta (na primjer, ako su sve potrebne mjere poduzete automatski ili od strane servisnog osoblja čak i prije nego što je kvaliteta stvarno smanjena). Primjeri: automatsko arhiviranje podataka i oslobađanje scratch diska kada se približi točki prelijevanja; prebacivanje na rezervni poslužitelj ako glavni zakaže, itd. Međutim, takvi se slučajevi ne mogu isključiti s popisa incidenata. Pravilna organizacija zahtijeva postupanje s takvim incidentima u skladu s punom procedurom (tj. njihovo naknadno prikazivanje u izvješćima i poduzimanje potrebnih mjera za njihovo sprječavanje u budućnosti).

Svaki proces upravljanja incidentom može se formalno opisati navođenjem niza karakteristika.

Ulazni podaci za opisivanje incidenata su:

• detaljan opis incidenta dobiven od Service Deska, usluge za osiguranje operativnog funkcioniranja mreža ili poslužitelja i sl.;
• opis konfiguracija i elemenata koji su možda povezani s incidentom. Opisi su preuzeti iz CMDB-a, baze konfiguracijskih jedinica koje uključuju sve elemente IT infrastrukture (hardver, softver, dokumentacija, pružene usluge itd.);
• informacije (ako su dostupne) iz baze podataka problema i baze podataka poznatih grešaka;
• opis metode razrješenja.

Ishod procesa upravljanja incidentom mogao bi biti:

• zahtjev za privremene promjene za rješavanje incidenta, ažurirani zapis o incidentu uključujući rješenje i/ili zaobilazno rješenje;
• riješen (riješen) i zatvoren incident;
• poruka klijentu;
• informacije o upravljanju (izvješće).

Moguće aktivnosti upravljanja incidentima:

• identificiranje i snimanje incidenta;
• klasifikacija incidenata i početna pomoć;
• istraživanje i dijagnostika;
• rješavanje incidenata i oporavak sustava;
• zatvaranje incidenta;
• vlasništvo, praćenje, praćenje i interakcija.

Uloge i funkcije upravljanja incidentima:

• timovi prve, druge i treće linije podrške, kao i specijalistički timovi i vanjski partneri (uloge); voditelj upravljanja incidentima (uloga); Service Desk manager (funkcija).

Moguće metrike:

• ukupan broj incidenata;
• prosječno vrijeme za rješavanje ili zaobilaženje incidenta za različite vrste incidenata;
• postotak incidenata riješenih u vremenskom razdoblju koje ne prelazi ono navedeno u SLA-u;
• prosječni trošak rješavanja incidenta;
• postotak zatvorenih incidenata bez uključivanja drugih stručnjaka;
• broj i postotak incidenata riješenih na daljinu (bez posjeta korisniku).

Kako bi se osiguralo poštivanje vremenskog okvira dodijeljenog za provedbu određenih radnji, koristi se funkcionalna i hijerarhijska eskalacija. "Eskalacija" se odnosi na organizacijski mehanizam koji pomaže u kontroli vremena za rješavanje incidenta; treba ga koristiti u svim aktivnostima tijekom procesa rješavanja incidenta. Njegova bit leži u potrebi da se ili obvezno proslijede informacije o incidentu kvalificiranijim stručnjacima, ili da se uprava obavijesti o nemogućnosti uklanjanja incidenta u dogovorenom roku.

Prijenos incidenta sa Service Deska na drugu liniju podrške (funkcionalna eskalacija) potreban je ako je nemoguće riješiti incident na prvoj liniji. Automatska funkcionalna eskalacija je moguća, ali se mora pažljivo planirati u skladu sa SLA.

Hijerarhijska eskalacija je nužna kada je nemoguće riješiti incident niti u zadanom vremenu niti potrebnom kvalitetom. U pravilu, to ručno provodi osoblje Service Deska prema svom iskustvu. Također se koristi automatizirana hijerarhijska eskalacija koja se može graditi na temelju uzimanja u obzir vremenskih intervala. Preporučljivo je da se provede prije vremena navedenog u SLA; to će relevantnom upravitelju dati priliku za poduzimanje daljnjih radnji.

Učinak implementacije procesa upravljanja incidentima

Nabrojimo najvažnija korisna svojstva koja se stječu provedbom procesa upravljanja incidentima. Za poslovanje općenito ovo je:

• smanjenje negativnog utjecaja incidenata na poslovanje, što se postiže povećanjem učinkovitosti i smanjenjem vremena potrebnog za njihovo rješavanje;
• proaktivno (anticipativno) utvrđivanje potrebe za proširenjem i korekcijom poslovno kritičnih sustava;
• Dostupnost upravljačkih informacija potrebnih za poslovanje, u korelaciji s uvjetima SLA.

Rad IT odjela također dobiva niz korisnih kvaliteta:

• napredno praćenje za mjerenje izvedbe u odnosu na SLA;
• poboljšane informacije za upravljanje kvalitetom usluge;
• optimalnija iskorištenost osoblja i učinkovitiji rad;
• otklanjanje gubitaka i netočnog evidentiranja incidenata i zahtjeva;
• točnije održavanje baze podataka konfiguracijske jedinice CMDB;
• bolje zadovoljstvo kupaca.

Rad bez sustava upravljanja incidentima može rezultirati nizom problema. Nepostojanje osoba odgovornih za rješavanje i eskalaciju incidenata dovodi do konfuzije u rješavanju kvarova i smanjuje kvalitetu usluge. Stručnjaci za podršku odvlače se od svojih dužnosti, što smanjuje učinkovitost njihovog rada. Kako bi riješili incidente i probleme, korisnici su prisiljeni komunicirati jedni s drugima, ometeni od svojih glavnih odgovornosti. Svaki put morate iznova analizirati incidente – čak i one koji se redovito događaju i koji bi trebali biti poznati.

Upravljanje problemima

Primarni cilj procesa upravljanja problemima je smanjiti negativan utjecaj incidenata i problema koji proizlaze iz pogrešaka u IT infrastrukturi na osnovnu djelatnost organizacije te spriječiti ponavljanje incidenata povezanih s tim pogreškama. U tu svrhu traže se i razjašnjavaju uzroci incidenata te se poduzimaju radnje za poboljšanje stanja ili otklanjanje utvrđenih uzroka.

Proces upravljanja problemima je i reaktivan i proaktivan. Prva opcija odnosi se na rješavanje problema povezanih s nastalim incidentima, druga je usmjerena na prepoznavanje i uklanjanje problema koji bi mogli dovesti do, ali još nisu doveli do incidenata.

Kontrola problema i pogrešaka, zajedno s proaktivnim upravljanjem problemima, odgovornosti su procesa upravljanja problemima. U jeziku formalnih definicija, "problem" je nepoznati osnovni uzrok jednog ili više incidenata, a "poznata pogreška" je uspješno dijagnosticiran problem za koji je pronađeno rješenje ili rješenje.

Što se tiče procesa upravljanja incidentima, predstavljamo skupine glavnih karakteristika procesa upravljanja problemima. Iako su neki od njih isti, ima smisla navesti ih sve jer je riječ o različitim procesima.

Ulazni podaci za opis su:

• pojedinosti o incidentu proizašle iz upravljanja incidentom;
• detaljan opis konfiguracija iz CMDB-a;
• sva poznata rješenja (iz upravljanja incidentima).

Mogući događaji:

• kontrola problema i grešaka;
• proaktivna prevencija problema;
• identifikacija trendova;
• analiza akumuliranih informacija i priprema izvješća;
• priprema upravljačkih informacija.

Rezultati mogu biti sljedeći:

• opis novih poznatih grešaka;
• zahtjevi za promjenama;
• ažurirani dnevnik problema, uključujući moguće rješenje problema i/ili bilo koje dostupno rješenje;
• za riješene probleme, dnevnik zatvorenih problema;
• traženje analoga incidenta među poznatim pogreškama i problemima koji se razmatraju;
• informacije o upravljanju.

Uloge i funkcije: zaposlenici odgovorni za rješavanje problema (uloge); Voditelj upravljanja problemima (uloga).

Moguće metrike:

• broj pokrenutih zahtjeva za promjenama i utjecaj tih zahtjeva na pouzdanost i dostupnost usluga koje pokrivaju;
• vrijeme utrošeno na istraživački i dijagnostički rad za svaki odjel, uzimajući u obzir podjelu na vrste problema;
• broj i utjecaj incidenata koji su se dogodili prije utvrđivanja uzroka problema ili prije nego što je poznata pogreška prijavljena;
• omjer obujma napora za trenutnu pomoć i potporu prema planiranim;
• broj problema i grešaka grupiranih prema različitim kriterijima (status, usluge, utjecaj, kategorije, grupe korisnika);
• prosječno i maksimalno vrijeme potrošeno na zatvaranje problema ili usklađivanje poznatog problema, izračunato od trenutka kada je problem prijavljen, grupirano prema kodovima utjecaja i grupama podrške;
• očekivano vrijeme za rješavanje otvorenih pitanja;
• ukupno vrijeme potrošeno na sva zatvorena pitanja.

Učinak implementacije procesa upravljanja problemima

Nabrojimo najvažnije korisne kvalitete koje se stječu kao rezultat implementacije procesa upravljanja problemima.

• Kvaliteta usluga. Upravljanje problemima pomaže u održavanju kontinuiranog ciklusa kontinuiranog poboljšanja kvalitete IT usluga.
• Smanjenje broja incidenata. Proces upravljanja problemima je alat za smanjenje broja incidenata koji negativno utječu na poslovanje organizacije.
• Kontinuirano rješenje. Kao rezultat procesa smanjuje se broj i utjecaj na poslovanje već riješenih problema i poznatih grešaka.
• Napredna obuka. Proces se temelji na konceptu korištenja akumuliranog znanja iz prošlosti i pruža mogućnosti analize trendova i sprječavanja poremećaja ili smanjenja njihovog značaja i utjecaja na core business.
• Povećanje broja incidenata riješenih na prvi poziv. To se postiže davanjem preporuka Service Desku o tome kako spriječiti i zaobići incidente koji se dogode.

Zauzvrat, odbijanje provedbe procesa obećava brojne probleme. Čisto "ex-post" usluga podrške počinje raditi tek kada usluga više nije dostupna. Razvija se infrastruktura koja od korisnika zahtijeva samostalno korištenje IT alata. Neučinkoviti, skupi i slabo motivirani timovi za podršku uvijek iznova rješavaju iste probleme ne uzimajući u obzir prethodno iskustvo.

Provedba i provedba

Već smo skrenuli pozornost na glavnu razliku između razmatranih procesa, koja je uzeta u obzir pri formiranju ključnih metrika kvalitete. Cilj upravljanja incidentima je riješiti incidente što je brže moguće. Upravljanje problemom treba isključiti mogućnost ponovnog događanja incidenta iz istih (a ponekad i iz sličnih) razloga.

U organizacijskom smislu to znači da nitko ne može obavljati odgovornosti za oba ova procesa u isto vrijeme, jer ne bi mogao pravilno odrediti prioritete. Kao izlaz iz situacije s tradicionalno ograničenim osobljem, preporučuje se jasno definiranje u uputama vremenskog ili drugog okvira koji omogućuje stručnjaku da jasno obavlja ulogu u samo jednom od procesa. Primjerice, djelatnik Službe za upravljanje mrežom banke, u kritičnim vremenima za obavljanje velikih plaćanja, dužan je, ako dođe do kvarova, poduzeti sve mjere da se ti kvarovi što prije otklone i vrati funkcionalnost sustava, igrajući ulogu stručnjaka za upravljanje incidentima. U relativno manje kritičnim trenucima, ovom stručnjaku je zabranjeno reagirati na novonastale incidente i upućeno mu je da analizira prikupljene informacije o kvarovima i traži njihove uzroke, te na taj način provodi mjere upravljanja problemima.

Prihvatljivo je (i preporučljivo) kombinirati funkcije Service Deska i funkcije upravljanja incidentima. Međutim, važno je zapamtiti da su to različiti procesi: početna komunikacija s korisnicima nije dio procesa upravljanja incidentom. Osim toga, korisnik se može obratiti službi za podršku ne samo u vezi s incidentom, već i iz drugog razloga (potreba za informacijama, potreba za nadopunom potrošnog materijala itd.). S druge strane, kod nekih načina implementacije (primjerice, u slučaju izgradnje servisa podrške temeljenog na web tehnologijama, kada korisnik samostalno unosi sve potrebne podatke u obrasce), upitna je potreba za namjenskim Service Deskom. Pritom, ni u kojem slučaju ne treba odbiti upravljanje incidentima – bez obzira odakle dolazi poruka o njihovom nastanku, netko mora biti odgovoran za njihovo otklanjanje.

Jasno je da je implementacija upravljanja problemima u nedostatku upravljanja incidentima praktički nemoguća: osnova i izvor podataka za razmatranje problema su informacije akumulirane tijekom analize i obrade incidenata. Ponekad je prihvatljivo implementirati samo upravljanje incidentima. Tipično, posredničke tvrtke nemaju upravljanje problemima - imaju vlastitu dispečersku službu, takve tvrtke organiziraju prijem i registraciju zahtjeva kupaca, pomažu im, ako je moguće, rješavaju incident uz pomoć konzultacija, prenose složenije zahtjeve kooperantima i kontroliraju njihove radnje, čime se provodi upravljanje incidentima. Istodobno, oni ne analiziraju probleme, budući da nisu stvarna operativna organizacija. Upravljanje problemom često je isključeno čak i ako za to nema prilike ili želje. U nekim slučajevima čak se preporučuje uključivanje vanjskih stručnjaka za analizu problema, jer to zahtijeva vrlo visoke kvalifikacije, kao i skupu opremu. Primjer su tradicionalni kontakti s tvrtkama specijaliziranim za izgradnju i održavanje telekomunikacija radi utvrđivanja stvarnog opterećenja podatkovnih mreža: odgovarajuća oprema je skupa, a potreba za njezinim korištenjem javlja se iznimno rijetko.

Za alate za automatizaciju, ITIL preporučuje, barem, duboke mogućnosti integracije između alata za upravljanje problemima i incidentima. Doista, kada se analiziraju problemi, važno je moći sagledati sve prijavljene incidente iz različitih perspektiva. Zauzvrat, kako bi učinkovitije komunicirali s korisnicima kada se pojave novi incidenti, relevantni stručnjaci trebaju pristup neriješenim ili već zatvorenim problemima i poznatim pogreškama.

Ovo se može lako razumjeti na primjeru sljedeće situacije. Korisnik kontaktira podršku s porukom o naglom povećanju vremena odgovora poslužitelja. Operater pregledom popisa analiziranih problema pronalazi zapis o obavljenom radu na analizi pada performansi poslužitelja, nakon čega obavještava korisnika da je njegova poruka registrirana i da se odnosi na problem koji se razmatra te se očekuje otklanjanje nakon određenog vremena, o čemu će korisnik biti dodatno obaviješten. U nedostatku mogućnosti pregleda popisa problema, operater ne bi mogao povezati incident s konkretno analiziranim problemom, zatim brzo pratiti činjenicu da je riješen i obavijestiti korisnika o tome.

Proizvođači alata nastoje uzeti u obzir navedene preporuke. Na primjer, HP OpenView Service Desk 3.0 ima modularnu strukturu. Mogućnost registracije i upravljanja korisničkim zahtjevima, incidentima i problemima implementirana je kao zaseban modul, što je u potpunosti u skladu s navedenim preporukama: integracija je u ovom slučaju što potpunija. Korisnici sustava izgrađenog na temelju ovog proizvoda imaju mogućnost graditi veze između registracijskih zapisa svih navedenih tipova, pretraživati ​​po kontekstu i uzimajući u obzir te veze utvrđivati ​​poznate metode za rješavanje novonastalih problema. Razdvajanje ovih funkcija može smanjiti učinkovitost alata, a kao rezultat i kvalitetu implementacije procesa. Istovremeno, temelj svakog rješenja za upravljanje IT infrastrukturom je uzimanje u obzir postojeće opreme, aplikacija, dokumentacije itd. - sve ono što čini ovu infrastrukturu. Ove su mogućnosti također dostupne kao dio HP Service Desk 3.0. Osim toga, značajke dizajnirane za automatizaciju upravljanja promjenama i SLA upravljanja implementirane su kao zasebni moduli. Integracija svih gore navedenih modula implementirana je u najvećoj mogućoj mjeri, pružajući mogućnost korištenja dotičnog proizvoda kao temelja za izgradnju sveobuhvatnog IT sustava upravljanja.

Proizvod Remedy izgrađen je nešto složenije; temelji se na Remedy Action Request System instaliranom na poslužitelju. Dodatni funkcionalni moduli mogu se kupiti kao aplikativni dio sustava: Help Desk, Asset Management, Change Management i Service Level Agreement. Svaki od modula može se koristiti samostalno (bez drugih aplikacijskih modula) ili kao dio integriranog rješenja. Pitanja automatizacije procesa upravljanja problemima i incidentima, kao u slučaju HP rješenja, implementirana su u modulu Remedy Help Desk. Istodobno, postoje neke razlike i provode se individualni pristupi razumijevanju ovih procesa, ali se glavne želje i zahtjevi ITIL-a u potpunosti uzimaju u obzir.

Za uspješnu implementaciju procesa upravljanja incidentima i problemima

Moraju biti ispunjeni najmanje sljedeći uvjeti.

• Dostupnost aktualne i pravovremeno ažurirane CMDB baze podataka. Ako ova baza podataka nije dostupna, informacije o konfiguracijskim stavkama koje se odnose na incident dohvaćat će se ručno, što će značajno produžiti vrijeme obrade incidenta i povećati njegovu složenost.
• Dostupnost ažurirane baze znanja o pogreškama/problemima i načinima za njihovo rješavanje i zaobilaženje. Posjedovanje takve baze podataka omogućuje vam brzo rješavanje mnogih problema. Poželjno je da se na njega mogu povezati slične baze podataka koje su razvile druge organizacije i tvrtke. Problemi s kompatibilnošću koji se pojave mogu dovesti do velike složenosti, stoga se preporučuje korištenje rješenja otvorene arhitekture koja uključuje alate za uvoz i izvoz podataka. U posljednje vrijeme kao standardna metoda pristupa informacijama sve se više koristi Web sučelje koje je praktično i razumljivo te široko rasprostranjeno.
• S obzirom na potencijalni sukob između upravljanja problemima i upravljanja incidentima (zbog različitih ciljeva), potrebno je organizirati zajednički rad i suradnju između nositelja oba procesa. Pritom ne smijemo zaboraviti da iz istih razloga jedna te ista osoba ne može istodobno obavljati obje dužnosti: bit će joj vrlo teško pronaći ravnotežu interesa.
• Organizacija učinkovitog automatiziranog sustava registracije incidenata s mogućnostima detaljne i kvalitetne klasifikacije, što je iznimno važan element za organizaciju funkcioniranja kako servisa Service Desk tako i procesa koji se razmatraju u čistom obliku. Ne preporuča se korištenje papirnih tehnologija u ove svrhe.

Vrlo je zgodno ako alati koji se koriste za implementaciju dotičnih procesa imaju sljedeće dodatne mogućnosti:

• automatska registracija incidenata koji se javljaju u najvažnijim uređajima (poslužiteljima, mrežnoj opremi itd.), što može zahtijevati stvaranje dodatnih sučelja;
• automatska eskalacija incidenata u slučaju kršenja vremenskih rasporeda;
• fleksibilno usmjeravanje incidenta, budući da se pomoćno osoblje može nalaziti u različitim sobama i zgradama;
• automatsko pretraživanje potrebnih podataka u CMDB bazi podataka;
• posebna rješenja za olakšavanje klasifikacije incidenata;
• integracija s telefonskim sustavima;
• prisutnost raznih dijagnostičkih modula.

Ilustrirajmo navedene mogućnosti na primjeru već spomenutog Service Deska 3.0. Kao član HP OpenView obitelji proizvoda, Service Desk uključuje mogućnost primanja poruka od drugih proizvoda u obitelji, uključujući Network Node Manager, alat za nadzor i upravljanje mrežnim uređajima, i VantagePoint Operations, alat za nadzor i upravljanje poslužitelji i aplikacije. Ovi proizvodi mogu automatski, na temelju prikupljenih informacija o nadziranim objektima, generirati zahtjeve za Service Desk, koji se automatski prenose i analiziraju od strane operatera servisa podrške ili se automatski obrađuju. Uz odgovarajuće postavke, drugi dijagnostički alati također mogu postati izvori sličnih poruka. Proizvod pruža mogućnost automatskog informiranja slanjem poruka menadžerima na odgovarajućim razinama ako se prekrše rokovi za rješavanje incidenta. Implementira napredne mogućnosti traženja potrebnih informacija među već zabilježenim problemima, incidentima i drugim podacima. Proizvod pruža mogućnosti integracije sa sustavima pošte, telefona i dojavljivanja.

S obzirom na relevantnost i korisnost navedenih dodatnih značajki, proizvođači programskih rješenja nastoje ih uključiti u svoje proizvode. Velik dio onoga što je rečeno o HP Service Desku odnosi se i na proizvode drugih proizvođača, uključujući Remedy, Tivoli, CA, Peregrin, FrontRange.

Oni koji preuzimaju posao provedbe procesa koji se razmatraju moraju biti spremni na niz poteškoća. Među njima:

• nedostatak potpore uprave i osoblja, što može dovesti do nedostatka resursa za provedbu;
• nerazumijevanje poslovnih potreba, nedostatak dogovorenih razina usluga, loše definirani ciljevi, mogućnosti i odgovornosti različitih službi;
• otpor promjenama i nemogućnost promjene postojećih radnih praksi;
• nedostatak znanja za rješavanje incidenata, neprikladna obuka osoblja, loše formalizirana pravila za interakciju korisnika sa službama podrške i različitim službama međusobno;
• loša integracija s drugim procesima, nekvalitetni alati za automatizaciju te nemogućnost povezivanja evidencije incidenata i odgovarajućih problema značajno umanjuje mogućnosti procesa, uključujući i mogućnost predviđanja problema.

***

Usredotočili smo se na dva najčešće citirana IT procesa upravljanja u rješavanju problema. Iako sasvim razumljivi na intuitivnoj razini, ovi su procesi teško provedivi s gledišta potrebe za striktnim pridržavanjem organizacijskih mjera i procedura. Iako slični na mnoge načine, procesi upravljanja incidentima i upravljanja problemima također imaju značajne razlike koje proizlaze iz njihovih primarnih ciljeva. Prilikom implementacije procesa, alati za automatizaciju koji se koriste u te svrhe postaju od iznimne važnosti. Nažalost, primarni izvori o ITIL-u dostupni su vrlo ograničenom krugu zainteresiranih: vrlo su skupi, naručiti ih nije lako, a nabaviti ih je još teže. Zahtjevi i želje za alate navedene u članku temelje se na stvarnom iskustvu u radu s različitim alatima i analizi načina rješavanja problema koji su se pojavili.

Književnost

1. Z. Aljehine. ITIL je osnova koncepta upravljanja IT uslugama. "Otvoreni sustavi". 2001, br. 3
2. Z. Aljehin. Service Desk - ciljevi, mogućnosti, implementacija. "Otvoreni sustavi". 2001, broj 5-6
3. CCTA. Najbolja praksa za servisnu podršku. London: The Stationery Office, 2000

Zaurbek Alekhine ([e-mail zaštićen]) - voditelj projekta u i-Teco (Moskva).

Što je incident

Prema ITIL definiciji "incident" znači „svaki događaj koji nije element normalnog funkcioniranja usluge, a istodobno ima ili može utjecati na pružanje usluge prekidajući je ili smanjujući njezinu kvalitetu.“

Prijave:

• usluga nedostupna;
• greška u aplikaciji koja onemogućuje normalan rad klijenta;
• Prostor na disku je potrošen.

Oprema:

• kvar sustava;
• interni alarm;
• kvar pisača.

Zahtjevi za usluge:

• zaprimanje zahtjeva za dodatne informacije, savjete, dokumentaciju;
• zaboravljena lozinka.

Većina IT timova uključena je u rješavanje neke vrste incidenta. Service Desk je odgovoran za praćenje rješavanja svih prijavljenih incidenata, budući da je vlasnik svih takvih incidenata. Ovaj proces je u velikoj mjeri reaktivan; Za učinkovito reagiranje na incidente potrebno je definirati formalni način rada zaposlenika, uključujući korištenje potrebnog softvera.

One incidente koje Service Desk ne može izravno riješiti treba proslijediti odgovarajućim stručnjacima. Metodu za rješavanje incidenta ili zaobilazno rješenje treba uspostaviti i priopćiti korisnicima što je prije moguće. To proizlazi iz glavnog cilja - minimizirati negativan utjecaj na glavne aktivnosti korisnika. Nakon što je uzrok incidenta otklonjen i usluga vraćena na razinu navedenu u SLA, incident se zatvara.

Temeljni uzrok događaja incidenta informacijske sigurnosti je potencijalna sposobnost napadača da stekne nerazumne privilegije za pristup imovini organizacije. Procjena rizika takve prilike i donošenje ispravne odluke o zaštiti glavna je zadaća hitnog tima.

Svaki rizik mora imati prioritet i tretirati ga u skladu s politikom procjene rizika organizacije. Procjena rizika smatra se stalnim procesom, čija je svrha postizanje prihvatljive razine zaštite, drugim riječima, potrebno je poduzeti dostatne mjere za zaštitu imovine od nerazumne ili neovlaštene uporabe. Procjena rizika doprinosi klasifikaciji imovine. U velikoj većini slučajeva, imovina koja je kritična s gledišta rizika također je ključna za poslovanje organizacije.

Stručnjaci timova za odgovor analiziraju prijetnje i pomažu u održavanju ažurnim model uljeza koji je usvojila služba za informacijsku sigurnost organizacije.

Kako bi tim za odgovor na nesreću radio učinkovito, organizacija mora imati uspostavljene procedure za opisivanje procesa funkcioniranja jedinica. Posebnu pozornost treba posvetiti popunjavanju baze dokumenata službe informacijske sigurnosti.

Detekcija i analiza incidenata informacijske sigurnosti

Incidenti informacijske sigurnosti mogu imati različite izvore podrijetla. U idealnom slučaju, organizacija bi trebala biti spremna za bilo kakvu manifestaciju zlonamjerne aktivnosti. U praksi to nije izvedivo.

Funkcija odgovora mora klasificirati i opisati svaki incident koji se dogodi u organizaciji, kao i klasificirati i opisati moguće incidente koji su pretpostavljeni na temelju analize rizika.

Za proširenje tezaurusa o mogućim prijetnjama i mogućim incidentima povezanim s njima, dobra je praksa koristiti otvorene izvore na Internetu koji se stalno ažuriraju.

Znakovi incidenta informacijske sigurnosti

Pretpostavka da se u organizaciji dogodio incident informacijske sigurnosti trebala bi se temeljiti na tri glavna čimbenika:

• poruke o incidentima informacijske sigurnosti primaju se istovremeno iz nekoliko izvora (korisnici, IDS, log datoteke)
• IDS signal višestrukog ponavljanja događaja
• Analiza log datoteka automatiziranog sustava daje osnovu administratorima sustava za zaključak da bi se incidentni događaj mogao dogoditi.

Općenito, znakovi incidenta spadaju u dvije glavne kategorije, izvješća da se incident trenutno događa i izvješća da bi se incident mogao dogoditi u bliskoj budućnosti. Sljedeći su neki znakovi koji ukazuju na događaj:

• IDS otkriva prekoračenje međuspremnika
• obavijest antivirusnog programa
• Pad WEB sučelja
• Korisnici izvješćuju o iznimno malim brzinama kada pokušavaju pristupiti internetu
• administrator sustava otkriva prisutnost datoteka s nečitljivim nazivima
• Korisnici prijavljuju mnogo dupliciranih poruka u svojim pretincima
• host piše u dnevnik revizije o promjeni konfiguracije
• aplikacija bilježi više neuspjelih pokušaja autorizacije u log datoteku
• mrežni administrator otkrije nagli porast mrežnog prometa itd.

Primjeri događaja koji mogu poslužiti kao izvori informacijske sigurnosti uključuju:

• datoteke zapisnika poslužitelja bilježe skeniranje portova
• najava u medijima o pojavi nove vrste exploita
• otvorena izjava računalnih kriminalaca koji objavljuju rat vašoj organizaciji, itd.

Analiza incidenata informacijske sigurnosti

Incident nije očita svršena stvar, naprotiv, napadači se trude učiniti sve da ne ostave tragove svojih aktivnosti u sustavu. Znakovi incidenta uključuju manju promjenu u konfiguracijskoj datoteci poslužitelja ili, na prvi pogled, standardnu ​​pritužbu korisnika e-pošte. Donošenje odluke o nastanku incidentnog događaja uvelike ovisi o osposobljenosti stručnjaka interventnog tima. Potrebno je razlikovati slučajnu pogrešku operatera od zlonamjernog, ciljanog utjecaja na informacijski sustav. Činjenica da se s informacijskim sigurnosnim incidentom postupa "bezvezno" također je informacijski sigurnosni incident, budući da odvlači stručnjake iz hitnog tima od hitnih problema. Rukovodstvo organizacije treba obratiti pozornost na ovu okolnost i omogućiti stručnjacima tima za hitne intervencije određenu slobodu djelovanja.

Kompilacija dijagnostičkih matrica služi za vizualizaciju rezultata analize događaja koji se odvijaju u informacijskom sustavu. Matrica se formira od redaka potencijalnih znakova incidenta i stupaca vrsta incidenta. Presjek daje ocjenu događaja na ljestvici prioriteta „visok“, „srednji“, „nizak“. Dijagnostička matrica je dizajnirana da dokumentira tijek logičnih zaključaka stručnjaka u procesu donošenja odluka i, zajedno s drugim dokumentima, služi kao dokaz istrage incidenta.

Dokumentiranje incidenta informacijske sigurnosti

Dokumentiranje događaja incidenta informacijske sigurnosti potrebno je za prikupljanje i naknadnu konsolidaciju istražnih dokaza. Sve činjenice i dokazi zlonamjernog utjecaja moraju biti dokumentirani. Pravi se razlika između tehnoloških dokaza i operativnih dokaza utjecaja. Tehnološki dokazi uključuju informacije dobivene tehničkim sredstvima za prikupljanje i analizu podataka (sniferi, IDS); operativni dokazi uključuju podatke ili dokaze prikupljene tijekom ankete osoblja, dokaze o pozivima servisnom pultu, pozivima pozivnom centru.

Tipična praksa je vođenje dnevnika istrage incidenta, koji nema standardni obrazac i razvija ga tim za odgovor. Ključne pozicije takvih časopisa mogu biti:

• trenutni status istrage
• opis incidenta
• radnje koje provodi ekipa za odgovor tijekom obrade incidenta
• popis sudionika istrage s opisom njihovih funkcija i postotkom zaposlenosti u istražnom postupku
• popis dokaza (uz obvezno navođenje izvora) prikupljenih tijekom obrade incidenta