Exemple de accidente și incidente aviatice. Descrierea proceselor cheie de management al serviciilor IT. Managementul nivelului de servicii
Valabil Editorial din 27.12.2007
| Numele documentului | "STANDARD NAȚIONAL AL FEDERATIEI RUSĂ. TEHNOLOGIA INFORMAȚIILOR. METODE ȘI MIJLOACE DE SECURITATE. GESTIONAREA INCIDENTELOR DE SECURITATE A INFORMAȚIILOR. GOST R ISO/IEC TO 18044-2007" (aprobat prin Ordinul Rostekhregulirovaniya din 27 .12.51307 N) |
| Tip document | ordine, standard, gust |
| Autoritatea de primire | Rostekhregulirovanie |
| Numărul documentului | 18044-2007 |
| Data acceptarii | 01.01.1970 |
| Data revizuirii | 27.12.2007 |
| Data înregistrării la Ministerul Justiției | 01.01.1970 |
| Stare | valabil |
| Publicare |
|
| Navigator | Note |
"STANDARD NAȚIONAL AL FEDERATIEI RUSĂ. TEHNOLOGIA INFORMAȚIILOR. METODE ȘI MIJLOACE DE SECURITATE. GESTIONAREA INCIDENTELOR DE SECURITATE A INFORMAȚIILOR. GOST R ISO/IEC TO 18044-2007" (aprobat prin Ordinul Rostekhregulirovaniya din 27 .12.51307 N)
6 Exemple de incidente securitatea informatieiși motivele lor
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 extreme mediu, de exemplu, temperatură ridicată (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 schiță generală Incidentele de securitate a informațiilor „colectarea de informații” 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, colecția de informații tehnice se extinde și se mută în acces neautorizat, dacă, de exemplu, un atacator, în timp ce caută o vulnerabilitate, încearcă să obțină acces neautorizat. 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 utilizare a accesului neautorizat mijloace tehnice include:
Î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.
Incident (incident sau INC) – orice eveniment (eșecuri, solicitări de consultații etc.) care nu face parte din funcționarea normală a serviciului, care duce/ar putea duce la oprirea serviciului sau la scăderea nivelului calității acestuia.
Scopul procesului de management al incidentelor- recuperare rapidă functionare normala serviciu în conformitate cu Acordul privind nivelul de servicii și minimizarea impactului eșecului asupra operațiunilor de afaceri.
Pentru a gestiona cu succes incidentele, este necesar să se creeze un serviciu de dispecerat ( Birou de service), care ar trebui să fie un singur punct de contact cu utilizatorii și să coordoneze rezolvarea incidentelor. Birou de service - diviziunea (în terminologie ITIL„funcție”), oferind un punct de intrare unic și unic pentru toate cererile utilizatorilor finali și o procedură unificată de procesare a cererilor.
Escaladare– un mecanism care servește la rezolvarea INC în timp util prin atragerea de cunoștințe suplimentare (escaladare funcțională) sau de autoritate (escaladare ierarhică). Scopul este de a rezolva INC în termenul specificat în SLA.
În cazul în care incidentul nu poate fi rezolvat de prima linie de asistență în timpul convenit, trebuie adusă expertiză sau autoritate suplimentară. Aceasta se numește escaladare, care are loc în conformitate cu prioritățile discutate mai sus și, în consecință, cu timpul de rezolvare a incidentului.
Există escaladare funcțională și ierarhică:
- Escaladarea funcțională(orizontală) – înseamnă implicarea mai multor specialiști sau furnizarea de drepturi de acces suplimentare pentru rezolvarea incidentului; în același timp, este posibil să existe o extindere dincolo de granițele unui departament IT structural.
- Escaladarea ierarhică(verticală) - înseamnă o tranziție verticală (la un nivel superior) în cadrul organizației, deoarece nu există suficientă autoritate organizațională (nivel de autoritate) sau resurse pentru a rezolva incidentul.
Sarcina Manager proces de management al incidentelor este de a rezerva în mod proactiv oportunități de escaladare funcțională în cadrul unităților de linie ale organizației, astfel încât rezolvarea incidentelor să nu necesite o escaladare ierarhică regulată. În orice caz, unitățile de linie trebuie să asigure resurse suficiente pentru acest proces.
Rutarea incidentelor, sau escaladarea funcțională, este determinată de nivelul necesar de cunoștințe, autoritate și urgență. Prima linie de sprijin(numit și suport de nivel 1) este de obicei Birou de service, a doua linie– departamente responsabile cu managementul infrastructurii IT, treilea- departamentele de dezvoltare software și arhitectură, iar al patrulea - furnizori. Cu cât organizația este mai mică, cu atât mai puțin niveluri de escaladare. În organizațiile mari Manager proces de management al incidentelor poate numi Coordonatori de incidenteîn departamentele relevante pentru a-și sprijini activitățile. De exemplu, coordonatorii pot acționa ca o interfață între activitățile de proces și managerii de linie. unitati organizatorice. Fiecare dintre ei coordonează activitățile propriilor grupuri de sprijin.
Distincția dintre incidenteŞi probleme este probabil una dintre cele mai faimoase, dar nu cele mai populare contribuții ale bibliotecii ITIL la dezvoltarea IT Service Management. Deși această distincție poate fi uneori confuză, principalul său avantaj este că face distincția între restabilirea rapidă a serviciului și identificarea cauzei unui incident și corectarea acestuia.
Procesul de management al incidentelor destinate pentru eliminarea incidentului și reluarea rapidă a serviciilor. Incidentele sunt înregistrate, iar calitatea informațiilor de înregistrare determină eficacitatea unui număr de alte procese.
Hank Marchiz oferte 6 Aspecte cheie ale procesului de management al incidentelor:
- Crearea unei baze de date cu înregistrările tuturor incidentelor. Este necesar să se înregistreze toate incidentele care apar, indiferent de modalitatea de primire a acestora (e-mail, apel telefonic, fax etc.). Toate informațiile despre progresul rezolvării incidentului ar trebui, de asemenea, înregistrate în baza de date.
- Crearea unei baze de cunoștințe unde va fi păstrat Informații suplimentare pentru a rezolva incidentul. Cu cât mai multe informații, cu atât mai bine. În ITIL, acestea sunt baze de date de management al configurației (CMDB) și/sau sisteme de management al configurației (CMS).
- Dezvoltați și aprobați clar instrucțiuni și reguli pentru tratarea incidentelor(înregistrare, clasificare, prioritizare, analiză etc.).
- Determinați, în raport cu SLA, proceduri care vă va permite să gestionați impactul unui incident asupra afacerii dvs.
- Crea modelul „incident major”.– un set de reguli care descriu în mod clar un incident foarte grav. Un incident major este unul care afectează un serviciu de afaceri critic și/sau număr mare clienti si utilizatori. În orice caz, incidentul de bază necesită escaladare imediată, notificare client și alte procese speciale. Ideea este că un astfel de incident necesită un răspuns maxim din partea organizației IT.
- Informa cei care v-au raportat incidentul, despre starea muncii. Trebuie să știi cui trebuie să trimiți informații și cât de des. De exemplu, puteți notifica clienții și utilizatorii despre incident. De asemenea, trebuie să îi informați că nu va fi posibilă revenirea nivelului de serviciu oferit la parametrii conveniți la ora convenită.
Dacă nu ați implementat cel puțin unul dintre aceste 6 puncte, atunci, în conformitate cu standardul ISO/IEC 20000-1 (Managementul serviciilor), concentrându-vă asupra acestuia, puteți îmbunătăți calitatea serviciului. Dacă aveți toate punctele implementate, atunci cel mai probabil nu mai trebuie să petreceți mult timp implementând procesul de management al incidentelor - concentrați-vă pe alte domenii ale ITIL, cum ar fi Managementul problemelor (Managementul problemelor) sau Managementul schimbării (Managementul schimbării).
În context biblioteci ITIL Incidentele includ nu numai erori hardware sau software, ci și Cereri de servicii.
Solicitare de service este o Solicitare din partea Utilizatorului de suport, informare, consultare sau documentare care nu reprezintă o defecțiune a infrastructurii IT.
Exemple de solicitări de servicii:
- o întrebare despre funcționarea sistemelor informatice sau o solicitare de informații;
- o solicitare despre starea (starea) a ceva din infrastructura IT;
- cerere de schimbare a parolei;
- solicitări de joburi în lot, recuperare de parolă sau autorizare;
- obținerea de informații din baza de date.
Pentru a putea distinge „ incidente reale" din " Incidente-Solicitari de servicii„, se recomandă atribuirea unei categorii speciale Cereri de servicii.
La procesarea mai multor incidente simultan, este necesar să se aranjeze priorități. Justificarea acordării priorității este nivelul de importanță al erorii pentru afacere și pentru utilizator. Pe baza dialogului cu utilizatorul și în conformitate cu prevederile Acorduri privind nivelul de servicii (Acorduri de nivel de serviciu – SLA-uri) Birou de service atribuie priorități care determină ordinea în care sunt procesate incidentele. Când incidentele sunt escalate la o a doua, a treia sau mai multe linie de asistență, aceeași prioritate trebuie menținută, dar uneori poate fi ajustată în consultare cu biroul de service.
- impactul incidentului: gradul de abatere de la nivelul normal de livrare a serviciilor, exprimat în numărul de utilizatori sau procese de afaceri afectate de incident;
- Urgența incidentului: întârzierea acceptabilă în rezolvarea unui incident pentru un utilizator sau un proces de afaceri.
Prioritatea este determinată în funcție de urgență și impact. Pentru fiecare prioritate se determină numărul de specialiști și cantitatea de resurse care pot fi direcționate pentru rezolvarea incidentului. Ordinea în care sunt tratate incidentele cu aceeași prioritate poate fi determinată în funcție de efortul necesar pentru rezolvarea incidentului. De exemplu, un incident ușor de rezolvat poate fi tratat înaintea unui incident care necesită mai mult efort.
5.3.1 Procesarea incidentelor.
Majoritatea departamentelor IT și a echipelor specializate sunt implicate într-o măsură sau alta în gestionarea incidentelor. Biroul de service este responsabil pentru monitorizarea procesului de rezolvare a tuturor Incidentelor înregistrate și este efectiv proprietarul tuturor Incidentelor. Acest proces funcționează în mare măsură pe o bază reactivă. Pentru a răspunde productiv și eficient, necesită metode de lucru formale care pot fi susținute de software.
Incidentele pe care biroul de service nu le poate rezolva imediat pot fi trimise uneia dintre echipele noastre dedicate pentru tratare. Rezoluția sau soluția de soluționare trebuie furnizată în măsura maximă posibilă. termene scurte pentru a restabili serviciul pentru Utilizatori cu impact minim asupra muncii lor. După ce cauza Incidentului a fost eliminată și serviciul convenit a fost restabilit, Incidentul este închis.
Figura 5.2 prezintă procesele care au loc în timpul ciclu de viață Incident. Anexa 5D prezintă aceste procese dintr-un punct de vedere diferit.
Figura 5.2 - Ciclul de viață al incidentului.
Starea unui incident reflectă poziția sa actuală în ciclul de viață, uneori denumită „poziția sa în diagramă”. Fiecare angajat trebuie să cunoască toate stările posibile și semnificațiile acestora. Câteva exemple de categorii de statut:.
■ nou;.
■ acceptat;.
■ au fost stabilite termene limită;
■ repartizat/transferat la un specialist;.
■ în lucru (Work In Progress, WIP);
■ așteptare;.
■ permis;.
■ închis.
În timpul ciclului de viață al unui Incident, este important ca evidența incidentului să fie ținută la zi. Acest lucru va permite oricărui membru al echipei de service să ofere Clientului cele mai recente informații despre evoluția cererii. Câteva exemple de acțiuni de actualizare a înregistrărilor:.
■ actualizarea informațiilor istorice;
■ schimbați starea (de exemplu, de la starea „nou” la starea „în curs” sau „în așteptare”);.
■ modificarea impactului asupra afacerii și a priorităților;
■ introduceţi timpul petrecut şi costurile;.
■ urmăriți starea de escaladare.
Descrierea declarată inițial de către Client se poate modifica în timpul ciclului de viață al Incidentului. Cu toate acestea, este important să păstrați o descriere a simptomelor originale, atât pentru revizuire, cât și pentru ca plângerea să poată fi referită folosind limbajul conținut în cererea inițială. De exemplu, Clientul poate să fi declarat că imprimanta nu funcționa, dar s-a stabilit că problema a fost cauzată de o defecțiune a rețelei. Când răspundeți Clientului, este mai bine să explicați mai întâi că incidentul de imprimantă a fost rezolvat, decât să vorbiți despre rezolvarea problemelor de rețea.
Un istoric verificat al unui Incident este necesar atunci când se analizează progresul procesării acestuia, acest lucru este deosebit de important atunci când se rezolvă probleme legate de încălcarea SLA. În timpul ciclului de viață al unui Incident, trebuie înregistrate următoarele actualizări ale înregistrării incidentului:.
■ numele persoanei care a făcut modificarea înregistrării;.
■ data și ora modificării;.
■ ce anume a schimbat această persoană (de exemplu, prioritate, statut, istoric);
■ de ce a fost făcută modificarea;.
■ timp pierdut.
Dacă furnizorilor externi nu li se permite să actualizeze înregistrările Service Desk (ceea ce este recomandat), atunci trebuie să definiți o procedură pentru actualizarea înregistrărilor pentru furnizor. Acest lucru asigură contabilizarea corectă a resurselor utilizate. Cu toate acestea, dacă software face posibilă identificarea unei clase de Incidente care pot fi rezolvate de furnizori externi și efectuate verificare preliminară informațiile introduse, unele organizații pot considera foarte convenabil să permită furnizorilor externi să actualizeze informațiile direct. Dacă luați această decizie, va trebui să determinați ce informații nu sunteți dispus să furnizați furnizorului și câte informații trebuie să aveți despre acțiunile furnizorului.
Aceeași situație poate apărea atunci când Service Desk actualizează o solicitare în locul unui tehnician de service suport tehnic situat în afara biroului. Uneori poate fi necesar să actualizați contul de incident după fapt, de exemplu, dacă lucrează specialiști ora serii, iar biroul de service ar trebui să actualizeze înregistrările în dimineața următoare.
5.3.2 Prima, a doua și a treia linie de sprijin.
Adesea, departamentele și grupurile de asistență (specializate) care nu fac parte din Service Desk sunt numite grupuri de suport de linia a doua sau a treia. Au abilități mai specializate, timp suplimentar sau alte resurse pentru a rezolva Incidentele. Pe baza acestui lucru, Service Desk se numește prima linie de asistență. Figura 5.3 arată cum se leagă această terminologie cu activitățile de management al incidentelor discutate în paragrafele anterioare.
Rețineți că al treilea și/sau a N-a linie asistența poate include în cele din urmă furnizori externi care pot avea acces direct la facilitățile de înregistrare a incidentelor (în funcție de reglementările de securitate și probleme tehnice).
Figura 5.3 ~ Prima, a doua și a treia linie de sprijin.
5.3.3 Comparație între escaladarea funcțională și ierarhică.
„Escalarea” este un mecanism care facilitează rezolvarea în timp util a unui Incident. Poate fi declanșat în orice etapă a procesului de autorizare.
Transferul unui Incident de la echipele de suport din prima linie la echipele de asistență din a doua linie sau mai departe se numește „escaladare funcțională” și are loc din cauza lipsei de cunoștințe sau abilități. Este de preferat ca escaladarea funcțională să aibă loc în cazurile în care timpul convenit alocat pentru rezolvarea Incidentului a expirat. Escalările funcționale automate care sunt declanșate după o anumită perioadă de timp trebuie planificate cu atenție și nu trebuie să depășească timpul de rezoluție convenit (în SLA).
„Escaladarea ierarhică” poate avea loc în orice moment în timpul procesului de rezolvare dacă există probabilitatea ca rezolvarea incidentului să nu fie finalizată în timp util sau să fie nesatisfăcătoare. În cazurile în care cunoștințele sau expertiza lipsesc, escaladarea ierarhică se face de obicei manual (de către biroul de service sau alt personal de asistență). Se poate lua în considerare escaladarea ierarhică automată după o perioadă critică de timp când devine evident că Incidentul nu va fi rezolvat în timp util. Este de preferat ca escaladarea să aibă loc cu mult înainte de expirarea timpului permis (în SLA) pentru rezoluție. Acest lucru va permite managementului de linie, cu autoritatea corespunzătoare, să ia măsuri corective, cum ar fi angajarea de specialiști de la un furnizor extern.
5.3.4 Prioritate.
Prioritatea unui Incident este determinată inițial de impactul acestuia asupra afacerii și de urgența cu care trebuie furnizată o soluție sau o soluție. Țintele pentru rezolvarea Incidentelor sau gestionarea solicitărilor sunt de obicei incluse în SLA. În practică, țintele de rezolvare a incidentelor sunt adesea asociate cu categorii. Exemple de categorii și priorități, precum și sistemele lor de codificare, pot fi găsite în apendicele 5A și, respectiv, 5B.
Biroul de service joacă un rol important în procesul de management al incidentelor:.
■ toate Incidentele sunt raportate Biroului de Asistență, iar angajații acestuia înregistrează Incidentele; În cazurile în care Incidentele sunt generate automat, procesul trebuie să includă în continuare înregistrarea prin Service Desk.
■ cea mai mare parte a Incidentelor (posibil până la 85% cu un nivel ridicat de abilități ale personalului) va fi rezolvată de Biroul de Asistență;
■ Service Desk este o unitate „independentă” care monitorizează progresul rezolvării tuturor Incidentelor înregistrate.
Mai jos este o listă a principalelor acțiuni care sunt efectuate de Service Desk după primirea notificării unui Incident:.
■ înregistrarea informațiilor de bază – inclusiv timpul și detaliile simptomelor obținute;
■ Dacă se face o cerere de serviciu, cererea este procesată în conformitate cu procedurile standard din această organizație;
■ pentru a completa înregistrarea incidentului pe baza CMDB, sunt selectate elementele contabile (EC) care sunt raportate a fi cauza incidentului.
■ stabilirea priorității corespunzătoare și transferarea către Utilizator a unui număr unic de Incident, generat automat de sistem (pentru a-l raporta la apelurile ulterioare către serviciu);
■ evaluarea Incidentului și, dacă este posibil, oferirea de recomandări pentru rezolvarea acestuia: acest lucru este adesea posibil pentru Incidente standard sau atunci când este cauzat de o Problemă/eroare cunoscută;
■ închiderea unei înregistrări de incident după rezolvarea cu succes a acesteia: adăugarea de informații despre acțiunile asociate rezoluției și setarea codului de categorie corespunzător;
■ escaladarea unui Incident către o echipă de asistență de linia a doua (adică, o echipă dedicată) după o încercare de rezolvare nereușită sau când se stabilește că este nevoie de un nivel mai ridicat de asistență.
5.3.5 Relațiile dintre incidente, probleme, erori cunoscute și cereri de modificare (RFC).
Incidentele rezultate din defecțiuni sau erori ale infrastructurii IT conduc la abateri reale sau potențiale de la funcționarea planificată a serviciilor IT.
Cauza Incidentelor poate fi evidentă și nu va fi necesară nicio investigație suplimentară pentru a rezolva cauza. Acest lucru va duce la efectuarea unei reparații, la definirea unei soluții de soluție sau la emiterea unui RFC care va corecta eroarea. În unele cazuri, eliminați Incidentul în sine - de ex. influența sa asupra Clientului poate fi realizată destul de rapid. Este posibil să necesite pur și simplu o repornire a computerului sau reinițializarea canalului de comunicare fără a identifica cauza Incidentului.
În cazurile în care cauza de bază a incidentului este necunoscută, poate fi necesară înregistrarea unei înregistrări a problemei. Deci, Problema este de fapt un indicator al unei erori necunoscute în infrastructură. De obicei, o problemă va fi înregistrată numai atunci când gravitatea problemei justifică o investigație.
Impactul unei astfel de Probleme va fi adesea evaluat pe baza impactului (atât real, cât și potențial) asupra serviciilor de afaceri, precum și a numărului de Incidente similare raportate care pot avea aceeași cauză subiacentă. Creare cont Problemele pot fi relevante chiar și atunci când consecințele Incidentului au fost eliminate. În consecință, o înregistrare a problemei poate fi tratată independent de înregistrările sale asociate de incident și atât înregistrarea problemei, cât și investigarea cauzei acesteia pot continua chiar și după ce incidentul inițial a fost închis cu succes.
Procesarea cu succes a unei intrări Problem va avea ca rezultat identificarea erorii de rădăcină; această intrare poate deveni o intrare de eroare cunoscută după ce este dezvoltată o soluție de soluție și/sau RFC. Acest lanț logic, de la notificarea inițială până la rezolvarea problemei inițiale, este prezentat în Figura 5.4.
Figura 5.4 - Relații între incidente, probleme, erori cunoscute și cereri de modificare (RFC).
Astfel, avem următoarele definiții:.
■ Problemă: cauza subiacentă necunoscută a unuia sau mai multor Incidente.
■ Eroare cunoscută: o problemă care a fost diagnosticată cu succes și pentru care se cunoaște o soluție.
■ RFC: Solicitare de modificare a oricărei componente a infrastructurii IT sau a oricărui aspect al serviciului IT.
Problema poate duce la multe Incidente; De asemenea, este posibil ca Problema să nu fie diagnosticată până când nu au avut loc mai multe Incidente într-o perioadă de timp. Gestionarea problemelor este semnificativ diferită de gestionarea incidentelor și, prin urmare, este descrisă de procesul de management al problemelor.
În timpul procesului de rezolvare, incidentul este verificat pentru relații în baza de date a problemelor și erorilor cunoscute. De asemenea, ar trebui verificat cu relațiile din baza de date de incidente pentru a determina dacă există Incidente similare deschise și dacă Incidente similare anterioare au fost rezolvate. Dacă o soluție sau o soluție este deja disponibilă, incidentul poate fi rezolvat imediat. În caz contrar, procesul de gestionare a incidentelor este responsabil pentru rezolvarea sau găsirea unei soluții de soluționare cu întrerupere minimă a procesului de afaceri.
Când procesul de management al incidentelor găsește o soluție, aceasta va fi revizuită de echipa de management al problemelor, care va actualiza apoi înregistrarea problemei corespunzătoare (vezi Figura 5.5). Trebuie remarcat faptul că înregistrarea problemei corespunzătoare poate să nu existe încă în acest moment. De exemplu, soluția poate fi trimiterea prin fax a unui raport din cauza unei eșecuri de comunicare, dar este posibil ca înregistrarea problemei pentru acea eșec de comunicare să nu existe ; în acest caz, echipa de management al problemelor ar trebui să-l creeze. Deci, procesul implică activități în care Service Desk asociază Incidente care sunt rezultatul unei Probleme înregistrate.
Figura 5.5 - Soluții de procesare și soluții de incidente.
De asemenea, este posibil ca echipa de management al problemelor, în timp ce investighează o problemă asociată cu un incident, să găsească o soluție sau o soluție pentru problema în sine și/sau pentru unele incidente conexe. În acest caz, echipa de management al problemelor trebuie să comunice acest lucru procesului de management al incidentelor pentru a schimba starea Incidentelor deschise în Eroare cunoscută sau Închis.
Atunci când, la momentul depunerii unui Incident, se sugerează ca incidentul să fie tratat ca o problemă, atunci acesta trebuie trimis imediat la procesul de management al problemelor, unde, dacă este necesar, o noua intrare despre Problemă. Procesul de management al incidentelor va fi, ca întotdeauna, responsabil pentru continuarea soluționării incidentului pentru a minimiza impactul acestuia asupra proceselor de afaceri.
11 octombrie 2012 la ora 10:58Tratarea incidentelor de securitate a informațiilor
- Securitatea informațiilor
Bună ziua, dragă habrahabr!
Continui să public articole din practica de securitate a informațiilor.
De data aceasta vom vorbi despre o componentă atât de importantă precum incidentele de securitate. Lucrul cu incidente va lua cea mai mare parte din timp după ce a fost stabilit regimul de securitate a informațiilor (documentele au fost acceptate, instalate și configurate partea tehnica, au fost efectuate primele antrenamente).
Raportarea incidentelor
Primul lucru pe care trebuie să-l faceți este să obțineți informații despre incident. Acest punct trebuie gândit în stadiul formării unei politici de securitate și al creării de prezentări privind programele educaționale în securitatea informațiilor pentru angajați.
Principalele surse de informare:
1. Serviciu de asistență.
De regulă (și aceasta este o tradiție bună), ei sună sau scriu la biroul de asistență al serviciului dumneavoastră IT despre orice defecțiuni, defecțiuni sau defecțiuni ale echipamentelor. Prin urmare, este necesar să „integrați” în prealabil procesul de afaceri al biroului de asistență și să indicați tipurile de incidente cu care solicitarea va fi transferată către departamentul de securitate a informațiilor.
2. Mesaje direct de la utilizatori.
Organizați un singur punct de contact și comunicați acest lucru în cadrul formării de securitate a informațiilor pentru angajați. În prezent, departamentele de securitate a informațiilor din organizații, de regulă, nu sunt foarte mari, fiind adesea formate din 1-2 persoane. Prin urmare, nu va fi dificil să desemnați pe cineva responsabil pentru primirea incidentelor, nici măcar nu trebuie să vă deranjați cu alocarea unei adrese de e-mail pentru nevoile IS Helpdesk.
3. Incidente detectate de personalul de securitate a informațiilor.
Totul este simplu aici și nu sunt necesare mișcări fizice pentru a organiza un astfel de canal de recepție.
4. Jurnalele de sistem și alertele.
Configurați alerte în consola antivirus, IDS, DLP și alte sisteme de securitate. Este mai convenabil să utilizați agregatoare care colectează și date din jurnalele de programe și sisteme instalate în organizația dvs. O atenție deosebită este necesar să se acorde atenție punctelor de contact cu rețeaua externă și locurilor în care sunt stocate informații sensibile.
Deși incidentele de securitate sunt variate și diverse, ele sunt destul de ușor de împărțit în mai multe categorii, care sunt mai ușor de păstrat statistici.
1. Dezvăluirea informațiilor confidențiale sau interne sau amenințarea unei astfel de dezvăluiri.
Pentru a face acest lucru, trebuie să aveți, cel puțin, o listă actualizată de informații confidențiale, sistem de lucruștampilarea suporturilor electronice și de hârtie. Bun exemplu- șabloanele de documente pentru aproape toate ocaziile, aflate pe portalul intern al organizației sau în depozitul de fișiere intern, sunt marcate implicit „Numai pentru uz intern”.
Permiteți-mi să clarific puțin despre amenințarea dezvăluirii într-o postare anterioară, am descris o situație în care un document etichetat „Numai pentru uz intern” a fost postat într-o sală comună adiacentă unei alte organizații. Poate că nu a existat nicio dezvăluire în sine (a fost postată după sfârșitul zilei de lucru și a fost observată foarte repede), dar faptul amenințării dezvăluirii este evident!
2. Acces neautorizat.
Pentru a face acest lucru, trebuie să aveți o listă de resurse protejate. Adică acelea în care se află orice informație sensibilă a organizației, clienților sau contractorilor acesteia. Mai mult, este de dorit să se includă în această categorie nu numai pătrunderea într-o rețea de calculatoare, ci și accesul neautorizat la spații.
3. Excesul de autoritate.
În principiu, puteți combina acest punct cu cel anterior, dar este mai bine să îl evidențiați și să explicați de ce. Accesul neautorizat se referă la accesul persoanelor care nu au acces legal la resursele sau sediul organizației. Acesta este un intrus extern fără intrare legitimă în sistemul dumneavoastră. Excesul de autoritate este înțeles ca acces neautorizat la orice resurse și sedii ale angajaților legali ai organizației.
4. Atacul de virus.
În acest caz, trebuie să înțelegeți următoarele: o singură infecție a computerului unui angajat nu ar trebui să ducă la litigii, deoarece aceasta poate fi atribuită unei erori sau unui factor uman notoriu. Dacă un procent semnificativ din calculatoarele organizației sunt infectate (aici se pornește de la numărul total de mașini, distribuția, segmentarea acestora etc.), atunci este necesar să se lanseze o investigație completă a incidentului de securitate cu căutarea necesară pentru surse de infecție, cauze etc.
5. Compromisarea contului.
Acest punct răsună 3
. De fapt, incidentul pleacă de la 3
V 5
categorie dacă în timpul investigației incidentului se dovedește că utilizatorul în acel moment era în imposibilitatea fizică și efectivă de a-și folosi acreditările.
Clasificarea incidentelor
Acest punct în lucrul cu incidente poate fi tratat în 2 moduri: simplu și complex.
Modalitatea ușoară este să luați acordul de nivel de servicii IT și să îl adaptați nevoilor dvs.
Pe calea grea: pe baza analizei de risc, identificați grupuri de incidente și/sau active pentru care rezolvarea sau eliminarea cauzelor incidentului trebuie să fie imediată.
Modul simplu funcționează bine în organizațiile mici unde nu există prea multe informații proprietare și nu cantitate uriașă angajati. Dar merită să înțelegeți că serviciul IT bazează SLA pe propriile riscuri și statistici de incidente. Este foarte posibil ca pe masă să fie o imprimantă blocată cu hârtie director general va avea o prioritate foarte mare dacă compromiterea parolei administratorului bazei de date corporative este mai importantă pentru dvs.
Strângerea dovezilor incidentului
Există o știință aplicată specială - criminalistica, care se ocupă de probleme de criminalistică în domeniul infracțiunilor informatice. Și există o carte minunată de N.N Fedotov. „Legal – criminalistica computerizată”. Nu voi descrie în detaliu aspectele criminalisticii acum, voi evidenția doar 2 puncte principale în conservarea și furnizarea dovezilor care trebuie respectate.
Pentru documentele pe hârtie, originalul este stocat în siguranță cu o înregistrare a persoanei care a descoperit documentul, unde a fost descoperit documentul, când a fost descoperit documentul și care a asistat la descoperire. Orice investigație trebuie să se asigure că originalele nu au fost falsificate
Pentru informații despre mediile computerizate: imagini în oglindă sau orice suport amovibil, trebuie luate informații despre hard disk-uri sau memorie pentru a asigura accesibilitatea. O evidență a tuturor activităților din timpul procesului de copiere trebuie păstrată și procesul trebuie asistat. Media și protocolul original (dacă acest lucru nu este posibil, atunci cel puțin o imagine în oglindă sau o copie) trebuie să fie păstrate protejate și intacte
După rezolvarea incidentului
Deci, incidentul s-a încheiat, consecințele au fost eliminate și s-a efectuat o anchetă oficială.
Dar munca nu ar trebui să se termine aici.
Acțiuni suplimentare după incident:
Reevaluarea riscurilor care au dus la incident
întocmirea unei liste de măsuri de protecție pentru a minimiza riscurile identificate în cazul reapariției incidentului
actualizarea politicilor, reglementărilor, regulilor de securitate a informațiilor necesare
organizarea de formare pentru personalul organizației, inclusiv angajații IT, pentru a crește gradul de conștientizare a securității informațiilor
Adică, este necesar să se întreprindă toate acțiunile posibile pentru a minimiza sau neutraliza vulnerabilitatea care a dus la implementarea unei amenințări de securitate și, ca urmare, la apariția unui incident.
1.
Păstrați un jurnal al incidentelor, în care înregistrați ora descoperirii, detaliile angajatului care a descoperit incidentul, categoria incidentului, activele afectate, timpul planificat și efectiv pentru rezolvarea incidentului, precum și munca depusă. pentru a elimina incidentul și consecințele acestuia.
2.
Înregistrați-vă acțiunile. Acest lucru este necesar, în primul rând, pentru dvs., pentru a optimiza procesul de rezolvare a incidentelor.
3.
Notificați angajații despre incident, astfel încât, în primul rând, să nu interfereze cu investigația dvs. și, în al doilea rând, să excludă utilizarea bunurilor afectate în timpul investigației.
Această carte poate fi numită o enciclopedie practică. Acesta oferă o acoperire maximă a problemelor de securitate a informațiilor, începând cu abordări moderne, o privire de ansamblu asupra suportului de reglementare în lume și în Rusia și terminând cu luarea în considerare a domeniilor specifice de securitate a informațiilor (oferirea de securitate a informațiilor perimetrale, contracararea atacurilor, monitorizarea securității informațiilor, privat virtual). rețele și multe altele), soluții hardware și software specifice în acest domeniu. Cartea va fi utilă managerilor de afaceri ai companiilor și celor a căror competență include rezolvarea problemelor tehnice de asigurare a securității informațiilor.
Toate drepturile rezervate. Nicio parte a acestei cărți nu poate fi reprodusă sub nicio formă sau prin orice mijloc, inclusiv postarea pe Internet sau rețelele corporative sau înregistrarea în memoria computerului pentru uz privat sau public, fără permisiunea scrisă a dreptului deținătorului drepturilor de autor. Referitor la problema organizării accesului la biblioteca electronica editorii vă rugăm să contactați
mailto:% [email protected]
În plus, la 26 noiembrie 2004, restul de șase suspecți au fost reținuți, inclusiv trei angajați ai serviciului de abonați al companiei VimpelCom însăși. În timpul anchetei, s-a dovedit că site-ul a fost creat de un fost student al Moscovei universitate de stat care nu a lucrat pentru această companie.
Hârtiile privind acest incident au devenit posibile datorită deciziei Curții Constituționale din 2003, care a recunoscut că detaliile apelurilor conțineau un secret. convorbiri telefonice protejate de lege.
Oportunități din interior
Doi dintre angajații VimpelCom identificați printre participanții la incident lucrau ca casier în companie, iar al treilea era un fost angajat și lucra la piața Mitinsky în momentul crimei.
Lucrul ca casier în cadrul companiei indică faptul că acești angajați aveau acces direct la informațiile oferite spre vânzare pe site-ul www.sherlok.ru. Mai mult, din moment ce fost angajat compania lucra deja pe piața Mitinsky, se poate presupune că în timp această piață ar putea deveni unul dintre canalele de distribuție pentru aceste informații sau orice alte informații din bazele de date ale companiei VimpelCom.
Consecințele
Principalele consecințe pentru VimpelCom ale acestui incident ar putea fi o lovitură adusă reputației companiei în sine și pierderea clienților. Cu toate acestea, acest incident a fost făcut public direct datorită acțiunilor active ale companiei însăși.
În plus, publicarea acestor informații ar putea avea un impact negativ asupra clienților VimpelCom, deoarece detaliile conversațiilor ne permit să tragem o concluzie despre activitățile curente ale abonatului, domeniul său de interes și cercul de cunoștințe.
În martie 2005, Tribunalul Districtual Ostankino din Moscova i-a condamnat pe suspecți, inclusiv trei angajați ai companiei VimpelCom, la diverse amenzi. Astfel, organizatorul grupului a fost amendat cu 93.000 de ruble. Cu toate acestea, funcționarea site-ului www.sherlok.ru a fost oprită pe termen nelimitat abia de la 1 ianuarie 2008.
Cea mai mare scurgere de date personale din istoria Japoniei
Adnotare
În vara lui 2006, a avut loc cea mai mare scurgere de date cu caracter personal din istoria Japoniei: un angajat al gigantului de tipar și electronice Dai Nippon Printing a furat un disc cu informații private de aproape nouă milioane de cetățeni.
Descrierea incidentului
Compania japoneză Dai Nippon Printing, specializată în producție produse de imprimare, a permis cea mai mare scurgere din istoria țării sale. Hirofumi Yokoyama, un fost angajat al unuia dintre contractorii companiei, a copiat datele personale ale clienților companiei pe un hard disk mobil și le-a furat. Un total de 8,64 milioane de persoane au fost în pericol, deoarece informațiile furate includ nume, adrese, numere de telefon și numere de card de credit. Informațiile furate au inclus informații despre clienți de la 43 de companii diferite, cum ar fi 1.504.857 clienți American Home Assurance, 581.293 clienți Aeon Co și 439.222 clienți NTT Finance.
După furtul acestor informații, Hirofumi a deschis comerț cu informații private în porțiuni din 100.000 de înregistrări. Datorită veniturilor stabile, insiderul și-a părăsit chiar locul de muncă permanent. Până la arestarea sa, Hirofumi reușise să vândă datele a 150.000 de clienți ai celor mai mari firme de credit unui grup de escroci specializați în achiziții online. În plus, unele dintre date au fost deja folosite pentru fraudă cu cardul de credit.
Mai mult de jumătate dintre organizațiile cărora le-au fost furate datele clienților nici măcar nu au fost avertizate cu privire la scurgerea de informații.
Consecințele
În urma acestui incident, pierderile cetățenilor care au suferit din cauza fraudei cu cardul de credit, care au devenit posibile doar ca urmare a acestei scurgeri, s-au ridicat la câteva milioane de dolari. În total, clienții a 43 de companii diferite au fost afectați, inclusiv Toyota Motor Corp., American Home Assurance, Aeon Co și NTT Finance. Cu toate acestea, mai mult de jumătate dintre organizații nici măcar nu au fost avertizate cu privire la scurgere.
În 2003, Japonia a adoptat Legea privind protecția informațiilor cu caracter personal din 2003 (PIPA), dar procurorii nu au putut să o aplice în cadrul procedurilor penale efective. acest caz la începutul anului 2007, procuratura nu a reușit să acuze persoana din interior pentru încălcarea PIPA. El este acuzat doar că a furat un hard disk în valoare de 200 de dolari.
Nu este apreciat. Hacker din Zaporojie împotriva unei bănci ucrainene
Adnotare
Un fost administrator de sistem al uneia dintre marile bănci din Ucraina a transferat aproximativ 5 milioane de grivne prin intermediul băncii în care anterior lucra din contul vămii regionale în contul unei inexistente companie falimentară din Dnepropetrovsk.
Descrierea incidentului
Cariera sa de administrator de sistem a început după ce a absolvit școala tehnică și a fost angajat de una dintre marile bănci din Ucraina în software și suport tehnic. După ceva timp, conducerea i-a observat talentul și a decis că va fi mai util băncii ca șef de departament. Cu toate acestea, apariția unui nou management la bancă a presupus și schimbări de personal. I s-a cerut să-și părăsească temporar postul. Curând, noua conducere a început să-și formeze echipa, dar talentul lui s-a dovedit a fi nerevendicat și i s-a oferit postul inexistent de șef adjunct, dar într-un alt departament. Ca urmare a unor astfel de schimbări de personal, a început să facă ceva complet diferit de ceea ce știa cel mai bine.
Administratorul de sistem nu a putut să suporte această atitudine de conducere față de sine și să renunțe la serviciu. după voie. Cu toate acestea, era bântuit de propria mândrie și resentimente față de management, în plus, a vrut să demonstreze că este cel mai bun în afacerea lui și să se întoarcă la departamentul în care și-a început cariera.
După ce a demisionat, fostul administrator de sistem a decis să returneze interesul fostului management față de persoana sa, profitând de imperfecțiunile sistemului „Bank-Client” folosit în aproape toate băncile din Ucraina. Planul administratorului de sistem era ca acesta să decidă să-și dezvolte propriul program de securitate și să-l ofere băncii, revenind la locul de muncă anterior. Implementarea planului a constat în pătrunderea sistemului Bancă-Client și efectuarea unor modificări minime la acesta. Întregul calcul a fost făcut pe baza faptului că banca ar fi descoperit un hack de sistem.
Pentru a pătrunde în sistemul specificat, fostul administrator de sistem a folosit parole și coduri pe care le-a învățat în timp ce lucra cu acest sistem. Toate celelalte informații necesare pentru hacking au fost obținute de pe diverse site-uri de hackeri, unde au fost descrise în detaliu diferite cazuri de hacking retele de calculatoare, tehnici de hacking și conținea tot software-ul necesar pentru hacking.
După ce a creat o lacună în sistem, fostul administrator de sistem a pătruns periodic în sistemul informatic al băncii și a lăsat diverse semne în el, încercând să atragă atenția asupra faptelor de hacking. Specialiștii băncii trebuiau să detecteze hack-ul și să tragă alarma, dar, spre surprinderea lui, nimeni nu a observat nici măcar pătrunderea în sistem.
Apoi administratorul de sistem a decis să-și schimbe planul, făcându-i ajustări care nu puteau trece neobservate. A decis să falsească ordin de platași transferați o sumă mare prin intermediul acestuia prin sistemul informatic al băncii. Folosind un laptop și telefon mobil cu un modem încorporat, administratorul de sistem a pătruns în sistemul informatic al băncii de aproximativ 30 de ori: s-a uitat la documente, conturile clienților, traficul numerar- cautare clienti potriviti. A ales ca atare clienți vama regională și o companie falimentară din Dnepropetrovsk.
După ce a obținut din nou acces la sistemul băncii, a creat un ordin de plată în care cont personal vama regională a retras şi transferat prin intermediul bancii în contul unei companii falimentare 5 milioane grivne. În plus, a făcut intenționat mai multe greșeli în „plată”, care, la rândul lor, ar fi trebuit să ajute și mai mult să atragă atenția specialiștilor bănci. Cu toate acestea, nici măcar astfel de fapte nu au fost observate de specialiștii băncii care deservesc sistemul Bank-Client și au transferat cu calm 5 milioane de grivne în contul unei companii defuncte.
În realitate, administratorul de sistem se aștepta ca fondurile să nu fie transferate, să se descopere faptul hacking-ului înainte ca fondurile să fie transferate, dar în practică totul a ieșit altfel și a devenit infractor, iar transferul său fals a escaladat în furt.
Faptul de hacking și furt de fonduri la scară deosebit de mare a fost descoperit la doar câteva ore de la transfer, când angajații băncii au sunat la vamă pentru a confirma transferul. Dar au raportat că nimeni nu a transferat o asemenea sumă. Banii au fost returnați de urgență băncii, iar un dosar penal a fost deschis la parchetul din regiunea Zaporojie.
Consecințele
Banca nu a suferit nicio pierdere, din moment ce banii au fost restituiți proprietarului, iar sistemul informatic a primit daune minime, drept care conducerea băncii a refuzat orice pretenție împotriva fostului administrator de sistem.
În 2004, prin decretul președintelui Ucrainei, a fost întărită răspunderea penală pentru infracțiunile informatice: amenzi de la 600 la 1000 de minime scutite de taxe, închisoare de la 3 la 6 ani. Cu toate acestea, fostul administrator de sistem a comis o infracțiune înainte de intrarea în vigoare a decretului prezidențial.
La începutul anului 2005 a avut loc un proces al administratorului de sistem. El a fost acuzat de săvârșirea unei infracțiuni în temeiul părții 2 a articolului 361 din Codul penal al Ucrainei - interferență ilegală în funcționarea sistemelor informatice care dăunează și în temeiul părții 5 a articolului 185 - furt comis la scară deosebit de mare. Dar, deoarece conducerea băncii a refuzat să facă vreo pretenție împotriva lui, acuzația de furt a fost înlăturată de la el, iar partea 2 a articolului 361 a fost schimbată în partea 1 - interferență ilegală în funcționarea sistemelor informatice.
Tranzacționare necontrolată la banca Societe Generale
Adnotare
Pe 24 ianuarie 2008, Societe Generale a anunțat o pierdere de 4,9 miliarde de euro din cauza mașinațiunilor comerciantului său Jerome Kerviel. După cum a arătat o investigație internă, de câțiva ani traderul a deschis poziții peste limită în futures pentru indici bursieri europeni. Valoarea totală a pozițiilor deschise s-a ridicat la 50 de miliarde de euro.
Descrierea incidentului
Din iulie 2006 până în septembrie 2007, sistemul de control intern al computerului a emis un avertisment cu privire la posibile încălcări de 75 de ori (de câte ori Jerome Kerviel a efectuat tranzacții neautorizate sau pozițiile sale au depășit limita admisă). Angajații departamentului de monitorizare a riscurilor băncii nu au efectuat verificări detaliate asupra acestor avertismente.
Kerviel a început să experimenteze tranzacțiile neautorizate în 2005. Apoi a luat o poziție scurtă pe acțiunile Allianz, așteptându-se ca piața să scadă. La scurt timp piața a căzut cu adevărat (după atacurile teroriste din Londra), așa că primii 500.000 de euro au fost câștigați. Ulterior, Kerviel le-a povestit anchetatorilor despre sentimentele pe care le-a trăit de la primul său succes: „Știam deja să-mi închid poziția și eram mândru de rezultat, dar în același timp am fost surprins. Succesul m-a făcut să continui, a fost ca un bulgăre de zăpadă... În iulie 2007, mi-am propus să iau o poziție scurtă în așteptarea unui declin al pieței, dar nu am primit sprijin de la managerul meu. Prognoza mea s-a adeverit și am făcut profit, de data aceasta a fost complet legal. Ulterior, am continuat să efectuez astfel de operațiuni pe piață, fie cu acordul superiorilor mei, fie în lipsa obiecției sale explicite... Până la 31 decembrie 2007, profitul meu a ajuns la 1,4 miliarde de euro. În acel moment, nu știam cum să declar asta la banca mea, deoarece era o sumă foarte mare care nu era declarată nicăieri. Eram fericit și mândru, dar nu am știut să explic conducerii mele primirea acestor bani și să nu am suspiciunea de a efectua tranzacții neautorizate. Prin urmare, am decis să-mi ascund profitul și să conduc operațiunea fictivă opusă...”
De fapt, la începutul lunii ianuarie a acelui an, Jerome Kerviel a reintrat în joc cu contracte futures pe cei trei indici Euro Stoxx 50, DAX și FTSE, care l-au ajutat să învingă piața la sfârșitul anului 2007 (deși a preferat să fie scurt la timp). Conform calculelor, în ajunul zilei de 11 ianuarie, portofoliul său conținea 707,9 mii futures (fiecare în valoare de 42,4 mii euro) pe Euro Stoxx 50, 93,3 mii futures (192,8 mii euro pe 1 bucată) pe DAX și 24,2 mii futures (82,7 mii euro). per 1 contract) pentru indicele FTSE. În total, poziția speculativă a lui Kerviel era egală cu 50 de miliarde de euro, adică era mai mult decât valoarea băncii în care a lucrat.
Cunoscând momentul efectuării verificărilor, a deschis la momentul potrivit o poziție de acoperire fictivă, pe care a închis-o ulterior. Drept urmare, recenzenții nu au văzut niciodată o singură poziție care ar putea fi considerată riscantă. Nu ar putea fi alarmați de cantitățile mari de tranzacții, care sunt destul de comune pe piață. contracte futures prin indici. A fost dezamăgit de tranzacțiile fictive efectuate din conturile clienților băncilor. Utilizarea conturilor diverșilor clienți ai băncilor nu a dus la probleme vizibile controlorilor. Cu toate acestea, de-a lungul timpului, Kerviel a început să folosească conturile acelorași clienți, ceea ce a dus la activitate „anormală” observată pe aceste conturi și, la rândul său, a atras atenția controlorilor. Acesta a fost sfârșitul înșelătoriei. S-a dovedit că partenerul lui Kerviel în afacerea de mai multe miliarde de dolari era o mare bancă germană, care ar fi confirmat tranzacția astronomică pe e-mail. Cu toate acestea, confirmarea electronică a stârnit suspiciuni în rândul inspectorilor, iar la Societe Generale a fost creată o comisie care să le verifice. Pe 19 ianuarie, ca răspuns la o solicitare, banca germană nu a recunoscut această tranzacție, după care comerciantul a acceptat să mărturisească.
Când a fost posibil să se afle dimensiunea astronomică a poziției speculative, CEO-ul și președintele consiliului de administrație al Societe Generale, Daniel Bouton, și-a anunțat intenția de a închide poziția riscantă deschisă de Kerviel. Acest lucru a durat două zile și a dus la pierderi de 4,9 miliarde de euro.
Oportunități din interior
Jerome Kerviel a lucrat cinci ani în așa-numitul back office al băncii, adică într-un departament care nu încheie direct nicio tranzacție. Se ocupă doar de contabilitate, executarea și înregistrarea tranzacțiilor și monitorizează comercianții. Această activitate ne-a permis să înțelegem caracteristicile sistemelor de control din bancă.
În 2005, Kerviel a fost promovat. A devenit un adevărat comerciant. În responsabilitățile imediate tânăr au inclus operațiuni de bază pentru a minimiza riscurile. Lucrând pe piața futures a indicilor bursieri europeni, Jerome Kerviel a trebuit să monitorizeze modul în care portofoliul de investiții al băncii se schimbă. Iar sarcina lui principală, după cum a explicat un reprezentant al Societe Generale, a fost să reducă riscurile jucând în direcția opusă: „În linii mari, văzând că banca pariază pe roșu, a trebuit să parieze pe negru”. La fel ca toți comercianții juniori, Kerviel avea o limită pe care nu o putea depăși, aceasta a fost monitorizată de el foști colegiîn back office. Societe Generale avea mai multe straturi de protecție, de exemplu comercianții puteau deschide poziții doar de pe computerul lor de lucru. Toate datele despre pozițiile de deschidere au fost transmise automat în timp real către back office. Dar, după cum se spune, cel mai bun braconier este un fost pădurar. Și banca a făcut o greșeală de neiertat punându-l pe fostul pădurar în postura de vânător. Jérôme Kerviel, care avea aproape cinci ani de experiență în monitorizarea comercianților, nu i-a fost greu să ocolească acest sistem. Știa parolele altora, știa când se făceau verificări la bancă, cunoștea bine tehnologia de informație.
Motive
Dacă Kerviel a fost implicat în fraudă, nu a fost în scopul îmbogățirii personale. Avocații săi spun asta, iar reprezentanții băncii recunosc și ei acest lucru, considerând acțiunile lui Kerviel iraționale. Kerviel însuși spune că a acționat exclusiv în interesul băncii și a vrut doar să-și demonstreze talentele de comerciant.
Consecințele
La sfârșitul anului 2007, activitățile sale au adus băncii un profit de aproximativ 2 miliarde de euro. În orice caz, asta spune însuși Kerviel, susținând că conducerea băncii probabil știa ce face, dar a preferat să închidă ochii atâta timp cât era profitabil.
Închiderea poziției riscante deschise de Kerviel a dus la pierderi de 4,9 miliarde de euro.
În mai 2008, Daniel Bouton a părăsit postul de CEO al Societe Generale, fiind înlocuit în această funcție de Frederic Oudea. Un an mai târziu, a fost nevoit să demisioneze din funcția de președinte al consiliului de administrație al băncii. Motivul plecării sale a fost critica acerbă din partea presei: Bouton a fost acuzat de faptul că managerii de vârf ai băncii aflate sub controlul său au încurajat tranzacțiile financiare riscante efectuate de angajații băncii.
În ciuda sprijinului consiliului de administrație, presiunea asupra domnului Bouton a crescut. Acţionarii băncii şi mulţi politicieni francezi i-au cerut demisia. De asemenea, președintele francez Nicolas Sarkozy i-a cerut lui Daniel Bouton să demisioneze după ce s-a știut că în anul și jumătate dinaintea scandalului, sistemul informatic de control intern al Societe Generale a emis un avertisment de 75 de ori, adică de fiecare dată când Jerome Kerviel a efectuat posibile încălcări neautorizate .
Imediat după ce au fost descoperite pierderile, Societe Generale a creat o comisie specială pentru a investiga acțiunile comerciantului, care includea membri independenți ai consiliului de administrație al băncii și auditorii PricewaterhouseCoopers. Comisia a concluzionat că sistemul de control intern al băncii nu a fost suficient de eficient. Acest lucru a dus la imposibilitatea băncii de a preveni o asemenea fraudă la scară largă. Raportul precizează că „personalul băncii nu a efectuat verificări sistematice” ale activităților comerciantului, iar banca însăși nu avea „un sistem de control care ar putea preveni frauda”.
Raportul privind rezultatele auditului comerciantului arată că în urma rezultatelor investigației s-a luat decizia de „întărire semnificativă a procedurii de supraveghere internă a activităților angajaților Societe Generale”. Acest lucru se va realiza printr-o organizare mai strictă a activității diferitelor divizii ale băncii și coordonarea interacțiunii acestora. De asemenea, vor fi luate măsuri pentru urmărirea și personalizarea operațiunilor de tranzacționare ale angajaților băncii prin „consolidarea sistemului de securitate informatică și dezvoltarea de soluții de înaltă tehnologie pentru identificarea personală (biometrie)”.
