Каждый видит мир по-своему
Многие
Из сравнения несравнимого можно делать какие угодно выводы
Личное наблюдение
Как-то в небольшой заметке я обещал поподробнее разобрать тему влияния особенностей MSSP на обнаруживаемые им инциденты, думаю, пришло время. Постараюсь в этой статье вылить весь поток сознания, который накопился за время изучения как собственной аналитики, так и отчетов коллег по цеху: что надо иметь в виду при чтении аналитических отчетов, на что следует обратить внимание и, вообще, можно ли как-то интерпретировать написанное, можно ли на основании публикуемой статистики инцидентов сделать объективное предположение о ландшафте угроз.
Первое, и самое простое: аналитический отчет - это отражение работы MSSP, его функциональных возможностей. Мне всегда интересно что умеют конкуренты, поэтому на косвенные или прямые подтверждения функционала предложения самого MSSP я обращаю внимание в первую очередь, а уже во вторую - на наблюдаемый им ладшафт угроз. Вообще, понимание функциональных возможностей, банально, какие типы инцидентов технически может обнаруживать MSSP, полностью определяют тот ландшафт угроз, который анонсирует в своем аналитическом отчете MSSP. Т.е., простой пример, если подавляющее большинство фиксируемых инцидентов MSSP брутфорс, из отчета такого поставщика будет следовать, что эта T1110 - определяющая среди угроз. Читая отчет, важно постоянно помнить, что данные в отчете - не отражение реальной картины, а отражение того, как это видит провайдер, его возможностей по обнаружению. По этому поводу не стоит сокрушаться, нас же не смущает что мы судим об окружающих нас вещах, наблюдая их в только видимом диапазоне света, который, ну, прямо скажем, весьма невелик, нужно просто это понимать. Поэтому, читая отчет, крайне важно понимать, как минимум: какие технологии используются для обнаружения - это нам позволит понять какие инциденты и каким образом может поставщик обнаружить, т.е. насколько широки его возможности по обнаружению, его видение.
В продолжение темы технологий, важно, чтобы используемый набор сенсоров, по количеству и типу, примерно повторялся по всей клиентской базе, т.е. чтобы уровень и качество мониторинга было сопоставимо по всем клиентам. Здесь тоже все просто: провайдер будет видеть разные инциденты у разных заказчиков, если у этих заказчиков он использует разный набор сенсоров, поэтому встречаемость одних инцидентов у одного заказчика и отсутствие у другого может быть следствием банальной разницы в возможностях по обнаружению со стороны MSSP, и не связано с особенностями ландшафта угроз для этих заказчиков. Важно и количество сенсоров: большее количество сенсоров создадут большее количество алертов, которые потенциально сконвертируются в большее количество инцидентов, к тому же, в случае пограничных ситуаций, аналитик предпочтет опубликовать инцидент заказчику, поскольку потенциальный ущерб от пропуска несравненно больше, чем ложноположительная публикация, здесь аналитику лучше перестраховаться.
В завершение темы сенсоров поговорим о минимальном наборе привентивных мер защиты. Очевидно, что случающиеся инциденты - отражение уровня безопасности инфраструктуры заказчика, и принципиальное значение имеют именно превентивные контроли ИБ, - упрощенно, ввиду их применения. какие-то типы инцидентов не могут произойти в принципе (на то и контроли привентивные). Со стороны MSSP на это сложно влиять, не всегда он может потребовать наличие каких-либо СЗИ от своих заказчиков, однако, превентивные СЗИ могут выступать поставщиками телеметрии для MSSP и тогда "заяц" требований к минимальной защите инфраструктуры, например, наличие EPP и\или NGFW, убивается автоматически.
Далее, если каких-то инцидентов\стран\индустрий нет в статистике поставщика, это не значит, что их не атакуют или там нет каких-то инцидентов, вполне возможно, что они - не клиенты\не обращались за сервисом. Верно и обратное - если большая часть клиентов, например, из Финансов, это не означает, что Финансы атакуют больше. Чтобы нивелировать это искажение видения поставщика, важно понимать распределение клиентской базы по индустриям, по странам: сколько, или какая доля клиентов приходится на какую отрасль или регион. Чем больше клиентов в какой-либо индустрии, тем больше там объектов мониторинга, тем больше там будет наблюдаться инцидентов. Поэтому важно смотреть не просто распределение инцидентов по отраслям\регионам, но в сравнении с распределением клиентской базы по тем же категориям.
Распределение заказчиков по индустриям\регионам - помогает, однако, клиенты бывают разные: с 1 000 эндпоинтов и со 100 000 эндпоинтов, и по количеству инцидентов они несравнимы. Чем больше размер сети, тем выше вероятность инцидента, и это подтверждается практикой. Тем более объем имеет значение, если сам эндпоинт является поставщиком телеметрии. Чтобы учесть объем мониторинга, можно показывать не абсолютное количество инцидентов в индустрии\регионе, а удельное - отношение количества инцидентов к количеству эндпоинтов. Удельное количество инцидентов позволит оценить частоту атак в выбранной группе (индустрии\сектору\региону). Правда, к сожалению, не удастся объяснить обусловлена ли эта частота атак в группе повышенным интересом атакующих или низким уровнем безопасности по сравнению с другими группами, но можно попробовать себя успокоить, что эту неопределенность можно не брать во внимание.
Итак, объем мониторинга - сколько у нас клиентов где, как они защищены и чем мы их мониторим - принципиален. Но не менее важен и уровень сервиса: по всей клиентской базе уровень сервиса должен быть одинаков, иначе, на основе регистрируемых инцидентов у разных заказчиков нельзя будет составить объективную картину о ландшафте угроз, так как предоставляемые сервисы определяют типы обнаруживаемых инцидентов, разделение ответственности между MSSP и командами заказчика, стадии килчейна когда подключается MSSP и многое другое. Т.е. если поставщик части клиентской базы оказывает MDR, части - DFIR, а кому-то SOC-as-a-Service, то обнаруживаемые типы инцидентов нельзя выдавать в виде единой аналитики по всей клиентской базе, она будет искажать фактический ландшафт угроз.
В эту же проблему уровня сервиса следует добавить и возможности по кастомизации: чем шире возможности по кастомизации, тем менее объективна общая статистика - в пределе, если для каждого заказчика предоставляется полностью кастомизированный набор услуг, то это явно отражается на выявленных инцидентах, и разные заказчики, ввиду использования разного набора сервисов, будут иметь разные инциденты, что будет отражать особенности их потребностей, а не реальный ландшафт угроз. Всё всегда определяют цели, поэтому если поставщик в интересах заказчика ищет инсайдеров, то среди найденных им инцидентов будет больше именно этого типа, а если MSSP ищет майнеры, то, нет сомнений, он их найдет в изобилии. "Просите, и дано будет вам; ищите, и найдете; стучите, и отворят вам; ибо всякий просящий получает, и ищущий находит, и стучащему отворят" (Евангелие от Матфея)
Если мы с вами пытаемся оценить ландшафт угроз на основе обнаруживаемых инцидентов, очень важно четкое формальное определение инцидента, причем, оно должно быть одинаковым по всему объему. Разное понимание инцидента у разных MSSP делает несопоставимыми их аналитики. Если у разных клиентов поставщика свое понимание того что считать инцидентом, а что нет, то аналитика по всему объему у такого поставщика неконсистентна: какой-то заказчик может считать инцидентом каждый алерт системы обнаружения, а кто-то только те случае, когда привлекалась команда DFIR. Если инциденты как-то классифицируются, например, по критичности, например, High, Medium, Low, то эта классификация также должна быть аналогичной по всему объему: критичный инцидент, инцидент уровня High, должен определяться одинаково во всех заказчиках по всему объему MSSP. Это требование сильно коррелирует с кастомизацией услуги, поскольку, как правило, кастомизация касается классификации инцидентов.
В целом, метод оценки ландшафта угроз на базе данных из Operations MSSP вполне рабочий, но для корректной интерпретации его результата нужно обладать дополнительной информацией об этом самом Operations, поскольку он вносит серьезные искажения. Тем более надо иметь в виду все здесь написанное, когда мы пытаемся сравнивать аналитику разных MSSP.
