Мониторинг инцидентов безопасности – это очень рутинный процесс. С течением времени он может привести к выгоранию специалистов и к тому, что сами процессы станут недейственными. Клиентам же важен эффективный мониторинг, а это не столько выявление, сколько конкретно реагирование на инциденты. IRP-система предполагает инструменты для поиска, анализа и реагирования на события. Эта платформа автоматизирует реагирование на инциденты, следовательно, повышает эффективность мониторинга.
В предыдущих статьях мы разобрали некоторые вопросы, связанные с центром мониторинга информационной безопасности (SOC):
- SOC: устройство центра мониторинга
- Для чего нужен центр мониторинга и реагирования на инциденты ИБ
- Виды центров мониторинга (SOC)
Чтобы понять контекст и предпосылки автоматизации процессов мониторинга, стоит погрузиться в историю построения SOC.
История создания центра мониторинга SOCRAT
О создании собственного центра мониторинга наша компания впервые задумалась в 2019 году. Тема SOC уже тогда широко обсуждалась в информационном пространстве, хотя компаний с выстроенным мониторингом инцидентов безопасности можно было пересчитать по пальцам одной руки. Поэтому главная задача, которая стояла перед нами на первом этапе, была понять, есть ли рынок под эту услугу. В связи с этим свой SOC мы строили с минимальными финансовыми вложениями, фактически на голом энтузиазме специалистов.
У такого подхода есть плюсы и минусы.
Плюсом станет постепенное погружение в предметную область и наращивание собственной экспертизы. Среди минусов можно отметить отсутствие системности в процессе построения центра мониторинга, что чаще всего ведет к ошибкам на уровне архитектуры.
Кроме того, на начальном этапе возникает множество вопросов:
- Какие технологии использовать?
Здесь мы увидели 2 варианта: использовать бесплатное Open Source-решение либо SIEM-систему из бюджетного сегмента. В первом случае проблема заключалась в том, что Open Source-решение не имело техподдержки и постоянно обновляемых баз правил. Кроме того, оно требовало доработки и наполнения его экспертизой. Второй вариант обходился относительно недорого, однако не закрывал все потребности и требовал применения дополнительных инструментов к имеющемуся функционалу SIEM.
- Если выбирать SIEM-систему, то какую именно?
Для решения этого вопроса необходимо проанализировать имеющиеся на рынке технологии, выбрать наиболее подходящие по стоимости и политике лицензирования, а в дальнейшем протестировать их.
- В каком режиме будет функционировать центр мониторинга и сколько человек нужно для организации смен?
В случае мониторинга в режиме 8х5 (8 часов в день 5 дней в неделю) расчет количества человек не составляет труда. Но в случае круглосуточного мониторинга возникает ряд вопросов: «Каким образом организовать смены?» «По сколько часов должны работать сотрудники в смене?» «Как выполнить соответствие трудовому законодательству?»
Возникали и другие вопросы. Их мы старались решать по мере поступления. Например, с развитием центра нам пришлось решать вопрос нужно ли организовывать взаимодействие с ГосСОПКА, а также будем ли мы развивать дополнительный функционал центра, и если да, то какой?
Итак, однозначных ответов на вопрос, как построить SOC, у нас не было. А потому мы «набивали шишки» и несколько раз вносили существенные изменения в архитектуру нашего SOC. В итоге на построение центра мониторинга ушло больше года, однако полученный опыт позволил глубоко погрузиться в тему.
Первый опыт реализации услуги и первые результаты
Когда центр мониторинга был построен и начал функционировать как внутренний SOC, появился первый клиент.
Работа велась штатно. Специалисты заступали на смену, контролировали поток событий, формировали инциденты в виде карточек. Карточки направлялись заказчику на почту. Раз в месяц готовился отчет со статистикой, перечнем инцидентов и рекомендациями для отправки в контролируемую организацию.
В процессе мониторинга мы регулярно получали обратную связь от заказчика, на основе которой нам удалось сформировать перечень ложно-позитивных инцидентов. Это, в свою очередь, сократило нагрузку на специалистов центра мониторинга.
Проблемы, с которыми столкнулся наш центр мониторинга
Большой поток событий ИБ и отсутствие обратной связи
Еще на стадии построения центра мы начали анализировать рынок и ходе изысканий заметили, что современные центры мониторинга используют время реагирования (SLA) в качестве отстройки от конкурентов. Это было похоже на некие соревнования: у кого выше скорость реакции, тот круче. Такие действия привели к тому, что быстрота реагирования стала не преимуществом, а чем-то само собой разумеющимся.
При этом возникла такая ситуация, когда центр мониторинга реагирует на выявленный инцидент быстро, а организация на своей стороне – в штатном порядке. Казалось бы, это дело заказчика. Но не все так просто.
Отсутствие обратной связи по предпринятым действиям со стороны заказчика приводило к тому, что SOC-аналитики вновь наблюдали те же инциденты, по которым уже был проведён анализ, сформированы рекомендации и отправлены уведомления. Такие инциденты отвлекали специалистов, так как их статус не был определен. Это инцидент ложно-позитивный, и его можно исключить, рекомендации по инциденту некорректные, и поэтому инцидент повторяется, или заказчик игнорирует рекомендации?
Сложности при отработке инцидентов ИБ
Наибольшие сложности наблюдались при круглосуточном мониторинге, когда специалисты работали посменно. Что произошло?
SOC-аналитик выявил инцидент, сформировал карточку и направил ее заказчику. Смена закончилась, специалист ушел с рабочего места. И если у заказчика возникали вопросы, с ним взаимодействовал уже другой сотрудник центра. Но для того, что быть дать корректный ответ, данному сотруднику нужно было найти карточку инцидента, изучить связанные с ним материалы, погрузить в суть произошедшей ситуации.
Такие действия отвлекали специалиста от процесса мониторинга.
Мониторинг более трех информационных систем
Вопрос отображения потока событий и инцидентов обострялся с каждым новым заказчиком. Все дело в том, что с самого начала мы позиционировали наш SOC как мониторинг под потребности конкретного заказчика. Поэтому у нас очень быстро возникла такая ситуация, когда у одного заказчика система мониторинга размещалась на его ресурсах, у другого источники событий были заведены в систему мониторинга SOC, у третьего система мониторинга располагалась на его площадке, но имела ряд сложностей с интеграцией. Все это приводило к тому, что в процессе мониторинга SOC-аналитику приходилось переключаться между интерфейсами разных систем. Это было неудобно.
Контекст
Для снижения количества ложно-позитивных инцидентов безопасности проводилась инвентаризация контролируемых узлов. Но с ростом количества заказчиков держать под рукой отчет с результатами инвентаризации по каждой инфраструктуре стало неудобно. Анализ отчета занимал время. Кроме того, в состав инвентаризации не попадали ресурсы, не включенные в состав контролируемых, несмотря на то, что они активно с ними взаимодействовали. Из-за этого не всегда была понятна легитимность сетевых потоков.
Поиск решений
Проблемы появлялись постепенно, с ростом зрелости центра мониторинга. Часть из них решали собственными силами специалистов центра при помощи разработки утилит.
Чтобы решить часть других проблем, мы попытались самостоятельно разработать приложение. Его цель – создавать карточки инцидентов и взаимодействовать с заказчиками. Однако сформировав первый рабочий вариант архитектуры и трезво оценив свои силы, от данной идеи мы отказались.
Также пробовали решить проблемы с помощью Open Source-решений. Но найти подходящее не удалось. Где-то не было ролевой модели, чтобы разграничить зоны видимости, где-то были проблемы с интеграцией.
В определенный момент мы поняли, что для эффективной работы нам нужен единый инструмент, с помощью которого можно будет закрыть все проблемы.
К моменту, когда проблем накопилось столько, что закрывать на них глаза уже было невозможно, а наш SOC начал приносить доход компании, руководство приняло решение инвестировать в дальнейшее развитие центра. Мы наняли стороннюю команду разработчиков под реализацию приложения, которое по итогу разработки стало тем самым единым инструментом для решения накопившихся проблем.
Как разработанная IRP-система позволила решить проблемы
Сокращение времени реакции на инциденты ИБ
До внедрения IRP-системы карточка проходила несколько этапов:
- создание документа;
- проверка специалистами и дополнение, если потребуется;
- упаковка в запароленный архив;
- отправка на почту клиенту.
После внедрения IRP-системы карточка стала вноситься в специальную веб-форму, и уже в рамках сервиса можно было вносить любые корректировки.
Кроме того, благодаря внедренной системе удалось сократить время реакции на инцидент безопасности со стороны заказчика. Нами был внедрен более удобный формат получения информации об инциденте. ИБ-уведомление в мессенджере и более эргономичное отображение карточки позволило сократить время на изучение заказчиком инцидента и предоставление обратной связи.
За счет этого решение по инциденту стали принимать быстрее, а база ложно-позитивных инцидентов стала пополнятся чаще. Данные шаги привели к сокращению потока неактуальных сработок.
Однако единого ответа, как оценить время реагирования, не было. Поэтому стали использовать собственную схему.
В IRP-системе был разработан функционал, позволяющий фиксировать дату создания карточки инцидента и вычитать из неё дату фиксации инцидента, а разницу выводить в виде времени реагирования. Помимо этого, в карточке организации разработчики добавили поле, где можно задать эталонное время реагирования, с которым сравнивается время реагирования на инцидент ИБ. Иными словами, в дашборде реализовали индикацию и отображение времени реагирования для каждого инцидента. В случае выхода за установленное время на реагирование инцидент подсвечивается. Данная информация отображается на всех уровнях: у руководителя центра мониторинга, специалистов и заказчика.
Решение проблемы взаимодействия
После внедрения IRP-системы взаимодействие центра с конкретным заказчиком ускорилось.
Теперь, когда у заказчика возникает вопрос по инциденту в рамках внедренной системы, он задает его в соответствующем разделе карточки инцидента – чате. После этого каждый специалист получает уведомление об изменении. Вся информация по инциденту располагается в едином пространстве, поэтому любой специалист может оперативно погрузиться в суть инцидента и ответить на вопрос.
Устранение проблемы отображения потока событий
Для решения этой проблемы IRP-система аккумулирует события и инциденты от систем мониторинга и отображает всю информацию в едином интерфейсе. Кроме того, фильтрацию ложно-позитивных событий можно организовать непосредственно в интерфейсе самой платформы реагирования на инциденты информационной безопасности.
Решение проблемы с контекстом
Решение отчасти пересекается с устранением проблемы с едином окном, полным событий. Для этого в IRP-системе была реализована возможность получения инвентаризационной информации, на основании которой впоследствии можно строить карту сети с узлами и установленным программным обеспечением.
Для сбора инвентаризационной информации внедрен агент, который устанавливается на каждом узле. Кроме этого, была добавлена функция импорта отчета со средств инвентаризации.
Заключение
Внедрение IRP-системы позволило не просто сократить время реагирования на инцидент, но и начать его контролировать. Были введены первые метрики, которые можно отслеживать и в дальнейшем влиять на эффективность работы центра мониторинга. Также внедрение платформы реагирования на киберинциденты позволило решить ряд проблем, которые озадачивали команду SOC в начале пути.
На текущий момент разработка продолжается, но мы решаем уже другие вопросы и задачи.