У мінулых артыкулах мы трохі азнаёміліся са стэкам elk і наладай канфігурацыйнага файла Logstash для парсера логаў, у дадзеным артыкуле пяройдзем да найважнейшага з пункта гледжання аналітыкі, тое што вы жадаеце ўбачыць ад сістэмы і дзеля чаго ўсё стваралася – гэта графікі і табліцы аб'яднаныя ў дашборды. Сёння мы бліжэй азнаёмімся з сістэмай візуалізацыі. Kibana, разгледзім як ствараць графікі, табліцы, і ў выніку пабудуем прасценькі дашборд на аснове логаў з міжсеткавага экрана Check Point.
Першым крокам працы з kibana - гэта стварэнне index pattern, лагічна, гэта база індэксаў адзіных па пэўным прынцыпе. Зразумела, гэта выключна настройка для таго, каб Kibana больш зручна шукала інфармацыю па ўсіх індэксах адначасова. Задаецца яна ў параўнанні радкі, дапусцім "checkpoint-*" і назвы індэкса. Напрыклад, "checkpoint-2019.12.05" падыдзе пад патэрн, а проста "checkpoint" ужо няма. Асобна варта згадкі, што ў пошуку шукаць інфармацыю па розных патэрна індэксаў адначасова нельга, крыху пазней у наступных артыкулах мы ўбачым што API запыты робяцца або па назве індэкса, або як раз па адной радку патэрна, малюнак кликабельна:
Пасля гэтага правяраем у меню Discover, што ўсе логі індэксуюцца, і наладжаны правільны парсер. Калі выявяцца якія або неадпаведнасці, напрыклад, памяняць тып дадзеных з радка на цэлы лік, неабходна адрэдагаваць канфігурацыйны файл Logstash, у выніку новыя логі будуць запісвацца правільна. Для таго, каб старыя логі да змены прынялі патрэбны выгляд, дапамагае толькі працэс рэіндэксацыі, у наступных артыкулах гэтая аперацыя будзе разгледжана больш дэталёва. Пераканаемся, што ўсё ў парадку, малюнак кликабельна:
Логі апынуліся на месцы, значыць, можна прыступіць да пабудовы дашбордаў. На аснове аналітыкі дашбордаў ад security прадуктаў можна зразумець стан ИБ ў арганізацыі, навочна ўбачыць уразлівыя месцы ў бягучай палітыцы, і ў далейшым выпрацаваць спосабы па іх устараненню. Пабудуем невялікі дашборд, выкарыстоўваючы некалькі сродкаў візуалізацыі. Дашборд будзе складацца з 5 кампанентаў:
- табліца для падліку сумарнай колькасці логаў па блейдах
- табліцу па крытычных сігнатурах IPS
- кругавую дыяграму па падзеях Threat Prevention
- дыяграма па найбольш папулярных наведвальных сайтах
- дыяграма па выкарыстанні найбольш небяспечных прыкладанняў
Для стварэння фігур візуалізацыі, трэба перайсці ў меню Візуалізуе, і выбраць патрэбную фігуру, якую хочам пабудаваць! Пойдзем па парадку.
Табліца для падліку сумарнай колькасці логаў па блейдах
Для гэтага выберам фігуру Табліца дадзеных, правальваемся ў абсталяванне для стварэння графікаў, злева прастаўляецца налады фігуры, справа то як яна будзе выглядаць у бягучых наладах. Спачатку прадэманструю як будзе выглядаць гатовая табліца, пасля гэтага пройдзем па наладах, малюнак клікабельны:
Больш дэталёвыя налады фігуры, малюнак клікабельны:
Разбяром налады.
Першапачаткова наладжваецца метрыка, гэта значэнне, па якім будуць агрэгавацца ўсе палі. Метрыкі вылічаюцца на аснове значэнняў, вынятых тым ці іншым спосабам з дакументаў. Значэнні звычайна здабываюцца з палёў дакумента, але таксама могуць быць згенераваны з выкарыстаннем скрыптоў. У дадзеным выпадку ставім у Aggregation: Count (сумарная колькасць логаў).
Пасля гэтага дзелім табліцу па сегментах (палях), па якіх будзе лічыцца метрыка. Гэтую функцыю выконвае настройка Buckets, якая ў сваю чаргу складаецца з 2 варыянтаў наладкі:
- split rows - даданне калон і ў далейшым дзяленне табліцы на радкі.
- split table - дзяленне на некалькі табліц па значэннях пэўнага поля.
В каўшы можна дадаць некалькі дзяленняў для стварэння некалькіх слупкоў ці табліц, абмежаванні тут хутчэй каштуюць лагічныя. У aggregation можна абраць па якім спосабе будзе адбывацца дзяленне на сегменты: ipv4 range, date range, Terms і т.д. Найбольш забаўным выбарам з'яўляецца менавіта Умовы и Significant Terms, Дзяленне на сегменты вырабляецца па значэннях вызначанага поля індэкса, розніца паміж імі заключаецца ў колькасці вяртаюцца значэнняў, і іх адлюстраванне. Бо мы жадаем падзяліць табліцу па назове блейдаў, выбіраемы поле — product.keyword і задаем памер у колькасці 25 якія вяртаюцца значэнняў.
Замест радкоў у elasticsearch выкарыстоўваецца 2 тыпу дадзеных тэкст и ключавое слова. Калі вы жадаеце выканаць паўнатэкставы пошук, вы павінны выкарыстоўваць тып text, вельмі зручная рэч пры напісанні свайго пошукавага сэрвісу, напрыклад, шукаеце згадванне слова ў пэўным значэнні поля (тэксце). Калі вы хочаце толькі дакладнае супадзенне, вы павінны выкарыстоўваць тып keyword. Гэтак жа тып дадзеных keyword варта выкарыстоўваць для палёў, якія патрабуюць сартавання ці агрэгацыі, гэта значыць, у нашым выпадку.
У выніку Elasticsearch лічыць колькасць логаў за вызначаны час з агрэгаваннем па значэнні ў поле product. У Custom Label задаём назву калоны, якое будзе адлюстроўвацца ў табліцы, задаем час за якое збіраем логі, запускаем прамалёўку - Kibana адпраўляе запыт у elasticsearch, чакае адказ і пасля візуалізуе атрыманыя дадзеныя. Табліца гатова!
Кругавая дыяграма па падзеях Threat Prevention
Пэўную цікавасць уяўляе інфармацыя, а колькі наогул у працэнтных суадносінах рэакцый выявіць и прадухіляць на інцыдэнты ИБ у бягучай палітыцы бяспекі. Для такога выпадку добра падыходзіць кругавая дыяграма. Выбіраемы ў Visualize - Кругавая дыяграма. Таксама ў метрыцы задаем агрэгацыю па колькасці логаў. У buckets ставім Terms => action.
Накшталт усё правільна, але ў выніку паказваюцца значэнні па ўсіх блейдах, трэба адфільтраваць толькі па тых блейдах, якія працуюць у рамках Threat Prevention. Таму абавязкова наладжваем фільтр для таго, каб шукаць інфармацыю толькі па блейды якія адказваюць за інцыдэнты ИБ – product: ("Anti-Bot" OR "New Anti-Virus" OR "DDoS Protector" OR "SmartDefense" OR "Threat Emulation"). Малюнак клікабельная:
І больш дэталёвыя наладкі, малюнак клікабельны:
Табліца па падзеях IPS
Далей вельмі важным з пункту гледжання ИБ з'яўляецца прагляд і праверка падзей па блейд IPS и Threat Emulation, Якія не блакуюцца бягучай палітыкай, каб у далейшым або перавесці сігнатуру ў prevent, або калі трафік валідны - не правяраць сігнатуру. Табліцу ствараем таксама як і для першага прыкладу, толькі з тым адрозненнем, што ствараем некалькі калон: protections.keyword, severity.keyword, product.keyword, originsicname.keyword. Абавязкова наладжваем фільтр для таго, каб шукаць інфармацыю толькі па блейды якія адказваюць за інцыдэнты ИБ – product: ( "SmartDefense" OR "Threat Emulation"). Малюнак клікабельная:
Больш дэталёвыя наладкі, малюнак клікабельны:
Дыяграмы па найбольш папулярным наведвальным сайтам
Для гэтага ствараем фігуру - Вертыкальная паласа. Метрыку таксама выкарыстоўваем count (вось Y), а на восі X у якасці значэнняў будзем выкарыстоўваць назву наведаных сайтаў - "appi_name". Тут ёсць невялікая хітрасць, калі запусціць налады ў бягучым варыянце, то ўсе сайты будуць адзначацца на графіцы адным колерам, для таго каб зрабіць іх рознакаляровымі выкарыстоўваем дадатковую наладу - "split series", якая дазваляе дзяліць ужо гатовую калону на яшчэ некалькі значэнняў, у залежнасці ад абранага поля вядома! Гэты самы падзел можна альбо выкарыстаць як адна рознакаляровая калона па значэннях у рэжыме stacked, альбо ў рэжыме normal для таго каб стварыць некалькі калон па вызначаным значэнні з восі X. У дадзеным выпадку тут мы выкарыстаем тое ж значэнне, што і па восі X, гэта дае магчымасць зрабіць усё калонкі рознакаляровымі, справа зверху яны будуць пазначацца кветкамі. У фільтры задаём — product: «URL Filtering» для таго, каб убачыць інфармацыю толькі па наведаных сайтах, малюнак клікабельны:
налады:
Дыяграма па выкарыстанні найбольш небяспечных прыкладанняў
Для гэтага ствараем фігуру - Vertical Bar. Метрыку таксама выкарыстоўваем count (вось Y), а на восі X у якасці значэнняў будзем выкарыстоўваць назву выкарыстоўваных прыкладанняў- "appi_name". Найбольш важным з'яўляецца заданне фільтра - product: "Application Control" AND app_risk: (4 OR 5 OR 3) AND action: "accept". Фільтруем логі па блэйду Application control, бярэм толькі тыя сайты якія катэгарызаваны як сайты з рызыкай Critical, High, Medium і толькі ў тым выпадку калі на гэтыя сайты доступ дазволены. Малюнак клікабельная:
Налады, клікабельна:
Дашбард
Прагляд і стварэнне дашбордаў знаходзіцца ў асобным пункце меню. прыборная панэль. Тут усё проста, ствараецца новы дашборд, у яго дадаецца візуалізацыя, расстаўляецца па месцах і ўсё!
Ствараем дашборд, па якім можна будзе зразумець базавую сітуацыю стану ИБ у арганізацыі, зразумела, толькі на ўзроўні Check Point, малюнак кликабельна:
На аснове гэтых графікаў мы можам зразумець якія крытычныя сігнатуры не блакуюцца на міжсеткавым экране, куды ходзяць карыстачы, якія найболей небяспечныя прыкладанні яны выкарыстаюць.
Заключэнне
Мы разгледзелі магчымасці базавай візуалізацыі ў Kibana і пабудавалі дашборд, але гэта толькі малая частка. Далей у курсе асобна разгледзім настройку карт, працу з сістэмай elasticsearch, пазнаёмімся з API запытамі, аўтаматызацыяй і шмат чаго яшчэ!
Так што сочыце за абнаўленнямі (, , , ), .
Крыніца: habr.com