Bună ziua, în articolele anterioare ne-am familiarizat cu munca ELK Stack. Și acum vom discuta despre posibilitățile pe care le poate realiza un specialist în securitatea informațiilor în utilizarea acestor sisteme. Ce jurnale pot și ar trebui adăugate la elasticsearch. Să luăm în considerare ce statistici pot fi obținute prin configurarea tablourilor de bord și dacă există un profit în acest sens. Cum pot implementa automatizarea proceselor de securitate a informațiilor folosind stiva ELK. Să creăm arhitectura sistemului. În concluzie, implementarea tuturor funcționalităților este o sarcină foarte mare și dificilă, așa că soluției i s-a dat un nume separat - TS Total Sight.
În prezent, soluțiile care consolidează și analizează incidentele de securitate a informațiilor într-un singur loc logic câștigă popularitate, drept urmare, un specialist primește statistici și un front de acțiune pentru îmbunătățirea stării de securitate a informațiilor într-o organizație. Ne-am propus o astfel de sarcină în utilizarea stivei ELK, ca urmare, am evidențiat funcționalitatea principală în 4 secțiuni:
- Statistică și vizualizare;
- Detectarea incidentelor IS;
- Prioritizarea incidentelor;
- Automatizarea proceselor de securitate a informațiilor.
Să aruncăm o privire mai atentă la fiecare în detaliu.
Detectarea incidentelor de securitate a informațiilor
Sarcina principală în utilizarea elasticsearch în cazul nostru este de a colecta doar incidente de securitate a informațiilor. Puteți colecta incidente de securitate a informațiilor din orice mijloc de protecție dacă acceptă cel puțin unele moduri de transfer de jurnal, cel standard este salvarea syslog sau scp într-un fișier.
Puteți da exemple standard de instrumente de protecție și nu numai de unde ar trebui să configurați redirecționarea jurnalelor:
- Orice fonduri NGFW (Check Point, Fortinet);
- Orice scanere de vulnerabilitate (PT Scanner, OpenVas);
- Web Application Firewall (PTAF);
- Analizoare Netflow (Flowmon, Cisco StealthWatch);
- Server AD.
Odată ce ați configurat Logstash pentru a trimite jurnalele și fișierele de configurare, puteți corela și compara cu incidentele care provin din diverse instrumente de securitate. Pentru a face acest lucru, este convenabil să folosim indexuri, în care vom stoca toate incidentele legate de un anumit dispozitiv. Cu alte cuvinte, un index reprezintă toate incidentele pentru un dispozitiv. Această distribuție poate fi implementată în două moduri.
Prima opțiune este de a configura Logstash config. Pentru a face acest lucru, trebuie să duplicați jurnalul pentru anumite câmpuri într-o unitate separată cu un tip diferit. Și apoi folosiți mai târziu acest tip. Exemplul clonează jurnalele din blade IPS al firewall-ului Check Point.
filter {
if [product] == "SmartDefense" {
clone {
clones => ["CloneSmartDefense"]
add_field => {"system" => "checkpoint"}
}
}
}
Pentru a stoca astfel de evenimente într-un index separat în funcție de câmpurile jurnalelor, de exemplu, cum ar fi IP-ul de destinație al semnăturii de atac. Puteți utiliza o construcție similară:
output {
if [type] == "CloneSmartDefense"{
{
elasticsearch {
hosts => [",<IP_address_elasticsearch>:9200"]
index => "smartdefense-%{dst}"
user => "admin"
password => "password"
}
}
}
Și în acest fel, puteți salva toate incidentele în index, de exemplu, după adresa IP, sau după numele de domeniu al mașinii. În acest caz, stocăm în index „smartdefense-%{dst}”, după adresa IP a destinației semnăturii.
Cu toate acestea, diferite produse vor avea câmpuri de jurnal diferite, ceea ce va duce la haos și la pierderea memoriei. Și aici va fi necesar fie să înlocuiți cu atenție câmpurile din setările de configurare Logstash cu unele pre-proiectate, care vor fi aceleași pentru toate tipurile de incidente, ceea ce este și o sarcină dificilă.
A doua opțiune de implementare - aceasta este scrierea unui script sau proces care va accesa baza elastică în timp real, va scoate incidentele necesare și le va salva într-un nou index, aceasta este o sarcină dificilă, dar vă permite să lucrați cu jurnalele după cum doriți și se corelează direct cu incidentele din alte instrumente de securitate. Această opțiune vă permite să personalizați munca cu jurnalele cât mai utile pentru cazul dvs. cu flexibilitate maximă, dar aici există o problemă în găsirea unui specialist care să poată implementa acest lucru.
Și, desigur, cea mai importantă întrebare ce poate fi corelat și detectat?
Pot exista mai multe opțiuni aici și, în funcție de instrumentele de securitate utilizate în infrastructura dvs., câteva exemple:
- Cea mai evidentă și din punctul meu de vedere cea mai interesantă opțiune pentru cei care au o soluție NGFW și un scanner de vulnerabilități. Aceasta este o comparație a jurnalelor IPS și a rezultatelor scanării vulnerabilităților. Dacă un atac a fost detectat (nu blocat) de către sistemul IPS și această vulnerabilitate nu este închisă pe mașina finală pe baza rezultatelor scanării, este necesar să aruncați în aer toate conductele, deoarece există o probabilitate mare ca vulnerabilitatea să fie exploatat.
- Multe încercări de conectare de la o singură mașină în locuri diferite pot simboliza activitate rău intenționată.
- Descărcarea fișierelor cu virusuri de către utilizator datorită vizitei unui număr mare de site-uri potențial periculoase.
Statistică și vizualizare
Scopul cel mai evident și de înțeles al stivei ELK este stocarea și vizualizarea jurnalelor, s-a arătat cum puteți obține jurnalele de pe diferite dispozitive folosind Logstash. După ce jurnalele ajung la Elasticsearch, puteți configura tablouri de bord, care au fost și ele menționate , cu informațiile și statisticile de care aveți nevoie prin vizualizare.
Exemple:
- Tabloul de bord al evenimentelor de prevenire a amenințărilor cu cele mai critice evenimente. Aici puteți reflecta ce semnături IPS au fost detectate, de unde provin acestea din punct de vedere geografic.
- Tabloul de bord privind utilizarea celor mai critice aplicații pentru care informațiile pot fi scurse.
- Rezultatele scanării de la orice scaner de securitate.
- Jurnalele din Active Directory de către utilizatori.
- Tabloul de bord pentru conexiunea VPN.
În acest caz, dacă configurați tablouri de bord pentru a se actualiza la fiecare câteva secunde, puteți obține un sistem destul de convenabil de monitorizare a evenimentelor în timp real, care poate fi apoi folosit pentru a răspunde cât mai repede posibil la incidentele de securitate a informațiilor dacă puneți tablouri de bord pe o ecran separat.
Prioritizarea incidentelor
În condițiile unei infrastructuri mari, numărul de incidente poate depăși scara, iar specialiștii nu vor avea timp să analizeze toate incidentele la timp. În acest caz, este necesar în primul rând să evidențiem doar acele incidente care reprezintă o mare amenințare. Prin urmare, sistemul trebuie să prioritizeze incidentele în funcție de gravitatea lor în raport cu infrastructura dumneavoastră. Este recomandabil să setați o notificare în e-mail sau telegrame a acestor evenimente. Prioritizarea poate fi implementată folosind instrumentele obișnuite Kibana, prin configurarea vizualizării. Dar cu o notificare este mai greu, implicit această funcționalitate nu este inclusă în versiunea de bază a Elasticsearch, doar în versiunea plătită. Prin urmare, fie cumpărați o versiune plătită, fie, din nou, scrieți singur un proces care va anunța specialiștii în timp real prin poștă sau telegramă.
Automatizarea proceselor de securitate a informațiilor
Iar una dintre cele mai interesante părți este automatizarea acțiunilor pentru incidentele de securitate a informațiilor. Anterior, am implementat această funcționalitate pentru Splunk, puteți citi puțin mai multe în aceasta . Ideea de bază este că politica IPS nu este niciodată testată sau optimizată, deși în unele cazuri este o parte esențială a proceselor de securitate a informațiilor. De exemplu, la un an de la implementarea NGFW și absența acțiunilor de optimizare a IPS, veți acumula un număr mare de semnături cu acțiunea Detect care nu vor fi blocate, ceea ce reduce foarte mult starea securității informațiilor din organizație. Iată câteva exemple de ceea ce poate fi automatizat:
- Comutarea semnăturii IPS de la Detect la Prevent. Dacă Prevent nu funcționează pe semnăturile critice, atunci acest lucru este în neregulă și o încălcare gravă a sistemului de protecție. Schimbăm acțiunea din politică la astfel de semnături. Această funcționalitate poate fi implementată dacă dispozitivul NGFW are funcționalitatea REST API. Acest lucru este posibil numai dacă aveți abilități de programare, trebuie să extrageți informațiile necesare din Elastcisearch și să executați solicitări API către serverul de control NGFW.
- Dacă au fost detectate sau blocate o mulțime de semnături în traficul de rețea de la o adresă IP, atunci este logic să blocați această adresă IP pentru ceva timp în politica Firewall. Implementarea constă și în utilizarea API-ului REST.
- Lansați o scanare a gazdei cu un scaner de vulnerabilități dacă această gazdă are un număr mare de semnături pentru IPS sau alte instrumente de securitate, dacă este OpenVas, atunci puteți scrie un script care se va conecta prin ssh la scanerul de securitate și rula scanarea.
TS Total Sight
În concluzie, implementarea tuturor funcționalităților este o sarcină foarte mare și dificilă. Fără abilități de programare, puteți configura funcționalitatea minimă, care poate fi suficientă pentru utilizare în productivitate. Dar dacă sunteți interesat de toată funcționalitatea, puteți acorda atenție TS Total Sight. Puteți găsi mai multe detalii pe site-ul nostru . Ca rezultat, întreaga schemă de lucru și arhitectură va arăta astfel:
Concluzie
Ne-am uitat la ce poate fi implementat folosind ELK Stack. În articolele ulterioare, vom lua în considerare separat și mai detaliat funcționalitatea TS Total Sight!
Așa că rămâneți pe fază, , , ), .
Sursa: www.habr.com