В предишни статии разгледахме накратко ELK стека и конфигурационния файл на Logstash за парсер на логове. В тази статия ще се насочим към най-важното от аналитична гледна точка — това, което искате да видите от системата и заради което всичко е създадено — графики и таблици, събрани в табло за управление. Днес ще се запознаем по-добре със системата за визуализация, Kibanaще разгледаме как да създадем графики и таблици и в резултат, ще изградим простичко табло за управление на базата на логове от межсетевия екран Check Point.
Първата стъпка в работата с Kibana е създаването на шаблон на индекси, което логично представлява база от индекси, обединени по определен принцип. Разбира се, това е изключително настройка, за да може Kibana по-удобно да търси информация по всички индекси едновременно. Задава се чрез съответствие на стринг, например “checkpoint-*” и името на индекса. Например, „checkpoint-2019.12.05“ ще отговаря на шаблона, а просто „checkpoint“ вече не. Струва си да се спомене, че не може да се търси информация по различни шаблони на индекси одновременно; по-късно в следващите статии ще видим, че API запитванията се правят или по името на индекса, или точно по един стринг шаблон. Картинката е кликаема:
След това проверяваме в менюто Discover, че всички логове се индексират и е настроен правилният парсер. Ако се открият някакви несъответствия, например, да се промени типът данни от стринг на цяло число, е необходимо да се редактира конфигурационния файл на Logstash и в резултат новите логове ще бъдат записвани правилно. За да се приведат старите логове в нужния вид преди промяната, помага единствено процеса на реиндексация; в следващите статии ще бъде разгледана тази операция по-подробно. Уверяваме се, че всичко е наред, картинката е кликаема:
Логовете са на място, значи можем да започнем изграждането на табла за управление. На базата на анализа на таблата за управление от продуктовата сигурност можем да разберем състоянието на ИТ сигурността в организацията, да видим визуално уязвимите места в настоящата политика и в последствие да изработим начини за тяхното отстраняване. Ще изградим малко табло, използвайки няколко средства за визуализация. Таблото ще се състои от 5 компонента:
- таблица за изчисляване на общото количество логове по нодове
- таблица по критични сигнатури IPS
- кръгова диаграма по събития на заплаха
- диаграма по най-популярните посещавани сайтове
- диаграма за използването на най-опасните приложения
За да създадете визуализационни фигури, трябва да отидете в менюто Визуализирайте, и да изберете необходимата фигура, която искаме да построим! Да действаме последователно.
Таблица за изчисляване на общия брой логове по блейдовете
За целта изберете фигура Data Table, влизаме в инструмента за създаване на графики, отляво се поставят настройките на фигурата, отдясно как ще изглежда в текущите настройки. Първо ще демонстрирам как ще изглежда готовата таблица, след което ще преминем през настройките, картинката е кликаема:
По-подробни настройки на фигурата, картинката е кликаема:
Нека разгледаме настройките.
Първоначално се настройва метрика, това е стойността, по която ще се агрегатират всички полета. Метриките се изчисляват на базата на стойности, извлечени по един или друг начин от документите. Стойностите обикновено се извличат от полета на документа, но също така могат да бъдат генерирани с помощта на скриптове. В този случай задаваме в Агрегация: Брой (общ брой логове).
След това разделяме таблицата по сегменти (полета), по които ще се изчислява метриката. Тази функция се изпълнява от настройката Buckets, която от своя страна се състои от 2 варианта на настройка:
- разделяне на редове — добавяне на колони и последващо разделяне на таблицата на редове
- разделяне на таблицата — разделение на няколко таблици по стойностите на определено поле.
В buckets може да добавите няколко разделения за създаване на няколко колони или таблици, ограниченията тук са по-скоро логически. В агрегацията можете да изберете по какъв начин ще се извършва разделянето на сегменти: ipv4 диапазон, диапазон на дати, Термини и т.н. Най-интригуващият избор е именно Термини и Значими термини, разделението на сегменти се извършва по стойностите на определено поле от индекса, разликата между тях се състои в броя на върнатите стойности и тяхното визуализиране. Тъй като искаме да разделим таблицата по имената на блейдовете, избираме полето — product.keyword и задаваме размер в количество от 25 върнати стойности.
Вместо редове в elasticsearch се използват 2 типа данни — ntext и ключова дума. Ако искате да извършите пълнотекстово търсене, трябва да използвате типа text, който е много удобен при разработването на вашата собствена търсачка, например когато търсите споменаване на дума в конкретно поле (текст). Ако искате само точно съвпадение, трябва да използвате типа keyword. Също така типът данни keyword трябва да се използва за полета, които изискват сортиране или агрегация, тоест в нашия случай.
В резултат на това Elasticsearch брои количеството логове за определено време, агрегиран по стойността в полето product. В Custom Label задаваме име на колоната, което ще се показва в таблицата, задаваме времето, за което събираме логовете, стартираме визуализация — Kibana изпраща заявка до Elasticsearch, изчаква отговор и след това визуализира получените данни. Таблицата е готова!
Кръгова диаграма по събитията Threat Prevention
Определен интерес представлява информацията, колко точно е процентното съотношение на реакциите detect и prevent на инциденти ИБ в текущата политика за сигурност. В такъв случай е подходяща кръговата диаграма. Избираме в Visualize — Pie chart. В метриката задаваме агрегация по количество логове. В buckets поставяме Terms => action.
Изглежда всичко е наред, но в резултат се показват стойности по всички блейдове, необходимо е да се филтрират само тези блейдове, които работят в рамките на Threat Prevention. Затова е задължително да настроим филтър за да търсим информация само по блейдове, отговарящи за инциденти ИБ — product: («Anti-Bot» OR «New Anti-Virus» OR «DDoS Protector» OR «SmartDefense» OR «Threat Emulation»). Снимката е кликаема:
И по-подробни настройки, снимката е кликаема:
Таблица по събитията IPS
Следва много важно от гледна точка на ИБ да прегледате и проверите събития по блейда IPS и Емуляция на заплахи, които не се блокират текущата политика, за да може в последствие или да преведем сигнатурата в prevent, или ако трафикът е валиден — да не проверяваме сигнатурата. Таблицата създаваме по същия начин, както в първия пример, само с разликата, че създаваме няколко колони: protections.keyword, severity.keyword, product.keyword, originsicname.keyword. Задължително настройваме филтър, за да търсим информация само по блейдове, отговарящи за инциденти ИБ — product: ( «SmartDefense» OR «Threat Emulation»). Снимката е кликаема:
По-подробни настройки, снимката е кликаема:
Диаграми по най-популярно посещаваните сайтове
За целта създаваме фигура — Vertical Bar. Метриката също така използваме 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
