Самый объективный способ проверить эффективность вашего 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. Но не будем продуктовыми стратегами других и кидать камни в чужие огороды.
Данная заметка начиналась с общих результатов теста, поэтому приведу картинку, с суммарными очками среди участников, наподобие приводимой ранее таблички.