Статья подготовлена по итогам вебинара «Автоматизация с R-Vision SOAR: первые шаги к передовому SOC», запись которого вы можете посмотреть тут.
Обогащение IoC возможно только в SOAR или в SIEM тоже можно обогатить?
Да, обогащение IoC можно делать и в SIEM, и в SOAR.
Но если говорить именно про SOAR, его ценность в том, что он позволяет:
- получать IoC из инцидента или алерта,
- автоматически обогащать их через внешние и внутренние источники,
- и сразу использовать результат в сценариях реагирования.
То есть SIEM чаще помогает обнаружить и передать IoC, а SOAR — обогатить их и встроить в дальнейшие действия по инциденту.
А есть ли возможность добавлять параметры безопасности в карточку актива?
Да, можно добавлять.
Карточка актива в системе гибко настраивается под ваши задачи:
- можно добавлять собственные поля,
- убирать лишние,
- менять приоритет и порядок отображения полей.
Это позволяет адаптировать карточку под нужный набор параметров безопасности и под разные роли специалистов.
Как исключить появление в карточке хоста IP-адресов Docker-контейнеров? Они в большей части одинаковые на разных хостах. И в ходе инвентаризации информация об этих адресах переходят от одного хоста к другому.
Да, на самом деле это частая ситуация в рамках инвентаризации.
Здесь сам контейнер, который находится на том или ином хосте, и его сеть будут записаны как отдельный сетевой интерфейс.
То есть Docker-контейнер, например, не будет отображаться как полноценный отдельный актив — он так или иначе будет относиться к определенному хосту.
Какой срок жизни активов, например, не поступают данные в течение Х-дней, через сколько актив удалится? Реализовано ли автоудаление?
Да, здесь как раз есть возможность задавать срок жизни, то есть жизненный цикл актива.
Его можно достаточно гибко настроить: например, на удаление, либо на уведомление пользователя о том, что данные по активу устарели и стоит провести дополнительную инвентаризацию или проверить интеграцию с СЗИ, из которого поступала информация.
Соответственно, информацию о старых активах тоже можно удалять, если она больше не нужна и не является актуальной.
Правильно ли я понимаю, что уникальность единицы оборудования определяется его FQDN. Но если у меня приходят данные по двум Linuх хостам, не введенным в домен с одинаковыми Hostname, эти хосты объединятся в один?
FQDN действительно является одним из идентификатором актива, но помимо него используются также IP-адрес и MAC-адрес, который в целом уникален.
Поэтому если в инфраструктуре появляются несколько активов с одинаковым Hostname или FQDN, система не будет опираться только на этот параметр — она дополнительно проверит другие атрибуты, чтобы точнее определить, разные это активы или нет.
Как выбрать первый процесс для автоматизации, с учетом того, что нет никакого регламента?
При первом знакомстве с SOAR часто возникает вопрос: как автоматизировать то, чего еще нет? Важно помнить, что не стоит автоматизировать хаос. Поэтому первый процесс для автоматизации лучше выбирать не самый сложный и не самый критичный — задача на старте показать, как работает SOAR, чтобы команда увидела результат, привыкла к процессу и начала доверять автоматизации.
Если говорить о критериях, то:
- Частота. Процесс должен повторяться достаточно регулярно, чтобы было видно эффект от автоматизации. Для этого стоит посмотреть на наиболее частые алерты — например, фишинг, срабатывания антивируса или события нелегитимного входа в систему.
- Рутинность. Процесс должен быть однотипным и предсказуемым. Например, при работе с фишингом обычно выполняются одни и те же шаги: поиск артефактов, проверка файлов и ссылок в песочнице, блокировка отправителя или зараженного хоста, очистка системы.
- Понятность процесса. Даже если регламента нет, у аналитиков уже есть практическое понимание, как проходит реагирование: кто участвует, какие шаги выполняются и где начинается и заканчивается процесс. Этого достаточно, чтобы начать автоматизацию.
Таким образом, при выборе первого сценария стоит ориентироваться на частоту, рутинность и понятность процесса.
Сколько должно быть сценариев реагирования?
В целом мы рекомендуем начинать примерно с пяти базовых сценариев. Этого достаточно, чтобы обкатать процессы автоматизации и показать команде, как работает SOAR. Далее можно постепенно добавлять более сложные плейбуки и расширять набор сценариев.
У нас также есть типовые шаблоны — например, для фишинга, вредоносного ПО, брутфорса и ряда других сценариев. При внедрении мы предлагаем заказчикам использовать эти шаблоны: где-то их можно взять за основу, а где-то — донастроить под конкретную инфраструктуру и задачи.
Карточка инцидента, которую вы показывали (расследование) — это специальная карточка инцидента, которая появляется только после интеграции с SIEM и при обогащении инцидента из SIEM или это стандартная форма из базовой конфигурации SOAR?
Информация, которая поступает из SIEM в рамках инцидента, обычно заполняет общие сведения — например, дату возникновения, категорию, тип инцидента и другие базовые параметры. В некоторых случаях в эту карточку также могут попадать дополнительные данные, например из письма, если информация приходит через интеграцию.
При этом дополнительные поля карточки полностью кастомизируются и настраиваются в зависимости от типа инцидента.
Та карточка, которую мы показывали, — это демонстрационный пример. В системе можно настроить карточку под те типы инцидентов, которые чаще всего встречаются у вас, чтобы упростить работу аналитиков и сократить время реагирования. Также мы делимся лучшими практиками и помогаем заказчикам наиболее эффективно настроить карточку под их процессы.
При импорте информации о сотрудниках из нескольких источников (к примеру, 1С и AD) информация из какого источника будет более приоритетной, не будет ли дублирования?
Здесь логика достаточно простая. Если информация о сотрудниках поступает из нескольких источников, например из 1С и AD, приоритет будет у данных из последнего источника, с которым была выполнена интеграция.
Соответственно, данные не дублируются — в системе используется актуальная информация, полученная из последнего подключенного источника.
Можно ли искать актив по MAC-адресу?
Да, можно.
MAC-адрес можно использовать как один из параметров при поиске и фильтрации активов, поэтому по нему можно найти нужный актив и работать с ним далее.
Можно ли наследовать критичность хоста от группы, в которую он включен?
Да, такая возможность есть.
Если критичность не задается для актива отдельно, он может наследовать её от группы, в которую входит. В дальнейшем эту критичность можно использовать, например, при приоритизации инцидентов.
Данные поступают в систему через общую политику (например, AD) или работы происходят через агенты?
Здесь всё зависит от того, о каких данных идет речь.
Если говорить про данные об активах, то для их сбора используется сетевое сканирование:
— SSH для подключения к Linux-хостам;
— WinRM для подключения к хостам под управлением Windows.
Если речь про Active Directory, то есть, два варианта интеграции:
— импорт пользователей из AD для добавления их в систему (например, аналитиков или администраторов);
— получение данных из AD для обогащения информации об активах.
Есть миграция одного или группы хостов с одной версии ОС на другую, как будет отрабатывать слияние?
В этом случае информация по хосту просто обновится. Если сохраняются те же идентификаторы, например, FQDN, IP-адрес, MAC-адрес или сетевой интерфейс — система распознает, что речь идёт об одном и том же активе.
Соответственно, при последующей инвентаризации данные по операционной системе будут обновлены в карточке этого хоста.
Как сортируются инциденты? На что обращать внимание в первую очередь аналитику?
Грид инцидентов можно настроить под свои задачи. Обычно аналитики ориентируются на уровень (критичность) инцидента и критичность активов, которая определяется в ходе инвентаризации и категоризации.
Также можно использовать фильтрацию по ответственному, чтобы каждый аналитик видел только назначенные ему инциденты и быстрее брал их в работу.
А что делать если SIEM начинает сбоить и шлет тысячи событий? Как система реагирует на это?
В такой ситуации создается большое количество инцидентов. Дальнейшая обработка зависит от технических ресурсов, выделенных для SOAR. Если ресурсов достаточно, система сможет обработать этот поток.
При этом стандартные технические требования обычно позволяют переживать временные пики нагрузки, например до момента, пока проблема на стороне SIEM не будет устранена.
Поддерживается ли автоматический откат действий плейбука, если один из шагов плейбука не завершился успешно?
Шаги: 1. Заблокировали пользователя 2. Остановили процесс 3. Тикет не создался в смежной системе для дальнейших действия по разблокировке.
Да, такая возможность есть.
В системе можно выполнять действия из карточки инцидента — например, в Active Directory: заблокировать пользователя, сменить пароль или разблокировать учётную запись. Эти действия могут выполняться как автоматически в рамках плейбука, так и вручную.
Также поддерживается возможность отката действий. Например, если ранее была выполнена блокировка пользователя, изоляция хоста или блокировка на межсетевом экране, эти действия можно впоследствии отменить и вернуть систему в исходное состояние.
Ответы на другие вопросы, а также полную запись вебинара от 03.03.2026 вы можете найти по ссылке.