Friday, April 24, 2020

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




Saturday, April 18, 2020

Продукты и Сервисы

Производитель продукта заинтересован делать качественные решения. Одной из важнейших характеристик "качественного" решения является низкая операционная стоимость (TCO), т.е. с учетом всех проявлений закона сохранения  такое решение дешево поддерживать и пользователю и производителю. Производителю очень важно иметь низкую стоимость поддержки, так как, в противном случае, с бесконечным ростом продаж ему придется бесконечно увеличивать штат пользовательской поддержки, что, безусловно, производителю делать не хочется, и он предпримет все, чтобы максимально снизить рост стоимости поддержки с увеличением объема продаж.
Перейдем в плоскость продуктов безопасности, а точнее, - систем обнаружения. С точки зрения производителя Продукта, решение которое генерит множество ложных срабатываний - плохое, так как каждое ложное срабатывание - потенциальное обращение в поддержку продукта. "Потенциальное" здесь означает, что не каждое ложное срабатывание решается исправлением логики обнаружения, какие-то - контекстные - решаются кастомными фильтрами и тонкой настройкой, насколько это возможно, так как давать широкие возможности по кастомизации - тоже не совсем в интересах Производителя, ибо сложное решение, опять же, дорого и в поддержке. А стоимость поддержки, как отмечено выше, надо минимизировать. Это означает, что в Продукте детектирующая логика будет максимально точной, генерящей минимально возможное количество ложных срабатываний (ситуация может быть даже немного хуже: сложную телеметрию, которую сложно понять, для работы с которой нужна высокая квалификация, и, следовательно, которая будет причиной множества обращений в продуктовую поддержку - тоже вопрос, стоит ли показывать, поскольку словосочетание "низкая стоимость поддержки" относится и к стоимости персонала, работающего с продуктом).
На первый взгляд может показаться, что это - хорошо. Но это не совсем так. С позиции здравого смысла, великой науки, а также подтверждено практикой, что чем более скрытые (сложные, целевые) атаки хочется обнаруживать, тем более чувствителен должен быть наш детект, тем к большему количеству обрабатываемых ложных срабатываний надо готовиться. Из этого несложно заключить, что чем более "экзектовая" (точная) логика используется, тем меньше шансов ее эффективно использовать против сложных атак, как минимум, потому что обход точных детектов, зачастую, тривиален. На этот счет есть богатый личный опыт: во время подготовки к OSCP я успел стать фанатом HTB, и заметил, что часто в машинках средней сложности и выше приходится обходить какие-либо превентивные (хороший пример системы экзектовых детектов, так как любой prevention не допускает ложных срабатываний, поскольку вынос легитимного приложения представляет собой значительно больший риск, чем пропуск ВПО, аналогично можно сказать про блокировку трафика) системы безопасности: WAF или примитивные HIPS, на Windows - практически всегда надо победить Windows Defender. Плотно общаясь с коллегами-пентестерами из смежного подразделения, могу с уверенностью сказать, что мне до них в части offensive примерно также как до Блэкмора по игре на гитаре, но даже мне не составляет труда забайпассить Defender, а что уж там говорить о реальных профи. В общем, человек всегда сможет победить автомат, как бы ни был продвинут последний, вопрос в профессионализме человека, времени и предварительной осведомленности\подготовке. А сложные атаки всегда делаются профессионалами и хорошо готовятся.
Но вернемся к обсуждаемой теме. Получается борьба противоположностей: с одной стороны, чтобы результативно находить сложные атаки, нужно системы обнаружения делать более чувствительными и быть готовыми к множеству ложных срабатываний - (1). А с другой стороны, много ложных срабатываний и сложность потенциально увеличивают стоимость использования продукта конечным потребителем и одновременно - повышает стоимость вендорского сопровождения, так как каждая фолса - потенциальная эскалация производителю (2). (1) - это про качество детекта, (2) - это про деньги.  Из (1) и (2) совсем несложно догадаться, что продукт всегда будет стремиться к максимальной точности детектов, так это соответствует минимальной стоимости сопровождения и для пользователя и для производителя.
Подсвеченная проблема в значительной степени решена в случае Сервиса. Сервис, безусловно стремится к минимизации костов (2), но и, вместе с тем, является конечной точкой ответственности за качество обнаружения (1). "Конечной" означает, что дальше эскалировать некуда: если Продукт пропустил APT - тому может быть масса объяснений - он неправильно настроен, его операторы недостаточно профессиональны, или, в конце концов, продукт реализует баланс между (1) и (2) в пользу (2); в случае Сервиса приведенные аргументы едва ли могут служить объяснениями: конфигурация инструментария и профессионализм команды - в руках поставщика услуги, а вариант баланса в пользу (2) означает "мы на вас экономим" - звучит смешно.
Написал достаточно много, но тому есть небольшое оправдание - хотелось наглядно донести позицию, поэтому соберу мысли в простые пункты:
1. Если есть желание обнаруживать сложные атаки, надо готовиться к ложным срабатываниям.
2. Ложные срабатывания - это косты сопровождения, которые никому (ни производителю, ни потребителю) не нужны и их всячески будут снижать.
3. В общем случае, человек всегда найдет способ обойти полностью автоматическое обнаружение.
4. Сервис всегда будет показывать более высокое качество обнаружения в сравнении с любым автоматическим продуктом.