В предишните статии се запознахме малко със стека ELK и настройките на конфигурационния файл Logstash за парсера на логове, в тази статия ще преминем към най-важното от аналитична гледна точка, това, което искате да видите от системата и поради което всичко е създадено — графики и таблици, обединени в дашборди. Днес по-близо ще се запознаем с визуализационната система Kibana, ще разгледаме как да създаваме графики, таблици и в крайна сметка ще изградим прост дашборд на база логовете от междусетевия екран Check Point.
Първата стъпка при работа с Kibana — е създаването на index pattern, логически, това е база от индекси, единни по определен принцип. Разбира се, това е изцяло настройка, за да може Kibana по-удобно да търси информация по всички индекси едновременно. Задава се по съпоставяне на низ, например “checkpoint-*” и името на индекса. Например, «checkpoint-2019.12.05» ще подхожда под патерна, а просто «checkpoint» вече не. Отделно си струва да се спомене, че не може да се търси информация по различни патерни на индекси едновременно, по-късно в следващите статии ще видим, че API заявките се извършват или по името на индекса, или точно по един ред патерн, изображението е кликаемо:
След това проверяваме в менюто Discover, че всички логове се индексират и правилният парсер е настроен. Ако се открият някакви несъответствия, например да се промени типът на данните от низ на цяло число, е необходимо да се редактира конфигурационният файл Logstash, в резултат на което новите логове ще се записват правилно. За да придадем нужния вид на старите логове преди промяната, помага само процесът на реиндексиране, в следващите статии тази операция ще бъде разгледана по-подробно. Удостоверяваме, че всичко е наред, изображението е кликаемо:
Логовете са на място, значи, можем да започнем изграждането на дашбордите. На база аналитиката на дашбордите от продуктите за сигурност може да се разбере състоянието на ИБ в организацията, визуално да се видят уязвимите места в текущата политика и в бъдеще да се разработят начини за тяхното отстраняване. Ще изградим малък дашборд, използвайки няколко средства за визуализация. Дашбордът ще се състои от 5 компонента:
- таблица за изчисление на сумарното количество логове по блейдовете
- таблица по критични сигнатури IPS
- Диаграма на циклите за събитията Threat Prevention
- Диаграма на най-популярните посещавани сайтове
- Диаграма на използването на най-опасните приложения
За да създадете визуализационни фигури, трябва да отидете в менюто Визуализирайте, и да изберете нужната фигура, която искате да изградите! Нека да започнем последователно.
Таблица за преброяване на общия брой логове по блейдовете
За тази цел изберете фигура Данна таблица, влизаме в инструмента за създаване на графики, отляво се задават настройките на фигурата, а вдясно как ще изглежда с текущите настройки. Първо ще демонстрирам как ще изглежда готовата таблица, след което ще прегледаме настройките, изображението е кликабелно:
По-подробни настройки на фигурата, изображението е кликабелно:
Нека разгледаме настройките.
Първоначално се настройва метрика, това е стойността, по която ще се агрегират всички полета. Метриките се изчисляват на базата на стойности, извлечени по един или друг начин от документите. Стойностите обикновено се извличат от поля на документа, но също така могат да бъдат генерирани с помощта на скриптове. В този случай задаваме Агрегация: Брой (общ брой логове).
След това делим таблицата на сегменти (поля), по които ще се изчислява метриката. Тази функция се изпълнява от настройката Buckets, която от своя страна се състои от 2 варианта на настройка:
- разделяне на редове — добавяне на колони и последващо разделение на таблицата на редове
- разделяне на таблицата — разделяне на няколко таблици по стойности на определено поле.
В бъкетс може да се добавят няколко разделения за създаване на няколко колони или таблици, ограниченията тук са по-скоро логически. В агрегацията можете да изберете по какъв начин ще се извършва разделянето на сегменти: ipv4 диапазон, дата диапазон, Условия и т.н. Най-забавният избор е именно Условия и Значими Условия, разделението на сегменти се извършва по стойности на определено поле от индекса, разликата между тях е в броя на връщаните стойности и тяхното показване. Тъй като искаме да разделим таблицата по име на блейдовете, избираме полето — product.keyword и задаваме големина от 25 връщани стойности.
Вместо редовете в elasticsearch се използват 2 типа данни — text и ключова дума. Ако искате да извършите пълен текстов търсене, трябва да използвате типа 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 и Emulatio на заплахи, които не се блокират от текущата политика, за да можем впоследствие или да прехвърлим сигнатурата в 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» за да видим информация само за посещаваните сайтове, картинката е кликабелна:
Настройки:
Диаграма по използването на най-опасните приложения
За това създаваме фигура — Вертикална колона. Метриката също използваме 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
