Суть услуги

ИИ-системы могут быть взломаны как и любой софт. Но у них есть особые уязвимости которых нет в обычных приложениях. Например отравление данных обучения — взломщик добавляет плохие примеры при обучении и модель начинает работать неправильно. Или adversarial атаки — специально сконструированные входы которые обманывают модель. Или кража модели через API. Нужна специальная защита.

Типичные угрозы для ИИ-систем:

Отравление данных обучения: взломщик добавляет плохие примеры при обучении. Модель учится на них и даёт неправильные результаты
Adversarial атаки: специально сконструированные входы которые выглядят нормально для человека но ломают модель
Model extraction: кража модели через API — постепенно воссоздают модель через множество запросов
Утечки данных: конфиденциальные данные остаются в модели после обучения — можно их вытащить
Backdoor атаки: скрытые команды в модели которые активируются при определённых входах
Отказ в обслуживании: перегрузить систему множеством запросов
Атаки на инфраструктуру: взлом серверов где лежит модель

Почему это опасно:

ИИ-система может быть критична для бизнеса — если она сломана весь процесс встанет
Модель может начать дискриминировать людей после отравления
Утечка данных обучения это утечка конфиденциальной информации
Кража модели это потеря инвестиций в разработку
Атака может быть незаметна — система продолжает работать но даёт неправильные результаты

Процесс анализа безопасности - 5 этапов (4-6 недель)

Этап 1: Инвентаризация активов и угроз (3-4 дня)

Определяем что нужно защищать: ИИ-модель, данные обучения, production данные, API, инфраструктура
Оцениваем критичность каждого актива
Определяем потенциальных противников и их мотивацию
Выявляем какие атаки наиболее вероятны
Определяем требования к безопасности (compliance требования)

Этап 2: Анализ уязвимостей кода и архитектуры (4-5 дней)

Проводим code review на предмет уязвимостей
Проверяем как обрабатываются входные данные — есть ли валидация
Проверяем как хранятся чувствительные данные
Анализируем API — есть ли проверка прав доступа
Проверяем конфигурацию и логирование
Ищем hardcoded пароли и ключи
Проверяем версии зависимостей на известные уязвимости

Этап 3: Тестирование на отравление и adversarial атаки (5-6 дней)

Тестирование отравления данных: пытаемся добавить плохие примеры при обучении. Проверяем устойчива ли модель
Adversarial примеры: генерируем примеры которые обманывают модель. Проверяем точность на них
Граничные случаи: тестируем экстремальные входы
Out-of-distribution примеры: примеры которые сильно отличаются от обучающих
Чёрный ящик атаки: пытаемся обманить модель не зная её внутреннего устройства

Этап 4: Анализ защиты данных и конфиденциальности (4-5 дней)

Проверяем как хранятся данные обучения — есть ли шифрование
Проверяем доступ к данным — кто может их видеть
Проверяем можно ли вытащить обучающие данные из модели (membership inference атаки)
Проверяем логирование — логируются ли чувствительные данные
Проверяем резервные копии — защищены ли они
Анализируем can ли модель memorize обучающие примеры

Этап 5: Тестирование extraction и DoS атак (3-4 дня)

Model extraction: пытаемся украсть модель через API постепенно
DoS атаки: отправляем множество запросов чтобы перегрузить систему
API жесткость: проверяем есть ли rate limiting, есть ли защита от ботов

Типичные уязвимости которые мы находим

Уязвимость 1: Отсутствие валидации входных данных

Описание: API принимает любые данные без проверки. Можно отправить SQL инъекцию, очень большие файлы, специфичные форматы.

Риск: Высокий. Через это можно взломать систему или вызвать отказ в обслуживании.

Как исправить: Добавить валидацию входных данных. Проверять тип, размер, формат. Использовать библиотеки для безопасного парсинга.

Уязвимость 2: Hardcoded пароли и API ключи

Описание: В коде хранятся пароли и ключи доступа в открытом виде. Если код попадёт в Git или на GitHub то все узнают пароли.

Риск: Критический. Взломщик получает доступ ко всем системам.

Как исправить: Использовать переменные окружения или хранилище секретов. Никогда не коммитить пароли в Git.

Уязвимость 3: Отсутствие шифрования данных

Описание: Данные хранятся в базе в открытом виде или передаются без шифрования.

Риск: Высокий. Если база будет скомпрометирована все данные станут известны.

Как исправить: Использовать шифрование данных в покое (at rest) и в пути (in transit). HTTPS для передачи, AES для хранения.

Уязвимость 4: Модель уязвима к adversarial примерам

Описание: Модель можно обманать малыми изменениями входа которые незаметны для человека.

Риск: Средний. Зависит от применения. В системе контроля качества это опасно, в системе рекомендаций менее опасно.

Как исправить: Тренировать модель на adversarial примерах. Использовать ансамбли моделей. Добавить мониторинг аномалий.

Уязвимость 5: Отсутствие мониторинга и логирования

Описание: Система не логирует кто что делает. Нельзя отследить атаку.

Риск: Средний. Безопасность хуже но технически система может работать.

Как исправить: Добавить логирование всех важных действий. Мониторинг аномалий. Алерты при подозрительной активности.

Уязвимость 6: Отсутствие rate limiting на API

Описание: API не ограничивает количество запросов от одного IP адреса. Можно отправить 1 миллион запросов и перегрузить систему.

Риск: Средний. Система может упасть.

Как исправить: Добавить rate limiting. Разные лимиты для разных типов операций. Кэширование частых запросов.

Примеры из реальной практики

Пример 1: Банк — атака на систему скоринга

Задача: Банк использует ИИ-систему для скоринга заявок на кредит.

Что произошло: Хакер обнаружил что API принимает любые данные. Отправил несколько тысяч запросов с поддельными данными чтобы украсть модель. Через 1000 запросов воссоздал примерно 80% функционала модели.

Что сделали: Добавили rate limiting (не более 10 запросов в минуту от одного пользователя). Добавили аутентификацию (только авторизованные пользователи). Добавили логирование и мониторинг необычной активности. Переобучили модель (старая была в интернете). Результат: атаки прекратились.

Пример 2: Производство — отравление данных контроля качества

Что произошло: Рабочий хотел пустить бракованную деталь. Открыл базу данных обучения и добавил пример как бракованная деталь выглядит хорошо. Переобучил модель. Система начала пропускать брак.

Что сделали: Ограничили доступ к базе данных обучения — только администраторы. Добавили версионирование данных обучения. Добавили automatic retraining модели когда заметно падение качества. Добавили ручную проверку случайных примеров. Результат: брак снова начал выявляться.

Пример 3: Финтех — утечка личных данных из модели

Что произошло: Исследователь показал что из модели можно вытащить личные данные клиентов которые использовались при обучении. Можно узнать есть ли конкретный клиент в обучающей выборке.

Что сделали: Добавили differential privacy при обучении модели. Зашифровали личные данные в логах. Ограничили доступ к модели. Добавили audit логирование кто обращается к модели. Результат: утечка закрыта, но теперь модель немного менее точна (trade-off).

Пример 4: Логистика — DoS атака на систему оптимизации маршрутов

Что произошло: Конкурент отправил 100000 запросов в секунду на API системы оптимизации маршрутов. Сервер упал. Компания потеряла деньги на доставках которые не получилось оптимизировать.

Что сделали: Добавили rate limiting (максимум 1000 запросов в минуту на пользователя). Добавили кэширование результатов (если запрос повторяется выдаём кэшированный результат). Распределили нагрузку на несколько серверов. Добавили DDoS protection. Результат: теперь система выдерживает атаки.

Пример 5: E-commerce — adversarial атаки на систему рекомендаций

Что произошло: Тестеры обнаружили что можно слегка изменить описание товара и система даст неправильную рекомендацию.

Что сделали: Переучили модель на adversarial примерах. Добавили второй слой проверки (ensemble из нескольких моделей). Добавили мониторинг — если рекомендации вдруг странные выключить систему. Результат: система более устойчива к атакам.

Что получает клиент

1. Отчёт об анализе безопасности (60-80 страниц): инвентаризация активов, анализ уязвимостей, результаты тестирования, оценка рисков, рекомендации
2. Детальное описание каждой уязвимости: что это, почему опасно, как исправить, примеры
3. Приоритизированный план исправления: критичные проблемы сначала, средние потом, низкие можно отложить
4. Оценка рисков: если ничего не менять какова вероятность взлома и какой ущерб
5. Рекомендации по архитектуре безопасности: как правильно устроить систему
6. Чек-листы для разработчиков: как писать безопасный код для ИИ-систем
7. Процедуры реагирования на инциденты: что делать если систему взломали

Кому это нужно

Финансовым учреждениям которые используют ИИ в критичных системах
Государственным учреждениям которые работают с конфиденциальными данными
Компаниям которые работают с личными данными клиентов
Производствам с критичными системами управления
Любым компаниям которые используют ИИ и беспокоятся о безопасности

Результаты анализа

✓ Полное понимание уязвимостей вашей ИИ-системы
✓ Оценка рисков и потенциального ущерба
✓ Приоритизированный план исправления
✓ Готовые рекомендации по защите
✓ Повышение уровня безопасности на 50-80%
✓ Защита от основных типов атак

Консультирование по кибербезопасности ИИ-систем

Для кого

Обсудить задачу