Журнал "Information Security/ Информационная безопасность" #4, 2022

Анна Андреева, Лаборатория информационной безопасности: Количество сотрудников необходи- мо выбирать исходя из требуемого временного режима реагирования и SLA, а также предполагаемого объе- ма, типа и глубины разбора инциден- тов. Если вы не готовы выделять целый рабочий день аналитика на исследование потенциально заражен- ного хоста, а поручите ИТ перезалить хост, то вам не нужна L3. А если нет необходимости вручную подтверждать каждый вход в критичный сегмент, то не нужна и L1. Для L1 достаточно любого технического образования, обучать их придется самостоятельно, для остальных линий требуется опыт расследований. Максим Степченков, RuSIEM: Количество и специализация сотруд- ников, необходимых для работы с SIEM, зависит от множества факторов, в том числе и от самой системы. Минималь- ное количество персонала для работы с нашей системой начинается от одного сотрудника, а точное число зависит от условий заказчика: размера компании, потока поступающих событий, фили- альной сети, типов источников и необходимости разрабатывать кастомные правила. В нашей системе вся работа ведется в едином веб-интер- фейсе, а необходимые парсеры мы при необходимости готовы разработать за заказчика. В нашей SIEM пред- усмотрены элементы реагирования, а также нет необходимости в дополни- тельных знаниях, например языков про- граммирования. И работа с системой становится легкой. Павел Пугач, СёрчИнформ: По специализации сотрудников вам подскажет вендор: один скажет, что специалист должен быть профессио- нальным программистом и, скажем, к тому же изучить два новых языка разработки. Другой – что для работы с SIEM достаточно среднего уровня пользователя ПК с пониманием, что такое ЛВС, а остальному "научим сами за два часа по удаленке". Требования к квалификации сотрудников, которые с ней работают, различаются для раз- ных систем. Вопрос о количестве сотрудников решать только компании. Границы очень условные: если у вас сто единиц сетевого оборудования, то может хва- тить и пары человек. Если имеется тысяча единиц оборудования и 6 тыс. сотрудников – наверное, двух сисад- минов и одного безопасника вам будет маловато. Если аналитики в стандарт- ное рабочее время справляются со своими задачами по SIEM и всеми остальными, скорее всего, вам их хва- тает. Если нет – расширяйте штат. Сергей Кривошеин, NGR Softlab: Большая часть времени аналитика уходит на расследования, предваритель- ное (определение FP) или глубокое – по факту инцидента. Наилучший эффект в оптимизации нагрузки дадут средства автоматического сбора и обогащения данных. Это можно делать на стороне SIEM или уже в IRP. В первом случае собранная информация может снизить FP-rate, то есть повлияет на точность обнаружения. Использование поведен- ческой аналитики для формирования локальных репутационных баз хостов или пользователей может также снизить количество ложных подозрений. Валерий Горбачев, ДиалогНаука: В первую очередь уменьшение нагруз- ки на SIEM-аналитика обеспечивается снижением уровня ложных срабатыва- ний. Для этого как минимум нужны каче- ственно проведенная категоризация активов, реализованная работа по касто- мизации правил корреляции для кон- кретной организации/отрасли, налажен- ное взаимодействие между ИБ и ответ- ственными администраторами систем от ИТ. Роман Назаров, Лаборатория Касперского: Вижу три направления снижения нагрузки: 1. Тюнинг правил детектирования для снижения FP. Обычно решается сред- ствами SIEM с подключением внешних систем для расширения контекста. 2. Автоматизация рутинных операций аналитика при обработке инцидента. Это, как правило, решается через IRP/SOAR, частично через SIEM. 3. Применение алгоритмов для авто- анализа инцидентов. Аналитик в такой схеме может вообще не участвовать либо может верифицировать финальный вердикт по инциденту. Анна Андреева, Лаборатория информационной безопасности: Аналитики часто совершают однотип- ные действия, их можно автоматизиро- вать с помощью IRP-системы: автома- тически проверить IP-адреса, хеши фай- лов, запустить антивирусную проверку и передавать в работу уже обогащенный данными инцидент. Для некоторых типо- вых событий стоит перейти с простого факта на математические модели пове- дения и расследовать только аномалии. Еще одним важным влияющим факто- ром будет классификация самих инци- дентов: какие из них регистрируются только для real-time уведомлений, какие требуют участия аналитика, а какие можно просматривать постфактум в рам- ках TH. Павел Пугач, СёрчИнформ: Главный вопрос в том, что составляет основную часть загрузки вашего SIEM- аналитика. Если это 600 задач в день, то, очевидно, лучшим инструментом для снижения его нагрузки будет найм еще одного специалиста. А если про- блема в том, что он руками вынужден писать скрипты, чтобы провести анализ, то решением станет графический кон- структор запросов и дашборды, чтобы визуально определять нужные зависи- мости. Вполне возможно, что специа- лист занимается тем, что вручную отправляет письма об инцидентах раз- ным сотрудникам, потому что в SIEM не настроена интеграция с почтовым сервисом. Решение очевидно: настроить такую интеграцию. А самое правильное – брать SIEM, в которых такие задачи решены "из коробки" либо вендор готов помочь решить в процессе использования системы. Иван Чернов, UserGate: Стоит рассмотреть переход на реше- ния класса NG-SIEM, а также использо- вание машинного обучения и вообще искусственного интеллекта, которые за счет более широкого инструментария и автоматизации процессов снижают нагрузку на персонал. Эти инструменты в целом также улучшат качество мони- торинга и реагирования на инциденты, что естественным образом приведет к сокращению объемов ручной работы операторов, ведь большая часть опера- ций будет неизбежно автоматизирова- на. Максим Степченков, RuSIEM: Инструменты, помогающие снизить нагрузку на SIEM-аналитиков могут, быть разными. Например, в RuSIEM можно добавлять в карточку инцидента описа- ние логики срабатывания правила кор- реляции или прописывать мини-плейбуки с рекомендациями по реагированию, чтобы в случае возникновения инцидента аналитикам не приходилось тратить время на то, чтобы разобраться, по какому принципу был выявлен конкрет- ный инцидент и что делать дальше. Можно также использовать механизмы автоматизации реакции на инциденты, в том числе через запуск различных скриптов. В качестве дополнительных инструментов для снижения нагрузки на аналитиков могут выступать и сторонние системы класса IRP/SOAR, которые тесно интегрируются с SIEM. l Какими инструментами можно снизить нагрузку на SIEM-аналитика без итогового снижения качества детектирования? • 35 SIEM www.itsec.ru Ваше мнение и вопросы присылайте по адресу is@groteck.ru