🤔 Product Requirement Document для Shift-Left
Салют,
Сегодня хочу поделиться с тобой своей практикой для проектного управления (PMI), которая позволяет мне видеть концептуально картинку и анализировать корректность выстраивания процессов DevSecOps, интеграции AppSec Toolchain и управления человеческими ресурсами.
Что такое PRD и зачем он нужен?
Используется при описании текущего сводного статуса проекта и features. Это общий документ/ справочник, который по сути одинаково понятен разработчикам, аналитикам, саппорту, менеджерам и ИБ.
Структура
- краткое описание функционала - описываем что мы хотим сделать простыми словами (как например, если бы рассказывали коллеге у "кулера")
Плохой пример: «Добавить кнопку «Верификация» в авторизованную часть 2FA, класть данные логов, кто заходил, потому что нужно потом строить из них графики»
Хороший пример: «Обеспечить безопасность пользовательских учетных записей и противодействовать нелигитимному доступу внутри инфраструктуры в случае компрометации учетной записи. С помощью интеграции у клиента, а также нас, появится возможность осуществлять контроль и гарантировать безопасное легитимное подключение» (чувствуете как это сложна и не понятно)
- почему мы это делаем - разворачивает смысл в первом абзаце. Дальше декомпозируется.
Плохой пример: «Потому что требует решгулятор эту фичу для соответствия требованиям»
Хороший пример: «Потому что это может дать нам возможность быстрого прохождения верификации и контроля пользователей, обезопасить user story и быть уверенными в защищенности данных (ссылка на результаты эксперимента/ расчет/ кейс)»
- ожидаемый результат - описываем какого именно результата ждем, наш Win Condition.
Win Condition отвечает на один простой вопрос — как мы поймем, что у нас получилось. Это может быть любая количественная или качественная метрика, событие оценки. Главные критерии качества для Win Condition — измеримость, однозначная трактуемость и простота (принцип Invest).
Fail Condition отдельно можно не прописывать. По умолчанию предполагаем, что при не достижении Win Condition мы автоматически попали в состояние Fail.
- риски ИБ - описываем и оцениваем, что может стать ее причиной и прямого/ косвенного урона требующих изменение архитектуры, функционала и тд, - как пример риск киберпреступления и мы понимаем, что входная поверхность атаки больше, чем мы покрыли и допускаем
- артефакты - исследования, результаты, требования, evidence
- функциональные требования - само решение, приводя альтеранативы для выбора и доработки кейсов, таким образом мы окажем сервисное обслуживание и оптимизируем взаимодействие
User Story: описываем что и для чего получит пользователь, ИБ, команда разработки и тд, с примерами и комментариями.
Хардкорные ФТ: описываем всю бизнес логику пошагово (применимо при проработке сложных кейсов.
- аналитика - важный раздел, описывающий какие ивенты, куда должны отправляться, также описываем какие метрики оценки у нас есть.
Итого:
- PRD хватает для того, чтобы техническая команда вместе могла провести первичную декомпозицию.
- Логика использования PRD в ИБ - встраивание Shift Left процесса в разработку и фиксация требований ИБ, а также контроль, сбор evidence.
- Именно он (или ссылка на него) составляет описание user story, которая потом декомпозируется на tasks (задачи)
- После окончания работ/ описания требований или иных дополнений над задачами - PRD становится документацией о том, как это работало и почему/ зачем было реализовано.
- PRD пишется для больших и сложных вещей, где есть много зависимостей и очень важно сохранить для истории как это работало.
#devsecop #pmi #specialty #pmcases