Технологии и оснащение SOC после 24-го февраля 2022 года

1. Инцидентов больше не стало, хотя число событий безопасности возросло, а по ряду направлений возросло на порядки. Например, число DDoS-атак выросло в сотни раз, а число атак на Web-приложения — в десятки. Это признают все участники. А вот по фишингу мнения разделились — у кого-то его почти нет с начала кибервойны, у кого-то (Касперский) его стало больше. При этом, несмотря на отсутствие роста числа инцидентов, возросла нагрузка на первую линию SOC, причиной чего является рост бдительности заказчиков и их желание разобраться, а что, как и почему происходит у них в инфраструктуре (опять же, надо учитывать, что многие высказывания и тезисы исходят от представителей аутсорсинговых SOCов).
2. Закупки IRP/SOAR многие заказчики отложили до конца года, а пока все бюджеты спускают на средства/сервисы борьбы с DDoS и на WAF. Тему IRP/SOAR/TIP на эфире про технологии для SOC вообще не поднимали, что немного было странно с одной стороны, но объяснимо с другой — абсолютное большинство участников эфира представляли аутсорсинговые SOCи (BI.ZONE, Касперский, Солар, Информзащита, УЦСБ, Джет и Позитив). Прозвучала мысль, что заказчики в последнее время вообще мало интересуются внутренней кухней SOCа, а хотят просто получить сервис и все. С другой стороны, любые бюллетени и указивки регуляторов приводят к росту вопросов от заказчиков, которые хотят понять, а будут ли они учтены в деятельности SOC.
3. Тема саботажа со стороны сотрудников, кооптируемых для участия в атаках на ресурсы российских компаний, была упомянута вскользь. Кто-то вообще считает, что такой проблемы для SOC не существует, так как техники и тактики инсайдеры используют те же, что и внешние хакеры. Я с этим и согласен и нет. То есть если мы рассматриваем ситуацию, когда сотрудник запускает в отдельной вкладке браузера DDoS или устанавливает вредоносный софт внутри инфраструктуры, то да, особенностей нет. Но есть пробивы конфиденциальной информации в рамках легальных полномочий сотрудников и никакие типичные TTP тут не помогают, так как сотрудник не делает ничего вне рамок своих полномочий. Так что инсайдер для SOC — это все-таки особый use case и его надо рассматривать.
4. А вот тему закладок в open source рассмотрели более детально. Правда, если брать историю с закладками в npm-модулях и иже с ними, то тут кроме SAST никто ничего не предложил (а они плохо с этой угрозой борятся), а вот использование вредоносных обновлений open source в самописном SOC обсудили поглубже. BI.ZONE, например, минимизирует использование удаленных библиотек и модулей с публичных репозиториев, стараясь использовать код, предварительной загружаемый в локальных репозитории, рассматриваемые как прокси.
5. С точки зрения источников телеметрии основными сейчас являются, помимо WAF и antiDDoS, EDR, сканеры безопасности и сетевые решения.
6. Санкции и приостановление деятельности зарубежных компаний в России и с отечественными компаниями привели к тому, что отвалилось около 10-15% источников Threat Intelligence, но некоторые участники эфира считают, что это не так уж и критично, так как они пользовались преимущественно российскими источниками (лично для меня это выглядит немного странно, либо было в словах некоторое лукавство). А вот отключение от VirusTotal — боль для многих. Правда, никто так и не ответил, используют ли они в своей деятельности «русский VT» — национальный мультисканер, разработанный по заказу ФСБ.
7. Переходить на отечественные SIEM никто не спешит. По оценкам Информзащиты это займет от года до полутора. Джет заявил, что они могут это сделать за месяц по требованию заказчика, но у многих на лицах были сомнения в озвученном сроке. Вообще, у меня сложилось впечатление, что никто не хочет особо обсуждать тему миграции с иностранцев на российское в своих SOCах. Про запросы от клиентов на миграцию говорят все (75/25 желающих/нет), а вот про то, что перейти надо и самим — никто. Оно и понятно — российские продукты пока уступают иностранным коллегам в вопросах масштабирования, функциональности, надежности, удобства и т.п. BI.ZONE пишет вообще свой технологический стек для SOCа и SIEM был последним решением, которое было зарубежное. Пока и остается, но постепенно переходят на свое и тут. Солар использует два решения — ArcSight и PT SIEM. Касперский по прошлым эфирам говорил, что они пока не перешли на свою KUMA в SOC, но стремятся к этому. При это никто не хочет становиться заложником вендоров технологий для SOC, даже если это вендора российские. И это при том, что по требованиям лицензии ФСТЭК на мониторинг, к SIEM (да и к другим решениям) предъявляются определенные требования, но мало кто их соблюдает или строит потемкинские деревни для проверяющих. Информзащита покритиковала российских вендоров SIEM и иных технологий для SOC, так как те не особо спешат выходить с какими-то интересными и выгодными предложениями (а зачем, и так купят).
8. Проблема перехода на отечественные инструменты SOC заключается не в бюджете, а в переносе контента обнаружения, который обычно является уникальным под конкретное решение и по щелчку не переносится, конвертеров особо нет. Солар говорил, что они контент пишут сразу для двух систем и по требованию заказчика могут легко перейти с одного SIEM на другой, что, на мой взгляд, означает, что основное решение у них все-таки не отечественное. Это же подтверждает и упомянутое число интеграций, которые они предполагают сделать для перехода на отечественный SIEM. Перенос контента из одной SIEM/SOAR/IRP в другую — это ручной труд, которым занимается специальная инженерная команда, которая есть далеко не во всех SOCах по моему опыту. Но проблема с миграцией еще и в том, что нужно переносить различные кастомизированные доработки и фильтры, а они могли быть заточены под конкретное решение и в принципе непереносимы на другую платформу. Да, доработки отечественные вендора по требования заказчиков делают, но это не так быстро, как хотелось бы.
9. Еще одна проблема — железо под работу SOC; особенно SIEM и хранилки событий и инцидентов. Сейчас с этим бооольшие проблемы. Поэтому возникли пожелания к отечественным вендорам подумать в сторону SaaS-модели для своих решений, а также рекомендация снижать объемы и число регистрируемых событий за счет использования брокеров, нормализации и правильной фильтрации телеметрии. Но у многих отечественных решений для SOC проблема не только с SaaS, но и вообще с поддержкой MSSP-модели, когда надо работать в среде multi-tenant, а также простраивать иерархию первичных и вторичных узлов сбора и обработки данных, позволяющих работать с данными сразу на двух площадках — у заказчика и у провайдера SOC-услуг (MSS или MDR).
10. Российским решениям по ИБ, выступающих в качестве источников событий для SOC, не хватает расширенной телеметрии и нормальных API. Да и вообще, российский рынок больше заточен под требования регуляторов, которые, в свою очередь, заточены больше на предотвращение угроз, чем на обнаружение и реагирование. Тут еще есть куда расти разработчикам — у нас вообще не хватает решений класса EDR, NDR, CDR и тем более XDR. Продуктовые экосистемы развиваются (Позитив, Касперский, BI.ZONE), но пока не так активно, как хотелось бы. А за этим будущее, которое позволит снизить зависимость от SIEM/SOAR и ускорить реагирование, в том числе и автоматизированное, на инциденты ИБ.

Заметка Технологии и оснащение SOC после 24-го февраля 2022 года была впервые опубликована на Бизнес без опасности .