Comments 31
Заголовок неправильный, вы с TLS ничего не делаете и сделать не можете. Вы анализируете только открытую часть трафика. Зачем эта джинса?
Заголовок корректный относительно приведенного в статье оригинального документа. В целом, на удивление хороший материал; увы, для узкого круга иссоедователей и имеющий ограниченную временную применимость.
Заголовок абсолютно корректный и отражает суть проделанной работы и используемых технологий — использование только SPLT (частотно-временные характеристики размеров пакетов), BD/BE (побайтное распределение/энтропия) для многих семейств вредоносов уже даёт точность порядка 70% и выше.
Общее представление о точности той или иной комбинации можно посмотреть тут (первая колонка — точность обнаружения, вторая — инвертированный false detect rate, для получения привычной частоты ложных срабатываний обоих родов вычтите из 100% цифру из второй колонки):
Общее представление о точности той или иной комбинации можно посмотреть тут (первая колонка — точность обнаружения, вторая — инвертированный false detect rate, для получения привычной частоты ложных срабатываний обоих родов вычтите из 100% цифру из второй колонки):
Простите, я немного не понял.
То есть для исследования был использован корпоративный (!!!) трафик (пусть и нерасшифрованный по Вашим словам) пользователей коммутаторов, маршрутизаторов и сетевых устройств Cisco в рамках программы телеметрии?
Я правильно всё изложил?
То есть для исследования был использован корпоративный (!!!) трафик (пусть и нерасшифрованный по Вашим словам) пользователей коммутаторов, маршрутизаторов и сетевых устройств Cisco в рамках программы телеметрии?
Я правильно всё изложил?
Ну, отчет Касперского о том, что 23% россиян заклеивают веб-камеру, из той же оперы ;)
Использовалась телеметрия из нескольких офисов Cisco, конечно же, насколько мне известно. У нас довольно большая территориально-распределённая сеть разных офисов, так что для моделирования они подходят неплохо.
Спасибо за ответ.
Мне кажется, об этом стоило бы указать в статье прямо, потому что я по прочтении как-то совсем разочаровался в продукции Cisco.
Вы это разочарование развеяли, правда, «насколько мне известно» осадочек оставляет :)
А если кроме шуток, то в свете найденных NSA-админок и бэкдоров в роутерах Cisco любая информация о телеметрии и анализе трафика весьма настораживает.
Никак официально не прокомментируете?
Мне кажется, об этом стоило бы указать в статье прямо, потому что я по прочтении как-то совсем разочаровался в продукции Cisco.
Вы это разочарование развеяли, правда, «насколько мне известно» осадочек оставляет :)
А если кроме шуток, то в свете найденных NSA-админок и бэкдоров в роутерах Cisco любая информация о телеметрии и анализе трафика весьма настораживает.
Никак официально не прокомментируете?
(к CISCO отношения не имею, просто высказать свое понимание материала)
Насколько понял, тут под телеметрией назван Netflow/IPFIX — суть отключаемые вещи, вы их можете и не отдавать, если не хотите, чтобы «на стороне» кто-то смотрел трафик. Основной посыл статьи, опять же, с моего видения — для качественного детекта имеющегося в корп. сети ВПО можно просто проанализировать куда ВПО стучится, с какой частотой и т.д., а далее использовать любой Threat Intelligence сервис на предмет сопоставления собранных данных с уже известными. Т.е. при желании вы можете у себя все это сами организовать на отдельной железке, завернув туда netflow, настроить, к примеру, splunk и подключив TI. Только это долго и с непонятным результатом, а тут предлагается решение «из коробки», хотя и с передачей части данных трафика «на сторону». Насколько целесообразна такая передача трафика для конкретной организации — решать уже вам как CISO.
Насколько понял, тут под телеметрией назван Netflow/IPFIX — суть отключаемые вещи, вы их можете и не отдавать, если не хотите, чтобы «на стороне» кто-то смотрел трафик. Основной посыл статьи, опять же, с моего видения — для качественного детекта имеющегося в корп. сети ВПО можно просто проанализировать куда ВПО стучится, с какой частотой и т.д., а далее использовать любой Threat Intelligence сервис на предмет сопоставления собранных данных с уже известными. Т.е. при желании вы можете у себя все это сами организовать на отдельной железке, завернув туда netflow, настроить, к примеру, splunk и подключив TI. Только это долго и с непонятным результатом, а тут предлагается решение «из коробки», хотя и с передачей части данных трафика «на сторону». Насколько целесообразна такая передача трафика для конкретной организации — решать уже вам как CISO.
Телеметрия анализируется локально (в Stealthwatch — habrahabr.ru/company/cisco/blog/229073 ), наружу отдаётся только то, на чём можно сделать глобальную корреляцию (и то, если это явно настроить). Отдаётся информация о внешних IP, хэшах ВПО, FQDN-имена запрашиваемых сайтов — для того чтобы понять инфраструктуру вредоноса.
Ждите от зловредов добавления рандомного наполнителя трафика, нивелирующего частотно-временной анализ пакетов :)
Это не так просто сделать, как кажется на первый взгляд, плюс это само по себе является хорошим индикатором для систем статического и динамического анализа — легитимное ПО так не делает.
Нужно не просто рандомно добавлять наполнение — нужно его добавлять таким образом, чтобы в сумме получалось похоже на имитируемое приложение.
Нет, достаточно чтобы ни на что не было похоже. Не существует базы статистических характеристик трафика всех существующих приложений.
Существует, и не одна. Более того, сделать свою базу (для своей компании) вполне посильная задача, полно open-source инструментов. Есть и целый класс коммерческих решений Network Behavior Anomaly Detection — en.wikipedia.org/wiki/Network_Behavior_Anomaly_Detection
То, на что вы ссылаетесь, осуществляет сигнатурный анализ сетевых пакетов, т.е. функция аналогична функции файлового антивируса. Для пакетов с шифрованием неприменима. Без сигнатур такие решения могут лишь набрать статистику в режиме обучения и следить в дальнейшем за их отклонениями, т.е. неприменима для нового программного обеспечения (а вредонос таковым и является). Именно потому, что «Не существует базы статистических характеристик трафика всех существующих приложений.» Принципиально такого существовать не может, поэтому нельзя определить вредонос по отсутствию его в такой мифической базе.
Никаких сигнатур там нет — есть анализ поведения и/или аномалий. Можно, конечно и их назвать сигнатурами второго порядка, но это уже терминологические дебаты. Работает это следующим образом — строятся базовые линии поведения для заданных временных интервалов (например, минута/ 5 минут/ 30 минут/ час / неделя и т.д.), для них ищем аномалии для заданной группы хостов, либо ищем поведение, характерное для вредоносов. Про новое ПО в статье нет ни слова, более того, написано что это работает для известного ВПО.
Никаких сигнатур там нет
А как вы это понимаете?
Most security monitoring systems utilize a signature-based approach to detect threats. They generally monitor packets on the network and look for patterns in the packets which match their database of signatures representing pre-identified known security threats. NBAD-based systems are particularly helpful in detecting security threat vectors in 2 instances where signature-based systems cannot (i) new zero-day attacks (ii) when the threat traffic is encrypted such as the command and control channel for certain Botnets.
In order for NBAD to be optimally effective, a baseline of normal network or user behavior must be established over a period of time.
«Большинство систем мониторинга (безопасности) используют сигнатурный подход для обнаружения угроз. Обычно они мониторят содержимое сетевых пакетов и ищут шаблоны, которые в их базе данных шаблонов представляют заранее идентифицированные, известные угрозы. NBAD-системы в большей степени полезны в обнаружении векторов угроз в двух случаях, когда системы, использующие сигнатурный подход не могут [обнаружить] новые, неизвестные ранее атаки, когда трафик угрозы идёт по зашифрованному каналу, как происходит в случае каналов контроля и управления [вредоносного ПО] для некоторых ботнетов».
«Для того, чтобы NBAD был максимально эффективен, необходимо использовать базовые линии нормального сетевого или пользовательского поведения, которые должны вычисляться на протяжении определённого временного периода».
И где тут сказано, что NBAD использует сигнатуры?
«Для того, чтобы NBAD был максимально эффективен, необходимо использовать базовые линии нормального сетевого или пользовательского поведения, которые должны вычисляться на протяжении определённого временного периода».
И где тут сказано, что NBAD использует сигнатуры?
Нда, я некорректно прочитал. NBAD не использует сигнатурный анализ, они применимы только для софта, который сначала устанавливают, а затем в режиме обучения набирается статистика. То есть неприменимы к новому софту «изкаропки», нужен период когда софт заведомо работает правильно. Потому что не существует баз готовой статистики «правильного трафика» для произвольного существующего софта. Итого, NBAD неприменимы для обнаружения зловредов без применения дополнительно систем с сигнатурным анализом. Таким образом, зловред (троян) использующий шифрование и рандомизацию трафика для размытия частотно-временных характеристик своих пакетов становится невидим как для сетевых антивирусных решений с сигнатурным анализом пакетов, так и для NBAD систем.
Именно для решения данной проблемы и используется глобальная репутация — мы видим обращения к нетипичным внешним IP/FQDN и смотрим их репутацию (плюс известную нам из TALOS корреляцию c инфраструктурой ботнетов). Обойти все три технологии обнаружения одновременно можно, но крайне трудозатратно и дорого.
А можно про open-source инструменты чуть подробнее? Snort вроде несколько про другое, как я понимаю, а что еще есть разумное и рабочее в этом контексте?
Алексей Лукацкий писал про них недавно на Хабре — habrahabr.ru/company/cisco/blog/346160
Инструмент, который использовали авторы — github.com/cisco/joy
В решении ETA функции сбора телеметрии (локально в сети, с помощью виртуальных или аппаратных коллекторов) делает Stealthwatch, он же запрашивает глобальную систему репутации Cognitive Threat Analytics об репутации и взаимосвязи внешних элементов (внешние IP, к которым шли необычные обращения, SHA256 хэши файловых образцов, если используется Cisco AMP, запрашиваемые во внешний мир подозрительные URL и FQDN). CTA требует явной настройки и по умолчанию выключен.
В решении ETA функции сбора телеметрии (локально в сети, с помощью виртуальных или аппаратных коллекторов) делает Stealthwatch, он же запрашивает глобальную систему репутации Cognitive Threat Analytics об репутации и взаимосвязи внешних элементов (внешние IP, к которым шли необычные обращения, SHA256 хэши файловых образцов, если используется Cisco AMP, запрашиваемые во внешний мир подозрительные URL и FQDN). CTA требует явной настройки и по умолчанию выключен.
Обнаружим-не обнаружим, а «телеметрию» (не принадлежащие компании данные) соберем, мало ли для чего ещё пригодится.
Вот бы к снорту или сурикате правила запилили.
Есть такие правила, для SURICATA например. Обнаруживают TOR, по корреляциям в длинах фрагментов TLS. lists.emergingthreats.net/pipermail/emerging-sigs/2017-October/028439.html
Sign up to leave a comment.
Обнаружение известного вредоносного кода в зашифрованном с помощью TLS трафике (без дешифровки)