ТризТех

PT NGFW 1.10.3 получил сертификат соответствия ФСТЭК России Что изменилось? 1️⃣ Рекомендуем обновление версии ПО, предыдущая сертифицированная версия 1.8.1 более не поддерживается. Дополнительные действия, помимо обновления до версии 1.10.3, совершать не требуется. 2️⃣ Добавили возможность использования виртуального NGFW в промышленных сетях. PT NGFW в виртуальном исполнении соответствует «Требованиям к Межсетевым экранам», утвержденным приказом ФСТЭК России 9 февраля 2016 г. по профилю Д четвертого класса защиты (ИТ.МЭ.Д4.ПЗ). 3️⃣ Изменения коснулись документации, сертификат №4877 остался прежним. 📄 Сертификат №4877 действует до 19 ноября 2029 года и подтверждает, что PT NGFW: ✅ Соответствует 4 уровню доверия Требований по безопасности информации, устанавливающим уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий (ФСТЭК России, 2020) ✅ Соответствует 4 классу защиты Требования по безопасности информации к многофункциональным межсетевым экранам уровня сети (ФСТЭК России, 2023) ✅ Соответствует 4 классу защиты, Требований к межсетевым экранам (ФСТЭК России, 2016) ✅ Соответствует профилю защиты межсетевых экранов типа Д четвертого класса защиты. 🛡 Где может применяться PT NGFW: ✔️ Значимые объекты КИИ 1 категории значимости ✔️ ГИС 1 класса защищенности ✔️ АСУ ТП 1 класса защищенности ✔️ ИСПДн при необходимости 1 уровня защищенности ✔️ ИС общего пользования II класса

Вышел патч 1.11.1. 🚀 🛠 Сделали ряд улучшений, исправили возникшие проблемы. 📝 Подробности в Release Notes. 🔄 Дистрибутив вы сможете скачать самостоятельно на портале, а также обратившись к вашему представителю или в службу технической поддержки 🤝 ➡️ Обратите внимание, что при проведении обновления на версию 1.11.1, так же, как и на 1.11.0, не используется AppImage файл. Обновление производится с использованием ISO-файлов, т.к. были изменены версии базовых операционных систем и разметка дисков. Перед обновлением, пожалуйста внимательно ознакомьтесь с инструкцией по обновлению.

Мечта номер 1: чтобы все люди в мире понимали эту эстетику и почему мы по ней тащимся.. 🤤 @triztech

Инженерная кухня PT NGFW В рабочем чате появился вопрос: категоризация сайтов работает без TLS-инспекции? Короткий ответ — да, но с ограничениями, о которых стоит знать. Разберем механику. Значение URL для категоризации PT NGFW извлекает из заголовка HTTP. Когда расшифрование не выполняется, заголовки недоступны. Тогда, если SNI доступен, источником становится он: по доменному имени из TLS ClientHello межсетевой экран определяет категорию сайта:

SNI: ya.ru
→ Поисковые системы

Во многих сценариях этого достаточно: блокировка нежелательных категорий, базовая фильтрация, разбор «куда ходят пользователи» работают и без расшифрования. Но у SNI есть предел точности: он дает имя узла, а не путь внутри него. Пока разделы сервиса размещены на разных доменных именах, SNI их различает. А вот если разные разделы и ресурсы доступны через одно доменное имя, без расшифрования они для политики неразличимы: все запросы выглядят как обращение к одному домену. Чем это оборачивается на практике?Представьте ссылку на вредоносный файл, размещенный в известном облачном хранилище. Сервис легитимен, его категория не дает повода для блокировки, и без расшифрования межсетевой экран не может применить политику к конкретному URL внутри него. А если по соединению передается файл, его содержимое становится доступно средствам анализа (антивирусу, IPS) только после расшифрования. Отсюда рабочая связка, а не выбор «или-или». Категория по SNI доступна до расшифрования, поэтому может быть условием правила расшифрования: межсетевой экран сначала узнает категорию, а уже по ней решает, расшифровывать ли соединение. Например, категории, где для решения недостаточно доменного имени (файловые обменники, веб-хранилища), становятся кандидатами на расшифрование; категории, которые организация намеренно не инспектирует (банки, медицина, госуслуги), задаются исключениями явно. Категоризация без расшифрования не конкурирует с инспекцией — она решает, что инспектировать. Второй вопрос из того же чата: PT NGFW сверяется только с локальной базой или запрашивает категории в интернете? Сегодня категоризация выполняется по локальной базе URL, которая регулярно обновляется: в разделе «Обновления» это тип контента «URL категории». У такого подхода есть преимущества: решение принимается на устройстве, быстро и без зависимости от внешних сервисов. Но есть и ограничения: объем базы ограничен хранилищем устройства, а новые ресурсы появляются в ней только с очередным обновлением. Поэтому мы планируем переход на облачный сервис категоризации: заложенные в него механизмы оптимизации позволят принимать решение так же быстро. Хотите разобрать свой вопрос — задайте его в комментариях, будем делать эту рубрику регулярной ⬇️

🚀 PT NGFW 1.11 уже доступен Выпустили один из самых насыщенных релизов PT NGFW за последнее время. Главное нововведение — Remote Access VPN. Теперь сотрудники могут безопасно подключаться к корпоративной сети из любой точки мира с помощью собственного VPN-клиента PT NGFW. Аутентификация пользователей происходит через RADIUS, поэтому можно централизованно управлять доступом и использовать второй фактор. Но этим обновление не ограничивается. В версии 1.11 также появились и были значительно доработаны: 🔘ECMP — теперь несколько равнозначных маршрутов можно использовать одновременно. Это позволяет эффективнее загружать каналы и сохранять передачу трафика при отказе одного из них. 🔘 GRE и GRE over IPsec — больше вариантов для подключения удаленных площадок, в том числе с динамической маршрутизацией. 🔘Jumbo Frames — поддержка увеличенного размера Ethernet-кадров для высокопроизводительных сетей и ЦОД. Благодаря этому можно передавать большие объемы данных меньшим количеством пакетов, снижая накладные расходы на их обработку. 🔘 Добавлена поддержка подстановочных символов (wildcards) при настройке URL-фильтрации, благодаря чему весь процесс становится для администраторов быстрее и проще. 🔘Управление маршрутизацией тоже стало комфортнее: пользователь может настроить профили проверки доступности узлов, и в случае необходимости трафик автоматически, без ручного вмешательства пользователя переключится на резервный канал. 💱 Узнать обо всех изменениях, улучшениях и исправлениях в Release Notes. Для нас каждый релиз — это результат обратной связи от инженеров, партнеров и заказчиков, которые каждый день работают с PT NGFW в реальной инфраструктуре. ➡️ Если хотите подробнее разобраться в релизе 1.11, посмотреть демонстрацию Remote Access VPN и узнать, что нового появилось в продукте, рекомендуем запись нашего вебинара, где команда разработки подробно разбирает все изменения. 🔄 Дистрибутив вы сможете скачать самостоятельно на портале, а также обратившись к вашему представителю или в службу технической поддержки 🤝

TLS-инспекция включена. А трафик точно расшифровывается? Споры вокруг TLS-инспекции обычно сводятся к двум позициям. Одни говорят: без расшифрования NGFW почти ничего не видит. Другие отвечают: включите расшифрование везде — получите проблемы с приложениями, сертификатами и производительностью. 💱 На практике вопрос интереснее: не включена ли инспекция, а какую долю трафика, подлежащего инспекции, межсетевой экран действительно проверяет? Без расшифрования NGFW не становится слепым. Продолжают работать правила по зонам, адресам, GeoIP и сервисам, блокировка известных вредоносных доменов, часть IPS-сигнатур по сетевым признакам. Используются и доступные данные TLS-рукопожатия: например, PT NGFW при отключенном расшифровании может определять URL-категорию по SNI из ClientHello. Но эта остаточная видимость сокращается на уровне самих протоколов. В TLS 1.3 большая часть рукопожатия уже зашифрована, включая сертификат сервера. А в марте 2026 года опубликован RFC 9849 — стандарт Encrypted Client Hello, который позволяет скрывать в том числе SNI. Например, Firefox использует ECH там, где серверная и DNS-инфраструктура его поддерживают. То есть подход «не расшифровываем, но домен все равно увидим» перестает быть универсальным. При этом полезная нагрузка HTTPS без расшифрования остается недоступной. Межсетевой экран может видеть соединение с download.example.com, но не знает, что передается внутри: документ, архив или вредоносный файл. Проверки, которым нужна полезная нагрузка, — например, анализ передаваемых файлов и часть IPS-сигнатур прикладного уровня, — эту видимость теряют. 📎 С другой стороны, включить TLS-инспекцию одной галочкой и считать задачу решенной тоже нельзя. Часть трафика приходится исключать намеренно, например из-за особенностей приложений или закрепления сертификата. Где-то расшифрование невозможно из-за технических ограничений. Клиентские устройства должны доверять корневому сертификату, которым NGFW подписывает сертификаты при расшифровании. Сам процесс требует вычислительных ресурсов. Поэтому реальная картина — это всегда три категории трафика: этот расшифровываем, этот намеренно исключили, этот не смогли расшифровать. Первые две задаются правилами, третья видна только по факту — из журнала. И здесь появляется показатель полезнее, чем «включено/выключено»: покрытие TLS-инспекцией. Из самой настройки политики не видно, какая доля HTTPS-трафика действительно расшифровывается, какие приложения чаще всего оказываются вне инспекции и где срабатывают исключения. В PT NGFW техническая база для такого контроля уже есть. Правила расшифрования позволяют задавать как инспекцию, так и явные исключения. В журнале трафика фиксируется признак decrypted, а отдельный журнал расшифрования показывает сработавшее правило, версию TLS, ошибки и этап, на котором не состоялось TLS-рукопожатие. Следующий логичный шаг — относиться к TLS-инспекции как к измеримому механизму защиты: считать долю реально расшифрованного трафика, причины пропуска и основные слепые зоны. Такой отчет о покрытии — естественное развитие наблюдаемости NGFW. Поэтому вопрос «стоит ли выключать TLS-инспекцию?» кажется нам не совсем правильным. Полезнее другой: какой трафик мы не расшифровываем — намеренно или из-за технических ограничений — и где эти слепые зоны создают наибольший риск? Потому что наличие TLS-инспекции в спецификации NGFW еще ничего не говорит о том, сколько зашифрованного трафика устройство действительно видит 🫡 💬 Чат для общения | Попробовать тест-драйв

SASE убьет NGFW? Скорее — представление о firewall как о коробке на периметре В августе 2025 года Gartner выпустил первый Magic Quadrant по категории Hybrid Mesh Firewall. ➡️ Показательно само изменение рамки: межсетевой экран теперь рассматривается не как одно устройство на периметре, а как набор физических, виртуальных и облачных точек применения политики с централизованным управлением. Показательно и происхождение категории: это прямой наследник квадранта по NGFW. Умер не NGFW — умерло представление о нем как об одной коробке на периметре. И произошло это не так, как обещали евангелисты SASE. При этом SASE остался отдельной категорией Gartner, а часть крупнейших вендоров присутствует одновременно и в SASE, и в HMF. То есть рынок движется не к простой замене одной архитектуры другой, а к их сосуществованию. Почему? SASE действительно забирает часть сценариев, ради которых трафик раньше вели через межсетевой экран на периметре. Доступ пользователей и филиалов к интернету, SaaS и корпоративным приложениям можно контролировать через облачные точки присутствия с помощью ZTNA, SWG, CASB и FWaaS. Но firewall как механизм применения сетевой политики от этого не исчезает. Меняется место, где политика применяется. Для удаленного пользователя такой точкой может быть FWaaS. Для трафика между сегментами ЦОД — аппаратный или виртуальный NGFW. Для облачной инфраструктуры — cloud firewall. Идея Hybrid Mesh Firewall как раз в том, что точек применения становится много, а управляться они должны как части одной системы. И здесь появляется проблема интереснее, чем «SASE против NGFW». Сотрудник прошел аутентификацию и проверку устройства через ZTNA. Через несколько минут он обращается к внутреннему приложению, и его трафик уже идет через NGFW между сегментами. Что видит межсетевой экран — только IP-адрес или тот же контекст: кто пользователь, в какой он группе, с какого устройства работает и не изменился ли уровень риска? Если точки применения политики не используют общий контекст, внутренняя сегментация работает вслепую относительно того, что уже известно на входе. Поэтому правильнее говорить не «SASE или NGFW», а единый контекст безопасности при разных точках применения политики. 💱 В PT NGFW базовый фундамент для такой модели уже есть: пользователь или группа могут быть условием того же правила безопасности, что и приложение. Следующий вопрос — как не ограничивать этот контекст одним межсетевым экраном и использовать его согласованно в разных точках применения политики. В российских условиях проблема согласованности становится особенно заметной. Инфраструктура часто собирается из решений разных классов и вендоров, а переходный период дополнительно создаёт смешанные среды. Чем больше независимых систем принимают решения о доступе, тем дороже обходится рассинхронизация между ними. Так что вопрос «убьет ли SASE NGFW» можно отправить в архив вместе со старым представлением о межсетевом экране как о коробке на периметре. Актуальный вопрос другой: кто заставит все точки применения политики принимать согласованное решение о доступе, когда пользователь, устройство и риск меняются в реальном времени? 😏 💬 Чат для общения | Попробовать тест-драйв

IDS с автоматической блокировкой — это уже IPS? Не совсем Под статьей про IPS на Хабре получилась содержательная дискуссия. Один из инженеров описал рабочую схему: Suricata получает копию трафика через SPAN, обнаруживает угрозу, скрипт разбирает журнал и через API добавляет IP-адрес в список блокировки на MikroTik. Автор несколько лет использует эту схему в рабочей инфраструктуре. На первый взгляд получается почти IPS: атаку обнаружили, источник автоматически заблокировали. Но важнее не название, а момент, когда принимается решение о пропуске трафика. В схеме со SPAN Suricata анализирует копию пакета. Оригинальный пакет к этому времени уже передан дальше. Затем событие должно попасть в журнал, его должен обработать скрипт, после чего изменится состояние межсетевого экрана. Это нормальная архитектура обнаружения с автоматической реакцией. Она вполне подходит, например, для блокировки известного C2 или подавления сканирования. Но она не гарантирует предотвращения той попытки эксплуатации, которая вызвала сработку. К моменту блокировки необходимые атакующему данные уже могли попасть на защищаемый сервер. Здесь и проходит основная граница с IPS, работающим в разрыв трафика. 💱 При этом дело не в Suricata. Она сама умеет работать в режиме IPS и блокировать трафик непосредственно при его прохождении. Поэтому корректнее сравнивать не «Suricata против встроенного IPS», а две архитектуры: анализ копии трафика + внешняя реакция и обнаружение + блокировка непосредственно в тракте прохождения трафика. Но и представление «IPS проверил первый пакет и сразу все понял» слишком упрощено. Для части атак одного пакета недостаточно. Системе может потребоваться состояние TCP-потока, данные прикладного протокола, а иногда и расшифрованный TLS-трафик. Поэтому окончательное решение может появиться не сразу: документация Suricata описывает режим IPS как анализ накопленного потока, а не отдельных пакетов. Получается, окно «данные уже идут, а решения еще нет» есть у обеих архитектур. У NGFW оно возникает из-за классификации: часть данных необходимо пропустить, чтобы определить протокол или приложение. Разница в том, что в схеме со SPAN это окно не закрыто ничем, а в разрыв трафика его можно закрыть отдельным механизмом. В PT NGFW таким механизмом служит IPS-профиль преклассификации. Он проверяет трафик, пока данных еще недостаточно для определения приложения и окончательного правила безопасности. То есть часть защиты включается ещё до того, как межсетевой экран полностью классифицировал сессию. Поэтому вопрос «стоит ли переплачивать за встроенный IPS?» мы ставим иначе. Платим не столько за сигнатуры, сколько за то, как механизм обнаружения встроен в обработку трафика и применение решения: - где относительно трафика принимается решение; - что происходит с данными до завершения классификации; - какой контекст доступен движку в момент решения: приложение, пользователь, расшифрованный TLS; - какой ценой это достигается по производительности и сложности эксплуатации. 🔘Если задача — видеть угрозы и ограничивать дальнейшую активность, Suricata на SPAN с автоматической реакцией через межсетевой экран может быть отличным и экономически разумным решением. 🔘Если требование звучит как «эта попытка эксплуатации не должна дойти до сервиса», обнаружение и блокировка должны находиться непосредственно в тракте прохождения трафика. Это точнее описывает разницу между IDS с автоматической реакцией и IPS, чем привычное «IDS обнаруживает, IPS блокирует». Если такие технические разборы интересны — напишите в комментариях, продолжим 😉

Как безболезненно мигрировать с Check Point, FortiGate или Cisco ASA? Мы продолжаем получать от пользователей один и тот же вопрос: как перейти на PT NGFW без ручного переписывания сотен правил и бессонных ночей? Для этого у нас есть утилиты миграции, которые помогают перенести существующие политики безопасности с популярных решений в PT NGFW. Миграция поддерживается и для других платформ, изучить больше вы можете по ссылке ниже 😉 Утилиты автоматически преобразуют конфигурации в формат PT NGFW, что позволяет значительно сократить время перехода и снизить риск ошибок при переносе. Скачать утилиту миграции можно здесь: 👉 https://addons.ptsecurity.com/utility-migraczii-na-pt-ngfw-1-6 Если у вас уже есть опыт миграции на PT NGFW — расскажите в комментариях, с какого решения переходили и с какими сложностями столкнулись. Это поможет коллегам, которым переход еще только предстоит.

Мы растем. И продолжаем собирать одну из сильнейших команд в российском сетевом рынке За последний год ТризТех прошел путь от идеи до отдельной компании с собственным продуктом, сотнями заказчиков и амбициями построить полноценную линейку сетевых решений. Впереди — еще больше. Поэтому сейчас мы открыли сразу несколько ключевых вакансий. Инфраструктура: 🔘 Руководитель отдела инфраструктуры Разработка: 🔘 ML Engineer (NGFW) 🔘 Старший / ведущий C++ разработчик Тестирование: 🔘 QA Engineer (VPN) 🔘 Senior QA Performance Engineer Инжиниринг: 🔘 Технический лидер / Head of Engineering Мы не просто развиваем PT NGFW. Мы строим нового российского вендора сетевых технологий. Если вам близок инженерный подход, хочется создавать технологии мирового уровня и влиять на развитие продукта с первых дней — будем рады познакомиться. 📩 Изучайте вакансии и присылайте резюме по ссылкам выше

Что пропустили? Собрали главные новости ТризТеха за последнее время 👇 1️⃣ Большое интервью Дениса Кораблева для «Коммерсанта» Вышло большое интервью генерального директора ТризТеха, где поговорили не только о PT NGFW, но и о будущем компании. Почему Positive Technologies выделила направление в отдельную компанию? Какие продукты появятся после NGFW? Какой рынок мы строим и почему считаем, что конкурировать нужно не с российскими вендорами, а с мировыми лидерами? Все ответы по ссылке выше. 2️⃣ Финансовые результаты PT NGFW Подвели итоги первого полугодия. Главная цифра: объем отгрузок PT NGFW за первые шесть месяцев 2026 года уже превысил результат всего 2025 года. Подробнее изучить можно здесь. 3️⃣ Новые обучающие видео Продолжаем развивать библиотеку технических материалов по PT NGFW. Уже вышли новые обучающие ролики, где наши эксперты показывают настройку функций продукта, отвечают на частые вопросы и разбирают реальные сценарии эксплуатации. И это только начало — сейчас готовим новую серию видеоуроков и технических разборов. 4️⃣ Анонс блога в запрещенной сети Там меньше официальных новостей и больше жизни команды: короткие технические ролики, инженерные мемы, закулисье разработки, выступления экспертов и контент о том, как создаются современные сетевые продукты. Следите за обновлениями — будет интересно 🔥 💬 Чат для общения | Попробовать тест-драйв

Ни в коем случае не отвечайте на эти звонки 🙏 Вдруг вас заставят работать? @triztech

🔥 PT NGFW за полгода превысил результат всего 2025 года по объему отгрузок Всего за шесть месяцев объем отгрузок PT NGFW уже превысил показатель за весь 2025 год. По сравнению с первым полугодием прошлого года объем отгрузок вырос на порядок — в том числе благодаря ряду крупных сделок. ➡️ За первое полугодие количество заказчиков выросло в 2,5 раза по сравнению с аналогичным периодом 2025 года — PT NGFW используют больше 130 компаний. Всего за отчетный период было отгружено около 500 устройств. Но особенно хорошо рост интереса к PT NGFW отражают два факта: 🔘 Крупнейшая сделка в истории «Группы Позитив», заключенная в первом полугодии 2026 года, была связана именно с поставкой PT NGFW. 🔘 Основой крупнейшей международной сделки Positive Technologies по состоянию на конец отчетного периода также стал PT NGFW. Для нас эти цифры — показатель того, как накопленный за предыдущие годы технологический потенциал начинает превращаться в конкретные бизнес-результаты.

«Объем отгрузок PT NGFW за первые шесть месяцев уже превысил результат всего прошлого года, а по сравнению с первым полугодием 2025 года вырос на порядок. Еще год назад рынок воспринимал PT NGFW как новый продукт, которому предстояло доказать свою конкурентоспособность. Сегодня крупнейшие российские компании выбирают его для защиты своей сетевой инфраструктуры. Динамика первого полугодия вселяет в нас оптимизм и дает надежду на то, что по итогам 2026 года мы будем бороться за первые строчки среди российских вендоров NGFW по объему отгрузок», – подчеркнул Денис Кораблев, генеральный директор компании «ТризТех».

При этом спрос на PT NGFW формируется уже не только за счет потребности заказчиков в импортозамещении. Продукт все чаще становится частью проектов, где сетевая защита создается с нуля, а также приходит на замену российским решениям, внедренным после 2022 года. Для нас это, пожалуй, один из самых важных сигналов рынка: выбор PT NGFW становится не вынужденной заменой ушедших технологий, а осознанным выбором для построения сетевой безопасности. Первое полугодие закончили с серьезным ускорением. Двигаемся дальше — бороться за первые строчки российского рынка NGFW 🔥 @triztech

🫥 Серия обучающих видео от экспертов PT NGFW Мы регулярно снимаем для вас уроки, где простым языком объясняем, как работать с PT NGFW и отвечаем на часто задаваемые вопросы. Список тем пополняется, и мы уже в процессе съемки новых видео! Сохраняем для вас подборку имеющегося материала: 1️⃣ Обновление узла PT NGFW со старой версии на новую 2️⃣ Обновление системы управления PT NGFW 3️⃣ Обновление системы управления PT NGFW в режиме кластера 4️⃣ Как настроить SNMP в PT NGFW? 5️⃣ Настройка базовых профилей безопасности: IPS и антивирус 6️⃣ Настройка журналирования и отправка логов по протоколу syslog ➡️ Сохраняйте себе плейлист

Боимся, что никто так и не найдет никого лучше 😎 ➡️ Мы создали блог в Instagram*, переходите по ссылке и подписывайтесь *Meta Platforms Inc. признана экстремистской организацией и запрещена на территории Российской Федерации.

🥳 ИИ научился находить 0-day, сбегать из песочницы и атаковать инфраструктуру. Но попросите его починить ваш собственный код — и он может отказаться За последние недели вокруг американских и китайских ИИ-моделей накопилось столько интересных кейсов, что получается довольно странная картина. Начнем с Hugging Face. Во время тестирования кибервозможностей GPT-5.6 Sol и ее более продвинутой предварительной версии модели запускали без обычных защитных барьеров, чтобы понять предел их возможностей. По опубликованному описанию, модели вышли за пределы изолированной среды. Они обнаружили возможность получить доступ в интернет через кэш-прокси реестра пакетов, повысили свои привилегии, нашли уязвимость нулевого дня и в итоге добрались до инфраструктуры Hugging Face. Целью стали серверы, связанные с тестовыми решениями для ExploitGym. Причем речь не шла о заранее прописанном сценарии «найди уязвимость Hugging Face». Модели искали способы решить поставленную перед ними задачу и в процессе вышли далеко за предполагаемые границы тестовой среды. Аномальную активность заметила служба безопасности OpenAI. После этого подключились специалисты Hugging Face, активность остановили, найденную 0-day ответственно раскрыли поставщику, а Hugging Face включили в программу доверенного доступа. И здесь начинается особенно забавная часть истории: когда Hugging Face потребовалось разобраться в произошедшем, американские модели, по опубликованным рассказам об инциденте, начали отказываться выполнять часть действий, ссылаясь на ограничения в области кибербезопасности. Тогда исследователи развернули китайскую GLM без аналогичных ограничений — и использовали ее для расследования. А теперь история практически повторилась. Исследователь из Twitter попробовал дать Codex и Fable уязвимый собственный код и попросил помочь найти и исправить проблемы. Обе модели, по его словам, уперлись во встроенные ограничения безопасности. Он дал ту же задачу китайской Kimi K3 — она просто взяла и сделала работу. Получается парадокс современной ИБ: ➡️ американская модель без ограничений находит 0-day, выбирается из изоляции и добирается до внешней инфраструктуры. ➡️ американская модель с ограничениями сообщает «Извините, я не могу помочь вам с этим кодом». ➡️ китайская модель без вопросов говорит «ок, давай глянем». Но считать Китай однозначным победителем этой истории тоже рано — давайте вспомним DeepSeek? В Google публичные чаты оказались доступны в поисковой выдаче. При введении запроса в поисковике выдается целый ряд переписок в формате Shared Conversations т.е. общие разговоры. И все это происходит на фоне большой технологической войны. США пытаются ограничивать распространение китайских ИИ-технологий и обсуждают санкции против китайских разработчиков из-за предполагаемого нарушения прав интеллектуальной собственности. Китай, в свою очередь, активно развивает собственные модели и все серьезнее относится к контролю доступа иностранцев к своим технологиям. Россия при этом подписала с Китаем меморандум о сотрудничестве в области ИИ. В итоге гонка становится интереснее, чем просто «у кого модель умнее». Теперь вопросов гораздо больше. 💬 Чат для общения | Попробовать тест-драйв

🙂 «Переходить надо не с иностранного на российское, а с хорошего на лучшее» В «Коммерсанте» вышло большое интервью с генеральным директором ТризТеха — Денисом Кораблевым — о том, зачем направление выделилось в отдельную компанию, как развивается PT NGFW и почему наши амбиции не заканчиваются одним продуктом. Positive Technologies (PT) выделила сетевое направление в отдельную компанию «ТризТех», передав ей права на разработку межсетевого экрана нового поколения PT NGFW в 2025 году. По итогам 2025 года выручка продукта составила около 3 млрд руб., что ниже ожиданий (5–10 млрд руб.), однако в компании прогнозируют рост минимум до 7,5 млрд руб. в 2026 году. В уставный капитал новой структуры технология внесена с оценкой 12,5 млрд руб., а сама компания «ТризТех» намерена развивать не только NGFW, но и смежные сетевые продукты — балансировщики нагрузки, дата-центровые коммутаторы и Wi-Fi-контроллеры. Мы не хотим, чтобы российские технологии выбирали просто потому, что «надо импортозаместиться». Наша задача — создавать инженерные продукты, которые выбирают потому, что они действительно лучше решают задачи заказчика. А рождение компании позволяет нам стать еще ближе к тем, для кого мы все это создаем:

«Выделение «ТризТеха» в отдельную компанию позволяет говорить на языке директоров по ИТ, архитекторов, выходить на сетевых инженеров напрямую и расширять охват рынка, не конфликтуя с позиционированием материнской компании».

➡️ Читать статью

Запись вебинара «За пределами сигнатур: продвинутые функции IPS, выявление атак в TLS, интеграция с Sandbox и не только» от 16 июля готова! Не получилось присутствовать онлайн? Сейчас самое время запланировать просмотр записи. Кстати, можете этим видео заменить просмотр вечернего стендапа — наши коллеги Михаил и Евгений имеют огромный потенциал в юморе, судя по реакции в чате участников! 😁 ➡️ Просмотреть запись на сайте ➡️ Или на RUTUBE

Когда продуктом пользуются сотни людей, легко увидеть результат. Намного сложнее увидеть людей, которые стоят за решениями и архитектурой Сегодня знакомим вас с Антоном Кузнецовым — Chief Product Officer ТризТеха — человеком, который отвечает за всю разработку в команде PT NGFW. ▶️ Антон родился и вырос в Москве. Еще в школе ему одинаково нравились и точные науки, и гуманитарные дисциплины. По его словам, именно сочетание логики и творчества в итоге привело его в технологии. Неспроста к нам приходят такие люди: даже в нашем названии мы несем идеологию творчества решения инженерных задач 😉 Высшее образование он получил в МТУСИ по направлению разработки программного обеспечения. Тогда программирование казалось ему почти магией, ведь это возможность создавать сложные системы буквально из идей. И, кажется, это ощущение не исчезло до сих пор. В ИТ и кибербезопасности Антон работает уже более 16 лет. За это время успел пройти путь от инженерных и продуктовых задач до ответственности за развитие крупных B2B-направлений и команд. Последние семь лет занимается развитием сложных enterprise-продуктов, где недостаточно просто написать хороший код или придумать красивую функцию. Антон сам об этом говорит с трепетом:

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

До ТризТеха Антон работал в BI.ZONE, где вместе с командой запускал и развивал направления Threat Intelligence и Brand Protection практически с нуля. Это был опыт превращения экспертизы в полноценные продукты, понятные бизнесу. 📎 Сегодня его зона ответственности — развитие и разработка PT NGFW. Это один из самых сложных продуктов в компании. Еnterprise-решения редко прощают ошибки и там практически не бывает лишних элементов. Любое слабое место рано или поздно начинает влиять на весь продукт, поэтому роль Антона — выстроить систему, в которой продукт растет стабильно без потери качества. Во многом большая часть работы Антона — помогать большой команде инженеров, архитекторов, аналитиков и разработчиков двигаться в одном направлении. Чтобы из тысяч технических решений рождался продукт мирового уровня. На вопрос о профессиональной миссии Антон отвечает так:

«Хочется показать, что в России можно создавать действительно сложные B2B on-premise продукты, которые способны конкурировать не только локально, но и на глобальном рынке. Исторически у многих enterprise-продуктов были проблемы с качеством, вниманием к пользователю и инженерной составляющей. Моя миссия — поднять эту планку».

Вне работы Антон увлекается компьютерными играми, сноубордом, любит караоке и встречи с друзьями 🏂 Но большую часть свободного времени старается проводить с семьей. Вместе с супругой они много путешествуют, а дома их всегда ждут кот и собака, которые регулярно напоминают, что кроме релизов, роадмапов и производительности существуют еще и другие важные вещи ❤️ #Команда

Начинаем вебинар, где обсудим, как эффективно выявлять современные атаки, в том числе скрытые в зашифрованном трафике ➡️ Ссылка для подключения и таймкоды в реальном времени будут в нашем чате