🥇TS Total Sight. Ürituste kogumise, juhtumianalüüsi ja ohtude reageerimise automatiseerimise vahend

Tere päevast, eelnevates artiklites tutvusime ELK Stacki tööga. Nüüd arutame võimalusi, mida saab rakendada infokaitse spetsialist, kasutades neid süsteeme. Milliseid logisid on vajalik salvestada Elasticsearchis. Kutsume vaatama, millist statistikat on võimalik saada, seadistades armatuurlauad ja kas sellest on kasu. Kuidas saab automatiseerida infokaitse protsesse, kasutades ELK steeki. Koostame süsteemi töö arhitektuuri. Kokkuvõttes on kogu funktsionaalsuse rakendamine väga suur ja keeruline ülesanne, mistõttu eraldati lahendus eraldi nime alla – TS Total Sight.

Praegu on suurenenud populaarsus lahendustel, mis konsolideerivad ja analüüsivad infokaitse intsidente ühes loogilises kohas, mille tulemusena saab spetsialist statistikat ja tegevusplaani инфокaitse seisundi parandamiseks organisatsioonis. Sellist ülesannet oleme endale seadnud ELK steeki kasutamisel, mille tulemusena jagasime põhifunktsiooni 4 jaotuseks:

Statistika ja visualiseerimine;
Infokaitse intsidentide tuvastamine;
Intsidentide prioriseerimine;
Infokaitse protsesside automatiseerimine.

Edasi vaatame neid üksikasjalikumalt.

Infokaitse intsidentide tuvastamine

Peamine ülesanne Elasticsearchi kasutamisel meie puhul on ainult infokaitse intsidentide kogumine. Infokaitse intsidente saab koguda igasugustest kaitsevahenditest, kui need toetavad vähemalt mingeid logide edastamise režiime, tavaline on syslog või scp kaudu faili salvestamine.

Saame tuua standardseid näiteid kaitsevahenditest ja mitte ainult, kust tuleks seadistada logide edastamine:

Igasugused NGFW vahendid (Check Point, Fortinet);
Igasugused haavatavuste skannerid (PT Scanner, OpenVas);
Veebirakenduste tulemüür (PT AF);
Netflow analüsaatorid (Flowmon, Cisco StealthWatch);
AD server.

Pärast seda, kui oleme seadistanud logide edastamise ja konfiguratsioonifailid Logstashis, on võimalik neid koordineerida ja võrrelda erinevate turvavahendite poolt saadud intsidentidega. Selleks on mugav kasutada indekseid, kus hoiame kõiki konkreetsele seadmele kuuluvad intsidente. Teisisõnu, üks indeks on kõik intsidentid, mis kuuluvad ühte seadmesse. Sellise jaotuse rakendamine on võimalik 2 viisil.

Esimene variant see on Logstashi konfiguratsiooni seadistamiseks. Selleks tuleb logi teatud väljade alusel kopeerida eraldi üksusesse teistsuguse tüübiga. Ja hiljem kasutada seda tüüpi. Näites kopeeritakse logid Check Pointi IPS tulemüürist.

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

Selleks, et salvestada eraldi indeksi sellised sündmused logide väljade, näiteks siht-IP rünnakute signatuuride alusel. Saab kasutada sarnast konstruktsiooni:

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

Nii saab indekseerida kõiki juhtumeid, näiteks IP-aadressi või masina domeeninime alusel. Sel juhul salvestame indeksi «smartdefense-%{dst}», siht-IP signatuuri alusel.

Kuid erinevatel tootetel võivad olla erinevad logiväljad, mis võivad tekitada segadust ja tarbetut mälukasutust. Siin tuleb kas Logstashi konfiguratsioonis hoolikalt välju eelnevalt ette nähtud võrdselt logikaologiseerida, mis kõikide juhtumite jaoks on keeruline ülesanne.

Teine rakenduse variant on kirjutada skript või protsess, mis reaalajas pöördub elastse andmebaasi poole, tõmbab vajalikud juhtumid ja salvestab need uude indeksi. See on keeruline ülesanne, kuid võimaldab logide haldamist vastavalt oma soovidele ning koordineerida otseselt teiste turvavahenditega. See variant võimaldab seadistada logide töötlemist teie juhtumi jaoks maksimaalselt kasulikult maksimaalse paindlikkusega, kuid siin tekib probleem leida spetsialist, kes suudab selle ellu viia.

Ja loomulikult, kõige olulisem küsimus, mida üldse saab koordineerida ja avastada?

Siin võib olla mitu varianti, ja see sõltub sellest, millised turvavahendid on teie infrastruktuuris kasutusel, mõned näited:

Kõige ilmsem ja minu arvates kõige huvitavam variant nende jaoks, kellel on NGFW lahendus ja haavatavuste skanner. See on logide võrdlemine IPS-i ja haavatavuste skaneerimise tulemuste osas. Kui IPS-süsteem tuvastas rünnaku (mitte blokeeritud) ja antud haavatavus ei ole lõppmasinas skaneerimise tulemustest lähtuvalt suletud - tuleb häiret anda, kuna on suur tõenäosus, et haavatavust on ära kasutatud.
Palju sisselogimise katseid ühest masinast erinevatesse kohtadesse võib tähendada pahatahtlikku tegevust.
Kasutaja allalaaditud viiruslike failide tõttu, olles külastanud suurt hulka potentsiaalselt ohtlikke saite.

Statistika ja visualiseerimine

Kõige ilmsem ja arusaadavam põhjus, miks ELK Stack'i kasutatakse - see on logide salvestamine ja visualiseerimine, eelnevates artiklites oli näidatud, kuidas erinevatest seadmetest logisid sisse tuua, kasutades Logstash'i. Pärast logide edastamist Elasticsearch'i saab seadistada juhtpaneele, millest oleme ka rääkinud, eelnevates artiklites, vajaliku teabe ja statistika visualiseerimise kaudu.

Näited:

Threat Prevention'i sündmuste juhtpaneel kõige kriitilisemate sündmuste jaoks. Siin saab kuvada, milliseid IPS-i signatuure on tuvastatud ja kust need geograafiliselt pärinevad.
Juhtpaneel kõige kriitilisemate rakenduste kasutamise kohta, mille kaudu võib informatsioon lekkida.
Skaneerimise tulemused ükskõik millisest turvaskaanerist.
Active Directory logid kasutajate kohta.
VPN-i ühenduste juhtpaneel.

Antud juhul, kui seadistada juhtpaneelid värskenduma iga paar sekundi järel, võib saada üsna mugava reaalajas sündmuste jälgimissüsteemi, mida saab kasutada IT-intsidentidele kõige kiiremaks reageerimiseks, kui seadistada juhtpaneelid eraldi ekraanile.

Intsidentide prioriseerimine

Suure infrastruktuuri tingimustes võib intsidentide arv tõusta äärmuslikesse kõrgustesse ning spetsialistid ei pruugi jõuda kõiki juhtumeid õigeaegselt analüüsida. Sellisel juhul on oluline eristada esmajärjekorras neid intsidente, mis kujutavad endast suurt ohtu. Seega peaks süsteem prioriseerima intsidente nende ohtlikkuse alusel teie infrastruktuuri suhtes. Soovitav on seadistada teavitused nende sündmuste kohta e-posti või Telegrammi kaudu. Prioriseerimist saab rakendada Kibana vaikimisi tööriistade abil, seadistades visualiseerimise. Kuid teavitamise osas on olukord keerulisem, kuna vaikimisi ei ole see funktsioon Elasticsearchi tasuta versioonis saadaval, vaid ainult tasulises. Seega tuleb kas osta tasuline versioon või kirjutada ise protsess, mis reaalajas teavitab spetsialiste e-posti või Telegrammi kaudu.

Infotehnoloogia protsesside automatiseerimine

Üks huvitavamaid osi on infotehnoloogia intsidentide käsitlemise automatiseerimine. Varasemalt oleme seda funktsiooni rakendanud Splunki jaoks, millest saate rohkem lugeda siin. artiklisPõhiteema on see, et IPS-i poliitikat ei kontrollita ega optimeerita kunagi, kuigi teatud olukordades on see kriitilise tähtsusega osa infotehnoloogia kaitse protsessidest. Näiteks aasta pärast NGFW rakendamist ja IPS-i optimeerimise puudumist koguneb teil suur hulk signatuure, mille tegevus on Detect, mis ei blokeerita, mis märgatavalt vähendab teie organisatsiooni infotehnoloogia turvalisust. Siin on mõned näited, mida saab automatiseerida:

IPS signatuuri muutmine Detect-st Prevent-iks. Kui kriitilised signatuurid ei tööta Prevent režiimis, on see tõsine probleem ja tõsine turvaauk süsteemis. Muudame nende signatuuride tegevust poliitikas. Selle funktsiooni rakendamine on võimalik, kui NGFW seade omab REST API funktsionaalsust. Selleks on vajalik programmeerimisoskus, et välja tõmmata vajalik teave Elasticsearchist ja saata API päringud NGFW haldusse serverisse.
Kui ühest IP-aadressist on võrgu liikluses avastatud või blokeeritud mitu signatuuri, on mõistlik blokeerida see IP-aadress mõneks ajaks Firewall poliitikas. Rakendamine põhineb samuti REST API kasutamisel.
Käivitage hosti haavatavuse skanneri kontroll, kui sellele hostile on suunatud suur hulk IPS-i või muid turvameetmete signatuure. Kui see on OpenVas, saate kirjutada skripti, mis ühendab turvaskanneriga SSH kaudu ja käivitab skaneerimise.

TS Total Sight

Kogu funktsionaalsuse teostamine on väga suur ja keeruline ülesanne. Ilma programmeerimisoskuseta saab seadistada minimaalset funktsionaalsust, mis võib olla piisav tootmis kasutamiseks. Kuid kui teid huvitab kogu funktsionaalsus, võite tutvuda TS Total Sightiga. Rohkem teavet leiate meie veebisaidil. Seetõttu näeb kogu töö skeem ja arhitektuur välja selline: