30 Января 2025 14:56 30 Янв 2025 14:56 |

Поделиться

Меры ИБ-реагирования: что делать, если вашу компанию всё-таки взломали

Предупредить или отреагировать

В современных реалиях агрессивной киберсреды и непрерывно усложняющегося ландшафта угроз большинство организаций уделяют кибербезопасности повышенное внимание, однако даже самые крупные и хорошо защищенные компании, выделяющие на ИБ существенные ресурсы, становятся жертвами успешных кибератак. Причины заключаются в наличии объективных факторов, которые могут свести на нет все усилия по защите: человеческая ошибка в результате тщательно спланированного фишинга, использование атакующими 0-Day уязвимостей на периметре компании, атака на цепочку поставок или на доверенные отношения с контрагентами, подкуп сотрудников или даже физическое проникновение в здание. Киберзащитникам нужно выстроить целостную систему обороны, а злоумышленникам достаточно найти в ней всего лишь одну брешь для первичного проникновения.

Разумеется, следует уделять должное внимание превентивным мерам, поскольку инцидент проще не допустить и купировать на самых ранних стадиях. Однако никто не может гарантировать, что атакующие не пробьют защиту и не окажутся внутри периметра. На возникший киберинцидент необходимо будет оперативно и эффективно отреагировать для того, чтобы минимизировать ущерб, остановить атакующих и удалить их из инфраструктуры компании, а также устранить использованные ими уязвимости и улучшить СУИБ для недопущения повторных инцидентов. Сегодня ключевой задачей большинства ИБ-команд становится построение эффективных процессов управления киберинцидентами, о чем мы и поговорим в этой статье.

Управление киберинцидентами

Говоря о реагировании на киберинциденты, важно прежде всего помнить о необходимости выстраивания процесса управления инцидентами, который, помимо непосредственного реагирования, включает и подготовку к отражению кибератак, и пост-инцидентный анализ выученных уроков. Для более целостного понимания лучше сразу же заручиться поддержкой подходящего стандарта или фреймворка по киберинцидентами, например:

• Серия российских стандартов ГОСТ Р 59709-59712 («Защита информации. Управление компьютерными инцидентами») 2022 года.
• Серия международных стандартов ISO/IEC 27035 (Information technology — Information security incident management).
• Специальная публикация NIST SP 800-61 Computer Security Incident Handling Guide.
• Публикация института SANS Incident Handler's Handbook.
• Публикация MITRE 11 Strategies of a World-Class Cybersecurity Operations Center.

Эти документы объединяет ряд идей, которые мы подробнее рассмотрим ниже:

• Управление киберинцидентами — это процесс со всеми соответствующими свойствами и особенностями.
• Для результативного реагирования должны быть подготовлены и протестированы сценарии реагирования, инструменты, персонал.
• Процесс управления инцидентами ИБ может включать в себя следующие взаимосвязанные этапы: подготовка, обнаружение, анализ, сдерживание, устранение, восстановление, пост-инцидентные действия.
• Важнейшими этапами являются подготовка, в рамках которой повышается уровень знаний об инфраструктуре, и пост-инцидентные действия, в рамках которых анализируются использованные злоумышленниками недостатки и выполненные командой реагирования действия.
• Результатами реализации процесса должны стать повышение киберзащищенности компании и рост уровня зрелости СУИБ.

Процессный подход

Процессный подход в ИБ подразумевает непрерывное выполнение задач по минимизации киберрисков в целях удовлетворения потребностей стейкхолдеров компании. Для управления процессом реагирования на киберинциденты может быть применен классический цикл Деминга (планирование — выполнение — оценка — корректировка), а сам процесс нужно описать в корпоративной политике управления инцидентами ИБ и дополнительно формализовать в нотациях IDEF0 или BPMN.

В рамках каждого из этапов процесса реагирования требуются определенные входные данные и инструкции, по которым специалисты с помощью инструментов выполняют последовательность действий с объектами (активами) для получения ожидаемых результатов. Основными задачами процесса инцидент-менеджмента в зависимости от этапа должны быть своевременное выявление кибератаки, быстрое принятие обоснованных и оптимальных решений по вариантам реагирования, эффективная локализация и устранение угрозы, а если инцидент всё же привёл к негативным последствиям — максимально быстрое восстановление инфраструктуры и бизнес-процессов до рабочего состояния.

Управление киберинцидентами не должно представлять собой набор ситуативных хаотичных действий в ответ на кибератаку, также как не должно и деградировать до функции без конечной цели защитить интересы компании. Процесс управления инцидентами ИБ должен быть органично встроен в СУИБ компании и гармонизирован с другими корпоративными процессами, прежде всего процессами ИБ, такими как управление активами, доступами, уязвимостями, конфигурациями, изменениями, рисками, непрерывностью бизнеса, нормативными требованиями.

Управлением инцидентами нельзя заниматься только тогда, когда выявлена кибератака или стали очевидны её последствия — это не только не принесет желаемого результата, но и даст ложное чувство готовности к инцидентам только по причине наличия давно устаревшей инструкции по реагированию. Если собственных ресурсов для построения всеобъемлющего процесса управления инцидентами не хватает, то можно рассмотреть услуги коммерческих SOC-центров или MSS-провайдеров.

Сценарии реагирования

Политика управления инцидентами ИБ, описывающая соответствующий процесс — это высокоуровневый документ, в котором могут содержаться отсылки к сценариям реагирования на киберинциденты. Сценарий реагирования (playbook, плейбук) представляет собой подробный технический документ, содержащий порядок действий и используемых инструментов для обработки определенного типа инцидента ИБ — например, порядок действий и список используемых инструментов будет различным для DDoS-атаки, фишинга или вирусного заражения.

Однако, в ограниченном наборе разрабатываемых сценариев сложно предусмотреть все возможные случаи и вариации инцидентов. Кроме того, возможны и переходы между некоторыми сценариями — например, в случае, если в процессе анализа выяснилось, что подозрительное поведение пользователя и потенциальная утечка данных вызваны не компрометацией учетной записи внешними атакующими, а действиями сотрудника-инсайдера. Поэтому целесообразно разрабатывать атомизированные мини-сценарии, которые описывают отдельные наборы действий, которые можно повторно использовать в различных типах инцидентов и в разных условиях — например, в зависимости от количества скомпрометированных активов и их критичности.

Эти мини-сценарии могут описывать, например, процедуры сборы обогащающей информации об активах, затронутых инцидентом, и содержать детальные инструкции со списком Windows/Linux-команд или утилит для опроса источников данных (систем CMDB и ITAM, LDAP-каталогов). Также мини-сценарии могут описывать процедуры коммуникации и эскалации инцидента в зависимости от различных параметров — например, от критичности атакованного актива, которая отображается в CMDB, или от групп, в которые входит скомпрометированный аккаунт. Комбинируя такие мини-плейбуки, можно формализовать реагирование практически на любой тип инцидента, даже если какой-то из них не был учтен на этапе разработки сценариев.

Разработанные сценарии следует проверить и «обкатать», смоделировав рассмотренные типы инцидентов, проверив доступность СЗИ и вспомогательных решений, проверив контактные данные всех участников, например, в рамках командно-штабных теоретических учений или практических киберучений.

Эффективные инструменты

Детальный и протестированный набор сценариев реагирования — это ключ к эффективному использованию инструментов реагирования и средств автоматизации действий ИБ-специалистов. Инструменты могут включать в себя подготовленные и доступные специалистам внутренние системы, например, HR-системы, продукты CMDB/ITAM, ИБ-решения классов IdAM, EDR/XDR, SIEM, Vulnerability Management, песочницы, TIP, UEBA. Инструментами реагирования будут также внешние аналитические интернет-сервисы, из которых можно запрашивать дополнительную информацию по внешним IP-адресам, DNS-записям, URL-ссылкам, хэшам файлов. Такими сервисами могут быть IPinfo, Geo-IP, AbuseIPDB, Whois, URLScan, Shodan, VirusTotal и другие.

Средствами комплексной автоматизации работы членов команды реагирования будут системы классов XDR или IRP/SOAR. Решения XDR функционируют в определенной вендорской экосистеме и заточены под бесшовное эффективное взаимодействие всех установленных СЗИ от данного производителя (например, EDR, SIEM, песочница), а решения IRP/SOAR — вендоронезависимы и подойдут для тех инфраструктур, где совместно работают старые импортные и новые отечественные ИТ/ИБ-системы.

Важно, чтобы используемые инструменты были удобны в использовании и, по возможности, требовали минимальных временных затрат на переключение между консолями — например, SOAR-платформы позволяют управлять (оркестрировать) всеми интегрированными системами в едином интерфейсе, а добавление новых интеграций может быть упрощено за счет технологий low-code/no-code. Кроме взаимной бесшовной интеграции важно, чтобы СЗИ для реагирования могли «общаться» в едином контексте — например, за счет использования матрицы MITRE ATT&CK для описания обнаруживаемых тактик, техник и инструментов атакующих. Наш продукт Security Vision SOAR позволяет группировать инциденты в цепочки атак (Kill Chain), показывает маршрут злоумышленника на интерактивном графе, поддерживает технологию динамических плейбуков для выбора оптимальный действий по реагированию, использует подход low-code/no-code для настройки новых интеграций и сценариев реагирования, отображает тепловые карты для наборов экспертизы MITRE ATT&CK и БДУ ФСТЭК, а также формирует экспертные рекомендации по управлению инцидентами для ИБ-специалистов.

Необходимые специалисты

Специалисты — это ключевой компонент процесса управления киберинцидентами, неважно, это L1/L2-аналитик в SOC-центре, дежурный ИБ-специалист в технической поддержке или выделенный сотрудник отдела ИБ. Специалисты по кибербезопасности должны понимать все части процесса управления инцидентами ИБ, знать порядок выполнения действий в плейбуках, владеть навыками работы с настроенными инструментами для реагирования, а также уметь работать в команде и с пользователями.

Существующий дефицит сотрудников компании стараются компенсировать средствами автоматизации, которые снижают рутинную нагрузку на специалистов, уменьшают влияние человеческого фактора и число случайных ошибок, а также повышают лояльность и мотивированность работников — им становится интересно автоматизировать хотя бы часть монотонных действий и уделить больше времени развитию своих профессиональных навыков. Кроме того, одной из форм мотивации для персонала является профессиональное обучение — идеальным вариантом будет полноценный учебный курс по использующемуся в организации защитному решению. Например, в нашем учебном центре Security Vision мы проводим комплексное обучение работе с продуктами Security Vision и для заказчиков, и для наших партнеров (интеграторы, MSSP, коммерческие SOC).

Этапы процесса управления инцидентами ИБ

На каждом из этапов (подготовка, обнаружение, анализ, сдерживание, устранение, восстановление, пост-инцидентные действия) следует выполнять набор действий, который позволит:

• Минимизировать ущерб от кибератаки.
• Быстро восстановить работоспособность инфраструктуры.
• Не допустить повторения подобных атак в будущем.

Выполнение действий на каждом из этапов лучше максимально автоматизировать для ускорения и во избежание человеческих ошибок, а также иметь ввиду, что процесс реагирования может быть нелинейным, и в нём могут быть возвраты с более поздних этапов на более ранние.

Минимизация ущерба

Минимизация ущерба достигается за счет оперативного обнаружения инцидента, быстрого анализа, выявления всех скомпрометированных активов, локализации инцидента.

Выявление инцидента — это не только обработка актуальных предупреждений из SIEM или иных СЗИ. Не следует забывать и про ретро-поиск индикаторов компрометации в сохраненной истории событий ИБ, и про обработку тактических данных киберразведки (например, индикаторы самых последних атак еще могли не найти своё отражение в корреляционных правилах или сигнатурах СЗИ), и про получение сигналов от внешних контрагентов о подозрительной активности, которая исходит из сети компании. На более высоких уровнях зрелости выявлению инцидентов помогут дополнительные активности, такие как Compromise Assessment и Threat Hunting.

Для того, чтобы во время инцидента не тратить время на сбор информации о свойствах атакованного актива, поиск контактов ответственных лиц и просмотр Whois-записей, рекомендуется всю необходимую обогащающую информацию подгружать автоматически из различных источников в карточку инцидента. Предварительно собранная, структурированная и наглядно отображаемая информация о свойствах сущностей, участвующих в инциденте, поможет ускорить его анализ.

Чтобы эффективно противодействовать киберугрозе, важно понимать, каков скоуп киберинцидента: какие устройства и учетные записи были скомпрометированы, куда могли переместиться атакующие, где могли оставить бэкдоры для удаленного управления и быстрого возвращения. Скоуп может измениться и на дальнейших шагах — например, в процессе сдерживания, устранения или детального форензик-анализа может выясниться, что для ВПО характерны дополнительные индикаторы компрометации, которые будут найдены на ряде устройств, которые ранее считались чистыми. Чем раньше будут выявлены все атакованные активы, тем более эффективным будет и весь процесс реагирования.

Также в сценариях реагирования следует предусмотреть возможные действия по максимально оперативному сдерживанию (локализации) инцидента — например, за счет сетевой изоляции устройства, перемещения его в карантинный VLAN, отключения учетной записи, блокирования сетевых взаимодействий с подозрительными IP-адресами. Кроме того, нужно учесть, что в зависимости от типа ВПО и метода управления злоумышленников им (ручное или автоматизированное), ответной реакцией на меры активного противодействия может быть, например, удаление всей информации на зараженном устройстве в целях заметания следов или для достижения минимально возможной цели атаки («если не удалось скрытно пошпионить и нас заметили, то хотя бы навредим»).

Дальнейшее устранение угрозы может подразумевать восстановление данных из бэкапа, «перезаливку» устройств или точечные ручные действия (удаление вредоносного файла, завершение процесса, остановка и удаление сервиса). Однако именно на этапе устранения могут быть утеряны важные артефакты или улики, которые могут затем пригодиться при форензик-анализе или при обращении в правоохранительные органы. Поэтому в сценариях реагирования важно предусмотреть опции надежного сбора юридически значимых данных на более ранних этапах.

Восстановление работоспособности

Восстановление работоспособности инфраструктуры целесообразно выполнять, когда есть уверенность в том, что атакующие полностью удалены из инфраструктуры, а уязвимости и недостатки защиты, которые были использованы злоумышленниками для первичного проникновения в сеть, пропатчены и устранены.

На этапе восстановления нужно помнить, что некоторые атакующие так долго и незаметно присутствуют в инфраструктурах, что их бэкдоры попадают в долговременные бэкапы и затем восстанавливаются на чистых системах уже после того, как инцидент считается закрытым. Кроме того, некоторые атакующие нарушают процесс создания резервных копий (например, на ленты записываются зашифрованные вирусом данные), поэтому нужно быть готовым к возврату на более старые архивные копии.

Не следует забывать и про необходимость хранения минимум одного бэкапа на отчуждаемых носителях (на лентах, например), поскольку при кибердиверсиях атакующие удаляют в том числе и все резервные копии, которые доступны из инфраструктуры, включая NAS-хранилища и облачные бэкапы.

Недопущение подобных атак в будущем

Логичным результатом процесса управления киберинцидентами должно быть не только реактивное реагирования на возникший инцидент, но и корректировка превентивных мер защиты. Любой обработанный киберинцидент должен изучаться с точки зрения того, почему он произошёл, какие уязвимости использовались, какие превентивные защитные решения не отработали.

Можно также мысленно немного изменить свойства обработанного инцидента и продумать, был бы выявлен сходный инцидент, как бы сработали защитные механизмы, какие вредоносные действия могли бы выполнить злоумышленники. Подобный анализ лучше выполнить спустя непродолжительное время после инцидента, когда в памяти ещё свежи подробности, а злоумышленники ещё могут вернуться с немного видоизмененными инструментами и теми же техниками — такое бывает в случае атаки со стороны кибернаёмников, которые получили заказ на взлом компании, например, от конкурентов.

Важность подготовки и пост-инцидентных действий

Подготовка — это ключевой этап процесса реагирования, поскольку не только позволяет собрать всю информацию для оперативного анализа и реагирования на кибератаку, но и позволяет выявить серые зоны в настройках СЗИ и элементах инфраструктуры компании, обосновать актуализацию сетевых схем и разработку диаграмм потоков данных, сформировать централизованное хранилище достоверной и непрерывно обновляющейся информации об активах. Эти инициативы часто встречают противодействие среди различных подразделений компании, но подготовка процесса реагирования на инциденты ИБ может стать понятным обоснованием для выделения ресурсов на подобные полезные активности. Аналитики, собирающие информацию в рамках подготовки сценариев реагирования, должны отмечать явные недостатки СУИБ, которые могут быть использованы атакующими — возможно, в результате получится не отразить атаку, а не допустить её.

Пост-инцидентные действия помогают провести анализ «выученных уроков» и понять, почему атака была успешна, почему она не была предотвращена, какие особенности или слабости инфраструктуры и средств защиты были проэксплуатированы, а также оценить корректность и оперативность работы членов ИБ-команды. Результаты анализа важно использовать для улучшения процесса реагирования — возможно, стоит пересмотреть плейбуки, перенастроить СЗИ, скорректировать смежные процессы ИБ.

Во время реагирования часто нет времени на протоколирование выполняемых действий, поэтому важно использовать средства автоматизации, такие как SOAR-платформы — в них сохранится timeline инцидента и история действий специалистов. Использование SOAR поможет также оценить некоторые количественные показатели эффективности реагирования — например, MTTD (Mean Time To Detect, среднее время обнаружения инцидента) и MTTR (Mean Time To Respond, среднее время реагирования на инцидент).

Стратегические цели: повышение киберзащищенности компании и рост уровня зрелости СУИБ

Если киберинцидент был своевременно выявлен и устранен, то это, без сомнения, хороший результат. Но, как уже было подчеркнуто, инцидент лучше не допустить, чем ликвидировать его последствия, пусть даже и незначительные. Поэтому глобальными целями процесса управления инцидентами ИБ будут рост уровня кибербезопасности компании и повышение зрелости её СУИБ.

Этапы подготовки и пост-инцидентного анализа должны быть направлены на упорядочивание имеющейся информации о защищаемой инфраструктуре, активах, бизнес-процессах, пользователях, ландшафте киберугроз, риск-профиле компании, а также на совершенствование используемых защитных мер. В случае, если имеющихся сил и средств недостаточно для противодействия актуальным киберугрозам и нарушителям с широкими возможностями, то подобная оценка уровня готовности к отражению сложных кибератак может быть обоснованием для корректировки бизнес-процессов, внедрения новых мер защиты и расширения штата ИБ-подразделения.

Защитные меры и решения, которые минимизировали киберриски в небольшой компании, не будут эффективны при росте компании, формировании дополнительных бизнес-направлений, создании новых продуктов и услуг. При этом, вместе с ростом уровня цифровизации и степени зависимости компании от надежности и безопасности работы информационной инфраструктуры, должен повышаться и уровень зрелости СУИБ.

Результаты анализа произошедших киберинцидентов могут красноречиво свидетельствовать о том, что более высокий уровень автоматизации действий по реагированию помог бы существенно минимизировать ущерб. Высокая степень автоматизации процессов ИБ, включая управление киберинцидентами, может быть достигнута на уровнях «Регламентированный», «Количественно управляемый» и «Улучшающийся» (по модели оценки зрелости процессов CMMI).

Постепенный переход от автоматизации отдельных действий по сбору информации и мониторингу событий ИБ к автоматизированному или даже автоматическому реагированию на киберинциденты будет возможен по мере роста уровня зрелости всей СУИБ. В результате, со временем к базовым защитным решениям (антивирусам, межсетевым экранам, системам обнаружения вторжений) добавятся решения для управления активами, уязвимостями и конфигурациями, решения класса SIEM, EDR/XDR, песочницы, а затем TIP, UEBA, SGRC.

Мы в Security Vision предлагаем решения для компаний, отличающихся и по размеру, и по уровню зрелости СУИБ: от продуктов для управления активами (Security Vision AM) и уязвимостями (Security Vision VM) до системы автоматизации выявления и реагирования на киберинциденты (Security Vision SOAR, SecurityVision NG SOAR с функцией SIEM), платформы управления данными киберразведки (Security Vision TIP), решения для обнаружения аномалий и скрытых угроз (Security Vision UEBA).

Поделиться

Подписаться на новости Короткая ссылка