Требования ИБ к проекту разработки: что согласовать на старте
Пока в бэклоге ещё нет первой задачи, выставьте требования информационной безопасности так, чтобы их можно было принять или отклонить на демо, а не «иметь в виду». Результат — одна подписанная страница и три-пять критериев приёмки в задачах. Это не приложение к техническому заданию на закупку готовой системы: тот чек-лист — требования ИБ в ТЗ.
Статья опирается на логику направления «Архитектура кибербезопасности» из методики зрелости Группы Сбер (источник); это методика для крупных компаний, мы используем её как ориентир и пересказываем своими словами. Практики безопасной разработки в NIST SP 800-218 (SSDF) требуют заранее определить требования к ПО, а не ловить их на приёмке. Документ: SP 800-218. Это не российский закон.
Кого посадить на старте
На встречу на 30–40 минут: владелец продукта, ведущий разработки, ответственный за ИБ. Если в системе будут персональные данные — ещё тот, кто ведёт обработку ПДн. Не зовите «всю компанию»: чем шире стол, тем общее формулировки.
До встречи владелец продукта отвечает письменно на четыре вопроса: какие данные, кто пользователи, где крутится (свой сервер, облако, чужой SaaS), что будет в первом релизе. Без этого ИБ пишет абстрактное «должно быть безопасно», и страница мертва.
Одна страница, не политика
| Блок | Что зафиксировать | Как проверить на демо |
|---|---|---|
| Данные | Есть ли ПДн, платежи, коммерческая тайна; тестовый контур без боевой копии | В тестовой базе нет боевых ФИО и телефонов: тестовые данные и логи |
| Доступ | Личные учётки, роли, кто админ, вход подрядчика | Нет общей учётки в продуктиве, админка не в интернете без VPN |
| Конвейер | SAST и SCA в merge request, секреты не в git | Красный конвейер при секрете и при критичной находке: процесс SAST и SCA |
| Журналы и копии | Что пишем, сколько храним, куда бэкап | В логе нет полного номера карты и пароля |
| Приёмка | Что блокирует выпуск без отметки ИБ | Список блокеров совпадает с приёмкой релиза |
Каждый блок — формулировка «сделано, если …», не «стремиться к». Исключение пишите сразу: «ПДн нет, блок про обезличивание не применим» с датой и подписью владельца. Реестр типовых требований ко всем продуктам — отдельная статья очереди, сюда его не копируйте: на старте хватает этой страницы под один проект.
Модель угроз на полдня, если продукт новый и есть что терять: модель угроз за день. Не подменяйте ею бриф: угрозы без критериев приёмки не попадают в спринт.
Как положить в задачи
Из страницы вынесите в бэклог только то, что команда сделает в ближайших итерациях: «вход по личной учётке», «bandit в MR», «нет боевых ПДн на стенде». Критерий приёмки задачи копирует строку из брифа, а не «как обсуждали». Обучение разработчиков конкретным ошибкам — рядом, не вместо брифа: программа обучения.
Риск: подписать бриф и забыть. Повесьте пересмотр на первое демо и на смену состава данных (появились ПДн — страница устарела в тот же день).
Диагностика
| Симптом | Причина и что делать |
|---|---|
| «ИБ напишет требования, когда будет архитектура» | Без страницы архитектура приедет без журналов. Соберите ответы на четыре вопроса и закройте бриф за одну встречу |
| Бриф на 12 страниц | Смешали с ТЗ на закупку или с политикой. Оставьте одну страницу, остальное — ссылки |
| Критерии есть, в задачах нет | Бриф лежит в вики. Перенесите три пункта в ближайший спринт с формулировкой «сделано, если» |
| Подрядчик пишет код, брифа нет | Их договор без критериев. Добавьте страницу как приложение, иначе приёмка сорвётся в споре |
Где это в модели зрелости
Отдельного хаба SSDLC на сайте нет: материал относится к направлению «Архитектура кибербезопасности» (хаб: архитектура, карта: карта зрелости). Для блока безопасной разработки калькулятора без требований на старте остальные меры (сканеры, приёмка) не к чему привязать. Это не сегментация сети и не чек-лист перед продуктивным запуском уже купленной системы.
Как проверить
- На диске проекта есть бриф на одну страницу с датой, подписями владельца продукта и ИБ.
- В актуальном спринте есть хотя бы одна задача с критерием, скопированным из брифа.
- Если ПДн нет — это явно написано, а не «все поняли».
- Ссылка на ТЗ закупки, если система покупается, не подменяет бриф разработки, и наоборот.
- После смены состава данных дата брифа обновлена.
Источники
- NIST SP 800-218, Secure Software Development Framework (SSDF) 1.1: csrc.nist.gov.
- OWASP SAMM — ориентир, не закон РФ: owasp.org/www-project-samm.
