SOC –> SOC-MDR –> MDR

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

Я не буду заострять внимание на мелких неточностях, вроде того, что SOC занимается только мониторингом (хотя сам дальнейшее повествование построю именно в рамках этого сужения), а перейду к наиболее важным моментам.

В статье автор выделяет три вида SOC:

Создается впечатление, что в статье эти модели разделяются – это некорректно, а поскольку момент принципиальный о нем и поговорим в этой заметкестатье.

Ни для кого не секрет, что безопасность всегда немного позади: сначала придумали холодное оружие, потом – рыцарские доспехи, луки – щиты, огнестрельное оружие – бронежилеты и танки; перехват и подмена сообщений – шифрование трафика и взаимная аутентификация отправителей и получателей, вредоносное ПО – антивирусы, целевые атаки – новые подходы к обнаружению. Причем эти новые подходы, как правило, более комплексные, чем предыдущие, как танк столь же эффективен и против легкого огнестрельного оружия, и против более архаичных – конных лучников или Македонской фаланги, так и реальная NG-защита – это не то, что защищает только от NG-угроз и пропускает неNG-угрозы, но и защищает и  от “классических” атак и NG тоже . 

Мы все много делали усилий по цифровизации, элекронизации, диджитализации и т.п. и в итоге перенесли большую часть бизнесовых рисков в область ИТ, что позволяет воровать деньги и останавливать предприятия не вставая с места, двигая только пальцами. Производители ИТ тоже проделали огромную работу. и безопасность систем за последние годы радикально выросла – это хорошо. Но, беря во внимание первое предложение этого абзаца, – мотивация атакующих ничуть не ослабла, поэтому в итоге мы получили повышение сложностистоимости атаки – атаки стали целевыми. Получив трансформацию ландшафта угроз, мы вынуждены трансформировать подходы к обеспечению безопасности в наиболее общем смысле этого слова – изменить технологии, изменить процессы, изменить понимание и сознание, ломать стереотипы. При этом, конечно же не надо думать, что раз сейчас все атаки – целевые, и нам нужны только next-gen-ы, а “простых” атак и “вирусов” нет. Конечно же это не так, – атакующий всегда пойдет по наиболее дешевому пути, и, если инфраструктура может быть поломана элементарным способом, он и будет им использоваться, а высокоразвитвый  зрелый клиент будет скомпрометирован высокотехнологичной продвинутой атакой .

Но вернемся к обсуждаемой статье на Anti-Malware. Приведенные выше модели – это одни и те же подразделения операционной безопасности, но на разных этапах зрелости. Классический SOC, разгребающий события неправильной аутентификации, алерты сетевых систем обнаружения вторжений – то, что было раньше, и сейчас, очевидно, этого недостаточно, чтобы обнаруживать современные техники проведения атак. Если мы говорим о целевых атаках, когда и применяемые атакующими  техники  и, тем более инструменты, никогда ранее не были известны производителям используемых систем обнаружения, то здесь нужны возможности по проведению исследований. И эту проблему решает, пользуясь терминологией статьи, как раз модель MDR. С точки зрения сервиса SOC Обнаружение атак – MDR на текущий момент времени наивысшая ступень зрелости, так как его подходы являются наиболее комплексными для противодействия современным атакам, при этом, безусловно, не игнорируя “классические”, так как, как отмечено выше, продвинутый атакующий будет использовать те подходы, которые будут давать результат и при этом являться наиболее дешевыми. Два понятия “Обнаружение атак” и “Исследования” я выделил курсивом потому что их надо пояснить.

Обнаружение и расследование атак – основной сервис операционной безопасности, поскольку его цель совпадает с целью всего направления операционной безопасности (вынесем за скобки вопросы администрирования систем безопасности, выполняющих предотвращение возможных атак, снижающих их поверхность, к тому же, нередко это выполняется подразделениями ИТ). В этом несложно убедиться, если проанализировать другие сервисы SOC:

• Инвентаризация активов – для понимания, что может быть атаковано
• Управление уязвимостями – для понимания есть ли явные возможности для атаки
• Анализ угроз – для понимания, откуда может прийти атака
• Повышение осведомленности – то же, что и управление уязвимостями, так как латать дырки нужно не только в железе и софте, но и в сознании пользователей
• Управление инцидентами – операционная поддержка процесса обнаружения атак
• Реагирование на инциденты – часть Управления инцидентами
• Анализ результатов и совершенствование – часть Управления инцидентами
• …

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

Про исследования я много где говорил, еще даже  до того, как стал работать в компании , в которой бОльшая часть сотрудников занимается исключительно исследованиями. По-моему очевидно, что если мы претендуем на способность обнаружения уникальных атак, мы обязаны иметь зрелую практику проведения уникальных исследований. Потому что Threat hunting – это не что иное как перенос этой практики уникальных исследований в инфраструктура заказчика. Прошло то время, когда любую атаку можно заблаговременно найти в Интернете, выпустить детект и защитить клиентов. Целевую атаку можно найти только в целевой инфраструктуре, а значит те же подходы, применяемые при поиске в Интернете надо повторить в кастомизированном клиентском окружении. Собственные исследования – ключевой момент, дающий возможность заниматься Threat hunting-ом. Все очень просто: если поставщик за всю свою историю не выявил не одной АРТ, на чем основано утверждение, что он обнаружит целевую атаку в инфраструктуре заказчика? Наличие  собственной зрелой практики глубоких исследований  – наиболее объективное подтверждение компетентности в выполнении активного поиска угроз (Threat hunting). Кроме того, надо понимать, что любая АРТ с момента выявления становится операционной историей, требующей постоянного отслеживания – за АРТ стоят конкретные группы людей, которые изобретают новые техники, инструменты, у них меняется сфера интересов, мотивация … жизнь кипит… – эти изменения должны своевременно отслеживаться и должным образом адресовываться технологически-продуктово и организационно-сервисно. Поэтому упомянутые здесь исследования целевых атак должны быть не ad-hoc – что-то нашел, сделал публичный отчет, получил свой квант славы и забыл, а систематические – постоянное отслеживание известных группировок и их деятельности. Отсюда следует вторая важная характеристика способностей по Threat hunting-у – количество отслеживаемых АРТ-кампаний в настоящее время. 

Поговорим об инструментарии. Исследования атак – основа для придумывания логики обнаружения атак, гипотез (если быть точным, то Исследования – один из источников  TI, а уже TI  – основа для построения гипотез и детектов, это важно, будет время, сделаю про это отдельны пост, но для этой статьи не принципиально). На базе знаний об угрозах мы придумываем как обнаружить и обезвредить. Для этого нам, если сильно упрощенно, нужны: сенсоры (поставщики событий) и инфраструктура, выполняющая обработку этих событий. Очень важно, и совсем несложно это понять, что номенклатура событий сенсора определяет возможности по детекту, которые в свою очередь полностью определяют можем мы обнаружить ту или иную угрозу или нет. Как я отметил ранее, Исследования – первичны, так как они дают полное представление об угрозах, а следовательно исследования определяют требуемую номенклатуру событий – их типы, поля для каждого типа, интенсивность, методы сбора и т.п. Нам не выгодно собирать больше, поскольку это сопряжено с необоснованными инфраструктурными затратами, но нельзя и меньше, так как это не позволит выполнять детектирование эффективно или вообще что-либо обнаруживать. Поскольку атаки мутируют, это требует изменений в номенклатуре событий, поэтому чтобы оперативно и эффективно адресовать самые современные атаки, нужно уметь оперативно вносить изменения в сенсоры. Аналогичная ситуация с инфраструктурой обработки событий сенсоров. Принципиальный момент, который надо вынести: Исследования определяют какие сенсоры нам нужны, какие события с какими полями они должны генерить, какая обработка для этих событий требуется, и как ее оптимально перераспределить между самим сенсором, облаком и аналитиком. В итоге получается многоэтапный  эшелонированный подход . Теперь, я думаю, понятно почему MDR обычно стремится использовать собственные инструментальные средства. Использование других конечно же возможно, но это может иметь негативные последствия на качество сервиса.  Принцип Алана Кэя , который лично я услышал от не менее выдающегося Стива Джобса, работает и здесь:  если вы хотите искать уникальные атаки (== делать Threat hunting), вам нужны собственные уникальные исследования, которые вы трансформируете в уникальные инструменты, которые в сочетании с квалифицированной командой позволят вам это делать эффективно и результативно. Из сборной солянки, когда исследования от одних поставщиков, тулсет – от других, команда – от третьих тоже можно составить предложение MDR, но оно, по моему мнению. не сможет работать столь же эффективно, как от провайдера с собственными исследованиями, инструментарием и экспертизой.

Выше я выделил курсивом “команда”, поговорим немного об этом тоже. Для иллюстрации приведу свое мнение о минимальном количестве людей в SOC-е, без учета объема, чтобы только закрыть функционал обнаружения и расследования атак. 

Из картинки важно запомнить очень простую вещь: любой функционально полный MDR должен иметь минимум 14 выделенных сотрудников, не беря во внимание внешние по отношению к SOC подразделения разработки и исследований – программистов сенсорных и инфраструктурных компонентов, исследователей угроз и целевых атак, администраторов и автоматизаторов инфраструктур исследователей угроз и пр.

Но вернемся к первоначально обсуждаемому исследованию и коснемся модели SOC-MDR.
Внимательный читатель уже догадался (я не напрасно набил много букв, пытаясь пояснить в общем-то непростые вещи максимально просто с бытовыми аналогиями), но я все-таки напишу это: SOC-MDR – это SOC, который уже поднялся на более высокую модель зрелости, по сравнению с “классическим SOC”, но еще не достиг уровня модели MDR. Проще говоря – это переходный этап между SOC и MDR. Они по-прежнему работают в режиме классического SOC, собирая все подряд логи и реагируя на все возможные алерты, но уже пытаются находить продвинутые атаки с помощью доступного на рынке и  в Интернете инструментария , на базе  публичных исследований  и методологических  фреймворков . Расширив свой исследовательский потенциал, обязательный для Threat hunting-а, и выбрав эффективный инструментарий (в общем-то не обязательно свой, –  Android-телефоном, в общем-то, тоже можно пользоваться, как и Apple  🙂 ), SOC-MDR рано или поздно поднимется на следующую ступень модели зрелости и станет MDR в части сервиса Обнаружения атак, собственно, для чего и делается процесс Мониторнг. 

В завершении хочу отметить важность ограничения скоупа работ подразделения операционной безопасности в объеме данной статьи – мониторингом, обнаружением и расследованием атак, потому что  SOC  – это не только про мониторинг, и поэтому MDR не покроет всех задач SOC, как, например, согласование и контроль доступа, анализ проектной документации на предмет реализации требований безопасности при проектировании ИТ-систем, или поиск мошеннических операций по логам системы автоматизации розничной торговли…, но задача эффективного обнаружения инфраструктурных атак любой сложности – прямая цель MDR – решается им в полном соответствии с современным ландшафтом угроз.