Как понять, что вам пора покупать XDR | Блог Касперского

Как понять, что вашей компании нужен отдельный XDR вместо собранного из разных решений.

Есть такое когнитивное искажение «отклонение в сторону статус-кво». Оно про то, что нам всем не нравятся перемены, поскольку «ущерб от потери статус-кво воспринимается как больший, чем потенциальная выгода». А еще есть эффект владения, когда человек больше ценит вещи, которыми уже владеет, а не те, которыми может овладеть. И еще 13 разных искажений, которые заставляют нас предпочитать то, во что уже вложены время и усилия.

К чему это я и при чем тут XDR? А я это к тому, что мы не особо любим новое. И хотя вроде бы при принятии решений об использовании того или иного нового ИБ-продукта мы хорошенько все обдумываем и взвешиваем, причем не в одиночку, в конечном итоге все равно решение принимают люди.

Как правило, если рынок начинает активно обсуждать какую-то новую систему, то реальную ее полезность пользователи признают только через пару-тройку лет. И это в лучшем случае. Есть еще вариант, когда система вообще не проходит это испытание и либо плавно сливается с существующим классом решений, либо вовсе исчезает.

Сейчас новым кандидатом, проходящим тест на полезность, стал XDR. И в данном случае под XDR я буду подразумевать платформу, в состав которой входит как минимум EDR, NTA, TI, SIEM и SOAR/IRP. То есть защита сети и конечных точек, система мониторинга и автоматизации реагирования (плейбуки разной степени вложенности и вот это все).

И, возможно, наша нелюбовь к изменениям — это очень даже неплохо. Как будто бы это поможет нам подготовиться и выжать из XDR максимум пользы. Мы же помним, что в стратегиях MITRE есть одна из заповедей, которая говорит, что надо обязательно «максимизировать пользу от закупленных технологий». Да и вообще, вдруг нам не нужен XDR? Как понять, стоит ли отдать много денег вендору?

Как понять, не пора ли купить XDR?

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

Получается, если мы хотим использовать XDR — нам надо сначала выстроить все процессы. От выявления до реагирования. Давайте посмотрим, что тут можно сделать своими руками, без волшебной «XDR-коробки» от вендора. А потом подумаем, в каком случае она все-таки может нам пригодиться.

Если посмотреть на классические определения SOC, то вы увидите, что это либо исключительно команда аналитиков, либо совокупность людей, процессов и только в последнюю очередь — технологий.

Поэтому первым делом нужно выстраивать процессы в общечеловеческом понимании: определить, что в целом происходит в инфраструктуре, кто за что отвечает и кто поможет решить какие проблемы в случае чего. И тут особо не помогут никакая автоматизация и никакие инструменты: придется что-то придумывать самостоятельно. Ну или списать готовое, это тоже хороший вариант — не зря же методологи пишут тонны всевозможных документов про лучшие практики.

В целом при небольшом масштабе организации и наличии базовых средств защиты можно вообще остановиться на этом этапе и плюнуть на автоматизацию: все может работать и так, «прожиточный минимум» достигнут. Но, как правило, такое положение вещей не встречается в реальной жизни. Для реальности характерна другая картина: есть много разных решений, которые в целом должны вести к одной светлой безопасной цели, но по факту скорее мешают друг другу.

Попробуем решить эту проблему. Очевидное решение — взять меньше средств защиты и получше их настроить.

Мысленно строим XDR

Я считаю, что в состав XDR должны входить средства защиты сети и конечных точек, потоки данных об угрозах и какие-то средства мониторинга-автоматизации-оркестрации. Поскольку я разбираюсь в SIEM-системах лучше, чем в чем-нибудь сетевом, я буду в своем упражнении отталкиваться именно от SIEM и того, что можно сделать ее ресурсами. И, соответственно, в рассуждениях я оставлю за скобками многие важные функции XDR, которые SIEM никак не потянет: не буду говорить про функции защиты сети и конечных точек.

Один мой друг появление почти любого решения для мониторинга и управления ИБ (вроде SOAR и IRP) комментирует фразой «это все можно сделать в SIEM». И чаще всего это действительно так. Возьмем, например, два процесса, которые часто выносят на отдельные платформы. Первый — обогащение базовых событий данными об индикаторах компрометации и поиск в событиях по этим индикаторам. Второй — реагирование на инциденты.

Начнем с обогащения. Просто потому, что оно происходит раньше. Допустим, у меня нет никакой TI-платформы, только потоки данных и SIEM. Есть несколько вариантов выбора этапа, на котором мне стоит поискать, не найдется ли в моих событиях индикаторов компрометации. Первый — до записи событий в базу SIEM. Это самый предпочтительный вариант, поскольку наличие IoC — важный фактор, который точно стоит учитывать в корреляции. Если так не получится — придется делать это уже позже, на этапе полноценной корреляции. Нагрузка, конечно, увеличится, ну и ладно.

Дальше начинаются разные технические вопросы реализации: как именно мне обращаться к спискам индикаторов, хранить ли их в SIEM или обойтись внешними файлами, какой компонент будет выполнять сопоставление и так далее.

Тут все ограничится только моей фантазией, здравым смыслом и техническими ограничениями платформы. И если у меня достаточно мощная SIEM-система, у нее найдутся способы реализовать процессы, как только мне угодно.

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

Но в целом эту задачу мы решили, двигаемся дальше — к реагированию.

Тут мы очень тесно начинаем соприкасаться с теми самыми процессами, о которых шла речь в начале. Поскольку чтобы реагировать, надо понимать, а как, собственно, реагировать. Но я буду считать, что мы молодцы и не пропустили этап осознания и налаживания понимания происходящего, а потому примерно знаем, что нужно делать.

Дальше дело за малым — написать много разных правил корреляции, очень тщательно их отладить и приступить к написанию стопки скриптов, которые помогут нам раздавать ценные указания компонентам инфраструктуры: межсетевым экранам, почтовым сервисам, доменным контроллерам, рабочим станциям и так далее. Честно говоря, я бы не хотела этим заниматься. Но раз уж влезла в мысленный эксперимент, надо хотя бы его довести до конца.

По сути, мне сейчас придется средствами корреляционного движка SIEM реализовать workflow работы с ИБ-инцидентом. Рассмотрим на простом примере: обнаружен и не вылечен вирус на каком-либо хосте, при этом видно, что этот хост старательно пытается достучаться до какого-то адреса в Интернете, но межсетевой экран его не пускает. В целом план действий может быть таким: запускаем сканирование хоста, изолируем его от сети, на всякий случай отключаем учетную запись пользователя, который последним на этом хосте логинился.

Но очень велик шанс, что нам никто не разрешит просто так взять и заблокировать что-то где-то — это потребует согласования. То есть добавляется еще один шаг: предварительно оповестить администраторов систем (в нашем случае МЭ и AD). А вернее даже два шага, потому что надо еще и получить от них подтверждение того, что нам можно делать то, что мы хотим. А раз мы говорим об автоматизации, эти два шага добавляют нам необходимость как-то предусмотреть возможность поставить реагирование на паузу и потом, в определенный момент, продолжить.

Даже для простого инцидента получилось долго рассказывать. А для более сложного? А для десятка разных? А для критических систем, где потребуется более сложное согласование? Ужас.

Получается, что в целом я реализовала все, что мне было нужно. Но, как говорится, какой ценой. И что с этим всем будет, если я захочу уехать после всей этой настройки отдохнуть, а в процессе согласования что-то изменится? А если захочу переехать в теплые страны и больше никогда не работать? Есть ощущение, что ничего хорошего не выйдет. Мне всегда хочется верить в то, что архитектор системы хорош настолько, что создал идеальную документацию, предусмотрел все нюансы, спроектировал все с хорошим заделом на будущее. Но почему-то таких историй крайне мало. А вот обратных ситуаций, когда после ухода творца система какое-то время по инерции работает, но рано или поздно наступает тот момент, когда она превращается в абсолютно черный ящик, который проще переделать, чем разобраться в нем, случается немало.

В результате наметились вещи, которые я очень хотела бы, чтобы за меня сделала какая-нибудь волшебная машина за много денег. Я с удовольствием и большой пользой для производительности (как своей, так и SIEM-системы) отдам работу с фидами специальной платформе. И с еще большим удовольствием выделю процесс работы с инцидентом ИБ в модуль IRP/SOAR. И еще чтобы кто-то вместо меня занимался поддержанием работоспособности созданной системы.

То есть, по сути, мне уже действительно нужна та самая волшебная XDR-коробка от вендора. Просто потому, что ценный человеческий ресурс лучше не тратить там, где рутинную работу заменяет правило корреляции или плейбук. И тем более там, где можно отдать поддержку работоспособности системы ее создателю.

Но все же полезно это приобретение будет только тогда, когда я точно пойму, нужны ли именно мне функции XDR. Потому что иначе есть шанс оказаться в ситуации, когда у меня нет ни корреляции, ни понимания актуальных для инфраструктуры угроз, но непременно надо нарисовать какие-нибудь плейбуки. Куплено же.

Вот и получается, что польза от вендорского XDR есть, но только тогда, когда мы понимаем, что это такое, из чего оно состоит, что эти составные части делают и как именно они смогут упростить нам жизнь. То есть вы готовы к XDR, только если вы уже сами реализовали «свой XDR».

25.07.2023