Goeiemiddag, in vorige artikels het ons kennis gemaak met die werk van die ELK Stack. En nou sal ons die moontlikhede bespreek wat deur 'n inligtingsekuriteitspesialis in die gebruik van hierdie stelsels gerealiseer kan word. Watter logs kan en moet by elasticsearch gevoeg word. Kom ons kyk na watter statistieke verkry kan word deur dashboards op te stel en of daar wins hierin is. Hoe kan ek outomatisering van inligtingsekuriteitsprosesse implementeer deur die ELK-stapel te gebruik. Kom ons skep die argitektuur van die stelsel. Kortom, die implementering van al die funksionaliteit is 'n baie groot en moeilike taak, so die oplossing is 'n aparte naam gegee - TS Total Sight.
Tans word oplossings wat inligtingsekuriteitsvoorvalle op een logiese plek konsolideer en ontleed, gewild, gevolglik ontvang 'n spesialis statistieke en 'n front vir aksie om die stand van inligtingsekuriteit in 'n organisasie te verbeter. Ons het vir onsself so 'n taak gestel deur die ELK-stapel te gebruik, gevolglik het ons die hooffunksies in 4 afdelings uitgesonder:
- Statistiek en visualisering;
- IS voorval opsporing;
- Prioritisering van insidente;
- Outomatisering van inligtingsekuriteitsprosesse.
Kom ons kyk na elkeen in meer detail.
Opsporing van inligtingsekuriteitsinsident
Die hooftaak in die gebruik van elasticsearch in ons geval is om slegs inligtingsekuriteitsvoorvalle te versamel. U kan inligtingsekuriteitsvoorvalle vanaf enige beskermingsmiddel insamel as dit ten minste sommige log-oordragmodusse ondersteun, die standaard een is syslog of scp om na 'n lêer te stoor.
U kan standaardvoorbeelde van beskermingsinstrumente gee en nie net van waar u die aanstuur van logs moet opstel nie:
- Enige NGFW-fondse (Check Point, Fortinet);
- Enige kwesbaarheidskandeerders (PT Scanner, OpenVas);
- Web Application Firewall (PTAF);
- Netvloei-ontleders (Flowmon, Cisco StealthWatch);
- AD-bediener.
Sodra jy Logstash opgestel het om logs en konfigurasielêers te stuur, kan jy korreleer en vergelyk met voorvalle wat van verskeie sekuriteitsnutsmiddels af kom. Om dit te doen, is dit gerieflik om indekse te gebruik, waarin ons alle voorvalle wat verband hou met 'n spesifieke toestel sal stoor. Met ander woorde, een indeks is alle voorvalle vir een toestel. Hierdie verspreiding kan op twee maniere geïmplementeer word.
Die eerste opsie is om Logstash-konfigurasie op te stel. Om dit te doen, moet jy die logboek vir sekere velde in 'n aparte eenheid met 'n ander tipe dupliseer. En gebruik dan later hierdie tipe. Die voorbeeld kloon logs vanaf die IPS-lem van die Check Point-brandmuur.
filter {
if [product] == "SmartDefense" {
clone {
clones => ["CloneSmartDefense"]
add_field => {"system" => "checkpoint"}
}
}
}
Om sulke gebeurtenisse in 'n aparte indeks te stoor, afhangende van die velde van die logs, byvoorbeeld, soos die bestemmings-IP van die aanvalhandtekening. Jy kan 'n soortgelyke konstruksie gebruik:
output {
if [type] == "CloneSmartDefense"{
{
elasticsearch {
hosts => [",<IP_address_elasticsearch>:9200"]
index => "smartdefense-%{dst}"
user => "admin"
password => "password"
}
}
}
En op hierdie manier kan u alle insidente in die indeks stoor, byvoorbeeld volgens IP-adres, of volgens die domeinnaam van die masjien. In hierdie geval stoor ons in die indeks "smartdefense-%{dst}", deur die IP-adres van die handtekeningbestemming.
Verskillende produkte sal egter verskillende logvelde hê, wat chaos en vermorsde geheue tot gevolg het. En hier sal dit nodig wees om die velde in die Logstash-konfigurasie-instellings versigtig te vervang met vooraf-ontwerpte, wat dieselfde sal wees vir alle soorte voorvalle, wat ook 'n moeilike taak is.
Tweede implementering opsie - dit is die skryf van 'n skrif of proses wat intyds toegang tot die elastiese basis sal kry, die nodige insidente sal uittrek en dit in 'n nuwe indeks sal stoor, dit is 'n moeilike taak, maar dit laat jou toe om met die logs te werk soos jy wil , en korreleer direk met voorvalle van ander sekuriteitsinstrumente. Hierdie opsie laat jou toe om die werk met logs so nuttig as moontlik vir jou saak aan te pas met maksimum buigsaamheid, maar hier is daar 'n probleem om 'n spesialis te vind wat dit kan implementeer.
En natuurlik die belangrikste vraag wat gekorreleer en opgespoor kan word?
Daar kan verskeie opsies hier wees, en afhangende van watter sekuriteitsinstrumente in u infrastruktuur gebruik word, 'n paar voorbeelde:
- Die mees voor die hand liggende en uit my oogpunt die interessantste opsie vir diegene wat 'n NGFW-oplossing en 'n kwesbaarheidskandeerder het. Dit is 'n vergelyking van IPS-logboeke en resultate van kwesbaarheidskandering. As 'n aanval deur die IPS-stelsel opgespoor is (nie geblokkeer nie), en hierdie kwesbaarheid is nie op die eindmasjien gesluit op grond van die resultate van die skandering nie, is dit nodig om alle pype te blaas, aangesien daar 'n hoë waarskynlikheid is dat die kwesbaarheid was uitgebuit.
- Baie aanmeldpogings van een masjien na verskillende plekke kan kwaadwillige aktiwiteite simboliseer.
- Die aflaai van viruslêers deur die gebruiker as gevolg van die besoek van 'n groot aantal potensieel gevaarlike werwe.
Statistiek en visualisering
Die mees voor die hand liggende en verstaanbare doel van die ELK Stack is die berging en visualisering van logs, dit is gewys hoe jy logs van verskeie toestelle kan kry deur Logstash te gebruik. Nadat die logs na Elasticsearch gegaan het, kan u dashboards opstel, wat ook genoem is , met die inligting en statistieke wat jy nodig het deur visualisering.
Voorbeelde:
- Dashboard van Threat Prevention-gebeure met die mees kritieke gebeurtenisse. Hier kan jy weerspieël watter IPS-handtekeninge opgespoor is, waar hulle geografies vandaan kom.
- Dashboard oor die gebruik van die mees kritieke toepassings waarvoor inligting uitgelek kan word.
- Skandeer resultate vanaf enige sekuriteitskandeerder.
- Logs van Active Directory deur gebruikers.
- VPN-verbindingspaneelbord.
In hierdie geval, as jy dashboards opstel om elke paar sekondes op te dateer, kan jy 'n redelik gerieflike stelsel kry om gebeure in reële tyd te monitor, wat dan gebruik kan word om so vinnig as moontlik op inligtingsekuriteitsinsidente te reageer as jy dashboards op 'n aparte skerm.
Voorval prioritisering
In toestande van 'n groot infrastruktuur kan die aantal voorvalle van skaal afgaan, en spesialiste sal nie tyd hê om alle voorvalle betyds te ontleed nie. In hierdie geval is dit eerstens nodig om slegs daardie voorvalle wat 'n groot bedreiging inhou, uit te sonder. Daarom moet die stelsel insidente prioritiseer volgens hul erns in verhouding tot jou infrastruktuur. Dit is raadsaam om 'n kennisgewing in die pos of telegramme van hierdie gebeure op te stel. Prioritisering kan geïmplementeer word deur gebruik te maak van gewone Kibana-instrumente deur visualisering op te stel. Maar met 'n kennisgewing is dit moeiliker, by verstek is hierdie funksionaliteit nie ingesluit in die basiese weergawe van Elasticsearch nie, slegs in die betaalde een. Koop dus 'n betaalde weergawe, of skryf weer self 'n proses wat spesialiste intyds per pos of telegram in kennis sal stel.
Outomatisering van inligtingsekuriteitsprosesse
En een van die interessantste dele is die outomatisering van aksies vir inligtingsekuriteitvoorvalle. Voorheen het ons hierdie funksionaliteit vir Splunk geïmplementeer, jy kan 'n bietjie meer hierin lees . Die basiese idee is dat die IPS-beleid nooit getoets of geoptimaliseer word nie, hoewel dit in sommige gevalle 'n noodsaaklike deel van inligtingsekuriteitsprosesse is. Byvoorbeeld, 'n jaar na die implementering van NGFW en die afwesigheid van aksies om IPS te optimaliseer, sal jy 'n groot aantal handtekeninge ophoop met die Detect-aksie wat nie geblokkeer sal word nie, wat die toestand van inligtingsekuriteit in die organisasie aansienlik verminder. Hier is 'n paar voorbeelde van wat geoutomatiseer kan word:
- Verander die IPS-handtekening van Bespeur na Voorkom. As Prevent nie op kritieke handtekeninge werk nie, is dit buite werking en 'n ernstige oortreding in die beskermingstelsel. Ons verander die optrede in die beleid na sulke handtekeninge. Hierdie funksionaliteit kan geïmplementeer word as die NGFW-toestel die REST API-funksionaliteit het. Dit is slegs moontlik as jy programmeringsvaardighede het, jy moet die nodige inligting uit Elastcisearch haal en API-versoeke na die NGFW-beheerbediener uitvoer.
- As baie handtekeninge opgespoor of geblokkeer is in netwerkverkeer vanaf een IP-adres, is dit sinvol om hierdie IP-adres vir 'n geruime tyd in die Firewall-beleid te blokkeer. Die implementering bestaan ook uit die gebruik van die REST API.
- Begin 'n gasheerskandering met 'n kwesbaarheidskandeerder as hierdie gasheer 'n groot aantal handtekeninge vir IPS of ander sekuriteitsinstrumente het, as dit OpenVas is, dan kan u 'n skrip skryf wat via ssh aan die sekuriteitskandeerder sal koppel en die skandering uitvoer.
TS Total Sight
Kortom, die implementering van al die funksionaliteit is 'n baie groot en moeilike taak. Sonder programmeringsvaardighede kan jy die minimum funksionaliteit opstel, wat genoeg kan wees vir gebruik in produktiwiteit. Maar as jy belangstel in al die funksionaliteit, kan jy aandag gee aan TS Total Sight. Jy kan meer besonderhede op ons vind . As gevolg hiervan sal die hele skema van werk en argitektuur soos volg lyk:
Gevolgtrekking
Ons het gekyk na wat geïmplementeer kan word met behulp van die ELK Stack. In daaropvolgende artikels sal ons die funksionaliteit van TS Total Sight afsonderlik in meer besonderhede oorweeg!
So bly ingeskakel, , , ), .
Bron: will.com