InfoWatch сообщила о выпуске InfoWatch Traffic Monitor 6.5

InfoWatch сообщила о выпуске InfoWatch Traffic Monitor 6.5

InfoWatch сообщила о выпуске InfoWatch Traffic Monitor 6.5

В ТM 6.5 ключевые технологии анализа InfoWatch применяются не только на уровне сетевого шлюза, но и на конечных устройствах, включая персональные компьютеры и ноутбуки.

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

Интеграция InfoWatch Traffic Monitor в инфраструктуру компании, как и ранее, предполагает развертывание программного агента на рабочих станциях сотрудников. В отличие от предыдущей версии, на агентской части TM 6.5 выполняется лингвистический и сигнатурный анализ обрабатываемых данных, определение текстовых объектов, а также возможна комбинированная работа этих технологий анализа для более точного выявления конфиденциальной информации. Таким образом, блокировка утечек конфиденциальных данных осуществляется непосредственно на конечных устройствах сотрудников.

«Новая версия InfoWatch Traffic Monitor 6.5 позволяет заказчикам перейти от мониторинга инцидентов к их непосредственному предотвращению, — сказал ведущий менеджер по развитию продуктов ГК InfoWatch Александр Клевцов. — С высокой точностью при минимальной нагрузке на рабочую станцию TM 6.5 определяет несанкционированную передачу конфиденциальной информации с устройства сотрудника и блокирует ее, не нарушая непрерывность бизнес-процессов компании. В результате высокий уровень безопасной работы с информацией поддерживается и в пределах офиса, и за границей защищенного периметра».

Настройка политик безопасности TM 6.5 для рабочих станций осуществляется с помощью единого центра управления — консоли InfoWatch Traffic Monitor. Допускается применение отраслевых шаблонов либо создание уникальных политик для каждого конечного устройства.

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

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

M 6.5 ключевые технологии анализа InfoWatch применяются не только на уровне сетевого шлюза, но и на конечных устройствах, включая персональные компьютеры и ноутбуки. " />

ТСПУ начали перенаправлять DNS-запросы к Google и Cloudflare на НСДИ

С вечера 26 августа открытые DNS-запросы к серверам Google и Cloudflare начали перехватываться на российских технических средствах противодействия угрозам (ТСПУ). При обычном UDP-запросе к этим серверам для доменов YouTube и RuTracker возвращался ответ NXDOMAIN, будто таких адресов вообще не существует. Однако запрос по TCP успешно доходил до сервера и получал настоящие IP-адреса.

Об этом сообщил пользователь Хабра angry_agent, изучивший поведение адресов 8.8.8.8 и 1.1.1.1.

Анализ трафика показал ещё более интересную картину. Когда автор отправил DNS-запрос с малым значением TTL, в ответе ICMP TTL Exceeded обнаружился адрес 195.208.5.1, принадлежащий Национальной системе доменных имён (НСДИ), хотя исходный пакет предназначался для 8.8.8.8.

С произвольными UDP-пакетами такой подмены не происходило, система реагировала именно на DNS-трафик.

По версии исследователя, ТСПУ распознаёт открытый DNS-запрос и выполняет направленный DNAT: незаметно меняет адрес назначения и отправляет пакет на сервер НСДИ. Тот уже решает, какой ответ вернуть пользователю. При этом для оператора связи запрос выглядит направленным не к Google, а сразу к НСДИ.

Механизм оказался неидеальным. При быстрой отправке нескольких одинаковых запросов первый получал NXDOMAIN, а следующие всё-таки добирались до Google и возвращали реальные адреса. Кроме того, перенаправление срабатывало не для всех DNS-серверов.

Официального подтверждения такого механизма пока нет, выводы основаны на эксперименте одного пользователя. Напомним, вчера мы писали, что ользователи сразу нескольких российских операторов пожаловались на проблемы с защищёнными DNS-сервисами Google и Cloudflare.

RSS: Новости на портале Anti-Malware.ru