🥇TS Total Sight. Сродак збору падзей, аналізу інцыдэнтаў і аўтаматызацыі рэагавання на пагрозы ProHoster

Добры дзень, у мінулых артыкулах мы пазнаёміліся з працай ELK Stack. А зараз абмяркуем магчымасці, якія можна рэалізаваць адмыслоўцу па ИБ у выкарыстанні дадзеных сістэм. Якія логі можна і трэба завесці ў elasticsearch. Разгледзім, якую статыстыку можна атрымаць, наладжваючы дашборды і ці ёсць у гэтым профіт. Якім чынам можна ўкараніць аўтаматызацыю працэсаў ИБ, выкарыстоўваючы стэк ELK. Складзем архітэктуру працы сістэмы. У суме, рэалізацыя ўсяго функцыяналу гэта вельмі вялікая і цяжкая задача, таму рашэнне вылучылі ў асобную назву - TS Total Sight.

У наш час узмоцнена набіраюць папулярнасць рашэння, якія кансалідуюць і якія аналізуюць інцыдэнты ИБ у адным лагічным месцы, у выніку адмысловец атрымлівае статыстыку і фронт дзеянняў для паляпшэння стану ИБ у арганізацыі. Такую задачу мы сабе паставілі ў выкарыстанні стэка ELK, у выніку вылучылі асноўны функцыянал у 4 часткі:

Статыстыка і візуалізацыя;
Выяўленне інцыдэнтаў ИБ;
Прыярытызацыя інцыдэнтаў;
Аўтаматызацыя працэсаў ИБ.

Далей больш падрабязна разгледзім па асобнасці.

Выяўленне інцыдэнтаў ИБ

Галоўная задача ў выкарыстанні elasticsearch у нашым выпадку гэта збор толькі інцыдэнтаў ИБ. Збіраць інцыдэнты ИБ можна з любых сродкаў абароны, калі яны падтрымліваюць хоць нейкія рэжымы перасылання логаў, стандартнае гэта syslog ці па scp захаванне ў файл.

Можна прывесці стандартныя прыклады сродкаў абароны і не толькі, адкуль варта наладзіць перасылку логаў:

Любыя сродкі NGFW (Check Point, Fortinet);
Любыя сканары ўразлівасцяў (PT Scanner, OpenVas);
Web Application Firewall (PT AF);
аналізатары netflow (Flowmon, Cisco StealthWatch);
AD сервер.

Пасля таго, як наладзілі адпраўленне логаў і канфігурацыйныя файлы ў Logstash, можна скарэляваць і параўнаць з інцыдэнты, якія паступаюць з розных сродкаў бяспекі. Для гэтага зручна выкарыстоўваць індэксы, у якіх будзем захоўваць усе інцыдэнты, якія адносяцца да канкрэтнай прылады. Іншымі словамі, адзін індэкс - гэта ўсё інцыдэнты да адной прыладзе. Рэалізаваць такое размеркаванне магчыма 2 спосабамі.

Першы варыянт гэта наладзіць канфіг Logstash. Для гэтага неабходна прадубліраваць лог па вызначаных палях у асобную адзінку з іншым тыпам. І потым у наступным выкарыстоўваць гэты тып. У прыкладзе клануюцца логі па блэйду IPS міжсеткавага экрана Check Point.

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

Для таго каб захаваць у асобны азначнік такія падзеі ў залежнасці ад палёў логаў, напрыклад такі як Destination IP сігнатуры нападу. Можна выкарыстоўваць падобную канструкцыю:

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

І такім чынам можна зрабіць захаванне ў азначнік усіх інцыдэнтаў, напрыклад, па IP адрасе, ці па даменным імі машыны. У дадзеным выпадку захоўваем у азначнік "smartdefense-%{dst}", па IP адрасе назвы сігнатуры.

Аднак, у розных прадуктаў будуць розныя палі для логаў, што прывядзе да хаосу, і лішняму ўжыванню памяці. І тут трэба будзе альбо ўважліва ў наладах канфігу Logstash замяняць палі на загадзя задуманыя, якія будуць аднолькавыя для ўсіх тыпаў інцыдэнтаў, што таксама з'яўляецца складанай задачай.

Другі варыянт рэалізацыі - гэта напісанне скрыпту або працэсу, якія будуць у рэжыме рэальнага часу звяртацца да базы эластыка, вырываць патрэбныя інцыдэнты, і захоўваць ужо ў новы індэкс, гэта з'яўляюцца цяжкай задачай, але дазваляе працаваць з логамі як душы заўгодна, і карэляваць напрамую з інцыдэнтамі з іншых сродкаў бяспекі. Гэты варыянт дазваляе наладзіць працу з логамі максімальна карысна для вашага выпадку з максімальнай гнуткасцю, але тут узнікае праблема ў пошуку такога спецыяліста, які гэта зможа рэалізаваць.

І зразумела, самае галоўнае пытанне, а што ўвогуле можна скарэляваць і выявіць?

Тут можа быць некалькі варыянтаў, і залежыць ад таго, якія сродкі бяспекі выкарыстоўваюцца ў вашай інфраструктуры, парачка прыкладаў:

Самы відавочны і з майго пункта гледжання самы цікавы варыянт для тых у каго ёсць рашэнне NGFW і сканер уразлівасцяў. Гэта параўнанне логаў па IPS і вынікаў сканавання ўразлівасцяў. Калі было задэтэктавана атака (не блакіравана) сістэмай IPS, і дадзеная ўразлівасць не зачынена на канчатковай машыне зыходзячы з вынікаў сканавання – неабходна трубіць ва ўсе трубы, бо існуе вялікая верагоднасць таго што ўразлівасць была праэксплуатавана.
Шмат спроб лагіна з адной машыны ў розныя месцы, можа сімвалізаваць аб шкоднай актыўнасці.
Запампоўванне карыстачом вірусных файлаў з прычыны наведвання ў велізарнай колькасці патэнцыйна небяспечных сайтаў.

Статыстыка і візуалізацыя

Самае відавочнае і зразумелае, для чаго патрэбен ELK Stack – гэта захоўванне і візуалізацыя логаў, у мінулых артыкулах было паказана, якім чынам можна завесці логі ад розных прылад, выкарыстоўваючы Logstash. Пасля таго як логі ідуць у Elasticsearch, можна наладзіць дашборды, пра якія таксама згадвалі у мінулых артыкулах, з неабходнай для вас інфармацыяй і статыстыкай з дапамогай візуалізацыі.

Прыклады:

Дашбоард па падзеях Threat Prevention з найбольш крытычнымі падзеямі. Тут можна адлюстраваць якія сігнатуры IPS былі выяўлены, адкуль тэрытарыяльна яны зыходзяць.
Дашбоард па выкарыстанні найбольш крытычных прыкладанняў, па якіх можа злівацца інфармацыя.
Вынікі сканавання з любога сканара бяспекі.
Логі з Active Directory па карыстальніках.
Дашбоард па падлучэнне VPN.

У дадзеным выпадку, калі наладзіць дашбоарды на абнаўленне кожныя некалькі секунд, можна атрымаць даволі зручную сістэму для маніторынгу падзей у рэальным часе, якую далей можна выкарыстоўваць для найболей хуткага рэагавання на інцыдэнты ИБ, калі паставіць дашборды асобным экранам.

Прыярытызацыя інцыдэнтаў

Ва ўмовах вялікай інфраструктуры колькасць інцыдэнтаў можа зашкальваць, і спецыялісты не будуць паспяваць своечасова разбіраць усе інцыдэнты. У дадзеным выпадку, неабходна ў першую чаргу выдзяляць толькі тыя інцыдэнты, якія нясуць вялікую пагрозу. Таму сістэма павінна прыярытызаваць інцыдэнты па іх небяспецы ў адносінах да вашай інфраструктуры. Пажадана наладзіць апавяшчэнне ў пошту ці тэлеграм дадзеных падзей. Прыярытызацыю можна рэалізаваць штатнымі сродкамі Kibana, шляхам налады візуалізацыі. А вось з абвесткай цяжэй, па змаўчанні дадзены функцыянал не ўключаны ў базавую версію Elasticsearch, толькі ў платнай. Таму або купляць платную версію, або ізноў-ткі, самому напісаць працэс які будзе ў рэжыме рэальнага часу апавяшчаць адмыслоўцаў на пошту ці ў тэлеграм.

Аўтаматызацыя працэсаў ИБ

І адной з самых цікавых частак з'яўляецца аўтаматызацыя дзеянняў на інцыдэнты ИБ. Раней дадзены функцыянал мы рэалізоўвалі для Splunk, крыху падрабязней, можаце прачытаць у гэтай артыкуле. Асноўная ідэя ў тым, што палітыка IPS ніколі не правяраецца і не аптымізуецца, хаця ў некаторых выпадках з'яўляецца найважнейшай часткай працэсаў інфармацыйнай бяспекі. Напрыклад праз год пасля ўкаранення NGFW і адсутнасці дзеянняў па аптымізацыі IPS, у вас назапасіцца вялікая колькасць сігнатур з дзеяннем Detect, якія не будуць блакавацца, што моцна зніжае стан ИБ ў арганізацыі. Далей некаторыя прыклады таго, што можна аўтаматызаваць:

Пераклад сігнатуры IPS з Detect на Prevent. Калі на крытычныя сігнатуры не працуе Prevent, тое гэта не парадак, і сур'ёзны пралом у сістэме абароны. Змяняем дзеянне ў палітыцы на такія сігнатуры. Рэалізаваць дадзены функцыянал можна, калі прылада NGFW валодае функцыяналам REST API. Гэта магчыма толькі валодаючы навыкамі праграмавання, трэба выдзіраць патрэбную інфармацыю з Elastcisearch і выканаць API запыты на сервер кіравання NGFW.
Калі з аднаго IP адраса ў сеткавым трафіку выявілася ці заблакавалася мноства сігнатур, тое мае сэнс заблакаваць на некаторы час дадзены IP адрас у палітыцы Firewall. Рэалізацыя таксама складаецца з выкарыстання API REST.
Запускаць праверку хаста сканарам уразлівасцяў, калі на гэты хост прыходзіцца вялікая колькасць сігнатур па IPS ці іншых сродкаў бяспекі, у выпадку калі гэта OpenVas, то можна напісаць скрыпт, які будзе падлучацца па ssh на сканер бяспекі і запускаць сканаванне.

TS Total Sight

У суме рэалізацыя ўсяго функцыяналу гэта вельмі вялікая і цяжкая задача. Не валодаючы навыкамі праграмавання, можна наладзіць мінімальны функцыянал, якога можа быць дастаткова для выкарыстання ў прадукты. Але калі вас цікавіць увесь функцыянал, вы можаце звярнуць увагу на TS Total Sight. Больш падрабязна вы можаце азнаёміцца на нашым сайце. У выніку ўся схема працы і архітэктура будзе выглядаць падобнай выявай:

Заключэнне

Мы разгледзелі, што можна рэалізаваць, выкарыстоўваючы ELK Stack. У наступных артыкулах асобна разгледзім больш дэталёва функцыянал TS Total Sight!

Так што сочыце за абнаўленнямі (Тэлеграма, Facebook, VK, TS Solution Blog), Яндэкс.Дзэн.

Крыніца: habr.com

TS Total Sight. Сродак збору падзей, аналізу інцыдэнтаў і аўтаматызацыі рэагавання на пагрозы