Stealthwatch

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)!

В более ранних статьях было рассмотрено несколько обширных тем касательно решения по мониторингу Cisco StealthWatch. Напомню, что StealthWatch решение по мониторингу трафика в сети на предмет инцидентов безопасности и легитимности сетевого взаимодействия. В основе работы StealthWatch лежит сбор NetFlow и IPFIX с маршрутизаторов, коммутаторов и других сетевых устройств.
Приведу для справки ссылки на прошлые статьи: первое представление и возможности, развертывание и настройка, а также анализ и расследование инцидентов.
Прошу заметить, мониторинг, в частности Cisco StealthWatch, это прежде всего решение по детектированию угроз и атак. Все мониторинговые решения не подразумевают в себе предотвращение угроз, однако часто это требуется. У StealthWatch есть интеграция из коробки с Cisco ISE (Identity Services Engine). Интеграция состоит в том, что StealthWatch обнаруживает инцидент безопасности, а Cisco ISE вносит в хост карантин до момента, пока администратор руками его из карантина не вынесет.
В данной статье рассматривается настройка интеграции и пример срабатывания.

Cisco ISE это

Если кратко, то Cisco ISE это Network Access Control (NAC) решение для предоставления контроля доступа пользователям к внутренней сети с учетом контекстов. Cisco ISE позволяет:

• Быстро и просто создавать гостевой доступ
• Обнаруживать BYOD устройства (например, домашние ПК сотрудников, которые они принесли на работу)
• Централизовать и применять политики безопасности к доменным и не доменным пользователям с помощью меток групп безопасности SGT (технология TrustSec)
• Проверять компьютеры на наличие установленного определенного ПО и соблюдение стандартов (posturing)
• Классифицировать и профилировать оконечные и сетевые устройства
• Предоставлять видимость оконечных устройств
• Отдавать журналы событий logon/logoff пользователей, их учетки (identity) на NGFW для формирования user-based политики
• Делать все, что умеет ААА сервер

Про Cisco ISE писали многие коллеги по отрасли, рекомендую ознакомиться: практика внедрения Cisco ISE, как подготовиться к внедрению Cisco ISE и интеграция с Cisco FirePOWER.

Как работает карантин

Workflow действий добавить/удалить из карантина ANC политики (Adaptive Network Control) в Cisco ISE изображен ниже:

1. Предварительно пользователь логиниться в корпоративную сеть через WLC (контроллер точек доступа). Затем отправляется REST API запрос на карантин с ноды управления (Policy Administration Node).
2. Мониторинговая нода (Monitoring Node), которая отвечает за сбор логов, отправляет специальный PrRT запрос на PSN ноду (Policy Service Node, отвечает за применение политик ISE). Также отправляется CoA запрос с целью изменить атрибуты ААА и отключить пользователя.
3. Клиентское устройство отключается.
4. Клиент пытается заново аутентифицироваться и переподключиться.
5. RADIUS запрос со стороны клиента отправляется назад на мониторинговую ноду (Monitoring Node).
6. Устройство заноситься в карантин.
7. В карантине оно и остается, так как профиль карантина был применен и до сих пор активен.
8. Решив инцидент безопасности, администратор выводит хост из карантина.

Настройка

1. В веб-интерфейсе Cisco ISE перейдите во вкладку Operations > Policy List и создайте новую политику, нажав на Add.



2. Назовем ее StealthWatch_Quarantine и выберем действие Карантин (Quarantine) и нажимаем Submit.



3. Следующим шагом является настройка политики. Переходим в Policy > Policy Sets и нажимаем на самую правую стрелку под колонкой View.



4. Во вкладке Authorization Policy > Global Exceptions создается новое правило (следует нажать на +). Далее в колонке Conditions нажимаете + еще раз и выбираете атрибут Session ANCPolicy. Действие в данном правиле Equals StealthWatch_Quarantine.
В колонке Profile > DenyAccess и по желанию в колонке Security Groups можно указать вашу группу безопасности (например, гости или отдел маркетинга). В конце сохраняем изменения.



5. Во вкладке Operations > Live Logs (RADIUS или TACACS) можно посмотреть по пользователю или адресу логи. Предположим, найдем пользователя wesley.



6. Переходим в StealthWatch веб интерфейс и во вкладке Monitor > Users находим данного пользователя.



7. Переходим в его хост, нажав на IP адрес.



8. В пункте ISE ANC Policy выбираем Edit > StealthWatch_Quarantine > Save. Хост помещается в карантин до дальнейшего разбирательства.



Дополнительно в ANC политике можно использовать действия port_shutdown (выключение порта сетевого устройства) и port_bounce (shutdown/no shutdown устройства). Например, если зловред успел распространиться по целому VLAN, то на коммутаторе уровня доступа логичнее и быстрее будет выключить порт, а не вносить каждый хост в карантин.

Заключение

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

Не так давно я писал про мониторинг Netflow/IPFIX и про Cisco StealthWatch аналитическое решение, которое позволяет детектировать такие события, как сканирования, распространение сетевых червей, шпионское ПО, нелегитимные взаимодействия и различного рода аномалии. О расследовании инцидентов с помощью StealthWatch написано в статье.
Мониторинг облачной инфраструктуры давно уже не является новой задачей, так у каждого крупного игрока, есть свои инструменты Amazon CloudWatch или Amazon S3, Google Stackdriver, Azure Monitor. Эти инструменты отлично подходят для мониторинга приложений, производительности и инфраструктуры в целом, но они не закрывают задачи по безопасности (да и сами провайдеры облаков не сильно ей обеспокоены): распространение зловредного ПО, ботнет-коммуникации, обнаружение аномалий, попытки сканирования, нелегитимный доступ (включая варианты с использованием легитимных учетных данных) и многое другое.

StealthWatch Cloud

StealthWatch Cloud (SWC) SaaS-решение, которое напоминает Stealthwatch Enterprise (не зря Cisco последнее время стирает границы между этими двумя решениями в своей архитектуре), но учитывает специфику облачных сред. Если для Stealthwatch Enterprise важным источником информации является телеметрия на базе Netflow, то Stealthwatch Cloud использует в качестве таких данных журналы облачных сред (не ограничиваясь логами, получая и другие виды телеметрии). Дальше выполняются привычные для StealthWatch действия: моделирование объектов, построение их поведенческих моделей, обнаружение отклонений, проверка соответствия политикам, обнаружение событий безопасности (как встроенных, так и заданных пользователем) и многое другое. Угрозы, аномальная и зловредная активность обнаруживаются быстрее, как следствие, ущерб от инцидента снижается или даже полностью нивелируется.
При этом у тревог Stealthwatch Cloud есть привычная для XXI века функция: заказчик может оценить полезность сгенерированной тревоги одним кликом мышки. На текущий момент 96% тревог, сгенерированных для существующих заказчиков StealthWatch Cloud, признаны полезными.
Область применения StealthWatch Cloud не ограничена облаками: решение может использоваться для мониторинга публичных облаков, частных облаков, классической корпоративной инфраструктуры, а также, безусловно, гибридной архитектуры с использованием любого сочетания этих трёх компонентов. Учтены в Stealthwatch Cloud и варианты обслуживания нескольких клиентов при оказании услуг по обеспечении безопасности.
Варианты развертывания можно представить примерно следующим образом.


Рисунок 1. Варианты использования StealthWatch Cloud

StealthWatch Cloud можно использовать при работе с публичными облаками (Amazon, Azure, Google), приватными и гибридными облаками, которые построены на инфраструктуре из Kubernetes и, разумеется, корпоративными сетями.
К слову, Mail.ru являются сертифицированным партнером Kubernetes (K8s). В StealthWatch Cloud отправляются журналы событий подов K8s и потоки трафика между этими подами. В результате приобретаются полная видимость подов K8s, сущностей приватного облака и обнаружение инцидентов безопасности, о которых сказано ранее. На рисунке 2 изображена схема взаимодействия.


Рисунок 2. Схема интеграции StealthWatch Cloud c Kubernetes

В случае работы с частными корпоративными сетями требуется установка виртуальной машины (Virtual Sensor аналог Flow Sensor в StealthWatch Enterprise). На рисунке 3 изображено, что на сенсор отправляется Netflow, IPFIX, SPAN, а по шифрованному туннелю сенсор отправляет информацию в StealthWatch Cloud, где и производится вся аналитика. Тем самым, вычислительные мощности заказчика не задействуются от слова совсем, а внедрение и пилот проходят максимально оперативно.


Рисунок 3. Схема интеграции StealthWatch Cloud с корпоративной сетью

Также хочется отметить, что установка Virtual Sensor влечет за собой массу положительных моментов:

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

Существует вариант и без установки виртуального сенсора (Virtual Sensor), но тогда StealthWatch Cloud сможет работать только с телеметрией, то есть сигнатурный анализ доступен не будет.
Еще немного плюсов StealthWatch Cloud:

• Гибкая модель лицензирования по мега-потокам (Effective Mega Flows EMF, где 1 EMF = 1 млн. логов, которые предварительно дедуплицируются, т.е. остаются в едином экземпляре, и считаются в конце месяца);
• Поддержка многопользовательских сред (это плюс для партнеров, предоставляющих SOC на аутсорс, из одной консоли можно мониторить всех заказчиков).

Выводы:
При работе с публичными, приватными и гибридными облаками StealthWatch Cloud позволяет обнаруживать следующие инциденты безопасности:

• Аномальное поведение пользователей, хостов
• Ботнет активность
• Брутфорс
• Попытки удаленного доступа, в том числе из необычных геолокаций
• Распространение зловредного ПО и обращения к зловредным URL
• Нарушение ролей взаимодействия
• Новые устройства, потоки
• Попытки сканирования
• Флуд трафика, штормы
• Система обнаружения вторжений (IDS)
• Специфичные события для AWS, Azure, GCP

При работе с частными корпоративными сетями добавляется практически весь функционал StealthWatch Enterprise.

Интеграция с Amazon Web Services (AWS)

StealthWatch Cloud использует AWS Lambda API (сервис по автоматическому исполнению программного кода и управлению вычислительными ресурсами в AWS) и Identity and Access Management (IAM) API. Это позволяет получать информацию о политиках доступа к инстансам, изменениях исполнения программного кода, проводить аудит инстансов и другое.
Дополнительно SWC использует данные о потоках (взаимодействиях сетевого уровня) с мониторинговых сервисов Amazon CloudWatch или Amazon S3. VPC (Virtual Private Cloud) Flow logs так называются данные о потоках в терминологии AWS.
Следовательно, со стороны администратора в личном кабинете Amazon Web Services следует дать права на чтение потоков (VPC Flow logs) и журналов событий с сервисов Amazon CloudTrail, Amazon IAM, Amazon GuardDuty, AWS Lambda, Amazon Inspector и AWS Config, если вы их используете.
На рисунке 4 изображены схема работы StealthWatch Cloud и AWS.


Рисунок 4. Схема работы StealthWatch Cloud и AWS

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


Рисунок 5. Консоль мониторинга Amazon Web Services в StealthWatch Cloud

Интеграция с Microsoft Azure

В случае работы с Azure StealthWatch Cloud обращается к API Azure для считывания журналов событий, которые содержат информацию о трафике север-юг и запад-восток внутри облачной инфраструктуры. Называются такие журналы NSG Flow logs. По своей сути похожи на потоки Netflow, так как содержат в себе заголовки пакетов.
Большим отличием от кейса с AWS является то, что Azure может отправлять копию трафика с виртуальных машин через VTAP виртуальные ответвители трафика. VTAP является технологией разработанной Microsoft, но доступна для интеграции со всеми третьими решениями. Использование VTAP эффективно, потому что:

1. Копия трафика с нужных сегментов позволит SWC получить полную видимость и, как следствие, максимальное детектирование угроз.
2. Нагрузка на виртуальные машины не увеличивается, так как VTAP это трафик с виртуального коммутатора, а не самой машины.
3. Взаимодействие с SWC осуществляется по шифрованному TLS туннелю.

На рисунке 6 изображена схема взаимодействия.


Рисунок 6. Схема работы StealthWatch Cloud и Microsoft Azure

Интеграция с Google Cloud Platform

При интеграции с Google Cloud Platform (GCP) возможно только обращение к API со стороны SWC для считывания ранее упомянутых VPC Flow журналов событий (таких же, как и у Amazon) c Google Stackdriver. Google Stackdriver это сервис, который собирает логи и метрики из GCP, мониторит приложения, виртуальные машины и Google Cloud инфраструктуру в целом. Однако работа только с VPC Flow журналами событий дает немного меньшую видимость. Схема работы изображена на рисунке 7.


Рисунок 7. Схема работы StealthWatch Cloud и Google Cloud Platform

SWC vs. SWE

Хотя Stealthwatch Cloud и Stealthwatch Enterprise решают сходные задачи, области их применения и различия в основных источниках телеметрии обуславливают разные возможности. Сравнительные данные сведены в таблице ниже.
Можно заключить, что StealthWatch Enterprise является отличным вариантом, когда есть своя виртуальная инфраструктура, доступно много вычислительных ресурсов и нужен максимальный функционал по мониторингу корпоративной сети на предмет инцидентов безопасности, легитимных взаимодействий и видимости сети. К слову, можно приобрести и физическое исполнение StealthWatch.
В свою очередь, StealthWatch Cloud привлекателен быстротой развертывания (особенно для пилота), также для него не требуется развертывать и поддерживать виртуальные машины, кроме Virtual Sensor. SWC позволяет мониторить инфраструктуру в публичных, приватных облаках и поддерживает исходную интеграцию с единой платформой управления ИБ решениями Cisco SecureX.

Как протестировать?

Есть два варианта бесплатного пилотного проекта: самому или с партнером. В случае первого варианта, предлагаются обратиться к сайту. Лицензия выдается на 60 дней, гайды по настройке предоставляются на этом же сайте Cisco. В случае, если вы желаете больше погрузиться в детали и максимально качественно решить свои задачи по мониторингу, то обращайтесь к нам по ссылке.

Заключение

StealthWatch Cloud является многогранным решением, которое позволяет в максимально сжатые сроки получить полную видимость в приватном, публичном или гибридном облаке, будь-то Amazon Web Services, Microsoft Azure или Google Cloud Platform. Одновременно с этим данное решение может использоваться и для мониторинга корпоративных сетей, обладая при этом практически одинаковым функционалом в сравнении с on-premise StealthWatch Enterprise. Экономия времени, технических и человеческих ресурсов при работе c SWC вот явные преимущества.
В ближайшее время мы планируем еще несколько технических публикаций по различным продуктам ИБ. Если вам интересна данная тематика, то следите за обновлениями в наших каналах (Telegram, Facebook, VK, TS Solution Blog)!

Каждый год мы с друзьями ходим в баню. Каждый год, когда наши большие друзья, компания Positive Technologies проводит свое глобальное мероприятие для настоявших экспертов в области информационной безопасности PHDays. И каждый год мой друг и коллега Алексей Лукацкий говорит мне Миша, давай что-нибудь технологическое сделаем!. А потом выясняется, что заваленный рутиной, я опять все пропустил. Но этот год, как мы все уже заметили, глубоко особенный. И вместо PHDays было проведено очень эффективное и масштабное мероприятие под названием Standoff. В этот раз я решил послушать Алексея Викторовича и успеть что-то сделать! Тем более, что мероприятие существенно превосходило все, что когда-либо делалось ранее. Посмотреть детали этого впечатляющего киберполигона можно вот тут: https://standoff365.com/battlefield.
Вкратце скажу, что он эмулировал собой полноценный, и весьма немаленький город, в котором было практически все начиная от аэропорта, и заканчивая финансовыми организациями и парком аттракционов! Это давало злоумышленникам возможность проявить свои навыки взлома, а защитникам свои навыки обнаружения и отражения угроз.

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

Мы понимали, что вмешиваться в работу полигона мы не должны, а также заниматься детальной подстройкой профилей обнаружения атак формат мероприятия не позволяет, то и было выбрано решения класса NTA (NTA Network Traffic Analytics) это решения, которые определяют угрозы по анализу сетевой телеметрии, или, попросту говоря, профилю сетевого трафика. Внедрение таких систем идет гораздо проще и бесшовнее, чем, например, внедрение классических систем обнаружения и предотвращения вторжений. Это связанно и с тем, что нет необходимости вносить изменения в сетевую топологию, а также тем, что ядром таких систем является машинное обучение в сочетании с данными аналитики угроз. Такой подход позволяет системе не только быстро идентифицировать типовые угрозы, но и обучиться за определенный интервал времени, а затем использовать полученные знания для обнаружения нештатного поведения пользователей, систем и приложений. Также такие системы, просто по своему подходу, являются существенно менее шумными с точки зрения оповещения о всевозможных угрозах и гораздо более точными с точки зрения идентификации реальных инцидентов. На этом краткий экскурс в данную тему я закончу, кто хочет почитать об этом подробнее, советую обратить внимание на вот такой материал:
http://personeltest.ru/aways/habr.com/ru/company/cisco/blog/348532/

Изначально, я решил использовать давно и хорошо известный продукт Cisco Stealthwatch Enterprise, успешно применяемый многими моими коллегами в разных организациях. И уже собрался позвонить коллегам в Positive чтобы рассказать им, сколько мне нужно процессоров, места дисках, виртуалок и т. п. В этот момент странная мысль посетила меня я вспомнил, как много ресурсов и людских и технических было положено на создание этого киберполигона, и подумал, что на то, что часть этих ресурсов попрошу я, никто не рассчитывал. С другой стороны, отказываться от идеи не хотелось, и в рамках современных тенденций в области обеспечения информационной безопасности я решил перейти на облачное решение под названием Stealthwatch Cloud. Надо сказать, что это решение называется облачным не зря, так как оно умеет собирать и анализировать телеметрию частных облаков, создаваемых внутри публичных облаков, через прикладные программные интерфейсы (API). Т. е. с помощью этого решения я могу анализировать, с точки зрения информационной безопасности, происходящее внутри Amazon AWS, Microsoft Azure, Google GCP, а также контейнеров Kubernetes. Но сейчас мне было нужно другое применение этого продукта а именно мониторинг частных сетей. В этом случае в такую сетку просто устанавливается датчик (сенсор), которые и отдает телеметрию в облачную консоль мониторинга и управления. В предыдущем предложении я употребил слово просто и теперь попробую развернуть его подробнее.

Итак, как же выглядит процесс?

Надо запросить триалку, это занимает пару минут.
Ссылка тут:
https://www.cisco.com/c/en/us/products/security/stealthwatch/stealthwatch-cloud-free-offer.html?dtid=osscdc000283

Потом, в течение пары дней начинают приходить разные полезные письма и в конце концов приходит письмо про то, что портал активирован!
После этого получаешь себе личный портал, ссылка на который выглядит так:

cisco-YOUR_CISCO_USERNAME.obsrvbl.com, например: cisco-mkader.obsrvbl.com.

Заходя туда, мы видим главный экран, откуда можно скачать виртуальную машину сенсора для мониторинга частных сетей. Требования под эту виртулку не велики 2 vCPU, 2 гига памяти и 32 гига места на диске. А в целом процесс установки крайне прост и описан в непривычно простом и удобном руководстве, сделанным в виде листаемой электронной книги:
https://ebooks.cisco.com/story/swc-sensor-install/
Сразу скажу, что у сенсора есть два интерфейса один служит для связи с консолью управления и также собирает на себе телеметрию, например NetFlow, а заодно и мониторит весь приходящий на него трафик. Второй же может работать в режиме захвата пакетов (promiscuous mode) и генерировать телеметрию по пойманному им трафику. В нашем конкретном случае мы использовали только первый интерфейс.

После установки сенсор бежит в облако, где размещена консоль это на самом деле AWS и выдает прекрасное сообщение:
{error:unknown identity,identity:185.190.117.34}

Это тот самый IP адрес, под которым сенсор считает, что видит себя во внешнем мире, пробившись через корпоративный межсетевой экран, трансляцию адресов и т. п. На всякий случай, сразу скажу, что сенсору нужен HTTP и HTTPs, а также настройка DNS-а. После получения указанного выше сообщения надо просто взять этот адрес и добавить его в список своих сенсоров на консоли:



И через некоторое время сенсор окрашивается в зеленый цвет это означает, что сенсор установил соединение с консолью.
И, в общем то, на этом запуск системы завершен. Следующий шаг это добавление источников телеметрии, в дополнение к том, что сенсор слушает сам. Если мы хотим получать телеметрию по протоколу NetFlow, то крайне полезным является сайт https://configurenetflow.info/

На нем мы можем выбрать нужное нам сетевое устройство, ввести пару параметров и получить готовую конфигурацию:



И скопировать полученную информацию на наши сетевые устройства. Все система готова к работе! Вернее даже уже начала работать.
Кстати, примеры настроек Netflow с этого сайта можно использовать не только под Steathwatch, а под любой другой продукт, которому может пригодится такая телеметрия например Cisco Tetration, IBM QRadar и т. п.

Теперь можно заняться и мелким тюнингом системы. Сразу хочу сказать, что я очень люблю смотреть, как разные продукты компании Cisco по информационной безопасности сообщают мне обо всем происходящим на единую консоль мониторинга и реагирования Cisco SecureX. На самом деле SecureX штука крайне интересная и заслуживает отдельного описания. В двух словах это облачная система мониторинга информационной безопасности (SIEM), проведения расследований (Threat Hunting), расследования и реагирования на инциденты, а заодно еще и автоматизации процессов (SOAR). Очень рекомендую подробнее ознакомиться с этой системой, причем она прилагается по умолчанию к любому продукту Cisco по информационной безопасности. Ну и немного маркетинга по это теме вот тут: https://www.cisco.com/c/ru_ru/products/security/securex.html

Итак, первым делом и настроил такую интеграцию:



Заодно я настроил интеграцию и с нашей облачной платформой предоставления услуг безопасности Cisco Umbrella: http://personeltest.ru/aways/habr.com/ru/company/jetinfosystems/blog/529174/



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

После этого я создал себе новую консоль мониторинга в SecureX. Все это суммарно заняло минут 5, а может и того меньше. Пара картинок из моего SecureX -а ниже:





После этого я решил отключить неинтересные мне уведомления, и включить интересные. Для этого я вернулся в консоль SWC и пошел настраивать эти самые уведомления:



Сразу скажу, что по каждому из уведомлений можно посмотреть, что оно из себя представляет, сколько дней сбора телеметрической информации требуется для обнаружения соответствующей угрозы, и как она ложится, если ложится, на модель MITRE ATT&CK.
Количество обнаруживаемых угроз и связанных с ними уведомлений постоянно растет по мере развития самого по себе решения. Но мне про это думать особо не надо облако же, как что новое добавили, так это сразу в моем распоряжении.
Я отключил большую часть уведомлений, связанных с атаками на облака AWS, Azure, GCP, так как они в рамках данного полигона не использовались, и включил все уведомления, связанные с атаками на частные сети.
Также я могу поуправлять политиками мониторинга по разным подсетям, которые я хочу контролировать. Можно отдельно включить и мониторинг по особо интересующим нас странам:



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

Ну а теперь что же мы увидели?

В первые дни Standoff телеметрию мне отдавала парочка наших виртуальных межсетевых экранов ASAv, но потом количество источников несколько увеличилось добавилось еще межсетевых экранов, а также Netflow с центрального брокера трафика.
Первые уведомления пришли очень быстро, и, как и следовало ожидать, они были связаны с многочисленными сканированиями. Ну а потом наблюдать за процессом становилось интереснее с каждым часом. Я не буду тут расписывать весь процесс наблюдения, а просто расскажу о нескольких фактах. Во-первых, удалось собрать неплохую информацию что есть что на полигоне:





Во-вторых, оценить масштабность мероприятия с какими же странами был наиболее активный обмен трафиком:



На самом деле есть и более удобный формат представления этих данных, но тут я решил показать больше детализации.
Итак, основными внешними, помимо России, пользователями полигона были США, Германия, Голландия, Ирландия, Англия, Франция, Финляндия, Канада, хотя определенное взаимодействие было практически со всеми странами, включая страны Южной Америки, Африки и Австралию:



Конечно, мы могли посмотреть, кому принадлежат увиденные адреса:



И при желании, спросить про них у других полезных аналитических источников:



Что позволило увидеть, например, активное взаимодействие с ресурсами компании Microsoft во многих странах.
Причем таблицу наиболее активных взаимодействий можно было увидеть и в виде динамической картинки соединений с возможностью ее более подробного анализа:



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



Всего было идентифицировано 117 атак, подтвержденных множеством наблюдений (Observables) Мы видим тут и сетевые сканирования, и подозрительные длинные сессии, проблемы с SMB, некорректное использование сетевых портов и сервисов, странное поведение сетевых узлов, неожиданное изменение их поведения и прочие странности, которые должны насторожить специалиста по информационной безопасности.
По каждому интересующему нас событию мы можем получить подробную информацию, включая что оно из себя представляет, чем оно плохо и рекомендации по предотвращению. Пару таких интересный событий можно увидеть ниже это неожиданный запуск SSH сервера на рабочей станции Windows и использование нестандартного диапазона портов. Также можно обратить внимание на то, что, при настроенной интеграции можно прямо из описания события перейти в консоль проведения расследований SecureX Treat Response для подробного анализа данного инцидента:





Итак, немного коротких выводов по результатам этого небольшого и занимательного пилота.
Первый компания Positive Technologies провела прекрасные киберучения и было очень интересно немного понаблюдать за ними изнутри, причем это было удобно, легко и просто.

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

Третий участники полигона тоже активно пользовались облачными сервисами, например сервисами компании Microsoft

Четвертый автоматизированный машинный анализ разнообразной сетевой телеметрии позволяет легко выявить инциденты ИБ, включая спланированную деятельность злоумышленников. И советую обратить внимание на то, что уже существует множество проработанных сценариев эффективного применения решения Cisco Stealthwatch для нужд информационной безопасности. Каждый из читателей может найти себе сценарий по душе вот тут: https://cisco.bravais.com/s/kCvJYJKyhuyQqAZSU6Xk.

Ну и маленький заключительный комментарий в этой статье я сознательно не стал подробно перечислять полученные списки адресов IP, доменов, детали взаимодействия и т. п., понимая, сколько усилий стоило компании Positive Technologies собрать данный полигон и надеясь, что он неоднократно пригодится им и нам и в дальнейшем. И облегчать жизнь будущим атакующим мы не будем.