Cadrul legislativ al Federației Ruse. Managementul incidentelor și problemelor

Există două concepte în dicționarul ITSM care creează adesea confuzie în rândul profesioniștilor IT și utilizatorilor: incident și problemă. Ambele sunt asociate cu procesul de rezolvare a unei defecțiuni care a apărut și sunt înregistrate prin crearea unui bilet în sistemul Service Desk. Cu toate acestea, în esență, sunt destul de diferiți unul de celălalt și au soluții diferite. Să ne uităm la un exemplu care explică pur și simplu diferența dintre aceste concepte.

Fierbătorul este defect!

Dimineaţă. La micul dejun, decideți să vă pregătiți o ceașcă de ceai tare pentru a vă înveseli înainte de ziua de muncă. Turnați apă în ibric, îl conectați, dați comutatorul, dar nu se aprinde. Întoarceți întrerupătorul din nou și din nou, verificați dacă există electricitate în casă, conectați fierbătorul la o altă priză, dar tot nu funcționează. A avut loc un INCIDENT!

Ești dezamăgit și furios. Nu știi de ce fierbătorul nu funcționează, dar totuși vrei cu adevărat să bei ceai. Înțelegeți că puteți fierbe apa în diferite moduri: încălziți apă clocotită într-o filtru de cafea, puneți o cratiță cu apă pe gaz, scoateți un cazan de tabără din cămară - toate acestea sunt modalități de a vă atinge obiectivul. Într-un fel, apa este încălzită, ceaiul este preparat și turnat într-o cană - incidentul s-a încheiat, ați folosit o soluție pentru a finaliza sarcina.

Acum, în fiecare dimineață, vei folosi una dintre metodele enumerate pentru a încălzi apa până când vei găsi timp să mergi la un atelier, astfel încât un electrician să rezolve PROBLEMA care face ca fierbătorul să nu funcționeze. Problema este motivul pentru care fierbătorul se defectează. Electricianul va descoperi că siguranța s-a ars din cauza unei supratensiuni, va înlocui siguranța și veți putea fierbe din nou apă în ibric - problemă rezolvată.

Ce legătură are un ceainic cu IT?

Dacă în infrastructura IT apar incidente repetate, atunci este necesar să se afle cauza principală a apariției lor. Dacă profesioniștii IT clasifică incidentele care apar și analizează ce le determină să se repete, ei pot ajunge la fundul problemei care le provoacă să apară. Remedierea problemei eliberează timp și resurse ale departamentului IT pentru a face față altor incidente, mai degrabă decât „încălzirea apei cu un cazan în fiecare dimineață în loc să repari ibricul”.

Este simplu, dar foarte eficient!

Introducerea unui proces de management al problemelor vă permite să schimbați abordarea de rezolvare a incidentelor de la reactiv la proactiv. Aceasta înseamnă că IT începe nu numai să elimine incidentele și să se ocupe de cauza apariției acestora, dar și să ia măsuri pentru a se asigura că acestea nici măcar nu apar. Odată rezolvate toate incidentele și problemele care duc la acestea, specialiștii IT au timp să caute blocaje în infrastructură care încă nu se manifestă. O bună organizare a managementului incidentelor, priorităților și clasificării creează un efect de lanț pentru îmbunătățirea activității altor domenii IT ale companiei.

E timpul să bei un ceai delicios și să verifici siguranțele din alte aparate electrocasnice!

dimensiunea fontului

STANDARD NAȚIONAL AL ​​FEDERAȚIA RUSĂ - TEHNOLOGIA INFORMAȚIEI - METODE ȘI MIJLOACE DE SECURITATE - MANAGEMENT... Relevant în 2018

6 Exemple de incidente de securitate a informațiilor și cauzele acestora

Incidentele de securitate a informațiilor pot fi intenționate sau accidentale (de exemplu, rezultatul unor erori umane sau fenomene naturale) și cauzate atât de mijloace tehnice, cât și non-tehnice. Consecințele acestora pot include evenimente precum dezvăluirea sau modificarea neautorizată a informațiilor, distrugerea acestora sau alte evenimente care le fac inaccesibile, precum și deteriorarea sau furtul bunurilor organizației. Incidentele de securitate a informațiilor care nu au fost raportate dar au fost identificate ca incidente nu pot fi investigate și nu pot fi aplicate măsuri de protecție pentru a preveni reapariția acestor incidente.

Mai jos sunt câteva exemple de incidente de securitate a informațiilor și cauzele acestora, care sunt furnizate doar în scop de clarificare. Este important de menționat că aceste exemple nu sunt exhaustive.

6.1 Refuzarea serviciului

Refuzarea serviciului este o categorie largă de incidente de securitate a informațiilor care au un lucru în comun.

Astfel de incidente de securitate a informațiilor duc la incapacitatea sistemelor, serviciilor sau rețelelor de a continua să funcționeze cu aceeași performanță, cel mai adesea cu refuzul complet de acces utilizatorilor autorizați.

Există două tipuri principale de incidente de securitate a informațiilor asociate cu refuzul serviciului cauzate de mijloace tehnice: distrugerea resurselor și epuizarea resurselor.

Câteva exemple tipice de astfel de incidente intenționate de „refuzare a serviciului” de securitate a informațiilor tehnice sunt:

Verificarea adreselor de difuzare a rețelei pentru a umple complet lățimea de bandă a rețelei cu trafic de mesaje de răspuns;

Transmiterea de date într-un format neintenționat către un sistem, serviciu sau rețea în încercarea de a perturba sau perturba funcționarea normală a acestuia;

Deschiderea simultană a mai multor sesiuni către un anumit sistem, serviciu sau rețea în încercarea de a-și epuiza resursele (adică, încetinirea acestuia, blocarea sau distrugerea acestuia).

Unele incidente de „denegare a serviciului” de securitate a informațiilor tehnice pot apărea accidental, de exemplu, ca urmare a unei erori de configurare făcută de un operator sau din cauza incompatibilității software-ului aplicației, în timp ce altele pot fi intenționate. Unele incidente tehnice de securitate a informațiilor „denial of service” sunt inițiate intenționat cu scopul de a distruge un sistem, un serviciu și de a reduce performanța rețelei, în timp ce altele sunt doar produse secundare ale altor activități rău intenționate.

De exemplu, unele dintre cele mai comune metode secrete de scanare și identificare pot duce la distrugerea completă a sistemelor sau serviciilor vechi sau configurate greșit atunci când sunt scanate. Trebuie remarcat faptul că multe incidente tehnice intenționate de refuzare a serviciului sunt adesea inițiate anonim (adică sursa atacului este necunoscută), deoarece atacatorul nu cunoaște de obicei rețeaua sau sistemul atacat.

Incidentele IS „denegarea serviciului” create prin mijloace non-tehnice și care conduc la pierderea de informații, servicii și (sau) dispozitive de procesare a informațiilor pot fi cauzate, de exemplu, de următorii factori:

Încălcări ale sistemelor de securitate fizică care conduc la furt, deteriorarea intenționată sau distrugerea echipamentelor;

Deteriorarea accidentală a echipamentului și (sau) a locației acestuia din cauza incendiului sau apei/inundații;

Condiții de mediu extreme, cum ar fi temperaturi ridicate (din cauza defecțiunii sistemului de aer condiționat);

Funcționare incorectă sau suprasarcină a sistemului;

Schimbări necontrolate în sistem;

Funcționarea incorectă a software-ului sau hardware-ului.

6.2 Colectarea informațiilor

În termeni generali, incidentele de securitate a informațiilor „colectarea informațiilor” implică acțiuni legate de identificarea potențialelor ținte de atac și obținerea unei înțelegeri a serviciilor care rulează pe țintele de atac identificate. Astfel de incidente de securitate a informațiilor necesită recunoaștere pentru a determina:

Prezența unei ținte, obținerea unei înțelegeri a topologiei rețelei care o înconjoară și cu care această țintă este de obicei conectată prin schimbul de informații;

Potențiale vulnerabilități ale țintei sau ale mediului de rețea înconjurător imediat care pot fi exploatate pentru atac.

Exemple tipice de atacuri care vizează colectarea de informații prin mijloace tehnice sunt:

Resetarea înregistrărilor DNS (Domain Name System) pentru domeniul Internet țintă (transfer zonă DNS);

Trimiterea cererilor de testare către adrese aleatoare ale rețelei pentru a găsi sisteme de lucru;

Sondarea sistemului pentru a identifica (de exemplu, prin suma de verificare a fișierelor) sistemul de operare gazdă;

Scanarea porturilor de rețea disponibile pentru sistemul de protocol de transfer de fișiere pentru a identifica serviciile corespunzătoare (de exemplu, e-mail, FTP, rețea etc.) și versiunile software ale acestor servicii;

Scanarea unuia sau mai multor servicii cu vulnerabilități cunoscute într-o serie de adrese de rețea (scanare orizontală).

În unele cazuri, colectarea de informații tehnice se extinde în acces neautorizat, dacă, de exemplu, un atacator încearcă să obțină acces neautorizat în timp ce caută o vulnerabilitate. Acest lucru este realizat de obicei de instrumente automate de hacking care nu numai că caută vulnerabilități, ci și încearcă automat să exploateze sistemele, serviciile și (sau) rețelele vulnerabile.

Incidentele de strângere de informații create prin mijloace non-tehnice au ca rezultat:

Dezvăluirea sau modificarea directă sau indirectă a informațiilor;

Furt de proprietate intelectuală stocată în formă electronică;

Încălcarea înregistrărilor, de exemplu, la înregistrarea conturilor;

Utilizarea greșită a sistemelor de informații (de exemplu, cu încălcarea legii sau a politicii organizaționale).

Incidentele pot fi cauzate, de exemplu, de următorii factori:

Încălcări ale protecției securității fizice care conduc la acces neautorizat la informații și furtul dispozitivelor de stocare care conțin date sensibile, cum ar fi cheile de criptare;

Sisteme de operare prost și/sau configurate greșit din cauza modificărilor necontrolate ale sistemului sau a software-ului sau hardware defectuos, care au ca rezultat accesarea informațiilor fără autorizare de către personalul organizațional sau personalul neautorizat.

6.3 Acces neautorizat

Accesul neautorizat ca tip de incident include incidente care nu sunt incluse în primele două tipuri. În principal, acest tip de incident constă în încercări neautorizate de a accesa un sistem sau în utilizarea greșită a unui sistem, serviciu sau rețea. Câteva exemple de acces neautorizat prin mijloace tehnice includ:

Încercări de extragere a fișierelor cu parole;

Atacurile de depășire a tamponului pentru a obține acces privilegiat (de exemplu, la nivel de administrator de sistem) la rețea;

Exploatarea vulnerabilităților protocolului pentru a intercepta conexiuni sau a direcționa greșit conexiunile de rețea legitime;

Încercările de a crește privilegiile de acces la resurse sau informații dincolo de cele deținute în mod legitim de un utilizator sau administrator.

Incidentele de acces neautorizat create prin mijloace netehnice care au ca rezultat dezvăluirea sau modificarea directă sau indirectă a informațiilor, încălcări ale contabilității sau utilizarea greșită a sistemelor de informații pot fi cauzate de următorii factori:

Distrugerea dispozitivelor de protecție fizică cu acces ulterior neautorizat la informații;

Configurare nereușită și/sau incorectă a sistemului de operare din cauza modificărilor necontrolate ale sistemului sau a disfuncționalității software-ului sau hardware-ului care conduc la rezultate similare cu cele descrise în ultimul paragraf al 6.2.

Exemple de accidente și incidente aviatice.

Au fost mai multe incidente și accidente la nivel înalt din cauza factorilor umani. Site-ul de internet Factori umani în întreținerea și inspecția aviației (HFAMI) conține 24 de rapoarte NTSB despre incidente care implică factori umani. Au fost mai multe accidente și incidente în Marea Britanie. Detalii despre acestea sunt conținute pe site-ul AAIB. Unele dintre aceste incidente sunt enumerate mai jos:

• Incident cu Boeing 737 (zborul Aloha 243), Maui, Hawaii, aprilie 1988;
• Incident BAC 1-11, G-BJRT (zborul British Airways 5390), Didcot, Oxfordshire, 10 iunie 1990.
• Incident A-320, G-KMAM pe aeroportul Londra Gatwick la 26 august 1993;
• Incident cu Boeing 737, G-OBMM lângă Davintree 23 februarie 1995.

Incidentul care a avut loc pe zborul Aloha 243 în aprilie 1988 a implicat smulgerea a 18 picioare din pielea superioară a cabinei în timpul zborului. Aeronava a fost verificată înainte de zbor conform cerințelor SUA de către doi inspectori de aviație. Un inspector avea 22 de ani de experiență, iar al doilea, cel mai mare, avea 33 de ani de experiență. Niciunul nu a găsit fisuri în timpul inspecției. Testele post-incident au evidențiat peste 240 de fisuri în pielea aeronavei la momentul inspecției. Ca urmare a acestui fapt, au fost identificate multe probleme legate de factorii umani care conduc la inspecții inadecvate.

Ca urmare a incidentului Aloha Flight, Statele Unite au dezvoltat un program de cercetare a factorilor umani, cu accent pe inspecții.

10 iunie 1990 În Marea Britanie, BAC 1-11 (zborul British Airways 5390) a decolat de pe aeroportul din Birmingham. După ce a urcat la 17.300 de picioare, parbrizul din stânga a fost apăsat spre exterior în carlingă. Acest sticla a fost inlocuita inainte de zbor. S-a dovedit că din 90 de șuruburi de fixare, 84 aveau un diametru mai mic decât era necesar. Căpitanul navei a fost scos pe jumătate din cockpit printr-o deschidere a ferestrei și ținut de membrii echipajului până când copilotul a aterizat în siguranță pe aeroportul Southampton.

Directorul de tură (SMM), din cauza lipsei de personal în timpul schimbului de noapte, a decis să înlocuiască el însuși parbrizul. S-a uitat la Instrucțiuni (MM) și a concluzionat că era o treabă simplă. A decis să înlocuiască șuruburile de montare și a luat unul ca probă (7D)

a început să aleagă pe alții pentru a le înlocui. Depozitarul i-a spus că înlocuirea necesită șuruburi (8D), dar din cauza lipsei acestora în depozit, șeful de tură a decis că șuruburile (7D) ar fi bine. (De vreme ce au stat pe loc înainte). Cu toate acestea, a comparat și a atins vizual șuruburile și a selectat din greșeală șuruburile 8C, care sunt mai lungi și mai subțiri. De asemenea, nu a observat că în timpul instalării, locașul pentru capul șurubului (confundat) era mai adânc decât era necesar. A făcut singur munca și a semnat certificatul de eliberare. Procedura nu a necesitat o examinare aprofundată sau secundară. Mai mulți factori umani au fost implicați în acest incident, inclusiv dimensionarea incorectă a șuruburilor de către șeful de tură, iluminarea slabă în depozit, lipsa purtării ochelarilor, practicile de lucru și posibilii factori de proiectare și management al muncii.

Un avion A-320 în Marea Britanie în august 1993. La primul zbor după înlocuirea clapei, a existat o stagnare ascuțită la dreapta imediat după decolare. Avionul s-a întors la Gatwick și a aterizat în siguranță. Ancheta a scos la iveala ca in timpul intretinerii, pentru inlocuirea clapei drepte, spoilerele au fost puse in regim de intretinere si mutate in timp ce procedura era incompleta; în consecință, flanșele și steagurile nu au fost instalate. Scopul flanșelor și spoilerelor nu a fost bine înțeles de ingineri.

Această neînțelegere a fost cauzată parțial de familiaritatea și familiaritatea cu aeronava celuilalt

tip (Boeing 757) și a fost exprimat în indicarea insuficientă a stării spoilerelor în timpul preluării schimburilor. Spoilerul blocat nu a fost descoperit în timpul verificărilor de rutină ale pilotului.

În februarie 1995 Pe un avion Boeing 757-400, a fost detectată o pierdere de presiune a uleiului la ambele motoare. Avionul s-a întors și a aterizat în siguranță pe aeroportul Luton. Ancheta a scos la iveală că aeronava a fost supusă unei examinări boroscopice a ambelor motoare în noaptea precedentă și că carcasele de antrenare a rotorului de înaltă presiune nu au fost instalate după finalizarea lucrărilor. Ca urmare, aproape tot uleiul de la ambele motoare s-a pierdut în timpul zborului. Inginerul de întreținere de linie a fost programat inițial să facă această lucrare, dar din diverse motive, el a delegat jobul supervizorului de întreținere de bază. Controlorul nu avea documentele necesare pentru lucrul cu el. Inspectorul și mecanicul au finalizat lucrările, în ciuda numeroaselor întreruperi, dar nu au montat carcasele rotorului. Motoarele nu au fost testate la sol la ralanti pentru a detecta scurgerile de ulei. Lucrarea a fost raportată ca finalizată.

În toate cele trei incidente din Marea Britanie, inginerii implicați în întreținere au fost evaluați de companii ca fiind foarte calificați, competenți și de încredere. Toate incidentele au fost caracterizate astfel:

• nu era suficient personal;
• a existat presiunea timpului;
• Toate erorile au avut loc noaptea;
• Au fost efectuate preluări de ture;
• Toate persoanele implicate au efectuat sarcini manuale lungi;
• A existat un element al atitudinii „Pot înseamnă că fac”;
• Au fost pauze în muncă;
• Nu s-au folosit informații sau proceduri verificate;
• Instrucțiunile erau inconsecvente;
• S-au efectuat pre-planificare insuficientă, echipamente și piese de schimb.

Incidente și accidente - Încălcări ale factorilor umani.

În toate exemplele de mai sus, accidentele sau incidentele ar fi putut fi prevenite dacă unul dintre multele lucruri ar fi fost făcut diferit. În unele cazuri, când sunt implicați mai mulți lucrători, rezultatul muncii lor poate fi îmbunătățit dacă unul dintre ei a răspuns corect sau a întrebat despre o anumită acțiune. În orice situație dată, totuși, lucrătorii nu reușesc să recunoască și să răspundă la semnele de pericol potențial, nu reușesc să răspundă conform așteptărilor sau nu se lasă distrași de mâinile lor, lăsându-se deschiși să comită o greșeală.

Ca și în cazul multor alte incidente și accidente, exemplele citate mai sus implică o serie de probleme ale factorilor umani care se modelează lanț de erori(Vezi fig. 3). Dacă o verigă din acest lanț este ruptă prin luarea de măsuri care pot preveni problema la una sau mai multe etape ale dezvoltării sale, incidentul poate fi prevenit.

Fig 3. Lanț de eroare.

Pr Procesele de management al incidentelor și managementul problemelor sunt similare în multe privințe, dar au și diferențe semnificative. Vom descrie fiecare dintre procese separat, apoi le vom compara din puncte de vedere diferite, discutând despre metodele de implementare.

Managementul incidentelor

Scopul principal al procesului de management al incidentelor este de a restabili funcționalitatea normală a sistemului cât mai repede posibil și de a minimiza impactul negativ asupra afacerii care utilizează serviciile care au fost întrerupte. „Funcționarea normală a serviciilor” înseamnă funcționarea în conformitate cu acordul de nivel de servicii (SLA).

Incidentele nu pot include evenimente care nu au legătură cu calitatea serviciilor IT furnizate, precum și cele care, deși reduc această calitate, nu depășesc domeniul de aplicare specificat în SLA. Un loc aparte îl ocupă cazurile în care clientul nu a simțit prezența unui incident (de exemplu, dacă toate măsurile necesare au fost luate automat sau de către personalul de service chiar înainte ca calitatea să scadă efectiv). Exemple: arhivarea automată a datelor și eliberarea discului scratch atunci când acesta se apropie de punctul de overflow; trecerea la un server de rezervă dacă cel principal eșuează etc. Cu toate acestea, astfel de cazuri nu pot fi excluse din lista incidentelor. Organizarea adecvată necesită gestionarea acestor incidente în conformitate cu procedura completă (adică, afișarea lor ulterioară în rapoarte și luarea măsurilor necesare pentru a le preveni în viitor).

Fiecare proces de management al incidentelor poate fi descris în mod formal prin enumerarea unui set de caracteristici.

Datele de intrare pentru descrierea incidentelor sunt:

• o descriere detaliată a incidentului primit de la Service Desk, servicii de asigurare a funcționării operaționale a rețelelor sau serverelor etc.;
• descrierea configurațiilor și elementelor eventual legate de incident. Descrierile sunt preluate din CMDB, o bază de date de unități de configurare care include toate elementele infrastructurii IT (hardware, software, documentație, servicii furnizate etc.);
• informații (dacă sunt disponibile) din baza de date cu probleme și din baza de date a erorilor cunoscute;
• descrierea metodei de rezoluție.

Rezultatul procesului de management al incidentelor ar putea fi:

• o cerere de modificări temporare pentru a rezolva incidentul, o înregistrare actualizată a incidentului, inclusiv o soluție și/sau o soluție;
• incident rezolvat (rezolvat) și închis;
• mesaj către client;
• informatii de management (raport).

Activități posibile de gestionare a incidentelor:

• identificarea și înregistrarea unui incident;
• clasificarea incidentelor si asistenta initiala;
• cercetare și diagnosticare;
• rezolvarea incidentelor și recuperarea sistemului;
• închiderea incidentului;
• proprietate, monitorizare, urmărire și interacțiune.

Roluri și funcții de gestionare a incidentelor:

• echipele de suport din prima, a doua și a treia linie, precum și echipele de specialitate și partenerii externi (roluri); manager de management al incidentelor (rol); Manager Service Desk (funcție).

Valori posibile:

• numărul total de incidente;
• timpul mediu pentru rezolvarea sau ocolirea unui incident pentru diferite tipuri de incidente;
• procentul de incidente rezolvate într-o perioadă de timp care nu depășește cea specificată în SLA;
• costul mediu de rezolvare a unui incident;
• procentul de incidente închise fără implicarea altor specialiști;
• numărul și procentul de incidente rezolvate de la distanță (fără a vizita utilizatorul).

Pentru a asigura respectarea intervalului de timp alocat pentru implementarea anumitor acțiuni, se utilizează escaladarea funcțională și ierarhică. „Escaladare” se referă la un mecanism organizațional care ajută la controlul timpului de rezolvare a unui incident; ar trebui să fie utilizat în toate activitățile din timpul procesului de rezolvare a incidentelor. Esența acestuia constă în necesitatea fie de a transfera obligatoriu informații despre incident către specialiști mai calificați, fie de a informa conducerea despre imposibilitatea eliminării incidentului în intervalul de timp convenit.

Transferul unui incident de la Service Desk pe o a doua linie de suport (escaladare funcțională) este necesară dacă este imposibil de rezolvat incidentul pe prima linie. Este posibilă escaladarea funcțională automată, dar trebuie planificată cu atenție în conformitate cu SLA.

Escaladarea ierarhică este necesară atunci când este imposibil de rezolvat incidentul fie în timpul alocat, fie cu calitatea cerută. De regulă, este efectuat manual de către personalul Service Desk, în funcție de experiența acestora. Se folosește și escaladarea ierarhică automată și poate fi construită pe baza ținând cont de intervale de timp. Este recomandabil ca acesta să fie efectuat înainte de ora specificată în SLA; aceasta va oferi managerului relevant oportunitatea de a lua măsuri suplimentare.

Efectul implementării unui proces de management al incidentelor

Să enumeram cele mai importante calități utile care sunt dobândite ca urmare a implementării procesului de management al incidentelor. Pentru afaceri în general, acesta este:

• reducerea impactului negativ asupra afacerii al incidentelor, realizată prin creșterea eficienței și reducerea timpului necesar pentru rezolvarea acestora;
• determinarea proactivă (anticipativă) a necesității extinderii și corectării sistemelor critice pentru afaceri;
• Disponibilitatea informațiilor de management necesare afacerii, corelate cu condițiile SLA.

Munca departamentului IT dobândește și o serie de calități utile:

• monitorizare avansată pentru a măsura performanța față de SLA;
• informații îmbunătățite pentru managementul calității serviciilor;
• utilizarea mai optimă a personalului și munca mai eficientă;
• eliminarea pierderilor și înregistrarea incorectă a incidentelor și solicitărilor;
• întreținerea mai precisă a bazei de date a unității de configurare CMDB;
• o mai bună satisfacție a clienților.

Lucrul fără un sistem de management al incidentelor poate duce la o serie de probleme. Absența persoanelor responsabile pentru rezolvarea și escaladarea incidentelor duce la confuzie în rezolvarea defecțiunilor și reduce calitatea serviciului. Specialiștii serviciilor de asistență sunt distrași de la sarcinile lor, ceea ce reduce eficiența muncii lor. Pentru a rezolva incidente și probleme, utilizatorii sunt forțați să comunice între ei, distrași de la principalele lor responsabilități. De fiecare dată trebuie să reanalizezi incidente – chiar și cele care apar în mod regulat și ar trebui cunoscute.

Managementul problemelor

Scopul principal al procesului de management al problemelor este de a minimiza impactul negativ asupra activității de bază a organizației al incidentelor și problemelor rezultate din erorile din infrastructura IT și de a preveni reapariția incidentelor asociate cu aceste erori. Pentru a face acest lucru, se caută și se clarifică cauzele incidentelor și se întreprind acțiuni pentru îmbunătățirea situației sau eliminarea cauzelor identificate.

Procesul de management al problemelor este atât reactiv, cât și proactiv. Prima opțiune se referă la rezolvarea problemelor asociate cu incidentele apărute, a doua are ca scop identificarea și eliminarea problemelor care ar putea duce la, dar nu au condus încă la, incidente.

Controlul problemelor și erorilor, împreună cu managementul proactiv al problemelor, sunt responsabilitățile procesului de management al problemelor. În limbajul definițiilor formale, o „problemă” este o cauză principală necunoscută a unuia sau mai multor incidente, iar o „eroare cunoscută” este o problemă diagnosticată cu succes pentru care a fost găsită o soluție sau o soluție.

În ceea ce privește procesul de management al incidentelor, prezentăm grupuri de caracteristici principale ale procesului de management al problemelor. Deși unele dintre ele sunt aceleași, este logic să le enumeram pe toate deoarece vorbim despre procese diferite.

Datele de intrare pentru descriere sunt:

• detalii despre incident derivate din gestionarea incidentelor;
• descrierea detaliată a configurațiilor din CMDB;
• toate soluțiile cunoscute (de la gestionarea incidentelor).

Evenimente posibile:

• controlul problemelor și erorilor;
• prevenirea proactivă a problemelor;
• identificarea tendințelor;
• analiza informatiilor acumulate si intocmirea rapoartelor;
• pregătirea informațiilor de management.

Rezultatele pot fi după cum urmează:

• descrierea noilor erori cunoscute;
• cereri de modificare;
• un jurnal de probleme actualizat, inclusiv o posibilă soluție la problemă și/sau orice soluție disponibilă;
• pentru problemele rezolvate, jurnalul de probleme închis;
• căutarea de analogi ai incidentului printre erorile cunoscute și problemele luate în considerare;
• informatii de management.

Roluri și funcții: angajați responsabili cu gestionarea problemelor (rolurilor); Manager de management al problemelor (rol).

Valori posibile:

• numărul de solicitări de modificare inițiate și impactul acestor solicitări asupra fiabilității și disponibilității serviciilor pe care le acoperă;
• timpul alocat lucrărilor de cercetare și diagnosticare pentru fiecare departament, ținând cont de împărțirea în tipuri de probleme;
• numărul și impactul incidentelor care au avut loc înainte de identificarea cauzei problemei sau înainte de raportarea unei erori cunoscute;
• raportul dintre volumul eforturilor pentru asistență și sprijin imediat și cele planificate;
• numărul de probleme și erori grupate după diverse criterii (stare, servicii, impact, categorii, grupuri de utilizatori);
• timpul mediu și maxim petrecut pentru închiderea unei probleme sau reconcilierea unei probleme cunoscute, calculat din momentul în care problema a fost raportată, grupate pe coduri de impact și grupuri de suport;
• timpul estimat pentru rezolvarea problemelor deschise;
• timpul total petrecut cu toate problemele închise.

Efectul implementării unui proces de management al problemelor

Să enumeram cele mai importante calități utile care sunt dobândite ca urmare a implementării procesului de management al problemelor.

• Calitatea serviciilor. Managementul problemelor ajută la menținerea unui ciclu continuu de îmbunătățire continuă a calității serviciilor IT.
• Reducerea numărului de incidente. Procesul de management al problemelor este un instrument de reducere a numărului de incidente care au loc și care au un impact negativ asupra afacerii unei organizații.
• Soluție continuă. Ca rezultat al procesului, numărul și impactul asupra afacerii problemelor deja rezolvate și erorilor cunoscute sunt reduse.
• Pregătire avansată. Procesul se bazează pe conceptul de utilizare a cunoștințelor acumulate din trecut și oferă oportunități de a analiza tendințele și de a preveni întreruperile sau de a reduce semnificația și impactul acestora asupra activității de bază.
• Creșterea numărului de incidente rezolvate la primul apel. Acest lucru se realizează prin furnizarea Biroului de service cu recomandări cu privire la modul de prevenire și rezolvare a incidentelor care apar.

La rândul său, refuzul de a implementa procesul promite o serie de probleme. Serviciul de asistență pur „ex-post” începe să funcționeze numai atunci când serviciul nu mai este disponibil. Se dezvoltă o infrastructură care impune utilizatorilor să folosească instrumentele IT în mod independent. Echipele de suport ineficiente, costisitoare și slab motivate rezolvă aceleași probleme din nou și din nou, fără a ține cont de experiența anterioară.

Implementare și implementare

Am atras deja atenția asupra principalei diferențe dintre procesele luate în considerare, care a fost luată în considerare la formarea unor indicatori cheie de calitate. Scopul managementului incidentelor este de a rezolva incidentele cât mai repede posibil. Managementul problemelor ar trebui să excludă posibilitatea reapariției unui incident din aceleași motive (și uneori din aceleași motive).

Din punct de vedere organizatoric, aceasta înseamnă că nimeni nu poate îndeplini responsabilități pentru ambele procese în același timp, deoarece nu ar fi capabil să prioritizeze corect. Ca o cale de ieșire din situația cu personalul tradițional limitat, se recomandă definirea clară în instrucțiuni a unui timp sau alt cadru care să permită unui specialist să îndeplinească clar un rol doar într-unul dintre procese. De exemplu, un angajat al serviciului de operare a rețelei al băncii, în perioadele critice pentru efectuarea plăților majore, este obligat, dacă apar eșecuri, să ia toate măsurile pentru a elimina aceste defecțiuni cât mai repede posibil și a restabili funcționalitatea sistemelor, jucând rolul unui specialist în managementul incidentelor. În momente relativ mai puțin critice, acestui specialist îi este interzis să răspundă la incidente emergente și este instruit să analizeze informațiile acumulate despre defecțiuni și să caute cauzele acestora și, prin urmare, să ia măsuri de gestionare a problemelor.

Este acceptabil (și recomandat) să combinați funcțiile Service Desk și funcțiile de gestionare a incidentelor. Cu toate acestea, este important să ne amintim că acestea sunt procese diferite: comunicarea inițială cu utilizatorii nu face parte din procesul de management al incidentelor. În plus, utilizatorul poate contacta serviciul de asistență nu numai în legătură cu un incident, ci și dintr-un alt motiv (nevoie de informare, nevoie de reîncărcare consumabile etc.). Pe de altă parte, cu unele metode de implementare (de exemplu, în cazul construirii unui serviciu de asistență bazat pe tehnologii Web, când utilizatorul introduce în mod independent toate datele necesare în formulare), necesitatea unui Service Desk dedicat este discutabilă. În același timp, în niciun caz nu trebuie să refuzi gestionarea incidentelor - indiferent de unde vine mesajul despre apariția lor, cineva trebuie să fie responsabil pentru eliminarea lor.

Este clar că implementarea managementului problemelor în absența managementului incidentelor este practic imposibilă: baza și sursa datelor pentru luarea în considerare a problemei o constituie informațiile acumulate în timpul analizei și procesării incidentelor. Uneori este acceptabil să se implementeze doar managementul incidentelor. De obicei, companiile intermediare nu au probleme de management - având propriul serviciu de expediere, astfel de companii organizează recepția și înregistrarea cererilor clienților, îi ajută, dacă este posibil, să rezolve incidentul cu ajutorul consultării, transferă cereri mai complexe către subcontractanți și controlează. acțiunile lor, implementând astfel managementul incidentelor. În același timp, ei nu analizează problemele, deoarece nu sunt organizația efectivă de funcționare. Gestionarea problemelor este adesea exclusă chiar dacă nu există nicio oportunitate sau dorință de a face acest lucru. În unele cazuri, se recomandă chiar implicarea unor specialiști externi pentru a analiza problemele, deoarece acest lucru necesită calificări foarte înalte, precum și echipamente scumpe. Un exemplu sunt contactele tradiționale cu companii specializate în construcția și întreținerea telecomunicațiilor pentru a determina sarcina reală a rețelelor de date: echipamentul corespunzător este scump, iar necesitatea utilizării acestuia apare extrem de rar.

Pentru instrumentele de automatizare, ITIL recomandă, cel puțin, capabilități de integrare profundă între instrumentele de gestionare a problemelor și incidentelor. Într-adevăr, atunci când se analizează probleme, este important să se poată analiza toate incidentele raportate din perspective diferite. La rândul lor, pentru a comunica mai eficient cu utilizatorii atunci când apar noi incidente, specialiștii relevanți au nevoie de acces la problemele în așteptare sau deja închise și la erorile cunoscute.

Acest lucru poate fi ușor de înțeles folosind următoarea situație ca exemplu. Un utilizator contactează asistența cu un mesaj despre o creștere bruscă a timpului de răspuns de la server. Operatorul, căutând prin lista problemelor analizate, găsește o înregistrare a lucrărilor efectuate pentru a analiza scăderea performanței serverului, după care informează utilizatorul că mesajul său a fost înregistrat și are legătură cu problema luată în considerare, iar eliminarea este de așteptat. după o anumită perioadă de timp, despre care utilizatorul va fi informat suplimentar. În absența capacității de a vizualiza o listă de probleme, operatorul nu ar putea să asocieze incidentul cu problema analizată în mod specific, apoi să urmărească rapid faptul că a fost rezolvată și să informeze utilizatorul despre aceasta.

Producătorii de scule încearcă să țină cont de recomandările menționate. De exemplu, HP OpenView Service Desk 3.0 are o structură modulară. Capacitatea de a înregistra și gestiona solicitările utilizatorilor, incidentele și problemele este implementată ca un modul separat, care este pe deplin în concordanță cu recomandările menționate: integrarea în acest caz este cât se poate de completă. Utilizatorii unui sistem construit pe baza acestui produs au posibilitatea de a construi conexiuni între înregistrările de înregistrare de toate tipurile enumerate, de a căuta după context și, ținând cont de aceste conexiuni, de a determina metode cunoscute de rezolvare a problemelor emergente. Separarea acestor funcții poate reduce eficiența instrumentului și, ca urmare, calitatea implementării proceselor. Totodată, baza oricărei soluții de management al infrastructurii IT este luarea în considerare a echipamentelor existente, aplicațiilor, documentației etc. - tot ceea ce alcătuiește această infrastructură. Aceste capabilități sunt disponibile și ca parte a HP Service Desk 3.0. În plus, caracteristicile concepute pentru a automatiza managementul schimbărilor și managementul SLA sunt implementate ca module separate. Integrarea tuturor modulelor de mai sus este implementată în cea mai mare măsură posibilă, oferind posibilitatea de a utiliza produsul în cauză ca bază pentru construirea unui sistem cuprinzător de management IT.

Produsul Remedy este construit ceva mai complex, se bazează pe Remedy Action Request System, instalat pe server. Module funcționale suplimentare pot fi achiziționate ca parte a aplicației din sistem: Help Desk, Asset Management, Change Management și Service Level Agreement. Fiecare dintre module poate fi utilizat fie independent (fără alte module de aplicație), fie ca parte a unei soluții integrate. Problemele de automatizare a proceselor de gestionare a problemelor și incidentelor, ca în cazul soluției HP, sunt implementate în modulul Remedy Help Desk. În același timp, există unele diferențe și sunt implementate abordări individuale pentru înțelegerea acestor procese, dar dorințele și cerințele principale ale ITIL sunt pe deplin luate în considerare.

Pentru implementarea cu succes a proceselor de management al incidentelor și problemelor

Trebuie îndeplinite cel puțin următoarele condiții.

• Disponibilitatea unei baze de date CMDB actuale și actualizate în timp util. Dacă această bază de date nu este disponibilă, informațiile despre elementele de configurare legate de incident vor fi preluate manual, ceea ce va crește semnificativ timpul de procesare a incidentului și va crește complexitatea acestuia.
• Disponibilitatea unei baze de cunoștințe actualizate cu privire la erori/probleme și modalități de rezolvare și rezolvare a acestora. Având o astfel de bază de date, puteți rezolva rapid multe probleme. Este de dorit să se poată conecta la el baze de date similare dezvoltate de alte organizații și companii. Problemele de compatibilitate care apar pot duce la o mare complexitate, de aceea se recomanda utilizarea solutiilor de arhitectura deschisa care sa includa instrumente de import si export de date. Recent, interfața Web, care este convenabilă și de înțeles, precum și răspândită, este din ce în ce mai folosită ca metodă standard de accesare a informațiilor.
• Având în vedere potențialul conflict între managementul problemelor și managementul incidentelor (datorită diferitelor obiective ale acestora), este necesar să se organizeze lucrul comun și cooperarea între executanții ambelor procese. În același timp, nu trebuie să uităm că din aceleași motive una și aceeași persoană nu poate îndeplini ambele sarcini în același timp: îi va fi foarte greu să găsească un echilibru de interese.
• Organizarea unui sistem eficient de înregistrare automată a incidentelor, cu capabilități de clasificare detaliate și de înaltă calitate, care este un element extrem de important pentru organizarea funcționării atât a serviciului Service Desk, cât și a proceselor luate în considerare în forma lor pură. Utilizarea tehnologiilor hârtiei în aceste scopuri nu este recomandată.

Este foarte convenabil dacă instrumentele utilizate pentru implementarea proceselor în cauză au următoarele capacități suplimentare:

• înregistrarea automată a incidentelor apărute în cele mai importante dispozitive (servere, echipamente de rețea etc.), care pot necesita crearea de interfețe suplimentare;
• escaladarea automată a incidentelor în cazul încălcării orarelor;
• rutare flexibilă a incidentelor, deoarece personalul de asistență poate fi amplasat în diferite încăperi și clădiri;
• căutarea automată a datelor necesare în baza de date CMDB;
• soluții speciale pentru a facilita clasificarea incidentelor;
• integrare cu sistemele de telefonie;
• prezența diferitelor module de diagnosticare.

Să ilustrăm capabilitățile enumerate folosind exemplul deja menționat Service Desk 3.0. Ca membru al familiei de produse HP OpenView, Service Desk include posibilitatea de a primi mesaje de la alte produse din familie, inclusiv Network Node Manager, un instrument pentru monitorizarea și gestionarea dispozitivelor de rețea și VantagePoint Operations, un instrument de monitorizare și gestionare. servere și aplicații. Aceste produse pot genera automat, pe baza informațiilor colectate despre obiectele monitorizate, cereri pentru Service Desk, care sunt transmise și analizate automat de operatorii de servicii de asistență sau procesate automat. Cu setări adecvate, alte instrumente de diagnosticare pot deveni, de asemenea, surse de mesaje similare. Produsul oferă posibilitatea de a informa automat prin trimiterea de mesaje managerilor la nivelurile corespunzătoare dacă termenele limită pentru rezolvarea unui incident sunt încălcate. Implementează capabilități avansate de căutare a informațiilor necesare printre problemele, incidentele și alte date deja înregistrate. Produsul oferă capabilități de integrare cu sisteme de poștă, telefon și paginare.

Având în vedere relevanța și utilitatea caracteristicilor suplimentare enumerate, producătorii de soluții software încearcă să le includă în produsele lor. Multe din ceea ce s-a spus despre HP Service Desk se aplică și produselor de la alți producători, inclusiv Remedy, Tivoli, CA, Peregrin, FrontRange.

Cei care întreprind munca de implementare a proceselor luate în considerare trebuie să fie pregătiți pentru o varietate de dificultăți. Printre acestea:

• lipsa de sprijin din partea conducerii și a personalului, ceea ce poate duce la o lipsă de resurse pentru implementare;
• lipsa de înțelegere a nevoilor afacerii, lipsa nivelurilor de servicii convenite, obiective prost definite, capacități și responsabilități ale diferitelor servicii;
• rezistența la schimbare și incapacitatea de a face modificări practicilor de lucru existente;
• lipsa de cunoștințe pentru rezolvarea incidentelor, pregătirea necorespunzătoare a personalului, regulile slab formalizate pentru interacțiunea utilizatorilor cu serviciile de asistență și diverse servicii între ei;
• integrarea slabă cu alte procese, instrumente de automatizare de proastă calitate și incapacitatea de a lega înregistrările incidentelor și problemele corespunzătoare reduc semnificativ capacitățile procesului, inclusiv capacitatea de a prezice probleme.

***

Ne-am concentrat pe două dintre cele mai frecvent citate procese de management IT în depanarea. Deși destul de ușor de înțeles la nivel intuitiv, aceste procese sunt greu de implementat din punctul de vedere al necesității respectării stricte a măsurilor și procedurilor organizaționale. Deși similare în multe privințe, procesele de gestionare a incidentelor și de gestionare a problemelor au, de asemenea, diferențe semnificative care decurg din obiectivele lor principale. La implementarea proceselor, instrumentele de automatizare utilizate în aceste scopuri devin de maximă importanță. Din păcate, sursele primare pe ITIL sunt disponibile unui cerc foarte restrâns de persoane interesate: sunt foarte scumpe, comandarea lor nu este ușoară, iar obținerea lor este și mai dificilă. Cerințele și dorințele pentru instrumentele expuse în articol se bazează pe experiența reală în operarea diverselor instrumente și pe o analiză a modalităților de rezolvare a problemelor apărute.

Literatură

1. Z. Alekhine. ITIL este baza conceptului de management al serviciilor IT. „Sisteme deschise”. 2001, nr. 3
2. Z. Alekhine. Service Desk - obiective, capabilități, implementare. „Sisteme deschise”. 2001, nr. 5-6
3. CCTA. Cele mai bune practici pentru Service Support. Londra: The Stationery Office, 2000

Zaurbek Alekhine ([email protected]) - manager de proiect la i-Teco (Moscova).

Ce este un incident

Conform definiției ITIL a "incident"înseamnă „orice eveniment care nu este un element al funcționării normale a serviciului și, în același timp, are sau poate avea un impact asupra prestării serviciului prin întreruperea acestuia sau reducerea calității acestuia”.

Aplicatii:

• Serviciu indisponibil;
• o eroare în aplicație care împiedică clientul să funcționeze normal;
• Spațiul pe disc este epuizat.

Echipament:

• defecțiune a sistemului;
• alarma interna;
• defecțiune a imprimantei.

Cereri de servicii:

• primirea unei cereri pentru informații suplimentare, sfaturi, documentații;
• parola uitată.

Majoritatea echipelor IT sunt implicate în rezolvarea unui tip de incident. Serviciul de service este responsabil pentru monitorizarea soluționării tuturor incidentelor raportate, deoarece este proprietarul tuturor acestor incidente. Acest proces este în mare măsură reactiv; Pentru a răspunde eficient la incidente, trebuie definit un mod formal de lucru pentru angajați, inclusiv utilizarea software-ului necesar.

Acele incidente care nu pot fi rezolvate direct de către Biroul de Asistență trebuie transmise specialiștilor corespunzători. O metodă pentru rezolvarea unui incident sau a unei soluții ar trebui stabilită și comunicată utilizatorilor cât mai repede posibil. Acest lucru rezultă din scopul principal - de a minimiza impactul negativ asupra activităților principale ale utilizatorilor. După ce cauza incidentului a fost eliminată și serviciul a fost restabilit la nivelul specificat în SLA, incidentul este închis.

Cauza principală a unui incident de securitate a informațiilor este capacitatea potențială a unui atacator de a obține privilegii nerezonabile pentru a accesa bunul unei organizații. Evaluarea riscului unei astfel de oportunități și luarea deciziei corecte de protejare este sarcina principală a echipei de răspuns.

Fiecare risc trebuie să fie prioritizat și tratat în conformitate cu politica de evaluare a riscurilor a organizației. Evaluarea riscurilor este văzută ca un proces continuu, al cărui scop este atingerea unui nivel acceptabil de protecție, cu alte cuvinte, trebuie puse în aplicare suficiente măsuri pentru a proteja activul împotriva utilizării nerezonabile sau neautorizate. Evaluarea riscurilor contribuie la clasificarea activelor. În marea majoritate a cazurilor, activele care sunt critice din punct de vedere al riscului sunt, de asemenea, critice pentru afacerea organizației.

Specialiștii echipei de răspuns analizează amenințările și ajută la menținerea la zi a modelului de intrus adoptat de serviciul de securitate a informațiilor al organizației.

Pentru ca echipa de răspuns să funcționeze eficient, organizația trebuie să aibă proceduri pentru a descrie procesele de funcționare ale unităților. O atenție deosebită trebuie acordată completării bazei de documente a serviciului de securitate a informațiilor.

Detectarea și analiza incidentelor de securitate a informațiilor

Incidentele de securitate a informațiilor pot avea surse diferite de origine. În mod ideal, o organizație ar trebui să fie pregătită pentru orice manifestare de activitate rău intenționată. În practică, acest lucru nu este fezabil.

Funcția de răspuns trebuie să clasifice și să descrie fiecare incident care are loc în organizație, precum și să clasifice și să descrie posibilele incidente care au fost presupuse pe baza analizei de risc.

Pentru a extinde tezaurul despre posibilele amenințări și posibilele incidente asociate cu acestea, o bună practică este utilizarea surselor deschise actualizate constant pe Internet.

Semne ale unui incident de securitate a informațiilor

Presupunerea că un incident de securitate a informațiilor a avut loc într-o organizație ar trebui să se bazeze pe trei factori principali:

• mesajele de incident de securitate a informațiilor sunt primite simultan din mai multe surse (utilizatori, IDS, fișiere jurnal)
• Semnal IDS eveniment repetat multiplu
• Analiza fișierelor jurnal ale sistemului automat oferă o bază pentru administratorii de sistem pentru a concluziona că poate avea loc un eveniment incident.

În general, semnele unui incident se împart în două categorii principale, raportează că un incident are loc în prezent și raportează că un incident poate avea loc în viitorul apropiat. Următoarele sunt câteva semne ale unui eveniment care are loc:

• IDS detectează depășirea tamponului
• notificare program antivirus
• Blocarea interfeței WEB
• Utilizatorii raportează viteze extrem de mici atunci când încearcă să acceseze Internetul
• administratorul de sistem detectează prezența fișierelor cu nume imposibil de citit
• Utilizatorii raportează multe mesaje duplicate în căsuțele lor de e-mail
• gazda scrie în jurnalul de audit despre modificarea configurației
• aplicația înregistrează mai multe încercări de autorizare nereușite în fișierul jurnal
• administratorul de rețea detectează o creștere bruscă a traficului de rețea etc.

Exemple de evenimente care pot servi drept surse de securitate a informațiilor includ:

• fișierele jurnal ale serverului înregistrează scanările de porturi
• anunț în mass-media despre apariția unui nou tip de exploatare
• o declarație deschisă a criminalilor informatici care declară război organizației dvs. etc.

Analiza incidentelor de securitate a informațiilor

Incidentul nu este un fapt împlinit evident, dimpotrivă, atacatorii încearcă să facă totul pentru a nu lăsa urme ale activităților lor în sistem. Semnele unui incident includ o modificare minoră în fișierul de configurare a serverului sau, la prima vedere, o plângere standard a utilizatorului de e-mail. Luarea unei decizii cu privire la apariția unui eveniment incident depinde în mare măsură de competența experților echipei de răspuns. Este necesar să se facă distincția între o eroare accidentală a operatorului și un impact rău intenționat, direcționat, asupra unui sistem informațional. Faptul că un incident de securitate a informațiilor este tratat „întuneric” este, de asemenea, un incident de securitate a informațiilor, deoarece îi distrage atenția experților echipei de răspuns de la problemele stringente. Conducerea organizației ar trebui să acorde atenție acestei circumstanțe și să ofere experților echipei de răspuns o anumită libertate de acțiune.

Compilarea matricelor de diagnostic servește la vizualizarea rezultatelor analizei evenimentelor care au loc în sistemul informațional. Matricea este formată din rânduri de semne potențiale ale unui incident și coloane de tipuri de incidente. Intersecția oferă o evaluare a evenimentului pe scara de prioritate „înalt”, „mediu”, „scăzut”. Matricea de diagnosticare este concepută pentru a documenta fluxul de concluzii logice ale experților în procesul de luare a deciziilor și, împreună cu alte documente, servește ca dovadă a investigației incidentului.

Documentarea unui incident de securitate a informațiilor

Documentarea evenimentelor unui incident de securitate a informațiilor este necesară pentru a colecta și, ulterior, consolidarea probelor investigației. Toate faptele și dovezile de influență rău intenționată trebuie să fie documentate. Se face o distincție între dovezile tehnologice și dovezile operaționale ale impactului. Dovezile tehnologice includ informațiile obținute din mijloacele tehnice de colectare și analiză a datelor (sniffer, IDS) dovezile operaționale includ date sau dovezi colectate în timpul unei anchete de personal, dovezi ale apelurilor către biroul de service, apeluri către call center;

O practică tipică este menținerea unui jurnal de investigare a incidentelor, care nu are un formular standard și este elaborat de echipa de răspuns. Pozițiile cheie ale unor astfel de reviste pot fi:

• stadiul actual al anchetei
• descrierea incidentului
• acțiunile efectuate de echipa de răspuns în timpul procesării incidentului
• lista actorilor de anchetă cu o descriere a funcțiilor acestora și a procentului de angajare în procedura de investigație
• lista de probe (cu indicarea obligatorie a surselor) colectate în timpul procesării incidentului