Случаи кибератак ежегодно учащаются, и вместе с ними возрастают масштабы негативных последствий для бизнеса. По результатам исследования глобальных тенденций информационной безопасности, проведенного PricewaterhouseCoopers, бизнесу редко удается определить источники вредоносной активности. Поэтому на первый план выходит усиление устойчивости компаний к любым кибератакам, и становится актуальной тематика автоматизации большинства процессов в области информационной безопасности — например, с помощью платформы реагирования на инциденты (IRP).
- Введение
- Какой должна быть IRP-система
- Характеристики платформы TheHive
- Интеграция и взаимодействие
- Цикл киберразведки
- Выводы
Введение
Incident Response Platform (IRP) — это класс платформ, позволяющих автоматизировать процессы управления и реагирования на компьютерные инциденты. Предпосылками внедрения IRP стали реальные проблемы: отсутствие единой системы сбора информации об инцидентах, потеря времени при их расследовании ручными способами, низкая скорость реакции инженеров мониторинга при просмотре тысяч событий безопасности (а в связи с этим — и высокий процент пропущенных происшествий), отсутствие статистики и средств аналитики.
На текущий момент рынок IRP представлен в основном коммерческими продуктами, обзор на которые можно посмотреть в этой статье. Однако стоимость платформ данного класса находится в верхней ценовой категории, поэтому мы обратили свой взор на решения с открытым кодом (open source). Рассмотрев несколько продуктов, таких как Cyphon и Fast Incident Response (FIR), мы остановили свой выбор на TheHive, которую считаем лидером среди платформ с открытым исходным кодом: на фоне прочих систем она выделяется своей простотой, удобством и функциональными возможностями. К 2019 году она имеет 13 веток на GitHub, 45 выпущенных релизов (включая малые обновления), подробные инструкции по установке, администрированию и использованию платформы, а также внушительную пользовательскую базу.
Какой должна быть IRP-система
Можно выделить следующие характеристики систем класса IRP.
Ядром платформы является процесс управления инцидентами (Incident Management). Кроме основной функциональности (работы с происшествиями на протяжении всего жизненного цикла) этот процесс должен обеспечить:
- возможность подробного отслеживания задач, включая текущий статус и выполнение временных метрик согласно SLA;
- отслеживание информационных активов, участвующих в инциденте;
- отслеживание индикаторов компрометации и других объектов, наблюдаемых в инциденте, с возможностью их корреляции между кейсами;
- создание отчетов по KPI и другим критическим показателям.
Также каждое IRP-решение должно быть достаточно гибким, чтобы поддерживать интеграцию со множеством продуктов безопасности. Крайне важно, чтобы оно позволяло легко создавать двунаправленные интеграции с теми из них, которые не поддерживаются по умолчанию. Методы, используемые для обеспечения таких типов интеграций, могут различаться, но желательно иметь в их составе языки сценариев, такие как Perl или Python, API-интерфейсы или проприетарные инструменты. Выбранный метод должен быть прост в реализации, чтобы пользователь не оказался перегруженным сложностью его использования.
Одной из ключевых особенностей IRP-платформ является возможность автоматизировать рабочие процессы, чтобы снизить нагрузку на аналитиков безопасности от повторяющихся задач. Для этого должны поддерживаться различные методы реализации рабочих процессов: линейно выполняемые сценарии реагирования на инциденты (они же — плейбуки) или управляемые ранбуки, состоящие из условных шагов для выполнения тех или иных действий и имеющие элементы принятия решений. Поскольку оба метода имеют свои плюсы и минусы, и каждый из них подходит для разных вариантов использования, решениям IRP нужно поддерживать и тот, и другой. Реализация обязательно должна быть гибкой, чтобы поддерживать практически любой процесс, который может потребоваться описать в рамках решения. Сами рабочие процессы должны давать возможность применять как встроенные, так и пользовательские интеграции, а также создавать ручные задачи, которые будет выполнять аналитик.
Рисунок 1. Схема взаимосвязей управления инцидентами в IRP-системе
Характеристики платформы TheHive
Платформа позиционируется как продукт 4-in-1 и содержит в себе:
- ядро всей системы TheHive, где проходят основные рабочие процессы по управлению инцидентами,
- специализированный поисковик Cortex, позволяющий обогащать информацию о происшествиях как из внешних анализаторов, так и из внутренних систем (например, CMDB),
- агрегатор информации об угрозах Hippocampe, собирающий индикаторы компрометации из множества открытых источников,
- API-клиент для Python TheHive4Py, предлагающий огромный набор различных функций для доработок и интеграции со смежными системами.
Нельзя не упомянуть здесь о тесном сотрудничестве и глубокому взаимодействию с системой MISP — платформой по управлению информацией об угрозах.
TheHive написан на языке Scala и на текущий момент поддерживает ElasticSearch 5 / 6 для хранения данных. Клиентская часть системы использует AngularJS с Bootstrap. Предоставленные анализаторы в Cortex пишутся на Python. По состоянию на 2019 год «из коробки» доступно более 120 различных способов изучения объектов компрометации. Дополнительные анализаторы могут быть написаны на том же языке или на любом другом, поддерживаемом Linux.
Интеграция и взаимодействие
Система проста в использовании, интерфейс «пчелки» интуитивно понятен и не приводит к путанице во время реагирования на инциденты. Плейбуки выстраиваются в стиле текстовых задач, позволяют одновременно и автоматически назначить каждую задачу на ответственного специалиста, но, к сожалению, не имеют графических диаграмм, а также путей принятия решения. В рамках единой экосистемы платформа постоянно дополняется новыми сервисами. За счет плотной интеграции с техническими средствами расследования, такими как Cortex и Hippocampe, TheHive можно применять для поиска и расследования сложных угроз.
Конечно, «из коробки» нет взаимодействия с оповещениями SIEM-систем или с электронной почтой, однако использование REST API или Python-клиента TheHive4Py делает эту задачу легко решаемой. Также в TheHive не предусмотрен модуль SLA, но уже по соображениям философии разработчиков, которые выступают за более тесное общение между командами реагирования на инциденты. Вместо него внедрены несколько функций: «замороженные» (т.е. приостановленные) кейсы, маркировка кейсов и задач, а также уведомления о моих задачах и задачах, ожидающих исполнителя. Данные недостатки нивелируются тем, что при работе с платформой нет необходимости оплачивать лицензию и продлевать ежегодную поддержку.
Цикл киберразведки
Так как же решается основная задача системы — управление компьютерными инцидентами?
На входе в систему поступают события информационной безопасности из различных источников: вашей SIEM-системы, событий IDS, сканера безопасности и т.п. Создаются кейсы посредством API TheHive4Py — как за счет интеграции с системой, так и посредством парсинга электронной почты или текстового файла из директории; также кейсы могут создаваться вручную сотрудником ИБ. Особенностью TheHive является совместная работа: несколько сотрудников могут одновременно работать над одним и тем же кейсом и отслеживать статусы его изменения благодаря The Flow, своеобразному «твиттеру», который держит всех участников процесса в курсе происходящего в режиме реального времени.
Каждый зафиксированный инцидент на платформе TheHive может маркироваться не только индикатором компрометации (IoC), но и любым другим объектом, который вы хотели бы отслеживать в рамках процесса управления инцидентами ИБ. Это могут быть как стандартные IoC в виде ссылок, IP-адресов, доменов, семплов вредоносных файлов или хэшей, так и учетные записи пользователей, имена рабочих станций, дескрипторы подсетей и так далее. Через анализ поступивших сведений поисковик Cortex обогащает данные об инциденте. Аналитики безопасности, умеющие писать сценарии, могут легко добавлять свои собственные анализаторы (и вносить их обратно в сообщество, поскольку делиться своими достижениями очень полезно) для автоматизации скучных или утомительных действий, которые должны выполняться над наблюдаемыми объектами или IoC. Разбиение в соответствии с протоколом Traffic Light Protocol (TLP) позволяет влиять на то, кому дозволено передавать полученную информацию об угрозах. Красный цвет означает запрет на распространение, желтый — доступность только для участников организации, зеленый — для сообщества, а белый цвет — доступность для всех. Например, файл, добавленный как наблюдаемый, может быть отправлен на VirusTotal, если связанный TLP — белый или зеленый. Если ему присвоен желтый цвет, вместо самого файла вычисляется и передается на сканирование только его хэш. Если TLP — красный, то поиск по VirusTotal не выполняется. В связке с платформой киберразведки MISP платформа способна реализовать гибкий механизм реагирования на инциденты ИБ с возможностью создавать кейсы из событий MISP.
Рисунок 2. Рабочий процесс TheHive
Возьмем наглядный пример. Некий сценарий мониторинга обнаруживает на рабочей станции подозрительный файл; при срабатывании правила корреляции в SIEM-системе инцидент автоматически регистрируется в TheHive согласно шаблону реагирования на данный тип инцидента. Из этого же шаблона формируются задачи (Tasks), такие как «Получить образец вредоносного файла», «Изолировать рабочую станцию от сети», «Проверить рабочую почту сотрудника» и так далее.
Рисунок 3. Работа с задачами в TheHive
Разными задачами исполнители занимаются одновременно: пока сотрудник отдела IT изолирует и проверяет систему, аналитик ИБ с помощью возможностей Cortex определяет количество антивирусов, обнаруживших файл на VirusTotal, через сервисы киберразведки наподобие IBM XForce или AlienVault OTX узнаёт, в какой вредоносной кампании участвовал этот файл, получает известные YARA-правила для поиска дополнительных артефактов файла. Одновременно с этим образец отправляется как в облачные, так и в локальные песочницы — например, Cuckoo Sandbox. Все перечисленные действия запускаются нажатием всего на одну кнопку.
Рисунок 4. Данные о домене, связанном со вредоносной активностью, в интерфейсе TheHive
Данные закрытых подтвержденных инцидентов попадают в MISP, после чего рекомендации по реагированию автоматически отправляются в почтовой рассылке ответственным лицам. Помимо прочего, в связке с системами оркестрации существует возможность активной блокировки обнаруженных паттернов вредоносной кампании: IP-адреса командного центра злоумышленника — в межсетевом экране, хэшей файлов — в системах антивирусной защиты, постановки на мониторинг вновь выявленных индикаторов компрометации — в SIEM-системах. Кроме того, TheHive автоматически идентифицирует объекты, которые уже были замечены в предыдущих проверках через систему MISP.
Встроенные в платформу TheHive механизмы метрик анализируют работу групп мониторинга и реагирования на инциденты по назначенным для этого процесса критериям эффективности (KPI).
Рисунок 5. Схема взаимодействия TheHiveс другими решениями
Для использования TheHive вы можете:
- запустить его из docker,
- запустить его из двоичных файлов,
- создать его из источника и затем запустить.
Как уже отмечалось, TheHive применяет ElasticSearch для хранения данных. Обе программы используют виртуальную машину Java. Мы рекомендуем виртуальную машину с 8vCPU, 8 GB RAM оперативной памяти и 60 GB свободного места на жестком диске. Вы также можете использовать физическую машину с такими же характеристиками.
Рисунок 6. Структурная схема компонентов TheHive
Выводы
TheHive — весьма простая как в установке, так и в использовании IRP-платформа с функциональными возможностями, которые достаточны для выполнения базовых задач управления инцидентами. Она не имеет «из коробки» всесторонних, уникальных модулей вроде управления активами или уязвимостями, однако система достаточно гибка для интеграции с продуктами, способными решать такие задачи. TheHive постоянно развивается, разработчики не просто получают обратную связь, но и ведут активный диалог со своими пользователями и прислушиваются к их запросам. В рамках анализа инцидентов продукт имеет под собой мощную основу в виде Cortex, позволяющую оперативным центрам безопасности (SOC) или даже отдельным специалистам заниматься расследованием кейсов и не беспокоиться о том, как ими управлять.
