(за идею заголовка спасибо Sergey G. Brester sebres)

Коллеги, целью данной статьи является желание поделиться опытом годичной тестовой эксплуатации нового класса IDS-решений на основе Deception-технологий.



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

1. Направленные атаки – наиболее опасный вид атак, несмотря на то, что в общем количестве угроз их удельный вес невелик.
2. Какого-то гарантированного эффективного средства защиты периметра (или комплекса таких средств) пока еще не придумано.
3. Как правило, направленные атаки проходят в несколько стадий. Преодоление периметра — это только одна из начальных стадий, которая (можете закидать меня камнями) большого ущерба для «жертвы» не несет, если это, конечно не DEoS (Destruction of service) атаки (шифровальщики и т. п.). По-настоящему «больно» начинается позже, когда захваченные активы начинают использоваться для пивотинга и развития атаки «в глубину», а мы этого не заметили.
4. Так как мы начинаем нести настоящие потери тогда, когда злоумышленники все-таки добираются до целей атаки (сервера приложений, СУБД, хранилища данных, репозитарии, элементы критической инфраструктуры), логично, что одной из задач службы ИБ является прерывание атак до этого печального события. Но чтобы что-то прервать, надо об этом сначала узнать. И чем раньше – тем лучше.
5. Соответственно, для успешного управления рисками (то есть, снижения ущерба от направленных атак) критично наличие инструментов, которые обеспечат минимальное TTD (time to detect – время с момента вторжения до момента обнаружения атаки). В зависимости от отрасли и региона этот период с среднем составляет 99 дней в США, 106 дней в регионе EMEA, 172 дня в регионе APAC (M-Trends 2017, A View From the Front Lines, Mandiant).
6. Что предлагает рынок?
   
   • «Песочницы». Ещё один preventive control, который далек от идеала. Есть масса эффективных техник обнаружения и обхода песочниц или whitelisting-решений. Парни с «темной стороны» здесь пока на шаг впереди.
     
   • UEBA (системы профилирования поведения и выявления отклонений) – в теории может быть очень эффективно. Но, на мой взгляд, это когда-то в далеком будущем. На практике – это пока очень дорого, ненадежно и требует очень зрелой и стабильной ИТ- и ИБ-инфраструктуры, где уже есть все инструменты, которые будут генерировать данные для поведенческого анализа.
     
   • SIEM – хороший инструмент для расследований, но что-то новое, оригинальное, увидеть и вовремя показать не в состоянии, потому что правила корреляции суть те же сигнатуры.
   
   
7. В итоге, назрела необходимость в таком инструменте, который бы:
   
   • успешно работал в условиях уже скомпрометированного периметра,
     
   • обнаруживал успешные атаки в режиме близком к реальному времени независимо от инструментария и тех уязвимостей, которые используются,
   • не зависел от сигнатур/правил/сценариев/политик/профилей и прочих статичных вещей,
   • не требовал наличия больших массивов данных и их источников для анализа,
   • позволял бы определять атаки не как некий риск-скоринг в результате работы «лучшей в мире, запатентованной и поэтому закрытой математики», который требует дополнительного расследования, а практически как бинарное событие – «Да, нас атакуют» или «Нет, все ОК»,
   • был универсальным, эффективно масштабируемым и реально внедряемым в любой гетерогенной среде, независимо от используемой физической и логической топологии сети.

На роль такого инструмента сейчас претендуют, так называемые, deception-решения. То есть решения, в основе которых лежит старая добрая концепция ханипотов, но с совершенно другим уровнем реализации. Эта тема сейчас однозначно на подъеме.

По результатам Gartner Security&Risc management summit 2017 Deception-решения входят в ТОП-3 стратегий и инструментов, которые рекомендуется применять.

По данным отчета TAG Cybersecurity Annual 2017 Deception является одним из магистральных направлений развития IDS Intrusion Detection Systems) решений.

Целая секция последнего отчета Cisco о состоянии ИТ-безопасности, посвященная SCADA, построена на данных одного из лидеров этого рынка, TrapX Security (Израиль), решение которых уже год работает в нашей тестовой зоне.

ТрапХ Deception Grid позволяет стоить и эксплуатировать массированные распределенные IDS централизованно, без увеличения лицензионной нагрузки и требований к аппаратным ресурсам. Фактически, ТрапХ – это конструктор, который позволяет создать из элементов существующей ИТ-инфраструктуры один большой механизм обнаружения атак масштаба всего предприятия, своего рода распределенную сетевую «сигнализацию».

Структура Решения

В нашей лаборатории мы постоянно изучаем и тестируем различные новинки в области ИТ-безопасности. Сейчас здесь развернуто около 50 различных виртуальных серверов, в том числе и компоненты TrapX Deception Grid.



Итак, сверху вниз:

1. TSOC (TrapX Security Operation Console) – мозг системы. Это центральная консоль управления, с помощью которой осуществляется настройка, развертывание решения и вся ежедневная работа. Так как это веб-сервис, он может быть развернут где угодно – в периметре, в облаке или у MSSP провайдера.
2. TrapX Appliance (TSA) – виртуальный сервер, в который мы с помощью trunk-порта подключаем те подсети, которые мы хотим охватить мониторингом. Также здесь фактически «живут» все наши сетевые сенсоры.
   
   В нашей лаборатории развернут один TSA (mwsapp1), но на самом деле их может быть много. Это может понадобиться в крупных сетях, где между сегментами нет L2-связности (типичный пример – «Холдинг и дочерние предприятия» или «Головной офис банка и филиалы») или если в сети есть изолированные сегменты, например, АСУТП. В каждом таком филиале/сегменте можно развернуть свой TSA и подключить его к единому TSOC, на котором вся информация будет централизованно обрабатываться. Такая архитектура позволяет строить распределенные системы мониторинга без необходимости кардинальной перестройки сети или нарушения существующей сегментации.
   
   Также, на TSA мы можем подать копию исходящего трафика через TAP/SPAN. В случае обнаружения соединений с известными ботнетами, командными серверами, TOR-сессий мы также получим результат в консоли. За это отвечает Network Intelligence Sensor (NIS). В нашей среде этот функционал реализован на межсетевом экране, поэтому здесь мы его не использовали.
3. Application Traps (Full OS) – традиционные ханипоты на базе Windows–серверов. Их не требуется много, так как основная задача этих серверов – предоставить ИТ-сервисы следующему уровню сенсоров или выявлять атаки на бизнес-приложения, которые могут быть развернуты в Windows-среде. У нас в лаборатории установлен один такой сервер (FOS01)
   
   
   
4. Emulated traps – основной компонент решения, который позволяет нам с помощью одной единственной виртуальной машины создать очень плотное «минное» поле для атакующих и насытить сеть предприятия, все его vlan-ы, нашими сенсорами. Атакующий видит такой сенсор, или фантомных хост, как настоящий Windows ПК или сервер, Linux сервер или другое устройство, которое мы решаем ему показать.
   
   
   
   Для пользы дела и любопытства ради, мы развернули «каждой твари по паре» — Windows ПК и серверы различных версий, Linux-серверы, банкомат c Windows embedded, SWIFT Web Access, сетевой принтер, коммутатор Cisco, IP-камера Axis, макбук, PLC-устройство и даже умную лампочку. Всего — 13 хостов. Вообще, вендор рекомендует разворачивать такие сенсоры в количестве минимум 10% от количества реальных хостов. Верхняя планка — это доступное адресное пространство.
   
   Очень важным моментом является то, что каждый такой хост – это не полноценная виртуальная машина, которая требует ресурсы и лицензии. Это «обманка», эмуляция, один процесс на TSA, у которого есть набор параметров и IP-адрес. Поэтому мы с помощью даже одного TSA можем насытить сеть сотнями таких фантомных хостов, которые будут работать как датчики в системе сигнализации. Именно эта технология позволяет экономически эффективно масштабировать концепцию «ханипотов» в масштабах любого крупного распределенного предприятия.
   
   Эти хосты с точки зрения атакующей стороны являются привлекательными, так как содержат уязвимости и выглядят относительно легкими целями. Атакующий видит сервисы на этих хостах и может с ними взаимодействовать, атаковать их, используя стандартные инструменты и протоколы (smb/wmi/ssh/telnet/web/dnp/bonjour/Modbus и т. п.). Но использовать эти хосты для развития атаки т запуска своего кода невозможно.
   
5. Cочетание этих двух технологий (FullOS и эмулированных ловушек) позволяет достичь высокой статистической вероятности, что атакующий все таки рано или поздно столкнется с каким-либо элементом нашей сигнальной сети. Но как сделать так, чтобы эта вероятность была близка к 100%?
   
   В бой вступают так называемые токены (Deception tokens). Благодаря им мы можем включить в состав нашего распределенного IDS все имеющиеся ПК и серверы предприятия. Токены размещаются на реальных ПК пользователей. Важно понимать, что токены – это не агент, который потребляет ресурсы и может вызывать конфликты. Токены – это пассивные информационные элементы, своего рода «хлебные крошки» для атакующей стороны, которые ведут её в ловушку. Например, подключенные сетевые диски, закладки на фейковые веб-админки в браузере и сохраненные пароли к ним, сохраненные ssh/rdp/winscp сессии, наши ловушки с комментариями в hosts файлах, сохранённые в памяти пароли, учётные данные несуществующих пользователей, офисные файлы, открытие которых вызовет срабатывание системы, и многое другое. Таким образом, мы помещаем атакующего в искаженную среду, насыщенную теми векторами атак, которые на самом деле не представляют для нас угрозы, а, скорее, наоборот. И у него нет возможности определить где правдивая информация, а где ложная. Таким образом, мы не только обеспечиваем быстрое определение атаки, но и существенно замедляем её ход.

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

В нашей среде мы сконфигурировали и разместили ряд таких токенов на FOS01 под управлением Windows Server 2012R2 и тестовом ПК под Windows 7. На этих машинах запущен RDP и мы периодически «вывешиваем» их в DMZ, куда выведен также ряд наших сенсоров (emulated traps). Таким образом, мы получаем постоянный поток инцидентов, так сказать, естественным образом.

Итак, краткая статистика за год:

56 208 – инцидентов зафиксировано,
2 912 – хостов-источников атак обнаружено.


Интерактивная, кликабельная карта атак

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



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

Большинство из зафиксированных инцидентов – это попытки сканирования наших хостов или единичных соединений.



Или попытки перебора паролей для RDP



Но встречались и более интересные кейсы, особенно когда злоумышленникам «удавалось» подобрать пароль для RDP и получить доступ в локальную сеть.



Злоумышленник пытается выполнить код с помощью psexec.



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



Атакующий пытается провести SQL-инъекцию на ловушке, которая имитирует SWIFT Web Access.

Кроме таких «естественных» атак мы проводили и ряд своих собственных тестов. Одним из наиболее показательных является тестирование времени обнаружения сетевого червя в сети. Для этого мы использовали инструмент от GuardiCore, который называется Infection Monkey. Это сетевой червь, который умеет захватывать Windows и Linux, но без какой то «полезной» нагрузки.
Мы развернули локальный командный центр, на одной из машин запустили первый экземпляр червя и получили первую оповещение в консоли TrapX менее чем через полторы минуты. TTD 90 секунд против 106 дней в среднем…

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

Так, например, интеграция с NAC (Network Access Control) системами или с CarbonBlack позволит автоматически отключать скомпрометированные ПК от сети.



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

Интеграция с McAfee

Также в решении есть своя встроенная система корреляции событий.



Но нас её возможности не устроили, поэтому мы интегрировали его с HP ArcSight.



Справиться с обнаруженными угрозами «всем миром» помогает встроенная система тикетинга.



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

Вместо резюме

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