Еще одно мероприятие по SOCам, которое прошло на первой неделе, было организовано компанией Picus Security. Оно называлось SOC ReLoad 2021 и состояло из множества интересных докладов, которые представлялись двумя спикерами — каким-либо известным в американской ИБ-тусовке экспертом (типа Дэвида Бьянко, автора пирамиды боли TI, Криса Клоули, автора первого курса SANS по SOC, Аугусто Барроса, бывшего аналитика Gartner, ДжейДжея Каммингса из Cisco Talos и т.п.) и сотрудником Picus, которые фокусировались на различных вопросах построения и эксплуатации центров мониторинга.
В отличие от SOC Forum 2021, на котором преимущественно делились своими успехами (без особых деталей), рассказывали об инцидентах, КИИ, экономике и т.п., то есть об обвязке вокруг SOC, на SOC ReLoad 2021 как раз фокусировались на различных процессах SOC — разработке контента, плейбуках, симуляции атакующих, применении ATT&CK в работе SOC и т.п.
Для начала хочу отметить, что на Западе сегодня наметился вполне себе серьезный и, видимо, долгоиграющий тренд в сторону перехода к облачным SOCам. Обратите внимание, в отчете SANS по тому, какая модель развертывания SOC будет использоваться респондентами в следующие 12 месяцев, рост почти 100%, в то время как по остальным ответам наоборот — идет везде спад (кроме ответа «Другое», возможно речь идет о SOCless модели, которую я упомянул вчера и которая также находит своих сторонников).
Летом компания Google, которая, кстати, тоже является сторонницей идеи облачных SOCов и даже лидирует в этом сегменте, выпустила большой материал про автономный SOC, который должен десятикратно улучшить показатели мониторинга и реагирования. Этот материал стал одним из многих в череде рассказов о перезагрузке центров мониторинга, которые должны быть «быстрее, выше, сильнее» и которые должны стать этаким SOCом следующего поколения. Не обошли вниманием эту тему и на SOC ReLoad, где упомянули несколько компонентов, за счет которых SOC может стать еще лучше!
Один из таких компонентов лег в основу большой дискуссии, растянувшейся на несколько выступлений, о том, как готовить контент обнаружения, как его выбирать, как приоритизировать и т.п. Один из очевидных вариантов, который упоминается достаточно часто всеми экспертами, — использовать матрицу MITRE ATT&CK, которая позволяет оперировать не высокоуровневыми угрозами, а вполне конкретными техниками и тактиками злоумышленников.
Но так как число TTP в матрице достаточно велико и продолжает увеличиваться, то надо как-то приоритизировать готовящийся контент обнаружения. Один из вариантов — проанализировать отчеты разных ИБ-компаний, которые в конце года публикуют Топ10 попавших в их поле зрения техник и тактик нарушителей, чтобы потом понять, что из этого может угрожать и вам. Логично предположить, что если с помощью той или иной TTP атакую других, то могут использовать и против вас. И хотя это правило не всегда верно, как точку отсчета использовать его можно и нужно.
Этот же подход позволяет вам разобраться с тем, достаточно ли у вас нужных источников телеметрии, которые позволяют выявлять определенные TTP (в описании почти каждой техники есть такая информация), какие технологии обнаружения вам нужны для идентификации этих TTP, какие технологии нейтрализации вам могут понадобиться для предотвращения или реагирования на выявленные TTP (раздел Mitigations в матрицу, а также проекты MITRE Shield и MITRE D3FEND), а также насколько имеющиеся у вас ресурсы позволяют все это пережевать.
Очень интересный доклад был по тому, как создавать контент для обнаружения и в очередной раз всплыла тема с подходом «Detection as Code», которая набирает популярность последнее время. Она позволяет не только более эффективно описывать контент обнаружения, используемый в различных инструментах (IDS, SIEM, NDR, EDR и т.п.), но и делиться им в рамках открытого или закрытого комьюнити. На одном из эфиров AM Live про коммерческие SOCи заходила речь про сложность переноса контента обнаружения между SIEMами или SOCами в случае перехода с одного решения/поставщика на другое(го). Так вот идея «Detection as Code» позволяет ее решить более эффективно.
Пример такой библиотеки контента обнаружения представил организатор SOC ReLoad — компания Picus. Правда, доступна эта библиотека только для ее клиентов, которые могут использовать совершенно различные инструменты для мониторинга (ArcSight, Splunk, QRadar и т.п.), но при этом иметь единый контент обнаружения. В России пока такое никто не предлагает — все являются заложниками конкретных решений по ИБ.
Не менее интересно было слушать про такой процесс, который нечасто встретишь в SOCах, как симуляция атакующих, которая используется обычно для организации Red Team, но ее можно неплохо приземлить и на улучшение процессов SOC, а именно выбор сценариев обнаружения, проверка покрытия источников телеметрии, проверку механизмов обнаружения и т.п. В отличие от Red Team, которые преимущественно базируются на творческом и не всегда автоматизированном подходе, симуляция атак — это имеющий вполне конкретный результат набор инструментов, которые облегчает и ускоряет процесс улучшения SOC, превращая его в центр мониторинга следующего поколения.
У той же Picus есть свой библиотека таких симуляций, которая также доступна только для клиентов. Такие проекты не новость. У MITRE есть пример такого плана для группировки APT3, а также open source инструмент CALDERA, который автоматизирует эту задачу. Также есть еще и ATT&CK-Tools для этой задачи; тоже open source.
Так что стоит подумать о том, чтобы внедрить такого рода инструменты и процессы в деятельность своего SOCа, делая его более эффективным.
Защитники должны быть правы каждый раз. Злоумышленнику достаточно оказаться правым только однажды.
На конференции была произнесена фраза, которая нам больше известна как «Злоумышленнику достаточно найти всего одно слабое место, в то время как защитникам надо выявить их все». И если вернуться к MITRE ATT&CK, а точнее к ее идее с процедурами, называемыми ФСТЭК сценариями реализации угрозы, то получается, что действительно при таком количестве возможных комбинаций техник, число возможных ветвлений графа атаки становится практически бесконечным (да-да, я учил комбинаторику в школе, но в данном случае теоретически возможное число комбинаций позволяет мне назвать граф атак бесконечным.
Но на конференции прозвучала и иная мысль, которая не всегда приходит в голову тем, кто пытается защититься от всех возможных атак и как можно раньше. Почему-то считается, что если я не смог заблокировать нарушителя на этапе проникновения (даже не рекогносцировки), то все, мы проиграли бой. Но ведь это не так. Наша задача всего лишь не допустить, чтобы злоумышленник смог реализовать, как минимум, последнюю тактику в процедуре, ради которой все и делалось (слить информацию, уничтожить данные, вывести из строя и т.п.). Об этом и было сказано на конференции.
Злоумышленник должен быть правым на протяжении всей своей атаки. Защитнику достаточно всего лишь однажды обнаружить любую из используемых техник.
Не обошлось на SOC ReLoad и без рассказа о сложностях и ошибках, с которыми сталкиваются строители и потребители SOCов. В одном из докладов даже использовали красивое (любят американцы все упрощать и использовать всяческие аббревиатуры) наименование модели — 4V, по первым буквам 4-х основных направлений, в которых совершаются ошибки — охват телеметрией (visibility), объем данных (volume), уверенность в точности сигналов тревоги (verify) и т.д.
Cisco Talos пошло еще дальше и привело интересную статистику по эффективности многих современных SOCов, которая коррелирует с тем, что я написал вчера об обнаружении центрами мониторинга всего 10% сигналов тревоги с помощью SIEM. Популярные подходы к построению технологического ядра SOC (SIEM в центре всего) сегодня дают сбои и приводят к пропускам атак.
Это и заставляет специалистов улучшать свои возможности по мониторингу и реагированию, чему и посвящены были два американских мероприятия по SOCам, прошедшие в начале декабря, — Security Operations Summit и SOC ReLoad. Об этом же говорили и на российском SOC Forum, о котором я еще напишу завтра, продолжая тетралогию о SOC-мероприятиях.
Все верно. Я не ошибся. Не трилогия, а тетралогия, так как мероприятий про SOCи было 4, а не 3.
И чтобы завершить эту заметку, приведу еще один слайд с трендами угроз (а куда без них на мероприятии по ИБ), проанализированными компанией DarkTrace, и которыми можно дополнить прогнозы, сделанные специалистами НКЦКИ и представленными на SOC Forum.
