Мифы и легенды SOCостроителей, или 5 заблуждений о центрах мониторинга и реагирования на кибератаки

Уже завтра стартует V SOC-Форум — крупнейшее мероприятие по практикам выявления и анализа инцидентов в России. Уверен, что многие читатели этого хаба окажутся там и услышат немало профессиональных докладов по этому направлению информационной безопасности. Но помимо терминов, определений и устоявшейся практики, которая освещается на SOC-Форуме, в реальной жизни каждый из вас наверняка слышал массу разных мнений о функционировании SOC, защите от APT-атак и т. д. Сегодня мы обсудим несколько популярных мифов и легенд.

Нам интересно и ваше мнение по поводу каждого из них, поэтому ждем ваших комментариев. Добро пожаловать под кат.

Миф 1 – SOC на одной струне, или Магия разбора сетевого трафика

Очень часто, обсуждая с заказчиком комплексную защиту от внешних злоумышленников, мы слышим: «А у нас стоит железка А, она обогащена экспертизой вендора и информацией о новых угрозах, и она нас целиком защищает от внешних атак». И ладно, если бы после этих слов нам явили многомодульное Anti-APT-решение — вопросы бы остались, но их стало б куда меньше. Чаще же всего за этим «универсальным устройством» скрывается обыкновенный IDS, иногда с базовым функционалом анализа https-траффика. Мы не ставим под сомнение экспертизу вендоров в области кибербезопасности и их осведомленность о деятельности хакеров, как и полезность записи и анализа сетевого трафика (эта тема точно будет неоднократно подниматься на Форуме), но хотим, тем не менее, сделать акцент на ограничениях подхода, при котором SOC ориентируется только на события сети.

• Начнем с базового и несколько уже избитого. Еще с 2013 года мы наблюдаем хакерские атаки, проводимые без использования ВПО как такового и уж как минимум без модуля взаимодействия с сервером управления. На помощь злоумышленникам приходят легитимные утилиты удаленного администрирования (Remote Access Tools), которые с правильным конфигурационным файлом ведут себя неотличимо от пользователей, любящих поработать из дома, или работы удаленных администраторов в компаниях с невысоким уровнем зрелости ИТ. На уровне сетевых событий отличить одни сессии от других просто невозможно и для полноценного анализа способа и причин запуска сессии нужна информация с конечных систем.
• Если же злоумышленнику претит идея RAT или они неприменимы в конкретном кейсе атаки, на помощь приходит https-протокол как способ взаимодействия. На копии трафика дешифрация протокола невозможна, поэтому сенсору приходится довольствоваться исключительно информацией о заголовках пакета. Это полезно, только когда центр управления находится в какой-то специфической зоне и можно вычислить его по IP. Но все чаще речь идет о больших хостингах или публичных сервисах (о взломе страниц WordPress мы писали ранее), что не позволяет идентифицировать, где легитимное соединение, а где скомпрометированное.
• При всей полезности сетевые коннекты (а мы говорим, как правило, о железке, стоящей в районе периметра) фиксируют только взаимосвязи центра управления с верхней цепочкой бот-клиентов. Зачастую текущие злоумышленники используют цепочку проксирующих C&C-серверов (первый уровень захвата инфраструктуры) для связи с внутренними бот-клиентами. В этом месте ограничения расположения оборудования не дают полноценно детектировать атаку.
• При всем многообразии действий злоумышленника ему периодически вообще нет необходимости приходить из интернета. Возможна компрометация учетной записи удаленного доступа, а после этого — работа под легитимными правами администратора или пользователя. Все чаще группировки используют методику supply chain, начиная атаку со взлома подрядчика, у которого зачастую есть статичный и слабо контролируемый канал в инфраструктуру и все те же привилегированные учетные записи. Векторов с каждым годом становится все больше, и они все дальше от классических средств защиты.
• И вообще SOC — это не только про противодействие хакерам. Внутренние злоумышленники, нарушение политик ИБ или мошенничество, выгрузка или компрометация клиентских данных и многое другое тоже является частью комплексного SOC-подхода. И требует гораздо более сложных методик и инструментов в своей работе.

Миф 2 – SOC без ног, или Работа без первой линии

Одна из самых любимых нами легенд. Шутки про SOC, где работает всего 1 человек, поэтому он немного 1-ая, немного 2-ая и немного 3-я линия поддержки, уже заполонили интернет. Но очень многие заказчики, наслушавшись разных докладов и начитавшись статей, начинают говорить о том, что нужна волшебная железка/процедура/технология (нужное подчеркнуть), которая автоматизирует и решит все проблемы 1-ой линии. А поскольку зачастую в голове заказчика 1-я линия равнозначна режиму работы 24*7 (все остальные, как правило, работают уже по стандартному графику), это автоматически создает ощущение существенного снижения расходов на персонал и порождает разговоры в ключе «1-я линия не нужна, давайте начнем строить сразу со второй».

Ключевой проблемой этой легенды, на наш взгляд, является путаница в терминологии. Зачастую, когда докладчик говорит о 1-й линии, он руководствуется практиками ITIL, где действительно в руки операторов попадают атомарные задачи:

• прием задачи
• классификация
• добавление контекста (актива или информационной системы)
• приоритизация или уточнение приоритетов
• назначение на ответственного по системе/экспертизе/очереди.

Когда речь идет о такого рода задачах, конечно, никакая выделенная первая линия не нужна: данные процессы хоть и непросто, но вполне автоматизируемы. Что мы со своей стороны понимаем под 1-ой линией, мы уже несколько раз писали – например здесь). Все-таки 1-ая линия — это не замена автоматизации, и даже не команда, работающая исключительно по playbook. Это сотрудники пытливые и ищущие, хотя и обладающие лишь базовым навыком в анализе событий и расследовании инцидентов. В терминах ITIL такая линия бы называлась 2-й, что сразу снимает все вопросы и расхождения.

Не хотелось бы обойти стороной и вопросы 24*7. Про организацию смены, эффективность работы операторов и аналитиков в ночные часы, психологическую слепоту при просмотре событий сказано тоже достаточно немало. Интегральные выводы примерно те же – 1-ая линия SOC и круглосуточная смена становятся неэффективными и ненужными. Мы со своей стороны за долгие годы тоже испробовали разные методики и на текущий момент федеральный уровень SOC позволяет нам минимизировать риски усталости специалиста в ночную смену (критичный инцидент просто направляется в другой часовой пояс), тем не менее хотелось бы отметить несколько тезисов.

• Сокращение времени смены для оператора – очень хорошая идея. Работа по принципу ИТ-дежурства сутки-трое в ИБ скорее невозможна. При этом сохранение концентрации на инцидентах очень важно…
• НО…оператор 1-ой линии не сидит, как оператор из фильма «Матрица», просматривая поток сырых событий в поисках аномалий. По крайней мере, ни в одном известном нам SOC мы такой подход не встречали. Его работа состоит в анализе регулярных отчетов и хантов, или отработке срабатываний сценариев выявления инцидентов. В таком режиме переключения внимания и типов активности (при правильном балансе численности на линии) риски быстрой психологической слепоты нам кажутся минимальными.

И в завершение — как бы далеко не зашла автоматизация, на любом критичном производстве принято оставлять специалиста, контролирующего ситуацию с машинами и роботами. И если ваша развилка в данном случае в том, «может ли автоматизация помочь мне не выделять 5–6 ставок на дежурную смену», то наш ответ однозначный: не может.

Миф 3 – Идеальный SOC без единого разрыва, или Работаем без ложных срабатываний

Чем больше ты занимаешься построением SOC или работаешь с MSSP/MDR-провайдером, тем больше хочется идеального. Сейчас очень много заказчиков прошли через огонь, воду и медные трубы первых самостоятельных подходов к снаряду или пилотов/контрактов с внешними поставщиками и все так или иначе пытаются стремиться к идеалу. А идеал в глазах руководителя/ответственного за внешний сервис обычно выражается фразой «каждое оповещение — это подтвержденный инцидент» или «мы следим не за подозрениями — мы фиксируем атаки». И с точки зрения ключевых аспектов эффективности сложно спорить с этим утверждением. Но, как всегда, дьявол в деталях.

Большинство SOC-ов нацелены на эффективный, максимально глубокий анализ инцидента по всей доступной информации. И они все сильнее приближаются к совершенству, когда у них есть возможность получать снаряды логи для нее. Разберем на примере инцидента по фактам срабатывания сетевых индикаторов вирусного ПО (адреса связи с центром управления) – для их выявления достаточно лишь какой-то информации по сетевым потокам в интернет, например, логов межсетевого экрана, но они довольно часто дают ложный результат. Достаточно злоумышленнику спрятать свой сервер управления ВПО на хостинге, и мы автоматически будем сталкиваться с большим количеством ложных срабатываний. Для эффективной фильтрации и анализа инцидента необходимо локализовать активности на хосте-инициаторе (запускаемые процессы, открываемые сокеты и т.д). А это приводит нас к необходимости подключения событий со всех хостов сети.

Итого: чтобы SOC приблизился к возможности выявления исключительно атак, без ложных срабатываний, нам необходимо обеспечить максимальное покрытие инфраструктуры мониторингом — в идеале собирать ВСЕ журналы со ВСЕХ объектов.

Это приводит нас сразу к нескольким проблемам.

1. Фактическое противодействие ИТ-подразделений повышению уровня аудита или установке дополнительных систем для сбора (во избежание зла даже не будем касаться тематики подключения сегментов АСУ ТП и технологов). Тестирования на совместимость, непрогнозируемое повышение нагрузки на системы и прочие факторы, способные повлиять на общую доступность инфраструктуры, являются спусковым крючком для очередного витка войны между ИТ и ИБ. А чаще всего просто оставляют большие белые пятна на карте мониторинга инфраструктуры со стороны SOC.
2. Поддержание состояния полного покрытия. Невозможно собирать все логи со всех серверов. Например, в новых системах логи могут быть просто не включены. Нередко в процессе смены серверов частично или полностью пропадают настройки аудита на рабочих станциях и ограничения доступов. К тому же настройки необходимо обновлять по мере появления новых векторов атак. Все это создает операционные затраты на обеспечение полного покрытия, существенно более высокие, чем зачастую риски от неполного обзора мониторингом, и уж точно большие, чем расходы на потенциальное реагирование по ложному срабатыванию.
3. Третья проблема приводит нас к старой игре DOOM. Потому что, помимо прочего, полное покрытие требует от вас ввода кодов.

   a. IDKFA – полного боезапаса в виде бесконечных серверных мощностей на сбор и хранение событий и, что с точки зрения экономики много печальнее, – бесконечных лицензий на SIEM и прочие инструменты SOC.

   b. IDDQD – огромную и бессмертную команду SOC, которая в каждом инциденте сможет проанализировать все его явные и косвенные признаки.

Совпадение таких факторов, задач и объема бюджетов на информационную безопасность считается случаем встречи зеленого слона и поэтому не рассматривается как типовая ситуация в жизни SOC. А значит, выявление только подтвержденных атак (при всем желании анализировать максимально глубоко автоматическими инструментами) является чуть фантастической мечтой современных безопасников.

Вместо послесловия

Мы постарались обсудить только наиболее частые мифы тематики SOCостроения. Поэтому в сложных заводях запуска процессов мониторинга и реагирования на инциденты советуем вам максимально скептически относиться к поступающей информации, верифицировать ее в разных источниках и максимально опасаться контрафакта неподтвержденных опытом суждений.

И да пребудет с вами Сила;).