StealthWatch: анализ и расследование инцидентов. Часть 3

Cisco StealthWatch — это аналитическое решение в области ИБ, которое обеспечивает всесторонний мониторинг угроз в распределенной сети. В основе работы StealthWatch лежит сбор NetFlow и IPFIX с маршрутизаторов, коммутаторов и других сетевых устройств. В результате сеть становится чувствительным сенсором и позволяет администратору заглянуть туда, куда не могут добраться традиционные методы защиты сети, например, Next Generation Firewall.

В прошлых статьях я уже писал о StealthWatch: первое представление и возможности, а также развертывание и настройка. Сейчас предлагаю двигаться дальше и обсудить, как следует работать с алармами и расследовать инциденты безопасности, которые генерирует решение. Будет приведено 6 примеров, которые, я надеюсь, дадут хорошее представление о полезности продукта.

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

1. Анализ самых объемных взаимодействий внутри сети

Первоначальным шагом настройки StealthWatch является определение хостов и сетей по группам. В веб-интерфейсе вкладка Configure > Host Group Management следует разнести сети, хосты, сервера по соответствующим группам. Группы можно создавать и свои. К слову, анализ взаимодействий между хостами в Cisco StealthWatch довольно удобен, так как можно не только сохранять фильтры поиска по потокам, но и сами результаты.

Для начала в веб-интерфейсе стоит зайти во вкладку Analyze > Flow Search. Затем следует установить следующие параметры:

• Search Type — Top Conversations (самые популярные взаимодействия)
• Time Range — 24 hours (промежуток времени, можно использовать другой)
• Search Name — Top Conversations Inside-Inside (любое понятное имя)
• Subject — Host Groups → Inside Hosts (источник — группа внутренних узлов)
• Connection (можно указать порты, приложения)
• Peer — Host Groups → Inside Hosts (назначение — группа внутренних узлов)
• В Advanced Options дополнительно можно указать коллектор, с которого смотрятся данные, сортировку вывода (по байтам, потокам и прочее). Я оставлю по умолчанию.

После нажатия на кнопку Search выдается список взаимодействий, которые уже отсортированы по объему переданных данных.

В моем примере хост 10.150.1.201 (сервер) в рамках только одного потока передал 1.5 Гб трафика на хост 10.150.1.200 (клиент) по протоколу mysql. Кнопка Manage Columns позволяет добавить больше столбцов в выводимые данные.

Далее на усмотрение администратора можно создать кастомное правило, которое будет срабатывать постоянно на такого рода взаимодействия и уведомлять по SNMP, email или Syslog.

2. Анализ самых медленных клиент-серверных взаимодействий внутри сети на предмет задержек

Метки SRT (Server Response Time), RTT (Round Trip Time) позволяют выяснить задержки серверов и общие задержки в сети. Данный инструмент особенно удобен, когда следует быстро найти причину жалоб пользователей на медленно работающее приложение.

Примечание: практически все Netflow экспортеры не умеют отправлять метки SRT, RTT, поэтому зачастую, чтобы видеть такие данные на FlowSensor надо настроить отправку копию трафика с сетевых устройств. FlowSensor в свою очередь отдает расширенный IPFIX на FlowCollector.

Данную аналитику удобнее проводить в java приложении StealtWatch, которая устанавливается на компьютер администратора.

Правой клавишей мыши на Inside Hosts и переходим во вкладку Flow Table.

Нажимаем на Filter и устанавливаем необходимые параметры. В качестве примера:

• Date/Time — For the last 3 days
• Performance — Average Round Trip Time >=50ms

После выведения данных следует добавить интересующие нас RTT, SRT поля. Для этого следует нажать на колонку на скриншоте и правой клавишей мыши выбрать Manage Columns. Далее прокликать RTT, SRT параметры.

После обработки запроса, я отсортировал по RTT average и увидел самые медленные взаимодействия.

Чтобы провалится в детальную информацию, следует нажать правой клавишей мыши на поток и выбрать Quick View for Flow.

Данная информация говорит о том, что хост 10.201.3.59 из группы Sales and Marketing по протоколу NFS обращается к DNS серверу на протяжении минуты и 23 секунд и имеет просто ужасную задержку. Во вкладке Interfaces можно узнать, с какого Netflow экспортера данных информация получена. Во вкладке Table изображена более подробная информация о взаимодействии.

Далее следует узнать, какие устройства шлют трафик на FlowSensor и проблема скорее всего кроется там.

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

3. Аудит криптографических протоколов HTTPS

ETA (Encrypted Traffic Analytics) — технология, разработанная Cisco, позволяющая обнаруживать зловредные подключения в зашифрованном трафике без его расшифровки. Более того, данная технология позволяет “разбирать” HTTPS на версии TLS и криптографические протоколы, которые используются при соединениях. Данный функционал является особенно полезным, когда нужно обнаружить сетевые узлы, которые используют слабые криптостандарты.

Примечание: предварительно следует установить network app на StealthWatch — ETA Cryptographic Audit.

Переходим во вкладку Dashboards → ETA Cryptographic Audit и выбираем группу хостов, которую планируется проанализировать. Для общей картины выберем Inside Hosts.

Можно наблюдать, что выводятся версия TLS и соответствующий криптостандарт. По привычной схеме в колонке Actions переходим во View Flows и запускается поиск в новой вкладке.

Из вывода видно, что хост 198.19.20.136 на протяжении 12 часов использовал HTTPS с TLS 1.2, где алгоритм шифрования AES-256 и хэш-функция SHA-384. Таким образом, ЕТА позволяет найти слабые алгоритмы в сети.

4. Анализ аномалий в сети

Cisco StealthWatch умеет распознавать аномалии трафика в сети, используя в три инструмента: Core Events (события безопасности), Relationship Events (события взаимодействий между сегментами, узлами сети) и поведенческий анализ.

Поведенческий анализ, в свою очередь, позволяет со временем строить модель поведения для того или иного хоста или группы хостов. Чем больше трафика проходит через StealthWatch, тем более точные будут срабатывания благодаря этому анализу. Поначалу система много неверно триггерит, поэтому правила следует “подкручивать” руками. Рекомендую первые несколько недель не обращать внимания на такие события, так как система сама подстроится, либо же добавлять в исключения.

Ниже приведен пример предустановленного правила Anomaly, в котором говорится, что событие сработает без аларма, если хост в группе Inside Hosts взаимодействует с группой Inside Hosts и за 24 часа трафик превысит 10 мегабайт.

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

Выводится событие, говорящее о том, что обнаружено 162к “очков”, а по политике разрешено 100к “очков” — это внутренние метрики StealthWatch. В колонке Actions нажимаем View Flows.

Мы можем наблюдать, что данный хост ночью взаимодействовал с хостом 10.201.3.47 из отдела Sales & Marketing по протоколу HTTPS и скачал 1.4 Гб. Может быть данный пример является не совсем удачным, но детектирование взаимодействий и на несколько сотен гигабайт осуществляется точно таким же образом. Следовательно, дальнейшее расследование аномалий может привести к интересным результатам.

Примечание: в веб-интерфейсе SMC данные во вкладках Dashboards выводятся только за последнюю неделю и во вкладке Monitor за последние 2 недели. Чтобы проанализировать события более старой давности и для генерации отчетов нужно работать с java консолью на компьютере администратора.

5. Нахождение внутренних сканирований сети

Теперь рассмотрим несколько примеров фидов — инцидентов ИБ. Этот функционал интересен больше безопасникам.

Предустановленных типов событий сканирования в StealthWatch несколько:

• Port Scan — источник сканирует множество портов узла назначения.
• Addr tcp scan — источник сканирует целую сеть по одному и тому же TCP порту, меняя при этом IP адрес назначения. При этом источник получает TCP Reset пакеты или не получает ответов вовсе.
• Addr udp scan — источник сканирует целую сеть по одному и тому же UDP порту, меняя при этом IP адрес назначения. При этом источник получает ICMP Port Unreachable пакеты или не получает ответов вовсе.
• Ping Scan — источник посылает ICMP запросы на целую сеть с целью поиска ответов.
• Stealth Scan tсp/udp — источник использовал один и тот же свой порт для подключения к множеству портов на узле назначения в одно и то же время.

Для более удобного нахождения сразу всех внутренних сканеров существует network app для StealthWatch — Visibility Assessment. Перейдя во вкладку Dashboards → Visibility Assessment → Internal Network Scanners вы увидите инциденты безопасности, относящиеся к сканированию, за последние 2 недели.

Нажав на кнопку Details, будет видно начала сканирования каждой сети, тренд трафика и соответствующие алармы.

Далее можно “провалиться” в хост из вкладки на предыдущем скриншоте и увидеть события безопасности, а также активность за последнюю неделю для этого хоста.

В качестве примера проанализируем событие Port Scan с хоста 10.201.3.149 на 10.201.0.72, нажав на Actions > Associated Flows. Запускается поиск по потокам и выводится релевантная информация.

Как мы видим данный хост с одного своего порта 51508/TCP сканировал 3 часа назад хост назначения по портам 22, 28, 42, 41, 36, 40 (TCP). Некоторые поля не отображают информацию либо потому, что не вся поля Netflow поддерживаются на Netflow экспортере.

6. Анализ скачанных зловредов с помощью CTA

CTA (Cognitive Threat Analytics) — облачная аналитика Cisco, которая прекрасно интегрируется с Cisco StealthWatch и позволяет дополнить безсигнатурный анализ сигнатурным. Тем самым становится возможным детектирование троянов, сетевых червей, вредоносов нулевого дня и других зловредов и их распространение внутри сети. Также ранее упомянутая технология ЕТА позволяет анализировать такие вредоносные коммуникации и в зашифрованном трафике.

Буквально на первой же вкладке в веб-интерфейсе есть специальный виджет Cognitive Threat Analytics. Краткая сводка говорит об обнаруженных угрозах на пользовательских хостах: троян, мошенническое ПО, назойливое рекламное ПО. Слово “Encrypted” как раз-таки и свидетельствует о работе ЕТА. Нажав на хост, по нему выпадает вся информация, события безопасности в том числе логи по СТА.

Наводя на каждый этап СТА, события выводится подробная информация о взаимодействии. Для полной аналитики стоит нажать View Incident Details, и вы попадете в отдельную консоль Cognitive Threat Analytics.

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

Ниже изображен еще один пример — банковский троян, которым был заражен хост 198.19.30.36. Данный хост начал взаимодействовать со зловредными доменами, а в логах изображена информация по потокам этих взаимодействий.

Далее одно из лучших решений, которое может быть, — закинуть хост в карантин благодаря нативной интеграции с Cisco ISE для дальнейшего лечения и анализа.

Заключение

Решение Cisco StealthWatch является одним из лидеров среди продуктов мониторинга сети как с точки зрения анализа сети, так и информационной безопасности. Благодаря ему можно обнаруживать нелегитимные взаимодействия внутри сети, задержки приложений, самых активных пользователей, аномалии, зловредов и APT. Более того, можно находить сканирования, пентестеров, проводить криптоаудит HTTPS трафика. Еще больше use cases вы можете найти по ссылке.

Если у вас появилось желание проверить, насколько у вас в сети все гладко и эффективно работает, отправьте заявку.
В ближайшее время мы планируем еще несколько технических публикаций по различным продуктам ИБ. Если вам интересна данная тематика, то следите за обновлениями в наших каналах (Telegram, Facebook, VK, TS Solution Blog)!

Источник: habr.com