![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
bga68compДыра как инструмент безопасности или как ловить APT «на живца» | LinkedIn
Alex Lozikoff
Business Development Manager at Softprom by ERC
https://www.linkedin.com/pulse/дыра-как-инструмент-безопасности-или-ловить-apt-на-живца-lozikoff/
(за идею заголовка спасибо Sergey G. Brester @sebres)
Коллеги, целью данной статьи желание поделиться опытом годичной эксплуатации нового класса IDS-решений на основе Deception-технологий.
Чтобы сохранить логическую связность этого опуса, считаю нужным начать с предпосылок. Итак, проблематика, которая сподвигла нас смотреть в эту сторону:
На роль такого инструмента претендуют, так называемые, deception-решения. То есть решения, в основе которых лежит старая добрая концепция ханипотов, но с совершенно другим уровнем реализации. Что же это такое? Deception – это использование техник активного обмана атакующих с применением специализированных ловушек, приманок и других методов активной дезинформации.
По результатам Gartner Security&Risc management summit 2017 https://www.gartner.com/newsroom/id/3744917 Deception решения входят в ТОП 3 стратегий и инструментов, которые рекомендуется применять.
По данным отчета TAG Cybersecurity Annual 2017 https://www.tag-cyber.com/Annual/2017/ Deception является одним из магистральных направлений развития IDS Intrusion Detection Systems) решений.
Целая секция последнего отчета Cisco о состоянии ИТ-безопасности (https://www.cisco.com/c/en/us/products/security/security-reports.html), посвященная SCADA, построена на данных одного из лидеров этого рынка, TrapX Security (Израиль), решение которых уже год работает в нашей тестовой зоне.
ТрапХ Deception Grid позволяет стоить и эксплуатировать массированные распределенные IDS централизованно, без увеличения лицензионной нагрузки и требований к аппаратным ресурсам. Фактически, ТрапХ – это конструктор, который позволяет создать из всех элементов существующей ИТ-инфраструктуры один большой механизм обнаружения атак масштаба всего предприятия, своего рода сетевую сигнализацию и «минное поле» для атакующей стороны.
Структура Решения
В нашей лаборатории мы постоянно изучаем и тестируем различные новинки в области ИТ-безопасности. Сейчас здесь развернуто около 50 различных виртуальных серверов, в том числе и компоненты TrapX Deception Grid.
Итак, сверху вниз:
В нашей лаборатории развернут один TSA (mwsapp1), но на самом деле их может быть много. Это может понадобиться в крупных сетях, где между сегментами нет L2-связности (типичный пример – Холдинг и дочерние предприятия или Головной офис банка и филиалы) или если в сети есть изолированные сегменты, например, АСУТП. В каждом таком филиале/сегменте можно развернуть свой TSA и подключить его к единому TSOC, на котором вся информация будет сводиться и обрабатываться централизованно. Такая архитектура позволяет строить распределенные системы мониторинга без необходимости редизайна сети или нарушения существующей сегментации.
Также, на TSA мы можем подать копию исходящего трафика через TAP/SPAN. В случае обнаружения соединений с известными ботнетами, командными серверами, TOR-сессий мы также получим сработку в консоли. За это отвечает Network Intelligence Sensor (NIS). В нашей среде этот функционал реализован на межсетевом экране, поэтому здесь мы его не использовали.
Для пользы дела и любопытства ради, мы развернули «каждой твари по паре» - 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 и т.п.) Но использовать эти хосты для развития атаки, запуска своего кода невозможно.
Итак, краткая статистика за год:
56 208 – инцидентов зафиксировано
2 912 – хостов-источников атак обнаружено.
Интерактивная, кликабельная карта атак
При этом, решение не генерирует какой-то мега-лог или ленту событий, в которой надо дополнительно долго разбираться. Вместо этого решение само классифицирует события по их типам и позволяет команде ИБ фокусироваться в первую очередь на самых опасных – когда атакующая сторона пытается поднимать управляющие сессии (interaction) или когда у нас в трафике появляется бинарные пейлоады (infection).
Вся информация о событиях читаема и представляется, на мой взгляд, в легком для понимания виде даже пользователю с базовыми знаниями в области ИБ.
Большинство из зафиксированных инцидентов – это попытки сканирования наших хостов или единичных соединений. Что-то типа такого.
Или попытки перебора паролей для RDP
Но встречались и более интересные кейсы, особенно когда злоумышленникам «удавалось» подобрать пароль для RDP и получить доступ в локальную сеть.
Злоумышленник пытается выполнить код с помощью psexec
Злоумышленник нашел сохраненную сессию, которая привела его в ловушку в виде Linux-сервера. Сразу после подключения одним, заранее заготовленным набором команд он попытался уничтожить все файлы журналов и соответствующие системные переменные.
Атакующий пытается провести инъекцию на ловушке, которая имитирует SWIFT Web Access
Кроме таких «естественных» атак мы проводили и ряд своих собственных тестов. Одним из наиболее показательных является тестирование времени обнаружения сетевого червя в сети. Для этого мы использовали инструмент от GuardiCore, который называется Infection Monkey (http://www.guardicore.com/infectionmonkey/ ). Это сетевой червь, который умеет захватывать Windows и Linux, но без какой то «полезной» нагрузки.
Мы развернули локальный командный центр, на одной из машин запустили первый экземпляр червя и получили первую оповещение в консоли TrapX менее чем через полторы минуты. TTD 90 секунд против 106 дней в среднем. Неплохой результат!
Благодаря возможности интеграции с другими классами решений мы можем перейти только от быстрого детектирования угроз к автоматическому реагированию на них.
Так, например, интеграция с NAC (Network Access Control) системами или с CarbonBlack позволит автоматически отключать скомпрометированные ПК от сети.
Интеграция с песочницами позволяет автоматически передавать для анализа файлы, участвующие в атаке.
Интеграция с McAfee
Также в решении есть своя встроенная система корреляции событий
Но нас ее возможности не устроили, поэтому мы интегрировали TrapX с HP ArcSight
Справиться с обнаруженными угрозами «всем миром» помогает встроенная система тикетинга
Так как решение «со старта» разрабатывалось для нужд гос.органов и крупного корпоратива, то там, естественно, реализована ролевая модель доступа, интеграция с AD, развитая система отчетов и триггеров (событийных оповещений), оркестрация – для крупных холдинговых структур или MSSP провайдеров.
Вместо резюме
Лучше иметь такое или подобное решение, чем не иметь. Если есть подобная система мониторинга, которая, образно говоря, прикрывает нам спину, с компрометацией периметра игра только начинается. Самое главное то, что появляется реальная возможность бороться с ИБ-инцидентами, а не заниматься устранением их последствий.
Alex Lozikoff
Business Development Manager at Softprom by ERC
https://www.linkedin.com/pulse/дыра-как-инструмент-безопасности-или-ловить-apt-на-живца-lozikoff/
(за идею заголовка спасибо Sergey G. Brester @sebres)
Коллеги, целью данной статьи желание поделиться опытом годичной эксплуатации нового класса IDS-решений на основе Deception-технологий.
Чтобы сохранить логическую связность этого опуса, считаю нужным начать с предпосылок. Итак, проблематика, которая сподвигла нас смотреть в эту сторону:
- Направленные атаки – наиболее опасный вид атак, несмотря на то, что в общем количестве угроз их удельный вес невелик. Почему? Потому что каждая направленная атака - это бизнес-проект, который осуществляется хорошо подготовленными и мотивированными специалистами, которые очень хорошо знают, как монетизировать захваченные ресурсы. Именно поэтому ущерб от одной такой успешной атаки может на порядки превышать совокупную стоимость всех остальных кибер-угроз.
- Какого-то на 100% гарантированно эффективного средства защиты периметра (или комплекса таких средств) пока еще не придумано.
- Как правило, направленные атаки проходят в несколько стадий. Преодоление периметра - это только одна из начальных стадий, которая (можете закидать меня камнями) большого ущерба для «жертвы» не несет, если это, конечно не DEoS (Destruction of service) атаки (шифровальщики и т.п.). По-настоящему больно начинается позже, когда захваченные активы начинают использовать для пивотинга и развития атаки «в глубину», а мы этого не заметили.
- Так как мы начинаем нести настоящие потери тогда, когда злоумышленники все-таки добираются до целей атаки (сервера приложений, СУБД, хранилища данных, репозитарии, элементы критической инфраструктуры), логично, что одной из задач службы ИБ является прерывание атак до этого печального события. Но чтобы что-то прервать, надо об этом сначала узнать. И чем раньше – тем лучше.
- Соответственно, для успешного управления рисками (то есть, снижения ущерба от направленных атак) критично наличие инструментов, которые обеспечат минимальный TTD (time to detect – время с момента вторжения до момента обнаружения атаки). В зависимости от отрасли и региона этот период с среднем составляет 99 дней в США, 106 дней в регионе EMEA, 172 дня в регионе APAC (M-Trends 2017, A View From the Front Lines, Mandiant). В ходе атаки на энергосистемы Украины злоумышленники были в сети около года. И то, мы чаще всего обнаруживаем атаки тогда, когда уже появляются видимые признаки – мы обнаруживаем искаженные или зашифрованные данные, пропажу денег, недоступность сервисов и т.п. Почему?
- Причин, на самом деле, много. На мой взгляд, основная - неправильное понимание большинством заказчиков концепции defense in depth (эшелонированной обороны). Традиционная связка «межсетевой экран + доменные политики + антивирусы + DLP» - это не эшелонированная оборона, так это все инструменты одного типа, так называемые, preventive controls. Безусловно, они важны и должны быть, но для успешной борьбы с направленными атаками их мало. Они хорошо и быстро могут обнаруживать уже известные угрозы, «отстреливать» китайских script kiddies, но направленную атаку с использованием 0-day они не увидят. Нужны еще и средства мониторинга, анализа и проведения расследований.
- Что предлагает рынок?
- «Песочницы». Еще один preventive control, который далек от идеала. Есть масса эффективных техник обнаружения и обхода песочниц или whitelisting-решений. Парни с «темной стороны» здесь пока на шаг впереди.
- UEBA (системы профилирования поведения и выявления отклонений) – в теории может быть очень эффективно. Но, на мой взгляд, это когда-то в далеком будущем. На практике – это пока очень дорого, ненадежно и требует очень зрелой и стабильной ИТ- и ИБ-инфраструктуры, где уже есть все инструменты, которые будут генерировать данные для поведенческого анализа.
- SIEM – хороший инструмент для расследований, но что-то новое, оригинальное, увидеть и вовремя показать не в состоянии, потому что правила корреляции суть те же сигнатуры.
- Соответственно, назрела необходимость в таком инструменте, который бы:
- успешно работал в условиях уже скомпрометированного периметра
- обнаруживал успешные атаки в режиме близком к реальному времени независимо от инструментария и тех уязвимостей, которые используются.
- не зависел от сигнатур/правил/сценариев/политик/профилей и прочих статичных вещей
- не требовал наличия больших массивов данных и их источников для анализа
- позволял бы определять атаки не как некий риск-скоринг в результате работы «лучшей в мире, запатентованной и поэтому закрытой математики», который требует доп.расследования, а практически как бинарное событие – «Да, нас атакуют» или «Нет, все ОК»
- был бы универсальным, эффективно масштабируемым и «внедрябельным» в любой гетерогенной среде, независимо от используемой физической и логической топологии сети.
На роль такого инструмента претендуют, так называемые, deception-решения. То есть решения, в основе которых лежит старая добрая концепция ханипотов, но с совершенно другим уровнем реализации. Что же это такое? Deception – это использование техник активного обмана атакующих с применением специализированных ловушек, приманок и других методов активной дезинформации.
По результатам Gartner Security&Risc management summit 2017 https://www.gartner.com/newsroom/id/3744917 Deception решения входят в ТОП 3 стратегий и инструментов, которые рекомендуется применять.
По данным отчета TAG Cybersecurity Annual 2017 https://www.tag-cyber.com/Annual/2017/ Deception является одним из магистральных направлений развития IDS Intrusion Detection Systems) решений.
Целая секция последнего отчета Cisco о состоянии ИТ-безопасности (https://www.cisco.com/c/en/us/products/security/security-reports.html), посвященная SCADA, построена на данных одного из лидеров этого рынка, TrapX Security (Израиль), решение которых уже год работает в нашей тестовой зоне.
ТрапХ Deception Grid позволяет стоить и эксплуатировать массированные распределенные IDS централизованно, без увеличения лицензионной нагрузки и требований к аппаратным ресурсам. Фактически, ТрапХ – это конструктор, который позволяет создать из всех элементов существующей ИТ-инфраструктуры один большой механизм обнаружения атак масштаба всего предприятия, своего рода сетевую сигнализацию и «минное поле» для атакующей стороны.
Структура Решения
В нашей лаборатории мы постоянно изучаем и тестируем различные новинки в области ИТ-безопасности. Сейчас здесь развернуто около 50 различных виртуальных серверов, в том числе и компоненты TrapX Deception Grid.
Итак, сверху вниз:
- TSOC (TrapX Security Operation Console) – мозг системы. Это центральная консоль управления, с помощью которой осуществляется настройка, развертывание решения и вся ежедневная работа. Так как это веб-сервис, он может быть развернут где угодно – в периметре, в облаке или у MSSP провайдера.
- TrapX Appliance (TSA) – виртуальный сервер, в который мы с помощью trunk-порта подключаем те подсети, которые мы хотим охватить мониторингом. Также здесь фактически «живут» все наши сетевые сенсоры.
В нашей лаборатории развернут один TSA (mwsapp1), но на самом деле их может быть много. Это может понадобиться в крупных сетях, где между сегментами нет L2-связности (типичный пример – Холдинг и дочерние предприятия или Головной офис банка и филиалы) или если в сети есть изолированные сегменты, например, АСУТП. В каждом таком филиале/сегменте можно развернуть свой TSA и подключить его к единому TSOC, на котором вся информация будет сводиться и обрабатываться централизованно. Такая архитектура позволяет строить распределенные системы мониторинга без необходимости редизайна сети или нарушения существующей сегментации.
Также, на TSA мы можем подать копию исходящего трафика через TAP/SPAN. В случае обнаружения соединений с известными ботнетами, командными серверами, TOR-сессий мы также получим сработку в консоли. За это отвечает Network Intelligence Sensor (NIS). В нашей среде этот функционал реализован на межсетевом экране, поэтому здесь мы его не использовали.
- Application Traps (Full OS) – традиционные ханипоты на базе Windows –серверов. Их не требуется много, так как основная задача этих серверов – предоставить ИТ-сервисы следующему уровню сенсоров или выявлять атаки на бизнес-приложения, которые могут быть развернуты в Windows-среде. У нас в лаборатории установлен один такой сервер (FOS01)
- 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 и т.п.) Но использовать эти хосты для развития атаки, запуска своего кода невозможно.
- 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-сервера. Сразу после подключения одним, заранее заготовленным набором команд он попытался уничтожить все файлы журналов и соответствующие системные переменные.
Атакующий пытается провести инъекцию на ловушке, которая имитирует SWIFT Web Access
Кроме таких «естественных» атак мы проводили и ряд своих собственных тестов. Одним из наиболее показательных является тестирование времени обнаружения сетевого червя в сети. Для этого мы использовали инструмент от GuardiCore, который называется Infection Monkey (http://www.guardicore.com/infectionmonkey/ ). Это сетевой червь, который умеет захватывать Windows и Linux, но без какой то «полезной» нагрузки.
Мы развернули локальный командный центр, на одной из машин запустили первый экземпляр червя и получили первую оповещение в консоли TrapX менее чем через полторы минуты. TTD 90 секунд против 106 дней в среднем. Неплохой результат!
Благодаря возможности интеграции с другими классами решений мы можем перейти только от быстрого детектирования угроз к автоматическому реагированию на них.
Так, например, интеграция с NAC (Network Access Control) системами или с CarbonBlack позволит автоматически отключать скомпрометированные ПК от сети.
Интеграция с песочницами позволяет автоматически передавать для анализа файлы, участвующие в атаке.
Интеграция с McAfee
Также в решении есть своя встроенная система корреляции событий
Но нас ее возможности не устроили, поэтому мы интегрировали TrapX с HP ArcSight
Справиться с обнаруженными угрозами «всем миром» помогает встроенная система тикетинга
Так как решение «со старта» разрабатывалось для нужд гос.органов и крупного корпоратива, то там, естественно, реализована ролевая модель доступа, интеграция с AD, развитая система отчетов и триггеров (событийных оповещений), оркестрация – для крупных холдинговых структур или MSSP провайдеров.
Вместо резюме
Лучше иметь такое или подобное решение, чем не иметь. Если есть подобная система мониторинга, которая, образно говоря, прикрывает нам спину, с компрометацией периметра игра только начинается. Самое главное то, что появляется реальная возможность бороться с ИБ-инцидентами, а не заниматься устранением их последствий.
