Instrumentele software SIEM (Security Information and Events Management) (Security Information and Events Management) oferă două funcții principale: gestionarea informațiilor de securitate (SIM) și gestionarea evenimentelor, care sunt legate de securitate (managementul evenimentelor de securitate - SEM).

siem

Sistemele de colectare a jurnalelor (syslog și gestionarea evenimentelor) au interfețe cu servere, switch-uri, firewall-uri și multe alte tipuri de dispozitive, sisteme de operare și aplicații. Mesajele care sosesc în matricile de jurnalizare au diferite formate.

Funcționalitatea SIEM

Funcțiile principale ale SIEM pot fi rezumate în următoarea listă:

1. Colectare - acceptarea intrărilor de jurnal de pe platforme la distanță și înregistrarea într-o matrice locală, prin intermediari numiți colectoare și conectori.

2. Agregare - evenimentele legate sunt agregate pentru a evita notificările repetate ale aceluiași eveniment real dintr-un singur motiv.

3. Anonimatul pentru a păstra confidențialitatea - este posibil ca anumite evenimente să fie pre-procesate pentru a împiedica divulgarea anumitor informații.

4. Normalizare - textele mesajelor sunt traduse într-un format unificat.

5. Corelația - funcția principală îndeplinită de SIEM, detectează dependențele dintre evenimentele care formează un incident de securitate, în urma căruia este activată o schemă de răspuns.

6. Inteligență și cunoștințe cu modele de detectare a atacurilor [6].

7. Managementul răspunsului - o funcție care oferă măsuri tehnice și organizaționale ca răspuns la un incident. Funcționarii efectuează proceduri și mijloace tehnice - scripturi și operațiuni care opresc accesul, opresc sistemele, izolează segmente de rețea etc.

8. Pluginuri pentru a menține conformitatea cu standarde precum PCI-DSS sau HIPAA.

9. Rapoarte de stare [1], [7], care sunt generate și generate manual în caz de investigație a incidentului sau sunt planificate pentru trimiterea automată.

Partajarea jurnalelor între chiriașii serviciilor cloud

Utilizatorii de servicii cloud se confruntă cu furnizorii de servicii cloud cu nevoile lor de acces la intrările din jurnal. Jurnalele conțin informații sensibile care îi îngrijorează pe toți cei implicați în ciclul de viață al serviciului.

Prima etapă a unui atac cibernetic este informația țintă, iar revistele reprezintă o comoară pentru criminali. Accesul la jurnalele unui sistem le oferă date pe care nu le pot dezvălui prin sondarea rețelei și scanarea sistemelor individuale - nume de utilizator, parole și multe altele.

Intrările de jurnal pot fi utilizate pentru a identifica mașinile infectate cu malware sau securitate configurată inacceptabil.

Opinia predominantă este că barierele în calea partajării înregistrărilor jurnalului se bazează pe probleme tehnice și apoi pe nuanțe sociale. [8].

Figura 1 prezintă o versiune ușoară a intereselor clienților cloud față de informațiile generate și conținute în fișierele jurnal. Publicațiile pe această temă abordează problemele jurnalismului referitoare la coabitarea mai multor chiriași ai serviciului, dar rareori comentează cu privire la partajarea fișierelor jurnal între chiriași și furnizorii de servicii cloud.

Analiza diferențelor în procesul de gestionare a înregistrărilor jurnalului arată că atunci când angajează diferite modele de servicii cloud, este necesar ca organizațiile să cunoască și să diferențieze produsele în ceea ce privește funcționalitatea lor legată de SIEM. Concluziile la care am ajuns cu această ocazie sunt sistematizate în Tabelul 1.

Distincția prezentată acolo a fost ajutată de publicarea lui Terry Roberts și a co-autorilor [Eroare: Sursa de referință nu a fost găsită], unde într-un cuvânt este definită atitudinea organizațiilor față de diferitele modele de servicii cloud, și anume:

SaaS și PaaS sunt disponibile pe piață, care sunt construite pe o resursă închiriată. Un furnizor care oferă SaaS a angajat IaaS sau doar PaaS și a construit SaaS pe această resursă. Imaginea reală este mult mai complicată, deoarece există furnizori numiți agregatori care au angajat resurse de la multe alte DOE-uri diferite. Ca o consecință a acestei situații, există date în jurnalele furnizorului despre procesele din hipervizor care privesc toți utilizatorii finali, de exemplu:

Operațiuni cu mașini virtuale - copiere, mișcare, oprire a unui nod dintr-un cluster;

Acțiuni ale utilizatorilor privilegiați în mijlocul hipervizorului.

Pentru a fi furnizate clientului final, aceste date trebuie să fie suficient de depersonalizate sau mascate, astfel încât să nu afecteze alți chiriași și furnizori.

PaaS are mare nevoie de partajare publică și operațională a încălcărilor de securitate între platforme, deoarece compromiterea unei platforme ar trebui să alerteze pe toți ceilalți din același mediu, mai ales dacă sunt clone ale aceleiași mașini virtuale, dar aparțin unor chiriași diferiți.

Partajarea intrărilor de jurnal între chiriașii cloud și furnizorii de servicii cloud necesită anonimizarea și filtrarea datelor. Furnizorul poate oferi o vizualizare a unui utilizator individual la intrările din jurnalul de bord ale hipervizorului sau ale consolei de administrare a mașinii virtuale, dar numai datele referitoare la relația contractuală dintre cele două părți pot fi văzute acolo. De exemplu, care dintre angajații furnizorului au operat un serviciu SaaS și au văzut conținutul bazei de date, dar fără a vedea de la ce adrese IP s-au conectat. Situația este similară cu celelalte două modele de servicii cloud.

Există o nevoie tot mai mare de sisteme SIEM care să acopere mai multe infrastructuri TIC și să realizeze o acoperire globală. Pentru ca soluțiile de securitate să fie eficiente în astfel de infrastructuri complexe, pe scară largă, multi-chiriași și distribuite, acestea trebuie să includă mecanisme automate pentru a asigura un nivel macro de gestionare a fluxului de informații între modulele de bază, cum ar fi: între straturi cu fiabilitate diferită, din straturi de capăt neprotejate către nucleul mai protejat; între straturile unui nivel cu aplicarea mecanismelor de îmbunătățire a rezistenței [7].

Indiferent ce modele de servicii (SaaS, PaaS și IaaS) utilizează organizațiile, arhitectura sistemelor lor TIC este întotdeauna combinată cu rețele locale și cloud computing.

Modificări la SIEM după adaptarea la serviciile cloud

Diferitele modele de servicii cloud pe care organizațiile le adoptă definesc arhitecturi diferite ale sistemelor lor TIC și își pun în mod firesc amprenta asupra sferei, funcționalității și organizării operațiunilor pentru SIEM.

Cu SaaS, întreaga infrastructură SIEM existentă a organizației rămâne în mâinile sale. Furnizorul își menține propriul SIEM și, în cel mai bun caz, trimite jurnale filtrate fiecărui client.

Lăsați organizația să aibă contracte SaaS cu un număr de furnizori N. Fișierele jurnal care îl privesc sunt împrăștiate în cel puțin N noduri la distanță până când una dintre aplicațiile închiriate este mutată în următorul centru de date. Acest proces continuă în mod natural, ceea ce este o caracteristică normală a cloud computing-ului. Este deja dificil să ne imaginăm cum se schimbă operațiunile tipice SIEM în acest caz:

filtrarea fișierelor de mesaje jurnal;

detectarea atacurilor corelate;

detectarea anomaliilor în comportamentul sistemelor individuale;

depistarea acțiunilor ilegale;

detectarea potențialelor evenimente de slăbire a securității - actualizare neterminată a sistemului de operare, program antivirus etc;

reacție în caz de accident.

Să presupunem că avem o organizație de utilizatori SaaS. Există două scenarii posibile pentru relația dintre client și furnizorul de servicii cloud:

în prima, furnizorul agregă fișierele jurnal din infrastructura pe care o gestionează, filtrează partea care ține de aplicația client și o copieză pe un canal de comunicații. De acolo, clientul acceptă înregistrările care îl privesc și efectuează audituri, analize, corelații. În acest caz, atât clientul, cât și furnizorul pot efectua audituri, analize, verificări pentru atacuri corelate, dar primul va avea doar o parte din tabloul general.

În cea de-a doua opțiune, clientul este privat de acces la intrările din jurnal.

Opțiunile de procesare a jurnalelor considerate sunt complicate de diferitele scheme taxonomice existente pentru formate de fișiere jurnal, șabloane de detectare a atacurilor, limbaje de descriere a alarmelor de evenimente și atacuri corelate. Diferenți producători de pe piață mențin acorduri diferite adoptate în anumite comunități și, pentru a fi andocate, sunt necesare costuri suplimentare pentru recodarea formatelor de mesaje.

Scurtă listă de verificare a Dr. Anton Chuvakin și Lenny Zeltzer [9] este destinată sistemelor TIC convenționale. Comparând fiecare secțiune a acestuia cu cerințele C2, vedem că arhitectura și funcțiile SIEM și SIM convenționale nu îndeplinesc condițiile pentru funcționarea TIC, care includ servicii cloud:

intrările din jurnal nu sunt etichetate pentru distribuire către mulți utilizatori finali ai serviciilor C2;

nu există mecanisme pentru corelarea timpului evenimentului și înregistrării în cazul în care serviciul sau mașina virtuală sunt mutate în diferite centre de date ale DOE;

SIEM în sine nu este conceput pentru a aloca evenimente multor clienți pe baza trasării granulare a fiecăruia dintre utilizatorii unei organizații client;

mesajele nu sunt populate cu mesajele care conțin caracteristici specifice serviciului cloud - de exemplu, eșecul mutării serviciului după un accident, schimbarea adresei IP după mutarea unei mașini virtuale într-un alt centru de date etc.

Gestionarea evenimentelor de securitate în cloud

Pot apărea evenimente corelate care sunt asociate cu VM Escape și VM Introspection. Cu toate acestea, cel mai bine vor fi înregistrate atât de furnizor, cât și de client și vor părea aparent independente. Nu am găsit cercetări sau dezvoltări practice pentru a trata corelația evenimentelor, dintre care unele apar pe de o parte în mașinile virtuale și în rețeaua virtuală a clientului și o altă parte - în hipervizorul administrat de furnizor.

Urmează următoarele întrebări:

cine deține datele de atac ale aplicației atunci când este atacat un serviciu SaaS. În cazul în care furnizorul informează clientul în caz de atac și distruge datele din jurnalele care îl privesc după încheierea relației contractuale cu clientul său?

Reacțiile la accidente nu pot fi automatizate, deoarece aplicația nu poate fi oprită de utilizator.

dacă furnizorul detectează un incident, acesta trebuie să oprească aplicația și să facă serviciul inaccesibil tuturor utilizatorilor. În funcție de atac, serviciul poate continua cu copii ale aplicației care nu sunt afectate.

Recomandări

Pe baza experienței noastre empirice în domeniu, recomandăm organizațiilor care migrează către serviciile de căutare cloud, iar producătorii de produse SIEM oferă în cloud:

Serviciile SIEM și SIM, care se bazează în cloud, dar în conformitate cu particularitățile arhitecturii modelelor de servicii cloud;

Conectori și colectoare încorporate pentru jurnale de servicii cloud, interfețe la care să fie oferite clienților ca părți opționale ale produsului;

Acces filtrat al clienților la sistemul de reviste DOU - online și în arhive;

Dezvoltarea problemelor de mai sus a condus la propunerea către IETF pentru „extensia Syslog pentru cloud folosind date structurate syslog” de S. Johnston G. Golovinsky. În cloud computing, situația cu disponibilitatea și fiabilitatea revistelor este diferită. Mașinile virtuale pot fi activate și oprite foarte repede într-o perioadă scurtă de timp, oricând acestea sunt partajate nu numai între diferiți utilizatori, ci și între diferiți utilizatori din diferite companii. Deși mașinile virtuale continuă să-și înregistreze activitatea, informațiile nu pot fi legate de un mediu fizic specific. Chiar dacă se face o astfel de încercare, nu este sigur că aceeași mașină virtuală va funcționa pe același hardware și hipervizor în următoarea sa reîncarnare.

În această situație, nu există o modalitate clară de a determina câți utilizatori partajează hardware și care sunt identitățile și rolurile lor. Urmărirea modificărilor din mediu este practic imposibilă, cu excepția cazului în care se stabilește o schemă de înregistrare a corespondenței dintre resursele fizice și virtuale [3].

Același document propune date structurate pentru:

1. Identitatea utilizatorului autentificat înainte de serviciu (RUI).

2. Utilizatorul efectiv sau depersonalizat (EUI), identitatea utilizatorului în numele căruia se prezintă utilizatorul real. De exemplu, conturile altor utilizatori pot fi depersonalizate în numele administratorului sau un utilizator obișnuit își poate intensifica drepturile de root.

3. Furnizor - domeniu, serviciu etc. [3].

In concluzie

Dezvoltarea modernă a sistemelor SIEM nu este suficientă pentru a proteja datele care identifică personal utilizatorii. Meta-sistemele precum SIEM nu includ în prezent metode pentru a asigura confidențialitatea datelor cu caracter personal - ceea ce duce la un risc pentru confidențialitate, inclusiv încălcarea reglementărilor UE în transferurile transfrontaliere [4].

Organizațiile pot acorda, de asemenea, atenție analizei comparative a operațiilor de corelare a evenimentelor centralizate și distribuite în [5]. Soluțiile distribuite sunt potrivite pentru analiza evenimentelor în timp real, iar dificultățile de configurare a acestora sunt mai mari.

Surse:

[1] Volumul II - GHID DE UTILIZARE SENTINEL. Novell Inc., 404 Wyman Street, Suite 500, Waltham, MA 02451, S.U.A., 2008.

[2] Terry Roberts Frances Fragos Townsend. Cloud computing: riscuri, beneficii și îmbunătățirea misiunii pentru comunitatea de informații. Raport tehnic, INSA: Intelligence and National Security Alliance CLOUD COMPUTING TASK FORCE, martie 2012.

[3] S. Johnston G. Golovinsky. Extensie Syslog pentru cloud folosind schița de date structurate syslog draft-golovinsky-cloud-services-log-format-03. aprilie 2013.

[4] Dr. Andrew Hutchison. Implicații privind confidențialitatea pentru generațiile următoare și alte meta-sisteme. În Atelierul privind serviciile de securitate și confidențialitate în Orizont, 19 aprilie 2013, Bruxelles, aprilie 2013.

[5] Justin Myers. O metodologie de detectare a evenimentelor de securitate distribuită bazată pe jurnal configurabilă dinamic, utilizând un simplu corelator de evenimente. AFIT/GCO/ENV/10-J02, DEPARTAMENTUL FORȚEI AERIENE, UNIVERSITATEA AERIANĂ, INSTITUTUL DE TEHNOLOGIE A PORTULUI AERIAN Baza Forțelor Aeriene Wright-Patterson, Ohio, iunie 2010.

[6] NetIQ. Consilier sentinelă Novell. 2008.

[7] Alysson Bessani (FFCUL) Paulo Verissimo (FFCUL) Nuno Neves (FFCUL), Antonio Costa (FFCUL). Gestionarea informațiilor de securitate și a evenimentelor din infrastructura de servicii masiv fp7-257475 d5.1.1 - arhitectură cadru preliminar rezistent. Septembrie 2011.

[8] Adam J. Slagell, Yifan Li, Katherine Luo și I. Introducere. Partajarea jurnalelor de rețea pentru computerul criminalistic: un nou instrument pentru anonimizarea înregistrărilor NetFlow. În Proceedings of the Computer Network Forensics Research Workshop, septembrie 2005.

[9] Lenny Zeltser și Anton Chuvakin. Lista de verificare a revizuirii jurnalelor critice pentru incidentele de securitate.

În număr

Înregistrați-vă și obțineți acces la cele mai noi știri și tendințe din lumea tehnologiei din țara noastră