Ответ

История вопроса:
В последние годы растёт число атак на информационные системы, а требования к защите данных ужесточаются законом. Компании требуют комплексной и непрерывной проработки вопросов безопасности на всех этапах жизненного цикла продукта.

Проблема:
Нефункциональные требования к безопасности часто формулируются невнятно или копируются из стандартов без адаптации к специфике проекта. Это приводит к высоким рискам, повторам или невыполнимым задачам для ИТ-команды.

Решение:
Аналитик обязан:

1. Понять нормативную среду (например, GDPR, ФЗ-152, ISO/IEC 27001) и адаптировать её под нужды проекта.
2. В ходе интервью с ИБ-экспертами фиксировать специфические угрозы и требования (шифрование, аудит, контроль доступа).
3. Декомпозировать требования в формате, удобном для архитекторов и разработчиков (чёткие критерии безопасности, политики паролей, требования к логированию и отчётности).
4. Согласовывать технические меры с командой, чтобы их реализовать без блокировки процессов.

Ключевые особенности:

• Обязательное взаимодействие с экспертами по безопасности
• Перевод нормативных требований в технически реализуемые задачи
• Поддержка документации в актуальном состоянии

Вопросы с подвохом.

Можно ли полностью доверять чек-листам ИБ при формировании требований?

Чек-листы полезны как старт, но не охватывают все бизнес-особенности. Требования безопасности должны обсуждаться индивидуально для каждого проекта.

Обязателен ли аудит безопасности для всех частей системы?

Некоторые модули могут не обрабатывать чувствительные данные или быть внутренними. Однако анализ рисков обязателен для всего решения. Внедряется принцип минимально необходимого доступа.

Стоит ли пытаться реализовать требования безопасности на 100%?

Как правило, выполняются наиболее критичные меры, соответствующие классификации данных и уровню угроз. "Абсолютная безопасность" — миф, компромиссы неизбежны, важно управлять рисками.

Типовые ошибки и анти-паттерны

• Формальное копирование требований без учёта специфики
• Недостаточная детализация (например, "использовать шифрование" без определения стандартов)
• Отсутствие регулярного пересмотра безопасности при изменениях в системе

Пример из жизни

Негативный кейс: Требования ИБ свели к точке "соответствие стандарту ISO" и забыли про настройки шифрования канала передачи данных. Итог: инцидент, штраф. Плюсы: Быстро составили документацию. Минусы: Фактическая уязвимость и проблемы при аудите.

Положительный кейс: Аналитик привлёк ИБ-специалиста, провёл сессию анализа угроз, задокументировал требования в виде критериев приёмки. Все меры согласованы и выполнимы. Плюсы: Защита реализована, успешно пройден аудит. Минусы: Требовалось больше времени и усилий на согласование.