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

Суть услуги

ИИ-системы могут быть взломаны как и любой софт. Но у них есть особые уязвимости которых нет в обычных приложениях. Например отравление данных обучения — взломщик добавляет плохие примеры при обучении и модель начинает работать неправильно. Или 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%
• ✓ Защита от основных типов атак