MITRE оценила EDR и MDR, второй круг

Самый объективный способ проверить эффективность вашего SOC (blue team) - скрытая симуляция действий реальных злоумышленников (red teaming)

(Личный опыт)

Несмотря на наличие прекрасных инструментов анализа от самой MITRE и замечательных публикаций от участников, хочется продолжить серию статей о тесте, где я сравниваю решения по примитивной методике с коэффициентами за категории детектов, которой мне лично  удобно пользоваться, поскольку в итоге отрисовывается большая HTML-ка где по строкам можно удобно увидеть что каждый вендор выдал на соответствующую технику, и даже кликнуть и посмотреть скриншотик. Рассматривать скриншоты - очень увлекательное и полезное занятие, так как вскрывается некоторый инсайд, который частично может быть дешевой компенсацией отсутствия пилота - по скриншотам можно понять что бы вам выдавали продукт и/или сервис, если бы вы их сами себе установили и натравили бы на них реальный Red team. Как всегда все доступно у меня в хабе, t2.py - генерит две html-ки: out2.html (есть еще и json, с теми же данными) содержит полную сравнительную таблицу по всем участникам, out2-combined.html содержит сводную таблицу по простой сумме детектов по типам (Count) и по присвоенным очкам в рамках данной методики (Points = Count, умноженный на вес детекта соответствующего типа). Для работы t2.py надо скачать json-ы результатов.
Для начала остановимся на изменениях в весах детектов, по сравнению с предыдущей оценкой.
1. Веса Techinque (= Specific behavior), General (= General behavior) и Telemetry остались прежними, для сохранения объективности
2. В тесте добавился не совсем прозрачный, в сравнении с прошлогодним General behavior  (а следовательно, с текущим General), Tactic, - решил, что он лучше чем General, дал ему вес 40.
3. Детект MSSP оценил выше чем Technique, дал ему вес 70. Логика такая, что если есть детект MSSP, то вся соответствующая линейка из Telemetry, Techinque и все необходимые обогащения для расследования аналитиком MDR имеются в наличии, иначе бы MSSP не выдал инцидент.
Данный тест является первым и последним, где проверяются не только продуктовые детекты, но и инциденты, полученные от соответствующего сервиса (на сайте MITRE для каждого участника приведена тестируемая конфигурация, например). Мое мнение, исключать сервис из следующих тестов - некорректно, поскольку правильно смотреть комплексную картину, с участием всех элементов вендорского предложения, тем более с учетом того, что серийный продукт будет всегда будет иметь ограничения, а если мы хотим повышать эффективность противостояния сложным атакам, то синергия людей и автоматов должна усиливаться. Правда, отсутствие prevention, о чем писал здесь (прошу прощения, что не по-русски) по-прежнему сохраняет некоторую искусственность, так как в реальной жизни prevention не будет выключен, а попытки его обхода создадут дополнительный шум, что повысит вероятность успешного и раннего (так как prevention отрабатывает первым!) обнаружения. Кстати, коллеги написали целый раздел о своем опыте участия, думаю, имеет смысл почитать, особенно может быть интересно описание процесса. С учетом этого самого процесса проведения теста могу с уверенностью сказать, что он на данный момент является самым объективным инструментом оценки эффективности сервиса, поскольку никакими странными табличками нельзя проверить насколько качественно сервис обнаруживает реальные угрозы, кроме как непосредственной симуляцией. Я считаю, что те, кто не участвовал в тесте едва ли могут назвать себя Managed Detection and Response, поэтому косвенно тест не только сравнил предложения, но и, в общем-то, очертил круг доступных на рыке поставщиков MDR, забив осиновый кол в неопределенность отличия провайдеров alert-driven SOC от реальных предложений MDR. Причем, сравнить MDR по результатам теста MITRE даже проще, чем продукты, так как в тесте от сервиса учитывается только один тип детекта - MSSP, тогда в продуктах есть разные типы детектов, которые надо бы учитывать с разными весами, и тут как раз и появляется неопределенность и вероятная необъективность. MSSP можно сравнивать по обычной сумме выданных инцидентов. Если это сделать, то картина получается следующая (каждый сам может сделать это несложное упражнение с помощью out2-combined.html и любимого редактора табличек, наподобие Excel).

Картинка не содержит вендоров, кто вообще не имеет детектов категории MSSP. Я этого не понимаю. Я не понимаю, как вендор, не имеющий своего MDR может делать качественный продукт. Лучшая дорожная карта развития продукта появляется из практики его использования, не понятно на основании чего развивается продукт, если этой практики использования нет. Никакие интервьюирования заказчиков не компенсируют отсутствие личного опыта. Мне очень нравится тезис, что MDR - это практическая реализация Threat hunting в форме операционного сервиса, поэтому мне также не понятно, как может рассуждать о threat hunting вендор, не предоставляющий MDR. Но не будем продуктовыми стратегами других и кидать камни в чужие огороды.
Данная заметка начиналась с общих результатов теста, поэтому приведу картинку, с суммарными очками среди участников, наподобие приводимой ранее таблички.

MITRE оценила EDR, + EPP-вендоры

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

Сегодня заметил, что опубликовались тесты F-Secure и McAfee, чьи результаты крайне интересны, так как эти производители также предлагают не просто EDR или какой-то клон NextGen-а , а законченное решение EPP-EDR. 

Любопытство быстро победило прокрастинацию и результат оценки с помощью все того же тула уже доступен здесь (см. файлики out.json и out.html) + поправил ссылки со скриншотами, поскольку они переехали.

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

Предыдущая статья вызвала массу негатива, так как, из-за наличия в ней необъятной таблицы, она плохо читается, поэтому в эту заметку таблицу не публикую, можно взять ее самостоятельно с github-а (файлик out.*), однако, поскольку это ее уже не испортит, все же обновлю таблицу сравнения в предыдущей статье.

Итак, что же получилось по очкам:

FireEye	5262
CrowdStrike	4467
F-Secure	4240
PaloAltoNetworks	3611
Endgame	2971
McAfee	2913
CarbonBlack	2810
Cybereason	2648
Microsoft	2601
CounterTack	1173
SentinelOne	862
RSA	775

Жирным отметил авангард, курсивом - арьергард.

Проблемы, которые видны с ходу и, возможно, которые я адресую в следующих постах по этой же теме:
А. Надо оценивать не только абсолютное количество очков, но и равномерность покрытия.
Б. Возможно, надо на каждую процедуру проставлять не абсолютную оценку, а относительную на фоне других участников (поскольку есть ряд процедур, которые технологически продетектить сложно\невозможно\не рентабельно)
В. Надо оценивать визуализации, поскольку время, требуемое аналитику на расследование детекта - очень важная метрика, которая может косвенно характеризоваться понятностью скриншота.
Г. ... еще куча других важных моментов...

В завершении хочется сказать, что при всей своей раскрученности тестирование по MITRE ATT&CK тоже не лишено недостатков\особенностей и лишь косвенно отражает качество продукта, как минимум, поскольку:
1. Тестирование проводится в несколько искусственных условиях, когда отключены все превентивные механизмы. Мы должны понимать, что эффективная безопасность - это комбинация Prevention-Detection-ThreatHunting, а когда одна из составляющих искусственно отрезана совокупная эффективность системы защиты уже не та. Хотите тестировать Living-Off-the-Land техники и бесфайловые сценарии? - пожалуйста!, но давайте по-честному. (Почему-то вспомнился доклад на одной из менеджерских конференций где докладчик рассказывал о том, что он отказался от использования антивируса, заменил его на современный EDR и посадил смотреть в него SOC, который реагировал на детекты EDR в ручном режиме... Смешно? Тогда он сделал мой день, поскольку я впервые видел человека, который гордился тем, что он заменил автоматическое удаление антивирусом на ручное SOC-ом)
2. Проверяется релевантность детектов техникам MITRE. Не раз писал, что MITRE - отличная вещь, но все равно - это модель и, если мои детекты реализуют какую-либо другую модель (ну, например, я сам ее придумал, и моя практика мониторинга подтверждает, что мои типы детектов эффективны и результативны, и вообще лучше), это не значит, что они плохие. Отчасти поэтому используемый мной подход проставления абсолютных баллов типам детектов не совсем правильный, что, возможно, будет компенсировано отмеченным выше п. Б. Констатировать просто перечень типов детектов - более правильно, как и делает сама MITRE, но как-то же надо выполнять сравнение, поэтому я и придумал эти, не выдерживающие критики, баллы.
3. Типы детектов в первом раунде и, особенно во втором, не всегда очевидны, каковы критерии их присвоения и какова там доля субъективизма - не известно, но станет понятно после самостоятельного прохождения теста.

Прямая ссылка на результат сравнения.