SOC for beginners. 3 мифа об автоматизации и искусственном интеллекте в Security Operation Center
В последнее время (и тематический SOC-форум не стал исключением) все чаще можно слышать заявления, что люди в процессах SOC вторичны и технологии в состоянии заменить большинство из них — «Смерть Tier-1 аналитиков», «Искусственный интеллект, победивший самого умного пианиста/филолога/кандидата естественных наук», «Автоматические обучаемые правила» и вот это все. Наш же опыт подсказывает, что до власти SkyNet еще далеко, и недооценивать роль человека даже в базовых процессах SOC пока не стоит.
Сегодня хотелось бы разобраться, где правда, а где неистовый маркетинг, и заодно развенчать несколько мифов о возможностях искусственного интеллекта. Интересующиеся и желающие подискутировать — добро пожаловать под кат.
«Хакеры не будут атаковать просто!»
Миф 1: «Разбор базовых инцидентов — это прошлый век, нужно контролировать исключительно сложные атаки. Только Kill Chain, только хардкор!»
Существует мнение, что один из самых простых способов снизить нагрузку на SOC и «нацелить» его действия — перестать заниматься базовыми или «атомарными» инцидентами ИБ, а пытаться контролировать только сложные цепочки, развивающиеся атаки или, как сейчас очень модно говорить, Kill Chain. «Никому не интересно разовое вирусное заражение или одна попытка эксплуатации уязвимости на сервере на периметре, таких инцидентов сотни, и ими заниматься не обязательно», — периодически слышим мы от сообщества. И, казалось бы, вот он профит: меньше инцидентов, ниже нагрузка на специалистов SOC, можно набирать меньше людей и свести к минимуму рутинный operations.
Однако о некоторых фактах при этом почему-то забывают:
1. На сегодняшний день любой способ обнаружения Kill Chain низкоэффективен, и злоумышленник может его обойти.
На каждом из этапов реализации атаки у злоумышленника есть десятки и сотни возможностей для дальнейшего развития и закрепления в инфраструктуре: сканирование сети в поисках новой точки, повышение привилегий на хосте, получение паролей программными способами или с помощью анализа конфигурационных файлов, использование специализированного вредоносного ПО, в том числе скрывающего свое поведение от средств защиты и журналирования.
Позиция атакующего всегда предпочтительнее: он может заранее продумать атаку и просчитать шаги. Позиция обороняющегося заведомо более слабая. В таких условиях игнорировать одну ошибку злоумышленника, позволившую нам увидеть инцидент, значит недооценивать противника и предоставлять ему возможность развить свою атаку и выиграть.
2. Любая незаблокированная и нерасследованная атака таит в себе угрозу.
Если в нашей сети есть зараженный компьютер, можем ли мы считать ее безопасной? И более того: каковы гарантии того, что мы увидим следующий шаг злоумышленника, захватившего машину, что функционал вируса не позволит модифицировать или изменить настройки журналирования хоста, или что антивирусное ПО не будет удалено и заменено «муляжом» для связи с центром управления?
Аналогично — если мы видим попытку эксплуатации сигнатуры на уязвимом к ней сервере, то без анализа внутренних журналов и поиска следов дальнейших действий злоумышленника мы никогда не будем уверены в том, что наш периметр еще не взломан.
3. Только в мире «сферического коня в вакууме» SOC в состоянии контролировать любую активность и событие в сети.
Наверное, каждый безопасник хотя бы раз в жизни хотел купить себе SIEM/Sandbox/EDR на всю компанию, чтобы видеть и анализировать каждое событие, чувствуя себя не то горным орлом, не то всемогущим Сауроном. Но такие желания разбиваются об очень понятные земные материи: бюджетов не хватает на подключение к мониторингу всей инфраструктуры, ИТ-служба сопротивляется применению политик безопасности в продуктивных сегментах, платформа не может «переварить» такое количество событий и так далее.
В итоге работа SOC больше похожа не на единую паутину, покрывающую каждый сегмент сети в полном объеме, а на систему мин-ловушек, расставленных в ключевых местах. При этом SOC широковещательно фиксирует «аномалии» и странности во всех остальных сегментах.
При таких ограничениях стоит очень внимательно изучать фактическую область работы магического Kill Chain: может оказаться, что даже если злоумышленник успешно реализует «убийственную цепочку», нужной ему информации/системы в зоне контроля просто не окажется, и «уличная магия» не сработает по вполне объективным причинам.
В итоге при всей пользе от выявления цепочки атак и работы со связанными инцидентами ключевым вопросом безопасности по-прежнему является обеспечение целевой гигиены среды и инфраструктуры.
Мы считаем, что необходимо учиться работать с каждым алертом отдельно. Только после того, как аналитик понимает, как вручную разобрать каждую конкретную активность, можно пытаться накладывать на алерты схемы киллчейнов и собирать атомарные инциденты воедино. В этом случае они могут быть полезны в качестве дополнительных триггеров или фильтров.
Несмотря на то, что такой подход существенно увеличивает нагрузку на операторов и инженеров SOC, в ином случае рассчитывать на эффективное противодействие любым, в том числе комплексным атакам достаточно сложно.
Скажи мне, что за хост, и я скажу, как быть
Миф 2: «Экспертная система автоматически обогащается информацией о хосте, окружении и всеми прочими данными, требуемыми для принятия решения и фильтрации false positive».
Сейчас огромное количество вендоров, говоря о магии автоматизации, которая достигается с помощью их продуктов и технологий автоматического сбора информации по хосту, оперируют терминами Asset Management, Inventory и так далее. Давайте посмотрим на информацию, которую они собирают, и подумаем вместе, достаточно ли ее для корректного разбора инцидентов.
- Системы инвентаризации/сканирования на уязвимости и пр. собирают сумасшедший объем технической информации по хосту:
- Характеристики hardware (процессоры, память, диски и т.д.).
- Информацию по ОС и всех установленных патчах (и если повезет, даже с актуальными для них уязвимостями).
- Список установленного ПО с версионностью.
- Список процессов, запущенных на момент сканирования.
- Уйму дополнительной информации (MD5-библиотек и т.д.).
- Если на эту картину наложить системы анализа конфигурации и/или мониторинга сетевого оборудования, это приводит к уже, казалось бы, цельной и универсальной картине:
- Мы понимаем, из каких сегментов хост доступен.
- Мы понимаем границу его уязвимости и возможности злоумышленников по его взлому.
Таким образом мы видим, откуда может и откуда не может быть реализована атака на конкретную машину. Является ли это подспорьем? Безусловно.
Но чего нам по-прежнему явственно не хватает, так это информации о том, что вообще этот хост значит в нашей компании с точки зрения информационной безопасности. Стоит ли переживать от попытки брутфорса этой машины, может или не может на нем быть запущен Remote Admin Tool, и в каком темпе нам надо «бежать», если на этом хосте возникает проблема.
Часть этих данных может быть почерпнута из CMDB (если она есть), выгрузки из платформы виртуализации (самое важное обычно в комментариях), но ключевую информацию — что это за машина, и что она значит для ИБ — узнать неоткуда, пока мы не разберемся с этим активом, пообщавшись с его владельцем и безопасником компании.
Сравним два события:
«Запущен RAT утилита AmmyAdmin на хосте 172.16.13.2, расположенном в Московском центральном офисе, финансовый департамент»
и
«Запущен RAT утилита AmmyAdmin на хосте 172.16.13.2, машина Иванова Петра Михайловича, заместитель начальника узла связи, функционал — обработка рейсов МЦИ и работа с АРМ КБР, запрещена удаленная работа администратора»
В своей практике мы используем несколько метрик по оценке «ИБ-значимости» хоста: возможность его использования для монетизации атаки (майнинг биткойнов не в счет, речь о компрометации платежей:)), критичность его информации для изменения/компрометации и еще несколько других. На выходе это приводит нас к интегральной взвешенной оценке критичности хоста в зависимости от типа атаки. И эта же оценка определяет «темпы бега» в каждой конкретной ситуации и для каждого конкретного инцидента. Но путь к этому знанию лежит через подробный аудит и инфраструктуры, и организационно-штатной структуры.
«Автоматизируем нарушение бизнес-процессов»
Миф 3: «Автоматизированный Incident Response не только детектирует выявленную аномалию и инцидент, но и автоматически отдает сигнал средствам защиты ее заблокировать, поэтому никакой круглосуточный контроль за системой не нужен».
И еще один подход к «уличной» магии, с которым часто приходится сталкиваться в сообществе — возможность автоматического блокирования/применения политик на средствах защиты в блокирующем режиме. Подход сам по себе не новый, и безопасники старой формации могут помнить первые шаги в этом направлении — наверняка многие пытались автоматически включать новые выходящие сигнатуры на IPS, причем сразу в блокирующем режиме.
Даже если оставить за скобками сложность принятия итогового решения без контекста, недоступного автоматизированной системе, остается очень высокий риск ошибки автоматики или вендора, которая может очень негативно повлиять не только на конкретную систему, а на все средства защиты или даже бизнес-процессы.
Приведем несколько примеров из практики:
- Sandbox, автоматически интегрированный с антивирусом, с возможностью создания кастомных политик блокирования. В какой-то момент отдел разработки решает протестировать trial-версию утилиты для объединения и анализа xml-файлов, позволяющей оптимизировать работу с конфигурациями софта. В процессе очередной (не первой) загрузки sandbox решил, что утилита ведет себя подозрительно и должна быть классифицирована как троян. Через пятнадцать минут автоматизированного response разработка лишилась установленной у себя утилиты.
- При работе с threat intelligence некоторые компании настраивают автоматическое добавление индикаторов (домены, IP-адреса, DNS) в черные списки своих активных средств защиты. И вот в один прекрасный день в TI прилетел очередной адрес, который тут же попал в черные списки. Все бы ничего, но это был адрес одного из больших международных хостингов, и за этим IP жило около 300 сайтов, включая брокерские ресурсы, необходимые для работы компании.
- Ну, и в качестве финального примера: система анализа кода, интегрированная с активными средствами защиты по технологии virtual patching, увидела непонятную и потенциально уязвимую форму на новой версии e-commerce-платформы. И во избежание проблем закрыла виртуальным патчем доступ к тому, что было новым функционалом, ради которого, собственно, новая версия и выводилась в продуктив.
Думаю, что десяток-другой аналогичных историй найдется у каждого безопасника.
Отсюда следует очень значимый, на наш взгляд, принцип: ИБ не должна влиять на бизнес-процессы и мешать развитию бизнеса. А уж тем более не должна делать это спонтанно и непрогнозируемо для окружающих и в особенности для себя. Поэтому подход к задачам автоматического реагирования возможен только на очень узкой области кейсов и задач и не может заменить собственный центр компетенций или избавить от необходимости быстрого ручного реагирования на инциденты силами службы ИБ (спать с каждым годом нам все равно приходится все меньше).
На этом авторы статей «SOC for…» желают вам, чтобы год Желтой Земляной Собаки был удачным, а киберпространство — спокойным.
Расскажите, верите ли вы в эти тезисы или, если хотите обсудить тему и поспорить с нашими доводами, пишите в комменты:
