И снова всем привет. Цикл «SOC for …» продолжает свое движение и развитие. Первый слой внутренней кухни центров мониторинга и реагирования на инциденты мы уже успели осветить в предыдущих статьях, поэтому попробуем понемногу пойти вглубь, к техническим подробностям и более тонким проблемам.
Мы уже несколько раз косвенно касались темы управления активами: и в статье про контроль защищенности, и в вопросах автоматизации и искусственного интеллекта в SOC. Очевидно, что без инвентаризации инфраструктуры заказчика центр мониторинга не сможет его защищать. При этом составить ее детальное описание отнюдь не тривиальная задача. И главное — через пару месяцев оно снова не актуально: одни хосты исчезли, другие появились, возникли новые сервисы или системы. Но защита инфраструктуры — процесс непрерывный, и SOC не может притормозить свою деятельность до получения актуальной информации об активах заказчика. Напомню, качество работы Solar JSOC регулируется не абстрактными обещаниями, а вполне конкретным SLA, за нарушением которого следуют различные небесные кары. Как выкрутиться в такой ситуации и не потерять в качестве оказываемого сервиса?
![](https://habrastorage.org/r/w1560/webt/cq/ca/3m/cqca3m4hwgwyes5srqibczapd8k.png)
Предлагаем сейчас вернуться к этому вопросу через один из сравнительных примеров оповещения по инцидентам:
Казалось бы, разница между этими двумя уведомлениями в глубине анализа. В первом случае уведомление выглядит так, словно оно было получено автоматически от SIEM-платформы, а во втором видна работа оператора и обогащение инцидентов. Это и так, и не так. Для того чтобы оператор мог провести анализ инцидента и сделать какие-то выводы, ему крайне важно понимать, что (или кто) именно скрывается за этими загадочными и почти одинаковыми IP-адресами у заказчиков, и использовать эту информацию в разборе инцидента.
Процентов 20% наших читателей сейчас скажут: «Ну, для этого же во всех компаниях внедрена система CMDB, чего проще, чем подключить данные из нее в SIEM? Даже коннектор писать не надо». Оставим на этом убеждении коллег из интеграторов и вендоров. Из нашей практики, как ни печально это осознавать, информацию из CMDB не стоит даже подключать или экспортировать в SIEM по причине ее полной неактуальности. Так что приходится засучить рукава и делать все своими руками. Давайте посмотрим на этот вопрос внимательнее и попробуем понять, как разобраться в недрах инфраструктуры,не привлекая внимания санитаров не надеясь на полную поддержку ИТ-подразделений.
Едим слона по частям или погружаемся в описание инфраструктуры
В своем движении к инвентаризации активов мы обычно пытаемся пройти четыре контрольные точки.
1. Построение верхнеуровневой, но подробной сетевой карты организации
Здесь первым и основным контактом выступают ИТ-подразделения заказчика (за исключением тех случаев, когда в компании корректно внедрена и настроена система управления сетевым оборудованием или firewall management, но это пока исключение). В ход идут и описательные части информации с сетевого оборудования, и схемы сети, и так далее.
Целевым результатом данного этапа является возможность разбить все внутренние адреса на сетевые зоны с идентификацией следующей информации:
Отсюда следует первый важный вывод: активы — это не только описание конкретных хостов с указанием подробной инвентаризационной информации о них, но и возможность описать сегменты сети и использовать эти данные в отчетах/корреляции/поиске по событиям.
Вот как это выглядит в SIEM:
![](https://habrastorage.org/r/w1560/webt/np/ld/si/npldsic5fbz-atbk75naqy_alvy.png)
2. Описание основных подсистем в ЦОД
Как правило, стартовая идентификация данных машин появляется по итогам первых бизнес-интервью. Общение с безопасностью, ИТ, сетевиками и прикладниками позволяет в первом приближении понять, как устроена инфраструктура компании и какие ресурсы/системы в ней являются самыми критичными. Собрать информацию об их адресации и сетевой принадлежности получается достаточно легко. Далее в режиме точечных вопросов уже можно получить требуемую информацию:
На этом этапе обычно помогают выгрузки из различных систем централизации:
Из этого следует второй важный вывод: нужно уметь «забирать» информацию об активах из абсолютно разных источников и добавлять эту информацию в SIEM в соответствии с настроенными сценариями и логикой мониторинга.
3. Описание критичных хостов и активов с точки зрения информационной безопасности
Когда заказчик обозначил свои «болевые точки» и наиболее критичные системы, мы вступаем в диалог с ответственными за них, чтобы разобраться, как эти системы связаны между собой, какие данные там хранятся и какие риски ИБ с ними связаны. Также мы оцениваем их по дополнительным параметрам, после чего присваиваем некоторым из систем коэффициенты, повышающие уровень критичности. Вот на что мы обращаем внимание:
Пример описаний:
![](https://habrastorage.org/r/w1560/webt/y5/cg/5h/y5cg5hmkxiovdy7tmq-p90kq2su.png)
Третий важный вывод: у SOC должна быть возможность добавлять свои описания назначения, функционала и критичности хоста под каждый актив и под каждую подсеть, заведенные в систему. Как говорится, «на вкус и цвет все фломастеры разные», и то, что хорошо в ИТ, не всегда нужно в ИБ.
4. Обогащение информации по хосту/активу
В финале мы пытаемся обогатить информацию по хосту/активу данными из систем ИБ-инвентаризации или сканеров защищенности:
Эта информация бывает крайне полезной для расследования, хотя, на наш взгляд, не является первичной при идентификации и оценке критичности самого инцидента, связанного с хостом.
Разбираемся в возникающих проблемах
Хотя даже на первый взгляд процесс описания инфраструктуры выглядит достаточно непростым, на деле это только те сложности, которые лежат на поверхности. Как всегда, внутри можно обнаружить некоторое количество подводныхграблей камней. Попробуем обсудить их и поделиться возможными путями решения.
Выбор уникального идентификатора актива
Казалось бы, вопрос банальный и очевидный. Выбирай что угодно: хоть IP-адрес (если несколько интерфейсов – назначь главный), хоть доменное имя, хоть серийный номер. Но в жизни все оказывается не так просто.
Любые hardware- или software-идентификаторы действительно очень хороши своей уникальностью и прямой связкой с устройством. Проблема одна – мы работаем с логами, и инциденты выявляем на основании логов, а в них этих уникальных идентификаторов просто нет. Поэтому у нас нет (почти) никакой возможности корректно связать происходящее в нашей сети с активом.
DNS-имя тоже хорошо с точки зрения его уникальности (оставим без внимания те компании, которые предпочитают его не использовать). Но проблема, к сожалению, совершенно аналогична – абсолютное большинство журналов не содержит об этом самом DNS-имени никакой информации. Поэтому сопоставление инцидента с активом также остается проблемой.
Казалось бы, вариантов у нас не осталось, придется работать с IP-адресом. Он появляется в абсолютном большинстве журналов, с которыми нам приходится иметь дело, и в случае серверного сегмента является почти гарантированным критерием определения устройства.
Но все становится существенно сложнее, когда мы пытаемся использовать его для идентификации пользовательских хостов. Достаточно часто в пользовательских сетях или их части мы сталкиваемся с DHCP и случайной выдачей IP-адреса хоста в рамках сегмента. Это ломает всю логику работы с инцидентом: на момент возникновения события IP-адрес мог относиться к одной машине, а к моменту, когда аналитик подключится к разбору или ИТ-служба заказчика будет ее блокировать, этот IP-адрес может принадлежать уже совершенно другому хосту.
Встречаются и еще более феерические случаи. Посмотрите, например, на логирование Windows при аутентификации по RDP:
![](https://habrastorage.org/r/w1560/webt/2a/ka/zl/2akazle6_jokyf8m_iux0mrftmq.png)
![](https://habrastorage.org/r/w1560/webt/xg/zr/ec/xgzreca7at8bbdjdyeubdb36kt0.png)
![](https://habrastorage.org/r/w1560/webt/-_/td/gr/-_tdgrgnmhcm8-y36w9vsvjykhm.png)
В итоге в зависимости от типа события идентификатором будет либо хост, либо IP. И эту проблему вообще лучше решать на уровне парсинга события.
Чаще всего мы используем следующую схему определения хоста. При обработке событий последовательно проверяется ряд условий и выбирается первое не нулевое значение (проблемы с парсингом из примера выше решаются на уровне парсеров:)):
Этот процесс выполняется в отношении каждого поступающего события и используется при проверке всех списков исключений, профилей и т.д.
Здесь важно отметить, что завести активы для всех хостов в компании и поддерживать их в актуальном состоянии не получится никогда. В любом случае есть гостевые сети, VPN-пулы адресов, тестовые среды, интернет . В этих сетях нельзя завести актив, поскольку все постоянно меняется. Но при этом все равно важно корректно определять источник активности, а не генерировать алерты на один и тот же хост, присутствующий в логах в разном формате (например, nb-hostname.domain.local, nb-hostname, 10.10.10.10 (но есть nb-hostname в DHCP)).
Использование актуальной инвентаризационной информации при обогащении событий
Когда мы говорим об анализе инцидента, очень важно оперировать актуальными данными о наличии на хосте обновлений/ПО/уязвимостей и пр.
Как правило, регулярные сканирования (а соответственно, и обновление информации об активах) происходят в лучшем случае раз в месяц. Сканировать всю инфраструктуру чаще практически нереально, и это в какой-то момент порождает еще одну очень важную деталь в обработке инцидентов, которую часто упускают из виду: между двумя инвентаризационными сканированиями состояние хоста может меняться сколь угодно часто и при этом в конечном счете вернуться к исходному состоянию. Например, в инцидентах, связанных с вредоносными рассылками, переходами на зараженные веб-сайты, выявлением индикаторов компрометации и т.д., очень важно понимать, был ли антивирус активен конкретно в тот момент.
Эту проблему мы решаем двумя способами:
Эта информация автоматически добавляется в соответствующий инцидент:
![](https://habrastorage.org/r/w1560/webt/nv/rp/42/nvrp42v5n0dfs-_2btgubp_3-aq.png)
Поддержание информации об активах в актуальном состоянии.
Как мы уже говорили, с какой бы скрупулезностью вы не подошли к описанию инфраструктуры, очень скоро оно устареет. Буквально через месяц-два сеть заказчика начнет меняться: появятся новые сервисы или хосты, исчезнут старые, часть систем сменит свое назначение.
Вот несколько подходов, которые мы в Solar JSOC используем для сохранения актуального контекста:
Игра не стоит свеч, а результат – труда?
Наверняка не один из наших читателей-практиков к концу этой статьи задумался: а зачем вообще нужно городить всю эту безумную конструкцию с учетом и актуализацией модели активов? Может быть, проще и «дешевле» вручную разбираться с каждым хостом по факту возникающего инцидента, и конечному заказчику не нужна такая скрупулезная инвентаризация?
Мы попробуем на нескольких примерах показать, как модель активов упрощает и автоматизирует часть деятельности оператора SOC и помогает в его ежедневной работе.
Возможность фильтровать лишнее
«Правильные» SIEM-системы позволяют автоматически использовать модель активов для фильтрации потенциальных инцидентов в исключения. Это позволяет существенно сократить время, которое оператору приходится тратить на разбор «мусора».
Например, часто мы начинаем собирать первичную информацию о сработках сценариев у заказчика еще до того, как заполним первую сетевую модель, ведь правило по выявлению обращений к С&С-серверам и вредоносным сайтам можно запустить достаточно быстро.
Значит ли это, что вся сеть заказчика кишит вредоносным ПО или, наоборот, репутационные базы С&С-серверов дают столько ложных срабатываний? Как правило, ни то, ни другое. Просто в отделениях компании-заказчика работает гостевой wifi, все пользовательские сессии которого используют ту же инфраструктуру выхода в Интернет, что и основная клиентская сеть, и потому попадают в поле зрения мониторинга.
Интересно ли заказчику, насколько безопасны телефоны внешних людей, которые просто воспользовались его гостевым Wi-Fi? Стоит ли оператору SOC обрабатывать такие инциденты? Скорее всего, нет. Так что фильтрация Wi-Fi-сетей из этого сценария – очень разумный и желательный шаг.
Или вот другой пример: обычно в компании на уровне политики безопасности существует ограничение на использование Remote Admin Tools. Но сотрудники helpdesk, в чьи обязанности входит обслуживание удаленных машин, пользователей в командировках или удаленных точек продаж, зачастую вынуждены прибегать к этому инструменту в своей ежедневной работе. Не проще ли для SOC идентифицировать места расположения сотрудников helpdesk и игнорировать такие события, чем обрабатывать каждое подозрение на инцидент вручную?
Повышение критичности и приоритетности инцидента в зависимости от конкретного актива
Ситуация, на мой взгляд, также не требующая дополнительных комментариев. Инцидент, произошедший на АРМ КБР в банке или на стыке основного и технологического сегмента в энергетике, всегда будет многократно важнее и приоритетнее, чем даже фиксация запуска хакерских утилит в пользовательском сегменте. И такой инцидент должен быть выявлен и обработан значительно быстрее.
Из нашей практики последних лет видно, что злоумышленники научились пользоваться слабой приоритизацией инцидентов в молодых SOC. Как один из финальных этапов атаки они используют так называемый «incident storm», создавая несколько десятков подозрений на инцидент в разных частях инфраструктуры, прежде чем захватить целевой ресурс или скомпрометировать информацию. Оператор SOC, обрабатывающий несколько десятков инцидентов по очереди, попросту не успевает добраться до нужного, по-настоящему критичного, пока не становится слишком поздно. Тогда как правильная приоритизация позволила бы ему сфокусировать свое внимание на наиболее важном инциденте и предотвратить последствия атаки.
Возможность видеть странное
Чем больше информации об активе и о ситуации в целом есть у оператора в начале разбора инцидента, тем быстрее он примет решение, и тем более правильным оно будет. И конечно, тем больше шансов, что настоящая сложная атака, пойманная на основании маленькой аномалии, будет эффективно идентифицирована и разобрана в SOC.
Ну и вообще, кто владеет информацией, тот владеет миром. На этом хотелось бы закончить наше погружение в тематику управления активами. Для всех оставшихся практических и не очень вопросов – добро пожаловать в комментарии. И до новых встреч в цикле «SOC for….».
Мы уже несколько раз косвенно касались темы управления активами: и в статье про контроль защищенности, и в вопросах автоматизации и искусственного интеллекта в SOC. Очевидно, что без инвентаризации инфраструктуры заказчика центр мониторинга не сможет его защищать. При этом составить ее детальное описание отнюдь не тривиальная задача. И главное — через пару месяцев оно снова не актуально: одни хосты исчезли, другие появились, возникли новые сервисы или системы. Но защита инфраструктуры — процесс непрерывный, и SOC не может притормозить свою деятельность до получения актуальной информации об активах заказчика. Напомню, качество работы Solar JSOC регулируется не абстрактными обещаниями, а вполне конкретным SLA, за нарушением которого следуют различные небесные кары. Как выкрутиться в такой ситуации и не потерять в качестве оказываемого сервиса?
![](https://habrastorage.org/webt/cq/ca/3m/cqca3m4hwgwyes5srqibczapd8k.png)
Предлагаем сейчас вернуться к этому вопросу через один из сравнительных примеров оповещения по инцидентам:
Запущен RAT утилита AmmyAdmin на хосте 172.16.13.2.vs
Запущен RAT утилита AmmyAdmin на хосте 172.16.13.2, московский офис на Кузнецком мосту, машина Иванова Петра Михайловича, заместителя начальника узла связи, функционал — обработка рейсов МЦИ и работа с АРМ КБР, запрещена удаленная работа администратора.
Казалось бы, разница между этими двумя уведомлениями в глубине анализа. В первом случае уведомление выглядит так, словно оно было получено автоматически от SIEM-платформы, а во втором видна работа оператора и обогащение инцидентов. Это и так, и не так. Для того чтобы оператор мог провести анализ инцидента и сделать какие-то выводы, ему крайне важно понимать, что (или кто) именно скрывается за этими загадочными и почти одинаковыми IP-адресами у заказчиков, и использовать эту информацию в разборе инцидента.
Процентов 20% наших читателей сейчас скажут: «Ну, для этого же во всех компаниях внедрена система CMDB, чего проще, чем подключить данные из нее в SIEM? Даже коннектор писать не надо». Оставим на этом убеждении коллег из интеграторов и вендоров. Из нашей практики, как ни печально это осознавать, информацию из CMDB не стоит даже подключать или экспортировать в SIEM по причине ее полной неактуальности. Так что приходится засучить рукава и делать все своими руками. Давайте посмотрим на этот вопрос внимательнее и попробуем понять, как разобраться в недрах инфраструктуры,
Едим слона по частям или погружаемся в описание инфраструктуры
В своем движении к инвентаризации активов мы обычно пытаемся пройти четыре контрольные точки.
1. Построение верхнеуровневой, но подробной сетевой карты организации
Здесь первым и основным контактом выступают ИТ-подразделения заказчика (за исключением тех случаев, когда в компании корректно внедрена и настроена система управления сетевым оборудованием или firewall management, но это пока исключение). В ход идут и описательные части информации с сетевого оборудования, и схемы сети, и так далее.
Целевым результатом данного этапа является возможность разбить все внутренние адреса на сетевые зоны с идентификацией следующей информации:
- К какой площадке (геолокация/место, если применимо) относится конкретный IP-адрес.
- К какому типу площадки (ЦОД/головной офис/отделение/точка продаж) он принадлежит.
- Глобальное назначение выделенного сегмента сети — пользовательский/корпоративный Wi-Fi/гостевой Wi-Fi /админы/сервера.
- Прикладное назначение этого сегмента сети — относительно системы или бизнес-приложения, если это возможно.
Отсюда следует первый важный вывод: активы — это не только описание конкретных хостов с указанием подробной инвентаризационной информации о них, но и возможность описать сегменты сети и использовать эти данные в отчетах/корреляции/поиске по событиям.
Вот как это выглядит в SIEM:
![](https://habrastorage.org/webt/np/ld/si/npldsic5fbz-atbk75naqy_alvy.png)
2. Описание основных подсистем в ЦОД
Как правило, стартовая идентификация данных машин появляется по итогам первых бизнес-интервью. Общение с безопасностью, ИТ, сетевиками и прикладниками позволяет в первом приближении понять, как устроена инфраструктура компании и какие ресурсы/системы в ней являются самыми критичными. Собрать информацию об их адресации и сетевой принадлежности получается достаточно легко. Далее в режиме точечных вопросов уже можно получить требуемую информацию:
- Что именно за сервисы и приложения развернуты на данном хосте.
- К какому классу критичности согласно ИТ она отнесена.
- Какова функциональная роль системы (плановая).
На этом этапе обычно помогают выгрузки из различных систем централизации:
- Системы виртуализации. Зачастую в комментариях к созданию виртуальных машин дается описание их функциональных ролей.
- Active Directory и прочие каталоги. Как минимум, структура домена очень часто дает ответы о функциональном назначении систем:
- Различные СЗИ (как правило, антивирусы) обладают большим объемом инвентаризационной информации:
- Или просто большой Excel-файл, где перечислены ключевые системы с привязкой к платформам, адресации и т.д.
Из этого следует второй важный вывод: нужно уметь «забирать» информацию об активах из абсолютно разных источников и добавлять эту информацию в SIEM в соответствии с настроенными сценариями и логикой мониторинга.
3. Описание критичных хостов и активов с точки зрения информационной безопасности
Когда заказчик обозначил свои «болевые точки» и наиболее критичные системы, мы вступаем в диалог с ответственными за них, чтобы разобраться, как эти системы связаны между собой, какие данные там хранятся и какие риски ИБ с ними связаны. Также мы оцениваем их по дополнительным параметрам, после чего присваиваем некоторым из систем коэффициенты, повышающие уровень критичности. Вот на что мы обращаем внимание:
- Насколько данная система опасна с точки зрения монетизации атаки. Примеры – АРМ КБР, машины расчетного центра в банках, машины казначейства и банк-клиентов в прочих компаниях.
- Насколько данная система критична с точки зрения компрометации находящихся на ней данных. Примеры – системы управленческой отчетности, папки, хранящие информацию с коммерческой тайной и т.д.
- Насколько данная система при взломе может быть использована для развития атаки на инфраструктуру. Примеры – центральное сетевое оборудования, серверы антивируса, AD и сканера защищенности (владея ими, злоумышленник зачастую может получить доступ куда угодно).
- Другая причина высокой критичности данного хоста, о которой сообщает нам заказчик.
Пример описаний:
![](https://habrastorage.org/webt/y5/cg/5h/y5cg5hmkxiovdy7tmq-p90kq2su.png)
Третий важный вывод: у SOC должна быть возможность добавлять свои описания назначения, функционала и критичности хоста под каждый актив и под каждую подсеть, заведенные в систему. Как говорится, «на вкус и цвет все фломастеры разные», и то, что хорошо в ИТ, не всегда нужно в ИБ.
4. Обогащение информации по хосту/активу
В финале мы пытаемся обогатить информацию по хосту/активу данными из систем ИБ-инвентаризации или сканеров защищенности:
- Характеристики hardware (процессоры, память, диски и т.д.).
- Информация по ОС и всех установленных патчах (и, если повезет, даже с актуальными для них уязвимостями).
- Список установленного ПО с версионностью.
- Список процессов, запущенных на момент сканирования.
- Уйма дополнительной информации (MD5-библиотек и т.д.).
Эта информация бывает крайне полезной для расследования, хотя, на наш взгляд, не является первичной при идентификации и оценке критичности самого инцидента, связанного с хостом.
Разбираемся в возникающих проблемах
Хотя даже на первый взгляд процесс описания инфраструктуры выглядит достаточно непростым, на деле это только те сложности, которые лежат на поверхности. Как всегда, внутри можно обнаружить некоторое количество подводных
Выбор уникального идентификатора актива
Казалось бы, вопрос банальный и очевидный. Выбирай что угодно: хоть IP-адрес (если несколько интерфейсов – назначь главный), хоть доменное имя, хоть серийный номер. Но в жизни все оказывается не так просто.
Любые hardware- или software-идентификаторы действительно очень хороши своей уникальностью и прямой связкой с устройством. Проблема одна – мы работаем с логами, и инциденты выявляем на основании логов, а в них этих уникальных идентификаторов просто нет. Поэтому у нас нет (почти) никакой возможности корректно связать происходящее в нашей сети с активом.
DNS-имя тоже хорошо с точки зрения его уникальности (оставим без внимания те компании, которые предпочитают его не использовать). Но проблема, к сожалению, совершенно аналогична – абсолютное большинство журналов не содержит об этом самом DNS-имени никакой информации. Поэтому сопоставление инцидента с активом также остается проблемой.
Казалось бы, вариантов у нас не осталось, придется работать с IP-адресом. Он появляется в абсолютном большинстве журналов, с которыми нам приходится иметь дело, и в случае серверного сегмента является почти гарантированным критерием определения устройства.
Но все становится существенно сложнее, когда мы пытаемся использовать его для идентификации пользовательских хостов. Достаточно часто в пользовательских сетях или их части мы сталкиваемся с DHCP и случайной выдачей IP-адреса хоста в рамках сегмента. Это ломает всю логику работы с инцидентом: на момент возникновения события IP-адрес мог относиться к одной машине, а к моменту, когда аналитик подключится к разбору или ИТ-служба заказчика будет ее блокировать, этот IP-адрес может принадлежать уже совершенно другому хосту.
Встречаются и еще более феерические случаи. Посмотрите, например, на логирование Windows при аутентификации по RDP:
![](https://habrastorage.org/webt/2a/ka/zl/2akazle6_jokyf8m_iux0mrftmq.png)
![](https://habrastorage.org/webt/xg/zr/ec/xgzreca7at8bbdjdyeubdb36kt0.png)
![](https://habrastorage.org/webt/-_/td/gr/-_tdgrgnmhcm8-y36w9vsvjykhm.png)
В итоге в зависимости от типа события идентификатором будет либо хост, либо IP. И эту проблему вообще лучше решать на уровне парсинга события.
Чаще всего мы используем следующую схему определения хоста. При обработке событий последовательно проверяется ряд условий и выбирается первое не нулевое значение (проблемы с парсингом из примера выше решаются на уровне парсеров:)):
- Сеть имеет статическую адресацию, и в SIEM заведен актив для этого IP (идентификатор = имя актива).
- В активных арендах DHCP есть информация по HostName при выборке по IP из лога (идентификатор = имя хоста, без домена).
- Есть ли в логе HostName (идентификатор = имя хоста, без домена).
- Есть ли в логе IP-адрес (идентификатор = IP-адрес).
Этот процесс выполняется в отношении каждого поступающего события и используется при проверке всех списков исключений, профилей и т.д.
Здесь важно отметить, что завести активы для всех хостов в компании и поддерживать их в актуальном состоянии не получится никогда. В любом случае есть гостевые сети, VPN-пулы адресов, тестовые среды, интернет . В этих сетях нельзя завести актив, поскольку все постоянно меняется. Но при этом все равно важно корректно определять источник активности, а не генерировать алерты на один и тот же хост, присутствующий в логах в разном формате (например, nb-hostname.domain.local, nb-hostname, 10.10.10.10 (но есть nb-hostname в DHCP)).
Использование актуальной инвентаризационной информации при обогащении событий
Когда мы говорим об анализе инцидента, очень важно оперировать актуальными данными о наличии на хосте обновлений/ПО/уязвимостей и пр.
Как правило, регулярные сканирования (а соответственно, и обновление информации об активах) происходят в лучшем случае раз в месяц. Сканировать всю инфраструктуру чаще практически нереально, и это в какой-то момент порождает еще одну очень важную деталь в обработке инцидентов, которую часто упускают из виду: между двумя инвентаризационными сканированиями состояние хоста может меняться сколь угодно часто и при этом в конечном счете вернуться к исходному состоянию. Например, в инцидентах, связанных с вредоносными рассылками, переходами на зараженные веб-сайты, выявлением индикаторов компрометации и т.д., очень важно понимать, был ли антивирус активен конкретно в тот момент.
Эту проблему мы решаем двумя способами:
- Отдельные алерты на факты отключения/изменения состояния ПО или хоста.
- Выгрузка статусов по хостам или использование логов хоста для обновления текущего статуса.
Эта информация автоматически добавляется в соответствующий инцидент:
![](https://habrastorage.org/webt/nv/rp/42/nvrp42v5n0dfs-_2btgubp_3-aq.png)
Поддержание информации об активах в актуальном состоянии.
Как мы уже говорили, с какой бы скрупулезностью вы не подошли к описанию инфраструктуры, очень скоро оно устареет. Буквально через месяц-два сеть заказчика начнет меняться: появятся новые сервисы или хосты, исчезнут старые, часть систем сменит свое назначение.
Вот несколько подходов, которые мы в Solar JSOC используем для сохранения актуального контекста:
- Пополнение информации по активам on-demand, по факту возникающих подозрений на инцидент. Если при анализе инцидента выявлено, что актив (IP-адрес) не внесен в нашу сетевую модель, при оповещении мы запрашиваем у заказчика информацию по хосту. Это касается заполнения информации как об активе, так и о подсетях.
- Регулярная инвентаризация потенциальных новых хостов. Здесь есть несколько вариантов:
- Сделать выгрузку хостов из домена, антивируса и пр. и сравнить ее с текущим состоянием. Это делается с помощью простейшего корреляционного правила, в условиях которого можно прописать конкретный OrganizationUnit, hostname по маске и т.д. — в зависимости от того, что хочется видеть.
- Сделать выгрузку соответствия IP-MAC на коммутаторах в некоторых сегментах сети.
- Отслеживать сетевую активность хоста.
«На сдачу» к описанному выше процессу мы получаем информацию о хостах, которые очень давно не появлялись в обозначенных отчетах и которых, вероятно, больше не существует. Например, можно «следовать за процессом увольнения сотрудников» и сделать алерты/отчеты на перемещение хоста/УЗ в «OU=disabled».
- Сделать выгрузку хостов из домена, антивируса и пр. и сравнить ее с текущим состоянием. Это делается с помощью простейшего корреляционного правила, в условиях которого можно прописать конкретный OrganizationUnit, hostname по маске и т.д. — в зависимости от того, что хочется видеть.
- Ну и наконец самый сложный, но очень важный процесс — «ручной» сбор с ответственных специалистов заказчика информации об изменениях, новых подсистемах или масштабировании старых. В Solar JSOC этим занимается сервис-менеджер контракта, и зачастую эта работа приносит существенно больше результата, чем описанная выше автоматизация.
Игра не стоит свеч, а результат – труда?
Наверняка не один из наших читателей-практиков к концу этой статьи задумался: а зачем вообще нужно городить всю эту безумную конструкцию с учетом и актуализацией модели активов? Может быть, проще и «дешевле» вручную разбираться с каждым хостом по факту возникающего инцидента, и конечному заказчику не нужна такая скрупулезная инвентаризация?
Мы попробуем на нескольких примерах показать, как модель активов упрощает и автоматизирует часть деятельности оператора SOC и помогает в его ежедневной работе.
Возможность фильтровать лишнее
«Правильные» SIEM-системы позволяют автоматически использовать модель активов для фильтрации потенциальных инцидентов в исключения. Это позволяет существенно сократить время, которое оператору приходится тратить на разбор «мусора».
Например, часто мы начинаем собирать первичную информацию о сработках сценариев у заказчика еще до того, как заполним первую сетевую модель, ведь правило по выявлению обращений к С&С-серверам и вредоносным сайтам можно запустить достаточно быстро.
Значит ли это, что вся сеть заказчика кишит вредоносным ПО или, наоборот, репутационные базы С&С-серверов дают столько ложных срабатываний? Как правило, ни то, ни другое. Просто в отделениях компании-заказчика работает гостевой wifi, все пользовательские сессии которого используют ту же инфраструктуру выхода в Интернет, что и основная клиентская сеть, и потому попадают в поле зрения мониторинга.
Интересно ли заказчику, насколько безопасны телефоны внешних людей, которые просто воспользовались его гостевым Wi-Fi? Стоит ли оператору SOC обрабатывать такие инциденты? Скорее всего, нет. Так что фильтрация Wi-Fi-сетей из этого сценария – очень разумный и желательный шаг.
Или вот другой пример: обычно в компании на уровне политики безопасности существует ограничение на использование Remote Admin Tools. Но сотрудники helpdesk, в чьи обязанности входит обслуживание удаленных машин, пользователей в командировках или удаленных точек продаж, зачастую вынуждены прибегать к этому инструменту в своей ежедневной работе. Не проще ли для SOC идентифицировать места расположения сотрудников helpdesk и игнорировать такие события, чем обрабатывать каждое подозрение на инцидент вручную?
Повышение критичности и приоритетности инцидента в зависимости от конкретного актива
Ситуация, на мой взгляд, также не требующая дополнительных комментариев. Инцидент, произошедший на АРМ КБР в банке или на стыке основного и технологического сегмента в энергетике, всегда будет многократно важнее и приоритетнее, чем даже фиксация запуска хакерских утилит в пользовательском сегменте. И такой инцидент должен быть выявлен и обработан значительно быстрее.
Из нашей практики последних лет видно, что злоумышленники научились пользоваться слабой приоритизацией инцидентов в молодых SOC. Как один из финальных этапов атаки они используют так называемый «incident storm», создавая несколько десятков подозрений на инцидент в разных частях инфраструктуры, прежде чем захватить целевой ресурс или скомпрометировать информацию. Оператор SOC, обрабатывающий несколько десятков инцидентов по очереди, попросту не успевает добраться до нужного, по-настоящему критичного, пока не становится слишком поздно. Тогда как правильная приоритизация позволила бы ему сфокусировать свое внимание на наиболее важном инциденте и предотвратить последствия атаки.
Возможность видеть странное
Чем больше информации об активе и о ситуации в целом есть у оператора в начале разбора инцидента, тем быстрее он примет решение, и тем более правильным оно будет. И конечно, тем больше шансов, что настоящая сложная атака, пойманная на основании маленькой аномалии, будет эффективно идентифицирована и разобрана в SOC.
Ну и вообще, кто владеет информацией, тот владеет миром. На этом хотелось бы закончить наше погружение в тематику управления активами. Для всех оставшихся практических и не очень вопросов – добро пожаловать в комментарии. И до новых встреч в цикле «SOC for….».