Как я внедрял SOAR: в чем разница In-house- и Outsourced-подходов
Мне повезло получить опыт работы с SOAR с совершенно разных сторон: быть и на стороне Заказчика, который только внедряет SOAR и учится использовать его в ежедневных задачах, и на стороне компании-интегратора с богатым опытом внедрения решений автоматизации ИБ. Расскажу о преодолении трудностей, с которыми мне пришлось столкнуться, о поиске уникальных решений для успешной интеграции SOAR, а также о том, как эти испытания преобразили мое видение и подход к работе. Побывав в каждой из двух ролей, я на практике убедился в том, насколько важна адаптация подходов внедрения SOAR к уникальным требованиям каждой организации и как полезен обмен опытом реализации разных проектов.
Хочу поделиться не только личным опытом, но и дать практические рекомендации специалистам, которые стоят на пороге внедрения SOAR в своих организациях. Надеюсь, что эта статья поможет избежать типичных ошибок и усилить эффективность внедрения новых решений.
In-house-подход, или мой опыт как исполнителя внутри компании
Зачем нужен SOAR и какие задачи решает в компании
SOAR (Security Orchestration, Automation and Response) — это передовая технология, предназначенная для автоматизации и оркестровки процессов ИБ, а также для быстрого реагирования на инциденты безопасности. Внедрение SOAR позволяет организациям значительно повысить свою защищенность, минимизировать риски ИБ и оптимизировать работу специалистов по безопасности.
Внедрение системы SOAR в нашей банковской организации решало несколько задач одновременно. Во-первых, мы нуждались в эффективном и автоматизированном инструменте для реагирования на кибератаки и инциденты безопасности. Во-вторых, стремились обеспечить надежную защиту клиентов и их финансовых данных. Для этого было важно объединить информацию об инцидентах из различных систем в одном удобном окне, а инвентаризацию активов проводить безопасно и эффективно.
С какими сложностями внедрения столкнулись
При развертывании SOAR в нашей организациии возникло несколько сложностей, в первую очередь связанных с адаптацией системы к уже существующим процессам информационной безопасности. Мы столкнулись с необходимостью интеграции с SIEM-системой. У нас не было лицензий на готовые интеграции, а к поставщику для получения необходимой поддержки мы не обращались.
Обсудив все с коллегами и руководством, мы решили делать настройку интеграции SOAR самостоятельно по трем причинам:
рост экспертизы внутри команды. Разработка собственного решения позволяла нам глубоко погрузиться в детали технологии SOAR и адаптировать её под уникальные потребности и процессы нашего банка;
контроль процесса и затрат. Мы хотели полностью владеть процессом внедрения и настройки, не зависеть от поставщика и точно понимать наши затраты и оптимизировать их;
гибкость управления проектом. Нам важно было самостоятельно планировать сроки и этапы работы, а также оперативно вносить необходимые коррективы.
Наша команда состояла из двух человек: я занимался интеграцией различных систем, а мой коллега — настройкой карточек инцидентов для сотрудников. Ключевой трудностью стала необходимость самостоятельного решения всех возникающих проблем без возможности поделиться опытом или получить помощь от других.
Изучая технологию, посещая специализированные конференции и обмениваясь опытом с коллегами из других организаций, мы обнаружили, что большинство специалистов в компаниях не достигли уровня сложности в работе с SOAR, который был бы сопоставим с нашим. Во многих случаях использование SOAR ограничивалось лишь выполнением минимальных требований регуляторов, без разработки и внедрения полноценных процессов обработки инцидентов.
Как мы пытались «подружить» SOAR и SIEM
Cистема SOAR, которую мы использовали, на этапе внедрения не предоставляла возможности запуска произвольных скриптов. Поэтому мы настроили скрипты в рамках существующей SIEM-системы. Наша цель заключалась в установке интеграции, которая позволяла бы SIEM передавать инциденты в SOAR и обновлять их статус, если он менялся в любой из систем.
SIEM-система использовала концепцию кейсов, описывающих определенные события и инциденты. При создании таких кейсов генерировались внутренние события SIEM, из которых можно было передавать данные в скрипты, запускаемые в системе. Да, в самой SIEM-системе имеется встроенный механизм запуска скриптов.
Хотя нам удалось реализовать интеграцию, мы столкнулись с рядом проблем. Когда какая-либо из систем была существенно загружена, инциденты могли не передаваться из одной в другую, что приводило к необходимости ручной проверки статусов и наличия инцидентов в обеих системах. Мы предусмотрели уведомления в скриптах, которые помогали обнаруживать проблемы, однако этого было недостаточно, приходилось выполнять множество действий вручную.
В процессе интеграции через API мы столкнулись с еще одной проблемой. В документации к SOAR не были описаны необходимые методы передачи информации об активе в карточку инцидента. Мы провели исследование и обнаружили скрытый или неявный API, позволяющий установить связь между активом и инцидентом, включая передачу IP-адреса хоста, где произошел инцидент.
Проблемы и решения: инвентаризация активов, антивирус, производительность системы
Инвентаризация. В рамках нашей работы было необходимо реализовать инвентаризацию активов в SOAR. Изначально мы пытались осуществить это при помощи SIEM, используя получаемые события из различных источников. План состоял в следующем: получать события с Firewall, DNS и других устройств в сети, затем записывать их в листы в SIEM и передавать данные из них в SOAR. Однако мы отказались от этой идеи, так как работа с листами в SIEM не позволяла всегда поддерживать актуальное состояние хостов. Вместо этого мы нашли способы организовать инвентаризацию через SOAR, где уже имелись встроенные механизмы сканирования сети.
Кроме того, мы использовали модель тегов, чтобы добиться такого же распределения по сегментам, как в SIEM. Например, у актива ARM01 могли быть следующие теги: PCI DSS, Critical, ARM, Antivirus, DLP. Каждый тег описывал определенную характеристику: PCI DSS — принадлежность к сегменту PCI DSS, Critical — критичность хоста, ARM — автоматизированное рабочее место, Antivirus — наличие антивируса на данном хосте, DLP — необходимость наличия DLP на хосте.
Используя модель тегов, мы организовали эффективную автоматизацию процесса инвентаризации активов. Правила для присвоения тегов определялись заранее установленными политиками. Например, в случае когда сеть определена с адресом 10.1.0.0/24, мы автоматически назначаем ей тег PCI DSS. Данная сеть изначально классифицируется как соответствующая стандартам PCI DSS, что делает очевидным выбор в пользу присвоения соответствующего тега. Таким образом, наличие этого тега указывает на то, что сеть попадает под определенные требования безопасности данных, установленные стандартом PCI DSS, и к ней применяются специфические меры защиты и политики безопасности. Затем мы назначали другие теги, такие как DLP и Antivirus. Когда теги были присвоены, генерировалось событие, содержащее информацию о теге и хосте, на котором он был установлен. Это событие отправлялось в SIEM, где уже имелись листы с IP-адресами и статусами, такими как наличие антивируса или его отсутствие. Механизмы проверки наличия средств защиты информации на хостах были настроены далеко заранее, так как этот процесс был для нас очень важен. Каждое СЗИ проверялось по-разному. Например, в антивирусе у нас была настроена интеграция с базой данных. Оттуда SIEM забирала IP-адреса хостов и статус агента на них.
Антивирус. Мы настроили правило, которое проверяло наличие антивируса на хосте, полученном из SOAR. Если антивирус отсутствовал, SIEM отправляла новый тег Unactive Antivirus в SOAR и создавала инцидент о его отсутствии. Таким образом, мы реализовали автоматизированный процесс проверки наличия систем защиты информации на хостах в нашей компании.
Производительность. Хотя в SIEM есть возможность запуска скриптов, использование этой функции негативно сказывается на производительности системы. Когда у нас была лицензия, не позволяющая обновлять SIEM, и система размещалась на физических серверах, мы столкнулись с проблемами производительности. Были случаи, когда SIEM была недоступна около двух часов. Тогда нам удалось её восстановить без потери данных, так как коннекторы сохраняли события до момента восстановления доступности SIEM. Очевидно, что проблемы были вызваны не только запуском скриптов, но и большим количеством неиспользуемых или устаревших правил.
Кроме того, мы допускали ошибки в настройках правил SIEM и получали в SOAR тысячу событий в течение одной минуты. Накопление большого количества ненужных событий в SOAR негативно влияло на производительность системы и затрудняло работу с инцидентами для пользователей. Так как созданные события удалить невозможно, мы решили эту проблему, увеличив ресурсы SOAR и проведя оптимизацию работы базы данных PostgreSQL, изменив стандартную конфигурацию.
Из этого проекта я вынес следующее: для эффективного управления инцидентами и активами необходимо заранее провести тщательное проектирование. При этом следует учитывать, что каждая организация может иметь свои особенности и уникальные требования в этих процессах.
Outsourced-подход, или мой опыт работы в компании-системном интеграторе
Новый опыт, новые задачи, новые возможности
Мой первый проект в статусе инженера компании-интегратора заключался во внедрении системы SOAR в НИИ. Здесь всё было совершенно иначе. Внедряемая low-code платформа SOAR позволяла описать любой процесс в области информационной безопасности — этого мне так не хватало на предыдущем месте. В рамках этого проекта также требовалось настроить централизованный процесс обработки инцидентов и управления активами. Подход к интеграциям в данном случае значительно отличался от того, который я применял в банковской среде. Здесь мы располагали готовыми коннекторами и предварительно настроенными процессами безопасности. Казалось бы, какие в таком случае могут возникнуть проблемы во время внедрения?
В данном проекте наша задача состояла в создании процесса инвентаризации активов через интеграцию со смежными системами. Нам требовалось настроить интеграцию со сканером уязвимостей и системами DLP. Информация об активах должна была ежедневно выгружаться и обновляться, если происходили изменения. Важным условием было наличие уникального поля для каждого актива, по которому SOAR могла определить статусы и обновлять данные. Однако возникли определенные сложности, связанные с наименованием узлов сети, где в поле с наименованием мог быть указан как IP-адрес, так и DNS-имя. Это приводило к дублированию активов и возможным двойным записям. Кроме того, необходимо было учесть, что не во всех смежных системах могут быть указаны активы, поскольку некоторые узлы сети могли никогда не подвергаться сканированию или не имели DLP.
Для решения такой задачи было использовано новое решение — универсальные плейбуки в SOAR. Мы решили сканировать сети, в которых находились активы, и автоматически добавлять недостающие данные в SOAR. Это позволило нам решить две проблемы одновременно. Во-первых, мы гарантировали актуальность информации об активах. Если хост был недоступен более 7 недель, мы его удаляли из SOAR. Во-вторых, мы смогли заполнить пробелы в информации о хостах, которые по разным причинам отсутствовали в смежных системах.
При инвентаризации активов в банке я использовал подход сканирования известных сетей, получаемых из SIEM. При внедрении SOAR в НИИ, я столкнулся с другой проблемой — огромным объемом данных об активах. Если мы собирали данные со сканера уязвимостей, то количество записей о наличии ПО, например, различных версий 7-zip, в организации становилось огромным. Чуть позже я познакомился с понятием пагинации и решил эту проблему. Мы изменили процесс интеграции, выгружая по 500 записей за итерацию. Также мы решили не выгружать каждый день одни и те же записи. Организовали обработку данных в самом SOAR, где ПО «схлопывалось» в наиболее актуальную версию, и выгружали только те записи, которые были обновлены недавно.
Польза комплексного взгляда
Рад, что у меня был практический опыт работы с разных сторон: и со стороны Заказчика, и со стороны интегратора. Сейчас, работая в компании-интеграторе, я понимаю задачи Заказчика и могу быстро помочь решить проблемы, с которыми сталкивался сам.
Путь, который я прошел, помог понять, что важно не только быстро погружаться в неизведанные процессы и разбираться с новым ПО, но также важен состав команды и ее экспертиза, общий уровень экспертизы на рынке. Я писал, что мы посещали профильные конференции, но не на все вопросы смогли найти ответы. У маленьких команд ограничены возможности для обмена опытом и изучения лучших практик других организаций. Все это замедляет процесс внедрения и увеличивает трудоемкость работы по адаптации системы под специфические нужды организации.
Специалисты внешних интеграторов, напротив, имеют доступ к широкому спектру проектов и решений. Это позволяет не только учиться на опыте других, но и адаптировать успешные практики для решения задач в новых контекстах. Такой подход значительно упрощает процесс решения специфических задач и способствует более эффективному внедрению системы SOAR.
Описанный в статье пример построения автоматизированной инвентаризации активов подчеркивает разнообразие подходов, которые могут быть применены в зависимости от архитектуры сети и инфраструктуры заказчика. Речь идет о сканировании известных сетей и интеграции со смежными системами. А вот если в организации имеется так называемое «горло сети», через которое проходит весь трафик — это открывает возможности для задействования систем зеркалирования трафика, позволяет получить полную картину всех активов в инфраструктуре, упрощая процесс инвентаризации и повышая эффективность управления активами.
Таким образом, опыт работы как в In-house, так и в Outsourced при внедрении SOAR демонстрирует, что гибкость подходов и открытость к обмену опытом являются ключевыми факторами успеха в области кибербезопасности. Это не только способствует более эффективному внедрению и адаптации систем безопасности, но и обогащает профессиональное сообщество ценными знаниями и опытом.
Автор: Сергей Марченко, ведущий инженер направления «Автоматизация ИБ», УЦСБ
