Как обнаружить TPA?

15.06.2018 | Ровнов Павел
Want create site? Find Free WordPress Themes and plugins.

Как-то недавно мы общались с одной организацией по вопросам ввода в действие системы SIEM. У данной организации уже были применены различные сервисы такие, как межсетевой экран, IPS, Antivirus, Antispam, Web Application Firewall, и задача системы SIEM состояла в том, чтобы с использованием имеющихся сенсоров обнаружить атаку, которая может носить целенаправленный характер (Targeted Persistent Attack, TPA). Забегая вперед, отмечу, что сложность данной задачи состоит в том, что отдельные сенсоры могут быть не в состоянии обнаружить данную атаку. Справится ли данный набор сенсоров и система SIEM с поставленной задачей, с какими проблемами придётся столкнуться, и как можно было бы усилить решение, читайте в данной статье.

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

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

Проблема 1: Сенсоры
Система защиты информации организации, как правило, состоит из двух эшелонов средств защиты: на периметре сети и на хосте (рабочей станции или сервере). При этом примечательно то, что акцент средств защиты выполнен на противодействии атакам, но никак не на детектировании следов или следующих за проникновением в КСПД шагов. Акцентируя внимание заказчиков на том, что, вероятно, меры противодействия стоит усилить мерами детектирования прошедших атак, я всегда получаю один вопрос: на каком основании стоит допускать, что противодействие оказалось неуспешным?

Ответ на данный вопрос – в принципах противодействия: проверки на периметре, выполняемые на лету, используют преимущественно сигнатуры, для которых, с моей точки зрения, на первом месте находится быстродействие (задача: минимизировать вносимую в передачу данных задержку), а не точность. По тому же сигнатурному принципу действуют проверки на хосте (т. к. быстродействие также в приоритете), хотя, возможно, применяется и наблюдение за поведением программ при их исполнении.

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

Таким образом, вполне можно допустить, что отдельные средства защиты информации пропустят атаку. И если предположить, что атака прошла, как имеющиеся средства защиты смогут её обнаружить? Ответ, скорее всего, никак: средства защиты информации, заточенные на противодействие атаке, как правило, оказываются в «отыгранном положении».
Другой частью проблемы сенсоров является то, что сигналы, источником которых могут быть не средства защиты информации, а, например, операционные системы, как правило, или не собираются, или не воспринимаются как инциденты информационной безопасности (пример: событие запуска скрипта PowerShell на сервере – один из инструментов атаки).

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

Проблема 2: SIEM
В представлении многих организаций SIEM является «мозгом» системы защиты информации. Однако на практике оказывается, правила обработки сообщений о событиях (правила корреляции), на основе которых работает «мозг», не в состоянии обнаружить атаку. И вот почему. В дальнейших рассуждениям допустим, что в SIEM поступают сообщения от операционных систем, прикладного ПО, сетевых сервисов (например, ААА), которые содержат «следы» действий злоумышленника. Средства защиты информации хоть и настроены для отправки сообщений в SIEM в силу Проблемы 1 не обнаруживают атаку и не сообщают о ней.

Правила анализа сообщений, которые идут в поставке с системой SIEM, по моему опыту, сообщают не более чем об отдельных инцидентах, но не о ходе атаки в целом. Инциденты как, например, «Пользователь ввёл неверные учётные данные 5 раз. Учётная запись заблокирована» имеют нулевую практическую ценность, поскольку вряд ли соответствуют поведению злоумышленника, который хотел бы остаться незамеченным.

Другие правила, которые разрабатываются и «затачиваются» аналитиком в применении к задачам организации, возможно, и позволяют детектировать атаку, но имеют другой изъян. Аналитик фактически должен быть хакером: понимать, какой вектор выберет злоумышленник, какие механизмы будет использовать атака и в каких точках атаку можно будет обнаружить. На практике это приводит к тому, что удаётся разработать десяток правил для десятка специфичных атак, оставляя за скобками другие атаки. При этом уже написанные правила также требуют значительных усилий по поддержанию их в а актуальном состоянии: для избавления правила от ложных срабатываний как-то раз нам пришлось добавить порядка 50 исключений.

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

Вариант 1. Добавить сенсоры
Первая идея заключается в том, что в КСПД размещаются дополнительные сенсоры – сервисы-ловушки honey pot. Принцип honey pot в следующем: о существовании сервиса не знают пользователи сети, за счёт чего любое обращение к данному сервису является сильным индикатором атаки, который однозначно свидетельствует, что злоумышленник уже в КСПД.

Вторая идея заключается в добавлении сенсоров с принципиально другой задачей – детектирование атаки, а не противодействие ей, заменяя сигнатуры с выявлением в трафике аномалий, соответствующих атаке. Для примера, рассмотрим взаимодействие заражённого хоста с сервером C&C. Для известных сетей botnet такое взаимодействие могло бы быть выявлено по рейтингу IP адреса сервера (по сигнатурам), но если рейтинг сервера неизвестен, подход не работает. Однако если для соединений проанализировать частоту запросов, размер пакетов от хоста к серверу и в обратном направлении, длительность сессий, то оказывается, что данной информации может быть достаточно для классификации соединения как C&C и без сигнатур.

Вариант 2. Добавить другие способы анализа информации
Один из подходов состоит в замене механизмов анализа сообщений о событиях: статических правил (правил корреляции) на моделирование поведения пользователей, хостов и отслеживании отклонений от нормального поведения. При моделировании поведения учитываются не только сообщения средств защиты информации, но и любые другие события, как, например, события операционных систем, программного обеспечения, сетевых сервисов, анализ которых важен как раз для понимания атаки, которая развивается внутри периметра КСПД.

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

Другой подход заключается в использовании для анализа сообщений алгоритмов машинного обучения. В качестве примера приведу алгоритм машинного обучения, с помощью которого по лог-сообщениям шлюза в Интернет можно обнаруживать соединения Command&Control, устанавливаемые вредоносным программным обеспечением. На этапе обучения алгоритму подают на вход множество лог-сообщений с маркерами «С&C» и «не-C&C», из которых алгоритм для каждого атрибута соединения, как, например, метод запроса HTTP, длина URL, определяет вероятность встретить данное значение атрибута в соединении C&C. При поступлении нового сообщения алгоритм анализирует атрибуты и способен классифицировать соединение, вычисляя вероятность того, что данное соединение – это C&C

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

Did you find apk for android? You can find new Free Android Games and apps.
Комментариев пока нет
Добавить комментарий