| Слушать на Google Podcasts | Слушать на Mave | Слушать на Яндекс Музыке |
Руслан Рахметов, Security Vision
Друзья, в предыдущих статьях мы узнали, чем занимаются в Центрах SOC, рассмотрели основные принципы работы SIEM-систем, IRP-решений и платформ SGRC, а также познакомились с обработкой индикаторов компрометации. Мы, на первый взгляд, можем сказать, что работа аналитиков по кибербезопасности уже в достаточной мере автоматизирована, а применение разнообразных средств защиты, таких как IRP/SGRC/SIEM-системы, позволяет в достаточной мере упростить работу сотрудникам SOC-Центров. Но зачастую для обеспечения кибербезопасности используются настолько разные системы и средства защиты, а при обработке киберинцидентов нужно решать столько разнородных задач, что реагирование на инциденты ИБ требует еще большей степени автоматизации процессов.
Система снижает влияние человеческого фактора, повышает скорость реакции на инциденты и выстраивает проактивную защиту в соответствии с международными стандартами информационной безопасности. Узнать о продукте Security Vision SOAR →
Причем речь даже не столько про непосредственно активное противодействие угрозам (с этим справляются IRP-решения), сколько про интеграцию систем обработки данных киберразведки, обогащение полученных данных, коммуникации по инцидентам, применение методов искусственного интеллекта, машинного обучения и анализа больших данных (Big Data).
При необходимости автоматизировать большое количество смежных процессов реагирования на инциденты применяются системы SOAR - это означает Security Orchestration, Automation and Response, или платформы оркестрации, автоматизации и реагирования на киберинциденты. Данные продукты являются эволюцией платформ реагирования на киберинциденты (IRP-систем) и предоставляют расширенные функции по автоматизации процессов обработки инцидентов информационной безопасности. Какие именно - расскажем далее.
Давайте на минуту представим, какие типовые ежедневные задачи стоят перед аналитиками ИБ при реагировании на киберинциденты, если у них пока нет SOAR-систем. Итак, к примеру, при поступлении информации о возможной фишинговой атаке аналитикам потребуется сначала выделить из email-заголовка имя и адрес сервера, отправившего подозрительное сообщение, чтобы проверить их в системах Threat Intelligence на соответствие известным индикаторам компрометации. Затем из «тела» письма нужно будет извлечь все URL-ссылки и вложения и проверить их в системах анализа вредоносных ссылок и файлов («песочницах»). Затем в случае, если предположение о вредоносности подтвердится, предстоит удалить данные сообщения из почтовых ящиков всех пользователей, а также связаться с теми сотрудниками, которые уже прочитали email для выяснения, какие действия они совершили (прочитали и проигнорировали или перешли по ссылке/открыли файл). Если кто-то перешел по ссылке или открыл вредоносный файл, то потребуется проводить уже работу по локализации и устранению инцидента - изолировать устройства невнимательных сотрудников, проводить антивирусное сканирование оперативной памяти и жесткого диска зараженного хоста, проверять потенциальные места закрепления вредоносов (автозагрузка, новые системные службы, задачи в «Планировщике задач» и т.д.), анализировать наличие подозрительных сетевых соединений с этого устройства.
Потребуется также дополнительно провести поиск угроз (Threat Hunting) в сети компании: сформировать список индикаторов компрометации данной атаки на основании уже полученных данных «песочниц» и других СЗИ, а далее - искать индикаторы компрометации рассматриваемой атаки на устройствах и в сетевом трафике. Кроме этого, рекомендуется анализировать поведение пользователей и систем в сети компании на предмет наличия аномалий, т.е. отклонений в поведении от некоего «нормального» значения, измеренного до инцидента.
Помимо описанной ручной работы, аналитику нужно руководствоваться своим опытом и экспертизой, чтобы смотреть на атаку целостно, искать возможные неучтенные вектора атаки, затронутые инцидентом активы, пытаться сопоставить полученную информацию с ранее обработанными инцидентами и увидеть причинно-следственную связь, а лучше - понять, какую тактику применяют атакующие в данном случае, и постараться предугадать дальнейшее развитие атаки. При этом аналитику, работающему над инцидентом, надо быть на связи с сотрудниками департамента ИТ (например, для получения технических подробностей), с бизнес-владельцем и ответственным за атакованный актив (например, для уточнения возможности провести активные действия - изолировать ИТ-актив от сети или даже выключить на время), с юрисконсультами (в случае, если инцидент может иметь юридические последствия для компании), а также со своими коллегами и руководителем подразделения по защите информации.
После выполнения процедур сдерживания и устранения угрозы потребуется вернуть все атакованные устройства в состояние «до атаки», например, восстановив данные из бекапа, а затем придется некоторое время внимательно следить за активностью этих хостов на случай, если вредоносное ПО оказалось «хитрым» и не было нейтрализовано нашими мерами реагирования. Все совершаемые действия нужно тщательно протоколировать, а если есть вероятность того, что было совершено уголовное киберпреступление, то следует еще и вести юридически значимый сбор доказательной базы. После завершения активной фазы обработки данного инцидента его нужно будет тщательно проанализировать, найти корневую причину (root cause) инцидента и подвести итоги - понять, что привело к успешной реализации угрозы, какие уязвимости использовал данный вирус, как нужно перенастроить меры и средства кибербезопасности, чтобы подобные инциденты не повторялись. Средства защиты нужно будет переконфигурировать, уязвимости - устранить, а халатных пользователей - отправить на повторное обучение в рамках корпоративной Awareness-программы. Затем всю полученную и проанализированную информацию нужно будет агрегировать с данными по другим инцидентам и, возможно, представить руководству компании в виде ежемесячного отчета - наглядного и понятного.
Кроме того, в случае если инцидентом были затронуты охраняемые законодательством РФ данные, такие как банковская или коммерческая тайна, персональные данные, то совместно с юристами и GR/HR-специалистами потребуется выполнить необходимые по закону и внутренним требованиям мероприятия: уведомить регулятора, пострадавших сотрудников или клиентов, отправить сведения об инциденте в ГосСОПКА/ФинЦЕРТ. Если инцидент был масштабный и о нем стало широко известно, например, из-за длительной недоступности сервиса интернет-банкинга, то совместно с PR-специалистами будет целесообразно сообщить об инциденте через каналы официальной коммуникации (на веб-сайте или на официальной странице в соцсети), обновлять информацию при поступлении новых подробностей, отвечать на вопросы пользователей и журналистов, а также, возможно, продумать схему компенсации клиентам. Не следует забывать и о простановке отметок конфиденциальности на отчетах по инцидентам - определенную чувствительную информацию будет некорректно распространять, поскольку она может составлять коммерческую или иную тайну, а некоторые опубликованные технические подробности проведенного расследования могут помочь злоумышленникам в следующий раз улучшить методику атак.
Как видим, потребуется совершить достаточно много действий, требующих хладнокровия и собранности, проявление которых будет осложнено сложившейся ситуацией и недостатком времени. При этом эти действия должны быть алгоритмизированы, структурированы и выполнены в соответствии с заранее созданным сценарием реагирования, который отражает принципы и логику, заложенные в политике компании по реагированию на киберинциденты. Потребуется также выполнять рутинные задачи, которые могут быть автоматизированы - сбор, обогащение и агрегацию машиночитаемых данных из ИТ/ИБ-систем, корреляцию и проверку на непротиворечивость этих данных, отсев ложноположительных срабатываний, приоритизацию инцидентов, систематизацию и визуализацию информации в виде отчетов и дашбордов, осуществлять журналирование выполняемых действий, а также взаимодействовать со средствами защиты для анализа подозрительных объектов, поиска индикаторов компрометации и непосредственного сдерживания/устранения угрозы с последующим возвращением атакованного устройства в защищенное продуктивное состояние. Для эффективного взаимодействия ИБ-команде, особенно в SOC-Центре, потребуются средства совместной работы в едином консолидированном интерфейсе, с помощью которого также и сотрудники из других департаментов, участвующих в процессе обработки киберинцидентов (юристы, HR/GR/PR-специалисты, руководители), смогут получать актуальную консолидированную информацию.
Для реализации указанных задач и предназначены решения класса SOAR - системы оркестрации, автоматизации, реагирования на инциденты информационной безопасности. Платформы SOAR сочетают в себе следующий функционал:
1. оркестрация - это объединение и централизованное управление ИТ/ИБ-системами, использующимися при обработке киберинцидентов;
2. автоматизация - подразумевает алгоритмизацию процессов обработки киберинцидентов путем реализации бизнес-логики регламентов реагирования на инциденты в плейбуках (runbook или playbook) - сценариях реагирования, которые в виде блок-схем и графических элементов позволяют выстроить четкую, структурированную логику работы аналитиков ИБ;
3. реагирование - обеспечивает сбор информации об угрозе и активное противодействие (локализацию и устранение), а также совместную работу аналитиков над киберинцидентами (кейс-менеджмент, Case Management) в виде удобной платформы коммуникации и обмена информацией.
Дополнительно в решения класса SOAR могут быть включены модули Threat Intelligence (управление данными киберразведки), управления конфигурациями (Configuration Management), обновлениями (Patch Management) и уязвимостями (Vulnerability Management) программного обеспечения, а также модули аналитики и визуализации информации (дашборды, отчеты, метрики), а также функционал искусственного интеллекта, машинного обучения и анализа Big Data.
Рассмотрим подробнее каждый из функциональных блоков SOAR-решения.
Оркестрация в SOAR-системах реализуется в виде интеграции с ИТ/ИБ-системами либо с помощью взаимодействия через API, либо с помощью механизмов и протоколов получения/отправки данных, которые поддерживаются системами (Syslog, MS RPC, snmp и т.д.). API-вариант взаимодействия SOAR-систем является предпочтительным, поскольку позволяет реализовать двухстороннее взаимодействие, что означает синхронизацию данных о событиях и инцидентах ИБ в SOAR-системе и подключенном решении. Входящую информацию в SOAR-решения может подавать любая ИТ/ИБ-система, но чаще всего данные приходят от SIEM-систем. Здесь также отметим, что часто встречается мнение, что XDR-системы (XDR - Extended Detection and Response, платформа расширенного обнаружения и реагирования на киберинциденты) являются более продвинутыми вариантами SOAR-платформ и обладают расширенным функционалом. Отчасти это верно, однако не следует забывать, что XDR-решения интегрируют функционал обнаружения и реагирования на киберинциденты только в рамках единого решения одного вендора. Такой подход несет в себе определенные риски зависимости всей инфраструктуры от одного поставщика, не говоря уже о том, что такие гомогенные (однородные) системы информационной безопасности встречаются редко - в основном, компании выстраивают свои системы защиты информации на продуктах нескольких вендоров.
Автоматизация в решениях SOAR обеспечивает представление в логической машиночитаемой форме процесса реагирования на инциденты, утвержденного в компании. Такая логическая блок-схема процесса называется рабочим процессом (workflow) или сценарием реагирования (плейбук, или playbook, встречается также термин runbook), который представляет собой набор взаимосвязанных действий, осуществляющихся SOAR-системой при выполнении определенных логических условий и триггеров, задаваемых аналитиками в процессе создания и настройки плейбуков. При этом действия, описанные в плейбуке, могут включать в себя автоматические, автоматизированные и ручные задачи. Автоматические задачи выполняются SOAR-системами как правило в виде скриптов (написанных на Python, PowerShell, JavaScript), использующих в качестве параметров выполнения некоторые данные из поступившего события ИБ (например, IP-адрес устройства, на котором надо выполнить ту или иную операцию, или имя учетной записи, которую надо заблокировать). Автоматизированные задачи предполагают запуск скриптов аналитиками - в случае, если предстоит выполнить критичную операцию на важном ИТ-активе (например, временно отключить веб-сервер компании). Ручные действия подразумевают вовлечение сотрудников компании - например, им нужно согласовать определенное действие в рамках процедуры реагирования, или предоставить дополнительную информацию, или ответить на ряд вопросов для уточнения обстоятельств инцидента.
Реагирование в платформах SOAR подразумевает выполнение шагов по сбору необходимой информации об угрозе, с последующей локализацией и устранением угрозы, а также возвращение атакованных систем в безопасное состояние. Данный функционал реализуется через интегрированные системы и средства защиты информации, сетевое оборудование, ИТ-системы. SOAR-система может, например, подать управляющую команду на межсетевой экран для блокирования IP-адреса атакующего или на средство защиты конечных точек (EDR, Endpoint Detection and Response) для остановки подозрительного процесса. Также в SOAR-платформах реализован функционал совместной работы над инцидентами в модуле кейс-менеджмента (Case Management), который позволяет создавать заявки (кейсы) для каждого инцидента, хранить в карточке инцидента дополнительные данные, собранные автоматически или вручную, а также назначать задачи для выполнения, хранить историю обработки инцидентов, оставлять комментарии и вести переписку.
В SOAR-решении может быть реализована концепция ChatOps - совместное обсуждение и управление инцидентом через мессенджеры или чаты, с отправкой команд реагирования непосредственно через интерфейс программы (например, Teams, Telegram или Slack). Такой подход позволяет командам реагирования быть на связи буквально 24/7, что также повышает скорость реагирования на инциденты.
Модуль Threat Intelligence позволяет SOAR-решению получать дополнительную информацию об индикаторах компрометации и артефактах в целях обогащения данных по инцидентам, а также поиска ранее необнаруженных угроз внутри сети компании. Модули управления конфигурацией, уязвимостями и обновлениями позволяют не допустить повторения инцидента путем установки необходимых обновлений и перенастройки имеющихся систем. Механизмы искусственного интеллекта, машинного обучения и анализа Big Data помогают реализовать концепцию предиктивного реагирования на инциденты: спрогнозировать дальнейшее развитие атаки, показать тренды, порекомендовать самый подходящий сценарий для реагирования и даже назначить на инцидент аналитика, наиболее успешно решавшего аналогичные кейсы в прошлом.
Итак, с технической точки зрения мы описали SOAR-платформы как системы автоматизации действий по реагированию на киберинциденты, позволяющие существенно упростить решение задач аналитикам и снять с них рутинную нагрузку, что позволит высвободить их ценное время на более творческие задачи, а значит и уменьшить вероятность «профессионального выгорания» и текучки кадров, как следствие. С точки зрения метрик информационной безопасности, польза от внедрения SOAR-решений заключается в снижении показателей MTTD (Mean Time To Detect, среднее время обнаружения инцидента) и MTTR (Mean Time To Respond, среднее время реагирования на инцидент). Снижение данных показателей означает более быстрое обнаружение инцидента и реагирование на него, следствием чего является существенное уменьшение прогнозируемого ущерба от кибератак. С точки зрения бизнеса, SOAR-системы могут достаточно точно продемонстрировать хороший показатель ROI (Return On Investment, возврат инвестиций) путем подсчета сэкономленных за счет автоматизации человеко-часов аналитиков, а также за счет демонстрации снижения показателей MTTD и MTTR и, как следствие, уменьшения расчетного ущерба от реализации киберугрозы, избегания штрафных санкций со стороны регулятора, выполнения временных нормативов реагирования на киберинциденты (например, в случае защиты критической информационной инфраструктуры).
