🥇TS Täielik nägemine. Sündmuste kogumise, intsidentide analüüsi ja ohule reageerimise automatiseerimistööriist

Tere pärastlõunast, eelmistes artiklites tutvusime ELK Stacki tööga. Nüüd räägimegi võimalustest, mida infoturbespetsialist saab nende süsteemide kasutamisel realiseerida. Milliseid palke saab ja tuleks elastsearchidesse sisestada. Mõelgem, millist statistikat saab armatuurlaudade seadistamisega ja kas sellest on kasumit. Kuidas saab ELK pinu kasutades rakendada infoturbe protsesside automatiseerimist. Koostame süsteemi arhitektuuri. Kokkuvõttes on kogu funktsionaalsuse juurutamine väga mahukas ja raske ülesanne, mistõttu sai lahendus omaette nime – TS Total Sight.

Praegu on kiiresti populaarsust kogumas lahendused, mis koondavad ja analüüsivad infoturbe intsidente ühte loogilisse kohta, mille tulemusena saab spetsialist statistikat ja tegevuspiiri organisatsiooni infoturbe seisu parandamiseks. Selle ülesande seadsime endale ELK virna kasutamisel ja selle tulemusena jagasime põhifunktsioonid neljaks osaks:

Statistika ja visualiseerimine;
Infoturbeintsidentide avastamine;
Juhtumite prioriseerimine;
Infoturbe protsesside automatiseerimine.

Järgmisena vaatleme igaüks neist eraldi.

Infoturbeintsidentide tuvastamine

Elasticsearchi kasutamise põhiülesanne meie puhul on koguda ainult infoturbeintsidente. Infoturbeintsidente saate koguda mis tahes turbevahenditest, kui need toetavad vähemalt mõnda logide saatmise režiimi, standard on syslog või scp faili salvestamine.

Saate tuua standardnäiteid turbetööriistadest ja muust, kust peaksite logide edastamise konfigureerima:

Kõik NGFW tööriistad (Check Point, Fortinet);
mis tahes haavatavuse skannerid (PT Scanner, OpenVas);
veebirakenduste tulemüür (PT AF);
võrguvoolu analüsaatorid (Flowmon, Cisco StealthWatch);
AD server.

Kui olete Logstashis logide ja konfiguratsioonifailide saatmise konfigureerinud, saate korreleerida ja võrrelda erinevatest turvatööriistadest pärinevate intsidentidega. Selleks on mugav kasutada indekseid, kuhu salvestame kõik konkreetse seadmega seotud juhtumid. Teisisõnu, üks register on kõik ühe seadmega seotud juhtumid. Seda jaotust saab rakendada kahel viisil.

esimene teostus Seda tehakse Logstashi konfiguratsiooni konfigureerimiseks. Selleks peate teatud väljade logi dubleerima erineva tüübiga eraldi üksusesse. Ja siis kasutage seda tüüpi tulevikus. Näites kloonitakse logid Check Pointi tulemüüri IPS-i labast.

filter {
    if [product] == "SmartDefense" {
        clone {
	    clones => ["CloneSmartDefense"]
	    add_field => {"system" => "checkpoint"}
	}
    }
}

Selliste sündmuste salvestamiseks eraldi registrisse sõltuvalt logiväljadest, näiteks sihtkoha IP rünnakusignatuurid. Võite kasutada sarnast konstruktsiooni:

output {
    if [type] == "CloneSmartDefense"{
    {
         elasticsearch {
    	 hosts => [",<IP_address_elasticsearch>:9200"]
    	 index => "smartdefense-%{dst}"
    	 user => "admin"
    	 password => "password"
  	 }
    }
}

Ja sel viisil saate salvestada kõik juhtumid registrisse, näiteks IP-aadressi või masina domeeninime järgi. Sel juhul salvestame selle registrisse "smartdefense-%{dst}", allkirja sihtkoha IP-aadressi järgi.

Erinevatel toodetel on aga erinevad logiväljad, mis toob kaasa kaose ja tarbetu mälukulu. Ja siin peate kas hoolikalt asendama Logstashi konfiguratsiooniseadete väljad eelnevalt kavandatud väljadega, mis on igat tüüpi juhtumite puhul samad, mis on samuti keeruline ülesanne.

Teine rakendusvõimalus - see on skripti või protsessi kirjutamine, mis pääseb reaalajas juurde elastsele andmebaasile, tõmbab välja vajalikud juhtumid ja salvestab need uude registrisse, see on keeruline ülesanne, kuid võimaldab teil logidega töötada, nagu soovite, ja korreleeruvad otseselt teiste turvaseadmete vahejuhtumitega. See valik võimaldab seadistada töö logidega nii, et see oleks teie juhtumi jaoks kõige kasulikum ja maksimaalselt paindlik, kuid siin tekib probleem spetsialisti leidmisel, kes seda rakendaks.

Ja muidugi kõige olulisem küsimus, ja mida saab korreleerida ja tuvastada??

Siin võib olla mitu võimalust ja see sõltub sellest, milliseid turvatööriistu teie infrastruktuuris kasutatakse, paar näidet:

Kõige ilmsem ja minu vaatenurgast kõige huvitavam variant neile, kellel on NGFW lahendus ja haavatavuse skanner. See on IPS-i logide ja haavatavuse kontrolli tulemuste võrdlus. Kui IPS-süsteem tuvastas (ei blokeerinud) rünnaku ja seda haavatavust lõppmasinas skannimistulemuste põhjal ei suleta, on vaja vile puhuda, kuna on suur tõenäosus, et haavatavust on ära kasutatud. .
Paljud sisselogimiskatsed ühest masinast erinevatesse kohtadesse võivad sümboliseerida pahatahtlikku tegevust.
Kasutaja laadib viirusfaile alla suure hulga potentsiaalselt ohtlike saitide külastamise tõttu.

Statistika ja visualiseerimine

Kõige ilmsem ja arusaadavam asi, mille jaoks ELK Stacki vaja on, on palkide ladustamine ja visualiseerimine, varasemates artiklites näidati, kuidas saab Logstashi abil erinevatest seadmetest logisid luua. Kui logid lähevad Elasticsearchi, saate seadistada armatuurlaudu, mida ka mainiti varasemates artiklites, koos visualiseerimisega vajaliku teabe ja statistikaga.

Näited:

Ohtude ennetamise sündmuste armatuurlaud kõige kriitilisemate sündmustega. Siin saate kajastada, millised IPS-allkirjad tuvastati ja kust need geograafiliselt pärinevad.
Armatuurlaud kõige kriitilisemate rakenduste kasutamise kohta, mille kohta teave võib lekkida.
Skannige tulemusi mis tahes turvaskannerist.
Active Directory logib kasutaja järgi.
VPN-ühenduse armatuurlaud.

Kui seadistada armatuurlauad sellisel juhul uuenema iga paari sekundi tagant, siis saab üsna mugava süsteemi sündmuste reaalajas jälgimiseks, mida saab siis kasutada infoturbeintsidentidele kiireimaks reageerimiseks, kui paigutada armatuurlauad eraldi ekraan.

Juhtumite prioriseerimine

Suure taristu tingimustes võib intsidentide arv mastaapselt langeda ja spetsialistidel ei ole aega kõigi intsidentidega õigeaegselt tegeleda. Sel juhul tuleb esiteks välja tuua vaid need juhtumid, mis kujutavad endast suurt ohtu. Seetõttu peab süsteem seadma intsidendid prioriteediks nende raskusastme alusel seoses teie infrastruktuuriga. Nende sündmuste jaoks on soovitatav seadistada e-posti või telegrammi märguanne. Prioriteetide seadmist saab rakendada tavaliste Kibana tööriistade abil, seadistades visualiseerimise. Kuid märguannetega on see keerulisem; vaikimisi pole seda funktsiooni Elasticsearchi põhiversioonis kaasatud, vaid ainult tasulises versioonis. Seetõttu ostke kas tasuline versioon või kirjutage jällegi ise protsess, mis teavitab spetsialiste reaalajas e-posti või telegrammi teel.

Infoturbe protsesside automatiseerimine

Ja üks huvitavamaid osi on infoturbeintsidentide toimingute automatiseerimine. Varem rakendasime seda funktsiooni Splunki jaoks, sellest saate natuke rohkem lugeda siit. Põhiidee seisneb selles, et IPS-poliitikat ei testita ega optimeerita kunagi, kuigi mõnel juhul on see infoturbe protsesside oluline osa. Näiteks aasta pärast NGFW rakendamist ja IPS-i optimeerimise toimingute puudumist kogute toiminguga Tuvastage palju allkirju, mida ei blokeerita, mis vähendab oluliselt organisatsiooni infoturbe seisundit. Allpool on mõned näited selle kohta, mida saab automatiseerida.

IPS-allkirja ülekandmine funktsioonist Detect funktsioonile Ennetamine. Kui Prevent kriitiliste allkirjade puhul ei tööta, on see korrast ära ja kaitsesüsteemis on tõsine lünk. Muudame poliitikas toimingu sellisteks allkirjadeks. Seda funktsiooni saab rakendada, kui NGFW seadmel on REST API funktsionaalsus. See on võimalik ainult siis, kui teil on programmeerimisoskused, peate hankima Elastcisearchist vajaliku teabe ja tegema API päringuid NGFW haldusserverisse.
Kui võrguliikluses tuvastati või blokeeriti ühelt IP-aadressilt mitu allkirja, siis on mõttekas see IP-aadress mõneks ajaks tulemüüri poliitikas blokeerida. Rakendamine hõlmab ka REST API kasutamist.
Käivitage hosti kontroll haavatavuse skanneriga, kui sellel hostil on palju IPS-i allkirju või muid turvatööriistu; kui see on OpenVas, saate kirjutada skripti, mis loob ssh-i kaudu ühenduse turvaskanneriga ja käivitab kontrolli.