Организация внутреннего Центр мониторинга и реагирования на инциденты ИБ
Построение SOC
Выполнение требований по защите ПДн
в соответствие с 152-ФЗ
в соответствие с 152-ФЗ
Защита персональных данных
Создание централизованной ИБ-системы
на предприятии
на предприятии
Построение СОИБ
Объективная оценка ИБ для повышения уровня киберустойчивости
Аудит ИБ
Внедрение принципов ИБ на всех этапах разработки По от сборки до интеграции и развертывания
Безопасная разработка
Оценка защищенности систем и определение возможных векторов атак
Анализ защищенности
Выявление критичных недостатков ИБ и укрепление защиты ИТ-инфраструктуры
Экспресс-повышение уровня защищенности
Защита от сетевых атак, аудит архитектуры
и подбор средств защиты сети
и подбор средств защиты сети
Сетевая безопасность
Подключение к платформе цифрового рубля с полным сопровождением на всех этапах
Цифровой рубль
Выполнение требований 187-ФЗ и организация защиты информационных систем от киберугроз
Комплексная киберзащита субъектов КИИ
Комплексная проверка скрытых признаков компрометации на ИТ-инфраструктуру организации
Compromise Assessment
Программный комплекс на базе ePlat4m, обеспечивающий автоматизацию процессов ИБ
Автоматизация управления ИБ
Защита веб-приложений
WAF
Защита конечных точек
EDR
Анализ трафика
NTA
Управление уязвимостями
Sandbox
Автоматизация процессов управления ИБ, рисков и комплаенса
SGRC
Управление учетными записями и доступом
IdM/IGA
Межсетевые экраны нового поколения
NGFW
Управление уязвимостями
VM
Анализ и корреляция событий
SIEM
Комплексное решение для контроля соответствия требованиям ИБ
CheckU
Непрерывный мониторинг и оперативное реагирование на инциденты для минимизации ущерба
УЦСБ SOC
Облачная DevSecOps-платформа
для непрерывного анализа защищенности приложений
для непрерывного анализа защищенности приложений
Apsafe
Разбор актуальных тем по информационной безопасности от экспертов УЦСБ
Вебинары
Регулярные ответы на вопросы по инфомационной безопасности
FAQ ИБ
Последние новости и мероприятия Центра кибербезопасности УЦСБ
Новости
Получить рекомендацию
Заполните форму, и специалист Центра кибербезопасности свяжется с вами
Нажимая кнопку «Отправить», я даю свое согласие на обработку моих персональных данных, в соответствии с Федеральным законом от 27.07.2006 года № 152-ФЗ
«О персональных данных», на условиях и для целей, определенных в Согласии на обработку персональных данных
«О персональных данных», на условиях и для целей, определенных в Согласии на обработку персональных данных
ИИ в кибербезопасности
Внедрение передовых ИИ-решений для автоматизации процессов и повышения эффективности ИБ-команд
Единая экосистема защиты
Объединим технологии мониторинга, анализа и реагирования в единый контур кибербезопасности
Подключение к ЕБС под ключ
Поможем выбрать модель подключения к единой биометрической системе без лишних рисков
Сетевая безопасность
Защита от сетевых атак, аудит архитектуры
и подбор средств защиты сети
и подбор средств защиты сети
Построение SOC
Организация внутреннего Центр мониторинга и реагирования на инциденты ИБ
Защита персональных данных
Выполнение требований по защите ПДн
в соответствие с 152-ФЗ
в соответствие с 152-ФЗ
Построение СОИБ
Создание централизованной ИБ-системы
на предприятии
на предприятии
Автоматизация управления ИБ
Программный комплекс на базе ePlat4m, обеспечивающий автоматизацию процессов ИБ
Комплексная киберзащита субъектов КИИ
Выполнение требований 187-ФЗ и организация защиты информационных систем от киберугроз
Compromise Assessment
Комплексная проверка скрытых признаков компрометации на ИТ-инфраструктуру организации
Цифровой рубль
Подключение к платформе цифрового рубля с полным сопровождением на всех этапах
Экспресс-повышение уровня защищенности
Выявление критичных недостатков ИБ и укрепление защиты ИТ-инфраструктуры
Расследование инцидентов ИБ
Минимизация ущерба, выявление причин предотвращение повторных инцидентов
Аудит ИБ
Объективная оценка ИБ для повышения уровня киберустойчивости
Безопасная разработка
Внедрение принципов ИБ на всех этапах разработки По от сборки до интеграции
и развертывания
и развертывания
Анализ защищенности
Оценка защищенности систем и определение возможных векторов атак
MFA
Многофакторная аутентификация
IRP/SOAR
Защита от сетевых атак, аудит архитектуры
и подбор средств защиты сети
и подбор средств защиты сети
NGFW
Межсетевые экраны нового поколения
PAM
Контроль привилегированного доступа
TI
Киберразведка
SA
Повышение киберграмотности сотрудников
WAF
Защита веб-приложений
DLP
Предотвращение утечек информации
SGRC
Автоматизация процессов управления ИБ, рисков и комплаенса
IdM/IGA
Управление учетными записями и доступом
EDR
Защита конечных точек
NTA
Анализ трафика
Sandbox
Сетевые лесочницы
VM
Управление уязвимостями
SIEM
Анализ и корреляция событий
CheckU
Комплексное решение для контроля соответствия требованиям ИБ
УЦСБ SOC
Непрерывный мониторинг и оперативное реагирование на инциденты для минимизации ущерба
Apsafe
Облачная DevSecOps-платформа
для непрерывного анализа защищенности приложений
для непрерывного анализа защищенности приложений
DLP-сервис
Защитите конфиденциальные данные от утечек без капитальных затрат
Чтобы сделать сайт более удобным,
мы собираем cookie-файлы. Отключить сбор cookie можно в настройках браузера. Подробную информацию о файлах cookie можно изучить здесь.
мы собираем cookie-файлы. Отключить сбор cookie можно в настройках браузера. Подробную информацию о файлах cookie можно изучить здесь.
Ответы на вопросы к вебинару «Защита ИИ, которую нельзя игнорировать в 2026 году»
3 августа 2026
28 июля состоялся вебинар «Защита ИИ, которую нельзя игнорировать в 2026 году». Эксперты УЦСБ и AppSec Solutions рассказали, как защитить ИИ-системы, соответствовать актуальным нормативным требованиям и выбрать эффективные средства защиты.
В этом материале собрали ответы на самые интересные вопросы зрителей.
28 июля состоялся вебинар «Защита ИИ, которую нельзя игнорировать в 2026 году». Эксперты УЦСБ и AppSec Solutions рассказали, как защитить ИИ-системы, соответствовать актуальным нормативным требованиям и выбрать эффективные средства защиты.
В этом материале собрали ответы на самые интересные вопросы зрителей.
Есть ли интегральная оценка для угроз, или просто «светофор»? И учитывает ли интегральная оценка информацию по инфраструктуре и применяемым мерам митигации? Когда планируется появление интегральной оценки?
Методика использует двухфакторную матрицу 3x3 (вероятность L/M/H x критичность L/M/H), дающую 4 уровня риска в соответствии с матрицей: низкий, средний, высокий, критический — итоговую оценку для одной угрозы.
В результате работы для каждого класса угроз формируется таблица с перечислением актуальных рисков, указанием их уровня и кратким обоснованием. При необходимости оперативно получить единую общую оценку эти результаты можно использовать в качестве параметров.
Инфраструктура и внедрённые меры учитываются при заполнении чек-листа актуальности угроз: на основе ответов по каждой угрозе определяется, какие меры защиты уже внедрены и на каком уровне зрелости. Затем корректируется приоритет внедрения дополнительных контролей для угроз, по которым меры уже реализованы на достаточном уровне.
В результате работы для каждого класса угроз формируется таблица с перечислением актуальных рисков, указанием их уровня и кратким обоснованием. При необходимости оперативно получить единую общую оценку эти результаты можно использовать в качестве параметров.
Инфраструктура и внедрённые меры учитываются при заполнении чек-листа актуальности угроз: на основе ответов по каждой угрозе определяется, какие меры защиты уже внедрены и на каком уровне зрелости. Затем корректируется приоритет внедрения дополнительных контролей для угроз, по которым меры уже реализованы на достаточном уровне.
Есть ли шаблон модели угроз для ИИ моделей?
Есть чуть шире – для ИИ-систем. Для отдельной ИИ-модели делать модель угроз как будто бессмысленно: она не работает в вакууме.
В приложении к Методике есть шаблон модели угроз для ИИ-систем: общие сведения, архитектура ИИ-контура, таблица активов, перечень угроз с уровнями риска, обоснование исключённых угроз. Также в приложении есть готовые примеры заполнения (ИИ-чат, ИИ-система с RAG, ИИ-агент).
В приложении к Методике есть шаблон модели угроз для ИИ-систем: общие сведения, архитектура ИИ-контура, таблица активов, перечень угроз с уровнями риска, обоснование исключённых угроз. Также в приложении есть готовые примеры заполнения (ИИ-чат, ИИ-система с RAG, ИИ-агент).
ФСТЭК вынес на обсуждение проект приказа, который полностью отменит приказ №21 и перепишет правила защиты ПДн. Новое направление, которого не было вовсе, — это защита информации при использовании ИИ. Как по вашему мнению, возможно реализовать все предусмотренные 21 мероприятие по обеспечению безопасности для защиты информации при использовании ИИ? Какие из существующих на рынке СЗИ помогут в этом?
В зависимости от формулировок в финальной версии приказа можно будет дополнить исходные требования для разработки модели угроз в Методике, расширив существующие классы или добавив новые. Затем пересмотреть маппинг угроз на меры защиты. И уже в зависимости от выбранных мер защиты подбирать конкретные инструменты (маппинг «мера-инструменты» также зафиксирован в приложении к Методике).
Что входит в аудит?
Аудит ИИ-системы включает интервью с сотрудниками и техническое исследование, подготовку описания компонентного состава системы и связей элементов внутри неё, включая информацию об обрабатываемых данных и пайплайнах их передачи и изменения.
Как в методике проверяется не наличие меры защиты, а её фактическая эффективность против конкретного сценария атаки?
В два этапа. На первом проверяем по чек-листу, внедрена ли мера вообще и есть ли хоть какая-то защита. На втором проводим инструментальный анализ защищённости: проверяем, действительно ли меры останавливают реальные сценарии атак.
По «Алисе.Про» проводили оценку и какие меры защиты рекомендуете?
Оценка по методике не проводилась, так что конкретных мер назвать не можем. Вообще набор защиты зависит от того, какие у системы есть компоненты и интерфейсы. Если у «Алисы» доступ в интернет — одни риски, если работает в изолированном контуре и есть доступ к соседним системам — другие. Без описания контура рекомендации будут слишком общими.
Есть ли оценка вероятности наступления недопустимых событий в связи с применением отдельных инструментов, снижение на какой процент дает каждый? Существуют ли бенчмарки по отрасли по атакам на ИИ системы и инцидентам с ними?
Процентов и гарантированных цифр снижения риска от конкретного инструмента нет, для этого нужна как минимум накопленная статистика инцидентов, которой в отрасли ещё мало.
Бенчмарки существуют, но они почти сразу после публикации отстают от быстро развивающейся индустрии атак на ИИ, поэтому какого-то актуального, чтобы можно было на нём прогнать инструмент и сказать, что он снижает риск на Х%, нам не известно. В том числе из-за этого предлагаемая методика оперирует качественными, а не количественными оценками.
Бенчмарки существуют, но они почти сразу после публикации отстают от быстро развивающейся индустрии атак на ИИ, поэтому какого-то актуального, чтобы можно было на нём прогнать инструмент и сказать, что он снижает риск на Х%, нам не известно. В том числе из-за этого предлагаемая методика оперирует качественными, а не количественными оценками.
Расскажите, пожалуйста подробнее про ваш светофор «3х3», лучше на примере конкретной любой угрозы из существующего перечня (из методики).
Для каждой угрозы оцениваем два параметра по трёхбалльной шкале: вероятность (L — низкая, нужны особые условия; M — средняя, возможна при штатных настройках; H — высокая, публично известные приёмы атаки) и критичность (L — незначительный ущерб; M — частичная утечка или временная недоступность; H — утечка конфиденциальных данных, удалённое выполнение команд, полный отказ в обслуживании). Пересечение даёт итоговый риск (низкий, средний, высокий, критический).
Пример для прямой инъекции в промпт (самая известная атака «игнорируй предыдущие инструкции»): вероятность H — любой пользователь может это сделать, публичных инструментов для атаки достаточно. Критичность H — через инъекцию можно заставить модель выполнить опасные действия в системе (если LLM может вызывать инструменты, например). Итог — критический риск.
Пример для прямой инъекции в промпт (самая известная атака «игнорируй предыдущие инструкции»): вероятность H — любой пользователь может это сделать, публичных инструментов для атаки достаточно. Критичность H — через инъекцию можно заставить модель выполнить опасные действия в системе (если LLM может вызывать инструменты, например). Итог — критический риск.
В аудит не планируется включать, например, описывать SBOM и аудит процессов работы с ИИ? Процессы позволят точнее формировать гардрейлы и подключать модели безопасности?
Планируется, это уже есть в методике. SBOM входит в описание активов (перечень компонентов, зависимостей и артефактов системы). А аудит процессов проверяет, есть ли политики работы с ИИ, регламенты мониторинга и реагирования на инциденты. Без SBOM и описания процессов модель угроз будет неполной.
Как по вашей методике должен оцениваться контур, где AI coding agent работает через корпоративный LLM-шлюз, но выполняет команды на рабочей станции или выделенном dev-стенде?
Описываем все компоненты и их взаимосвязи: LLM-шлюз, агента, его инструменты, файловую систему, сетевые доступы. Затем смотрим, какие классы атак для такого набора актуальны. Ключевыми рисками такого контура могут быть злоупотребление инструментами агента, небезопасная передача вывода модели в команды, а также атаки на отказ в обслуживании (агент может бесконечно потреблять ресурсы). Методика не делает разницы между «сервером» и «рабочей станцией», важнее, какие доступы есть у агента.
Поясните примером тип атаки «по типу токенов».
Например, состязательные суффиксы (GCG). Вредоносный запрос дополняется большим количеством случайных токенов, и анализируется, какие из них сдвигают ответ модели в нужную атакующему сторону. Такие токены отбираются, комбинируются, усиливаются. Есть и более продвинутый вариант: автоматически подбирается суффикс — последовательность токенов, которая, будучи добавленной к любому запросу, заставляет модель игнорировать ограничения. Это всё автоматизированные методы, не ручной подбор.
По red team вопрос: целевой запрос — это то, что в среднем пользователи должны вводить в обычной работе, а дальше атакующая LLM его изменяет, чтобы сломать целевую модель?
В контексте этого раздела презентации под «целевым запросом» понимался тот, который приводит к реализации риска или недопустимому событию. То есть тот, который должен быть заблокирован системой защиты. Red team-инструменты модифицируют его так, чтобы он обходил защиту.
Для выявления Shadow AI рекомендуется анализировать трафик на шлюзах, проверять DNS-запросы к известным LLM-эндпоинтам. Также можно выявлять Shadow AI по поведению пользователей. Например, мониторинг процессов на АРМах, нетипичные команды в командной строке.
Для выявления Shadow AI рекомендуется анализировать трафик на шлюзах, проверять DNS-запросы к известным LLM-эндпоинтам. Также можно выявлять Shadow AI по поведению пользователей. Например, мониторинг процессов на АРМах, нетипичные команды в командной строке.
Методика тестирует только безопасность ответов модели или полную систему: RAG, vector database, системный промпт, API, авторизацию, MCP, инструменты агента, файловую систему и внешние интеграции?
Методика описывает защиту ИИ-системы в целом. Ядро ИИ-системы (в частности, это может быть LLM с ответами) — тоже, наряду с остальными компонентами. В методике выделено 15 типов активов, и для каждого определена актуальность классов угроз.
Тот же вопрос по рекомендациям по логам. Это не «классический» мониторинг получается. Много логов, много текста, много вариантов что и как можно логировать. Как не сжечь железо и не завалить мониторинг кучей мусорных логов?
При анализе логов предлагается смотреть на специфичные для ИИ-системы параметры (в зависимости от типа — Classic ML / LLM / CV, RL / agent и прочее). Выбор критичных контролируемых параметров выполняется для каждой системы в отдельности.
Есть ли образцы корпоративных ЛНА: политики ИИ, инструкции пользователя, стандартов ИБ при администрировании систем ИИ?
На текущий момент мы подобное разрабатываем по запросу заказчиков.
Как обеспечить безопасность при работе с оркестраторами типа Hermes Agents? Обычно там же наравне с локальными моделями добавлены внешние API с доступами к удалённым моделям, как бесплатные, так и платные.
Защищать весь контур. А дальше — или принимать риски, или использовать стандартные меры защиты, например периметровые для внешних моделей.
Вы встаете на канал взаимодействия с агентом и если да, то в разрыв/ в алертинг с подтверждением? Если нет, то когда планируется?
Да, встраиваемся в разрыв — это основной режим. AppSec.AIGate работает как обратный прокси на канале «приложение / агент ↔ LLM»: приложение направляет вызовы не напрямую провайдеру, а на шлюз, который проверяет запрос до отправки в модель и ответ до выдачи потребителю. Канал провайдеронезависимый: OpenAI, Anthropic, GigaChat, YandexGPT, локальные модели с OpenAI-совместимым API — форма запроса/ ответа описывается маппингом полей, а не хардкодом.
Как лицензируется AIGate? От количества запросов или от подключенных систем?
Количество запросов в месяц.
Что делать с аудиоконтентом (транскрибация, промпт, ответ голосом) и с генеративным контентом (картинки). Как его защищать?
Сейчас содержимое аудио и изображений мы не анализируем — распознавания речи и OCR в продукте нет (в данный момент). Проверяются текстовые части диалога. Поэтому подход к мультимодальности у нас построен не на обещании «мы всё видим», а на управляемом риске: непроверяемая модальность не должна проходить молча.
Какие остаточные риски для условно изолированных систем, например локальный n8n + локальная LLM в Docker?
Внутренний злоумышленник может заставить LLM вести себя некорректно, а также получить доступ туда, куда изначально ему было запрещено из-за недостаточной изоляции агентов или анализа контекста прав пользователей.
Как ваш прокси (шлюз защиты ИИ) интегрируется и совмещает работу с обычным веб-прокси в компании, через которую идет работа с ресурсами Интернет?
Нет. Это разные слои, они не конкурируют и не дублируют друг друга.
Как различаются персональные данные, коммерческая тайна и технические секреты? Regex и NER недостаточны для контекстных данных, как выявляются внутренние идентификаторы, фрагменты кода и бизнес-данные без фиксированного шаблона?
Персональные данные описаны законом и хорошо распознаются автоматически — их мы скрываем от модели и возвращаем в ответе. Технические секреты (ключи, токены, пароли, доступы к базам) узнаются по характерному виду — это самая надёжная категория. Коммерческую тайну определяет ваш внутренний перечень, а не вид строки, поэтому универсального детектора не существует ни у кого: здесь вы задаёте свои шаблоны для внутренних номеров и идентификаторов, списки кодовых названий и клиентов, а при необходимости подключаете собственный обученный детектор в наш конвейер.
Умеете ли работать с вложенными файлами?
Если приложение само извлекает текст из файла — а так работает большинство сценариев вроде «загрузите договор и задайте вопрос» — то да, проверяем полностью, размер документа не мешает. Если файл уходит в модель вложением, его содержимое мы не разбираем: чтения PDF, Word и Excel в продукте нет. В этом случае вы решаете, блокировать такие запросы, фиксировать их в журнале или пропускать. Рекомендуемая схема — извлекать текст до шлюза, тогда работают все проверки.
Какие языки детектируются?
Определение языка запроса — самостоятельная проверка, она распознаёт более 70 языков и позволяет задать правило «разрешены только такие-то», блокируя или помечая обращения на остальных (нужен текст хотя бы в несколько букв). Сами проверки безопасности — поиск атак на модель и запрещённой тематики — работают на многоязычных моделях; целевые и проверенные нами языки — русский и английский, причём русский обрабатывается напрямую, без перевода. То же и с персональными данными: распознавание имён и организаций в свободном тексте настроено на русский и английский, а данные с чёткой структурой — телефоны, банковские карты, паспорт, ИНН, СНИЛС, ОГРН, ключи и токены — находятся независимо от языка текста.
Как проверялась устойчивость к paraphrasing, multi-turn атакам, кодовым словам, base64, смешению языков и косвенной prompt injection?
Проверяли на размеченных наборах — около 3000 промптов по категориям атак и отдельный набор из 1000 промптов по персональным данным — с расчётом полноты, точности и доли ложных срабатываний, плюс калибровка порогов на валидационной выборке и регрессионные прогоны с наборами обходов перед релизами. По векторам:
- перефразирование закрывается тем, что работают семантические модели, а не списки фраз;
- multi-turn — тем, что проверяется вся история диалога, а не только последнее сообщение;
- base64, hex, rot13 и URL-кодирование декодируются перед проверкой, включая вложенные слои;
- невидимые символы, гомоглифы и смешение алфавитов — отдельной проверкой с выбором реакции;
- смешение языков — многоязычными моделями.
Чем AIGate функционально дополняет LiteLLM Guardrails и почему эти проверки нельзя реализовать непосредственно в LiteLLM?
LiteLLM Guardrails — это интерфейс для подключения проверок, а не сами проверки. Он даёт точки перехвата до и после вызова модели, но содержимое контроля вы приносите сами, либо подключая внешние сервисы, большинство из которых облачные. AIGate встраивается ровно в эту точку — у нас есть готовый адаптер, и в контуре LiteLLM мы работаем как поставщик проверок, то есть не конкурируем, а заполняем то, что LiteLLM намеренно оставляет пустым: модели детекции атак на модель и запрещённой тематики, поиск персональных данных с российской спецификой (ИНН, СНИЛС, ОГРН, паспорт) и обратимая токенизация, когда данные скрываются от модели и восстанавливаются в ответе. Плюс всё, что вокруг: централизованные политики с версиями и разграничением ролей вместо правил в конфиге, журнал событий и выгрузка в SIEM, единое поведение при сбое детектора (по умолчанию запрос блокируется, а не проходит без проверки), и одна и та же политика на другие каналы — прямой прокси, SDK.
Как Ваша система защищена от атак? Это же тоже ИИ – система.
Главное в архитектуре: наши детекторы — не чат-модели с инструкциями, а классификаторы. У них нет системного промпта, который можно переписать, они не выполняют инструкции из текста и не генерируют ответ — только выдают метку и оценку. Поэтому классического «уговорить проверяющую модель» здесь не происходит: фраза «игнорируй инструкции» для классификатора — просто входной текст, признак атаки, а не команда. Модели работают полностью локально, без обращений в интернет в момент работы и с запретом подгрузки внешнего кода. Есть ограничения на размер входа, глубину распаковки закодированных фрагментов и таймауты, чтобы вход нельзя было использовать для исчерпания ресурсов. Если детектор всё же недоступен или ответил ошибкой, запрос по умолчанию блокируется, а не пропускается, то есть отказ защиты не превращается в дыру.
AI Gate где разворачивается: в инфраструктуре заказчика/ у вас в инфраструктуре и используется как сервис?
Можно рассмотреть оба варианта, мы (УЦСБ) такой сервис готовы предоставлять, а также внедрять on-prem на инфраструктуре заказчика.
В современных браузерах уже встроена возможность обращения к облачным публичным LLM. Ваш шлюз сможет контролировать такой вариант работы пользователя и разбирать его запросы на уровне L7?
Если пользователь работает с публичным сервисом через обычную веб-страницу, контроль возможен, и делает его не шлюз, а наше браузерное расширение: оно встраивается в страницу и перехватывает отправку промпта на уровне запросов самого сайта, включая обычные запросы и веб-сокеты, после чего отправляет текст на проверку в тот же контур и применяет вердикт (пропустить, скрыть персональные данные, заблокировать). Поддерживаются конкретные сервисы, для каждого свой адаптер, устанавливается принудительно через групповые политики или Intune. Разбирать этот трафик на сетевом уровне бессмысленно: он зашифрован, а внутренние протоколы таких сервисов не являются публичным API и меняются без предупреждения, поэтому попытка инспекции на прокси даёт хрупкий и легко ломающийся контроль.
Каков полный порядок применения детекторов и политик при конфликте решений?
Для входящего запроса сначала выполняется нормализация и извлечение текста, затем параллельно запускаются Threat Detector, PII Detector, Content Policy и пользовательские детекторы.
После этого PDP применяет политики Rego и формирует итоговый вердикт. Если хотя бы один детектор возвращает BLOCK, запрос блокируется. В Monitor Mode событие регистрируется, но трафик пропускается.
После этого PDP применяет политики Rego и формирует итоговый вердикт. Если хотя бы один детектор возвращает BLOCK, запрос блокируется. В Monitor Mode событие регистрируется, но трафик пропускается.
Как Вы встраиваете Ваши системы в SIEM/ SOAR для создания целостной архитектуры ИБ?
События можно экспортировать через:
- Syslog;
- CEF;
- Webhook;
- Kafka;
- файл для последующего сбора агентом.
Подскажите, какие модели вы используете для Threat Detector в решении AppSec.AIGate?
Дообученные нами модели на базе Qwen3-4.
Напишите нам на cybersec@ussc.ru или оставьте заявку
Нужна консультация
по защите 1С?
Нажимая кнопку «Отправить», я даю свое согласие на обработку моих персональных данных, в соответствии с Федеральным законом от 27.07.2006 года №152-ФЗ «О персональных данных», на условиях и для целей, определенных в Согласии на обработку персональных данных