Поговорим про центры мониторинга и реагирования на инциденты ИБ (SOC), разберем, какие технологии применяются при построении SOC, линии поддержки, а также какие процессы происходят при выявлении атак и инцидентов безопасности.
Тема SOC не нова, но весьма обширна и запутаться в ней не сложно.
Начнём с понятия SOC.
SOC, или security operation center, дословно расшифровывается как центр оперативного реагирования. В России это центр мониторинга и реагирования на инциденты информационной безопасности.
Центр мониторинга представляет собой совокупность трёх составляющих – люди, процессы и технологии.
Технологии
Под технологиями подразумевается система мониторинга, которая собирает события, генерируемые различными активами, и аккумулирует их в едином месте с целью выявления аномального поведения в инфраструктуре.
Рассмотрим подробнее.
В инфраструктуре есть активы – всё то, что способно логировать действия и отдавать на сторону.
Например, это может быть операционная система, которая ведёт журналы и логирует всё, что происходит. Пользователь авторизовался – в журнал добавляется событие об успешной авторизации с указанием временной метки и информацией о пользователе.
Фиксировать действия пользователей может также некоторое прикладное ПО, а значит, и выступать в роли источника событий.
Таким образом, активами является всё, что может фиксировать те или иные действия пользователей и отдавать по сети на сторонний сервер.
Что такое сторонний сервер?
Под сторонним сервером здесь подразумевается система мониторинга, которая, в зависимости от задач центра мониторинга и, соответственно, его функций состоит из ряда компонентов.
На текущий момент, самым распространенным компонентом системы мониторинга является SIEM-система. SIEM-система аккумулирует в себе события, генерируемые активами, и на основе правил корреляции формирует инцидент ИБ.
Например, если в SIEM-систему поступают события, связанные с неудачной попыткой авторизации, а затем поступает событие, связанное с успешной авторизацией, при этом события поступили от одного актива, а авторизоваться пробовал один и тот же пользователь, то SIEM-система будет расценивать такое поведение, как успешный перебор паролей.
Стоит понимать, что одна, две, три неуспешные попытки, скорее всего пройдут незамеченными, так как вероятность подобрать пароль с такого количества попыток крайне низкая. Такое поведение больше связано с человеческим фактором: пользователь не поменял раскладку, случайно нажал CapsLock, забыл какой пароль установлен в системе, опечатался и т.д.. Но если неудачных попыток больше, скажем 10, то такое поведение уже подозрительное, и SIEM-система сформирует инцидент ИБ.
Помимо SIEM-системы в центре мониторинга могут использоваться решения анализа сетевого трафика (IDS\IPS, NTA). Цель таких решений – анализировать сетевые запросы и выявлять в них аномалии и недочеты.
Часто встречающиеся события от таких систем – это взаимодействие с web-приложениями через протокол HTTP, вместо HTTPS. Такое взаимодействие является небезопасным из-за возможности прочитать содержимое пакета в случае перехвата сетевого трафика. Также сюда можно отнести и авторизацию в web-приложении при помощи метода Basic Authorization, где логин и пароль передаются в кодированном Base64 виде и легко декодируются.
Кроме анализа сетевого трафика, есть класс решений, направленный на анализ поведения на конечных узлах (АРМ, сервера) – EDR. В отличие от простого сбора событий EDR может активно блокировать действия, связанные с подозрением на компьютерную атаку, а также удалять вредоносные файлы.
Еще система мониторинга может включать в себя «песочницу» для анализа файлов и почтовых вложений. Такое решение позволяет анализировать подозрительные файлы и выявлять вредоносную активность, либо предотвращать попытки фишинговой атаки через рассылку фишинговых писем с вредоносным вложением.
Таким образом, задачей системы мониторинга является сбор и анализ действий, выполняемых в инфраструктуре. Строится такая система исходя из задач и функций центра мониторинга и может включать в себя различные компоненты.
С технологиями разобрались. Идём дальше.
Люди
Под людьми подразумеваются аналитики/специалисты/инженеры центра мониторинга.
В классическом виде, специалисты центра мониторинга (SOC-аналитики) подразделяются на линии поддержки. Также, есть схемы, где специалистов разделяют по ролям.
Линии поддержки SOC
В SOC выделяют три линии поддержки:
1 линия поддержки – специалисты, которые смотрят в дашборды системы мониторинга и анализируют поступающие события и скоррелированные инциденты ИБ.
Их задача – выявлять потенциально опасные инциденты ИБ (те инциденты, которые могут навредить компании, например, остановить бизнес-процесс, зашифровав сервер с базой данных), а также обрабатывать ложно-позитивные инциденты ИБ.
Ложно-позитивные инциденты – это те инциденты, которые были скоррелированы системой мониторинга, но по факту являющиеся штатной работой инфраструктуры. Это может происходить в том числе из-за архитектурных особенностей инфраструктуры, когда система мониторинга воспринимает типовые действия как инцидент. Также есть примеры, когда идёт активная попытка эксплуатации конкретной уязвимости внешних ресурсов, но в организации, такая технология не используется.
В случае выявления потенциально опасного инцидента специалисты первой линии поддержки эскалируют инцидент на вторую линию. Чаще всего используется специализированный сервис – менеджер инцидентов или IRP-система.
2 линия поддержки – специалисты, которые расследуют потенциально опасные инциденты.
После эскалации со стороны первой линии сотрудники второй линии берут инцидент в работу и начинают расследование. Первым делом они собирают необходимую для анализа информацию: ищут информацию в системе мониторинга, например, связные события с пораженным узлом, информацию о сработавшем правиле корреляции, идентификаторы компрометации и т.д.. Общими словами, собирают доказательную базу для того, чтобы принять решение о статусе инцидента ИБ (ложно-позитивный либо потенциально опасный). По итогу расследования специалисты формируют рекомендации, которые передаются в сторону контролируемой организации для устранения выявленных недочетов.
Так как для расследования инцидента требуется контекст, в задачи специалиста второй линии входит проведение инвентаризации и анализа уязвимостей. Инвентаризация позволяет ориентироваться в инфраструктуре и даёт понимание, какие программные и технические средства используются в организации. Анализ уязвимостей помогает понять, какие уязвимости есть в инфраструктуре, что даёт понимание возможных "точек входа" злоумышленника.
Помимо этого в состав задач специалистов второй линии поддержки входит тестирование на проникновение (пентест). Пентест позволяет оценить уровень защищенности инфраструктуры, а при выявлении слабых мест – помочь организации с их устранением. В случае невозможности устранить слабое место, специалисты SOC подскажут компенсирующие меры и усилят контроль.
Если принять однозначное решение по инциденту затруднительно из-за его сложности, то специалисты 2 линии эскалируют инцидент на специалистов 3 линии.
3 линия поддержки – специалисты, которые преимущественно занимаются аналитикой и принимают участие в расследовании сложных атак.
Для того чтобы защищать, нужно понимать, как потенциальный злоумышленник может атаковать инфраструктуру. Поэтому специалисты третьей линии проводят большую работу по анализу трендов угроз и методов атак, адаптируют правила корреляции в системе мониторинга для выявления новых угроз.
Чаще всего специалисты третьей линии разделяются по ролям в зависимости от специализации. Например, специалист, занимающийся реверс-инжинирингом, своей задачей будет иметь исследование вредоносных образов (ВПО). В рамках своей роли, он может декомпилировать ВПО либо утилиту, которая использовалась в атаке, получить исходный код, проанализировать его и определить, в чем заключалась вредоносная нагрузка.
Также по отдельным фрагментам кода может быть установлена принадлежность такого образца к конкретной группировке либо определен разработчик. Например, в исходном коде утилиты могут присутствовать комментарии разработчика, написанные на определенном языке, из чего можно сделать вывод о принадлежности разработчика к той или иной стране либо части света.
Кроме специалистов линий поддержки в любом центре мониторинга должен быть его руководитель.
Руководитель центра мониторинга – специалист, который координирует действия SOC-аналитиков, а также формирует процессы и контролирует их выполнение.
Специалисту на роли руководителя центра мониторинга важно хорошо понимать процесс мониторинга и при необходимости уметь непосредственно осуществлять самому мониторинг и реагирование на инциденты ИБ, а также участвовать в расследовании инцидентов. Кроме того, в задачи руководителя центра мониторинга входят формирование архитектуры центра, регламентирования и запуска всех процессов.
Разобрались с людьми в SOC, переходим к процессам центра мониторинга.
Процессы
Под процессами понимается набор действий специалистов центра мониторинга, направленный на выявление атак и инцидентов ИБ, а также на их устранение и недопущение повторного появления.
Чтобы центр мониторинга функционировал корректно, необходим набор инструкций и правил, регламентирующий действия специалистов. В таком случае, при фиксации инцидента каждый из специалистов центра мониторинга будет четко понимать, что ему делать в той или иной ситуации.
Как мы писали выше, координацией всех действий и процессов занимается руководитель центра мониторинга.
Итак, в статье мы рассказали из чего состоит SOC и показали, что центр мониторинга (SOC) является сложным механизмом, в котором присутствуют различные, часто обладающие узконаправленным функционалом технологии и специалисты, выполняющие сложные специализированные задачи.
Именно поэтому процесс мониторинга внедрен далеко не везде, а многие организации сейчас предпочитают отдавать SOC на аутсорс ИБ-компаниям.