Привет! На связи снова Саша Симоненко, операционный директор Xilant. Сегодня разбираем конкретные методики написания безопасных требований: INVEST, SMART, What-If и misuse cases. Чтобы быть в контексте, зачем они нужны и какую проблему решают, рекомендую начать с первой части трилогии — о том, как неточные формулировки становятся уязвимостями и где в SDLC теряется безопасность.
Почему нельзя просто «написать понятнее»
Когда говорят «давайте просто нормально напишем требования», это звучит логично. Но на практике выясняется: «нормально» — понятие субъективное. Для бизнеса «нормально» — чтобы фича работала. Для разработчика — чтобы код был чистым и тестируемым. Для QA — чтобы сценарии можно было проверить. Для AppSec — чтобы данные были защищены.
Каждый понимает «нормально» по-своему, и в итоге требования становятся набором догадок. Именно поэтому нужны формальные методики. Они не усложняют процесс — они выравнивают его, потому что переводят субъективные «понятно» в объективные критерии.
Методики вроде INVEST, SMART, What-If и misuse-cases заменяют размытые фразы конкретикой: что именно нужно сделать, как это измерить, какие риски есть, кто отвечает за предотвращение, и что будет, если что-то пойдёт не так.
Что они меняют в процессе?
Убирают пространство для интерпретаций
Делают требования проверяемыми
Заставляют команду обсуждать не только «как должно работать», но и «как должно ломаться»
Помогают увидеть риски еще до появления первой строки кода
Формируют общий язык между BA, Dev, QA и AppSec
Иначе говоря: они дают структуру, которая не дает безопасности «раствориться» между этапами разработки.
INVEST: как сделать безопасность видимой
INVEST — это набор критериев, который позволяет оценить качество user-story. Но в контексте безопасности он становится не просто способом «оформить задачу», а инструментом удержания security-требований внутри бэклога.
Сложность в том, что требования безопасности часто «приклеиваются» к фичам: зависят от других задач, сдвигаются по времени, теряются между эпиками. INVEST помогает избежать этого — делает security-требование самостоятельным, описанным, оценимым и тестируемым.
Проблема усугубляется тем, что обычные user stories пишутся вокруг бизнеса: «пользователь должен видеть X», «нужно реализовать Y». В такой логике безопасность становится невидимой функциональностью. История оказывается слишком крупной, нечеткой, ее невозможно протестировать с позиции безопасности, и она закономерно проваливается между задачами. Именно здесь INVEST и начинает работать — он структурирует требования так, чтобы безопасность перестала быть фоном и стала частью результата.
Разберем каждый критерий:
Independent — автономность истории
Security-требование не должно зависеть от десятка других фич. Если у вас «проверьте RBAC, когда доделают модуль авторизации», то это не user-story, а закладка для будущей проблемы. Автономность = видимость и управляемость.
Отдельная story на «проверку схемы валидации», «настройку RBAC», «включение audit-logging» — правильный формат.
Negotiable — обсуждаем реализацию, но не цель безопасности
В безопасности цель неизменна («минимизировать риск», «не допустить компрометацию»), а вот способы реализации — предмет диалога.
Например:
цель: «данные должны быть защищены в транзите»;
реализация: TLS 1.3, mutual TLS, VPN - можно обсуждать.
Negotiable помогает не закапываться в догмы и технические предпочтения, сохраняя при этом саму цель неизменной.
Valuable - история должна снижать риск
Security-требование ценно, когда оно уменьшает вероятность инцидента или смягчает последствия. Если требование не снижает риск, это не безопасность, а украшение.
VALUABLE помогает отсечь «псевдобезопасность»: бессмысленные отчеты, проверки ради галочки, сложные механизмы, которые ничего не дают.
Estimable — трудозатраты должны быть понятны
Если невозможно оценить время на реализацию security-требования, команда будет откладывать его бесконечно. Оценимость требует понимания технологий, объема проверки, работ DevOps и AppSec. Это предотвращает ситуацию, когда «сделаем позже» — это «не сделаем никогда».
Small — задача должна помещаться в спринт
Security-элементы, растянутые на несколько месяцев, теряют фокус и управление.
Small заставляет дробить:
не «внедрить безопасность API», а «ограничить размер payload», «добавить rate-limit», «включить TLS», «настроить audit-events».
Так требования не теряются и проходят через CI/CD как часть процесса.
Но есть важный нюанс. Без security-acceptance INVEST теряет смысл, потому что user-story остаётся непроверяемой. Если нет конкретных сценариев, отрицательных кейсов, порогов, критериев, то INVEST это просто красивая формальность.
В реальности это проявляется так: задачи закрываются, тесты зеленые, а защита отсутствует. AppSec об инциденте узнаёт не в CI, а уже в проде.
Несколько рекомендаций:
Дробите security-истории до уровня «можно закрыть за 2–3 дня».
В acceptance всегда добавляйте хотя бы три negative-сценария.
Всегда фиксируйте результат: лог, метрика, ограничение, конфигурация.
Никогда не объединяйте безопасность с функциональностью в одну историю.
Отдельно назначайте владельца mitigation.
SMART: превращаем «защитить данные» в конкретное требование
Если INVEST помогает сделать требования безопасности видимыми и управляемыми, то SMART превращает расплывчатые желания в конкретные требования, которые можно реализовать и проверить. В безопасности это особенно важно, потому что фразы вроде «защитить данные» или «сделать безопасно» не дают никакого практического направления. SMART превращает хаос в структуру: что защищаем, как измеряем, сколько времени на это нужно, и почему это важно.
«Защитить данные» — это не требование, это намерение. Не указано что именно защищать, от чего защищать, какими способами, кто отвечает и как измерить успех. В таком виде эта фраза не приводит ни к какому изменению системы.
Критерии SMART:
Specific - конкретика
Не «обезопасить API», а «шифровать поля email, phone, passport в таблице users, ограничить вызовы /import до 100 req/min». Чем конкретнее, тем меньше ин��ерпретаций.
Measurable - измеримость
Что является доказательством выполнения?
наличие TLS 1.3
логирование actor/action/resource
прохождение negative-тестов
отсутствие payload > 5 МБ
Без измеримости безопасность превращается в мнение.
Achievable — реалистичность
Нельзя требовать HSM, если инфраструктуры нет. Нельзя требовать MFA, если IdP не поддерживает.
Achievable заставляет согласовывать желаемую безопасность с реальными возможностями.
Чаще всего в безопасности сложнее всего применить Achievable. Видение «как должно быть» легко сформулировать, но часто нет ресурсов, бюджета, инструментов или экспертизы. Даже простые меры требуют инфраструктурной поддержки, и именно здесь появляются конфликты между идеальной безопасностью и реальными проектными ограничениями.
Relevant - связь с риском
Без понимания риска требование будет игнорироваться. Команда должна видеть, что именно предотвращается: утечка данных, несанкционированный доступ, финансовый ущерб.
Time-bound - сроки
Без дедлайнов security-требования живут в бэклоге бесконечно.
Здесь важно фиксировать:
дату внедрения
дату ревью
дату пересмотра требований
Как перевести размытое требование в SMART?
Алгоритм простой:
Уточнить объект защиты. Конкретные таблицы, поля, файлы, эндпоинты.
Определить измеримые параметры. Шифрование, аудит, пороги, тесты.
Проверить реалистичность. Есть ли ресурсы, инфраструктура, знания.
Обосновать необходимость. Какой риск закрываем? Почему именно это важно?
Определить сроки. Когда ревью? Когда внедрение? Когда пересмотр?
Чтобы SMART-требование было полным и реально реализуемым, важно заранее разграничить ответственность:
BA — формулирует конкретику и бизнес-смысл.
AppSec — определяет риски и меры защиты.
DevOps — отвечает за реалистичность и инфраструктуру (Achievable).
PO — проставляет приоритеты и сроки (Time-bound).
Если роли не определены, требование получается неполным, ответственность размывается.
What-If: проверяем фичу на неожиданные сценарии
What-If — метод, который помогает заранее смоделировать неожиданные ситуации: «что если случится X?», «что если пользователь сделает Y?», «что если партнерский сервис отправит неверный payload?». Это упрощенная версия threat-моделирования: быстрее, проще, но при этом очень эффективная на уровне требований. Метод показывает, как фича может быть использована не по назначению или сломать систему, и сразу позволяет включить защиту в требование.
Это простой инструмент — таблица на одну строку. Она переводит разговоры в конкретные действия: риск → защита → ответственный
Для того чтобы анализ работал, важно фиксировать риск, mitigation и владельца. Без этого What-If превращается в список проблем и не влияет на бэклог.
Обычно достаточно 6–8 сценариев на одну фичу, чтобы выявить 80% рисков.
Как внедрять what-if так, чтобы он действительно работал?
Делать короткие сессии: 10–15 минут на фичу.
Фиксировать только реалистичные сценарии.
Сразу превращать mitigation в задачи.
Держать таблицу what-if в бэклоге рядом с user stories.
Главный принцип: what-if не должен быть «бумажным». Он должен влиять на бэклог.
Пример:
Feature: Импорт контактов партнера
What-if: Партнёр загружает специально сформированный CSV с «вредным» содержимым.
Risk: Парсер может упасть / выполнится вредный код / коррумпировать данные.
Mitigation: Schema-validation; парсинг в изолированном контейнере (sandbox); size limit 10MB; fuzz-тесты для парсера.
Owner: Dev + AppSec
Misuse Cases: когда систему используют против вас
What-If помогает найти непредвиденные ситуации. Но есть еще одна категория проблем — когда систему используют намеренно не так, как задумано. Для этого существуют misuse cases.
Безопасность ломается там, где фичи используются не так, как задумано. Misuse case помогает увидеть, как злоумышленник может обойти защиту, использовав вашу же логику против вас. Это мини-модели атаки, встроенные прямо в требования.
What-If рассматривает гипотетические ошибки или сбои, а misuse case — анализ осознанного злоупотребления функцией злоумышленником. По сути, это короткая, формальная фиксация угрозы, с четким описанием атакующего, цели, последовательности действий, условий, последствий, мер защиты и владельца ответственности.
Разберем два примера:
Parser exploitation (атака на парсер)
Actor: злонамеренный партнёр / бот
Goal: вызвать падение сервиса или выполнение кода через специально подготовленный файл
Sequence: отправляет «подложный» CSV/JSON с вложенными структурами → парсер падает / выполняет неожиданный код
Preconditions: парсер не валидирует schema, выполняется с повышенными привилегиями
Impact: DoS, возможный RCE, corruption of data
Mitigation: строгая схема валидации, обработка в песочнице, запуск парсера без привилегий, фаззинг тестирование, ограничение размера файла
Owner: Dev + AppSec
Это пример, когда злоумышленник использует доверенное место системы — файл от партнера — чтобы обрушить парсер или выполнить код. Проблема чаще всего в отсутствии валидации схемы, sandbox-режима, ограничения размера файла. Mitigation логичен: строгие схемы, ограниченный пользователь, тесты, лимиты.
Account takeover via SSO misconfig
Actor: злоумышленник, получивший доступ к внешнему SSO
Goal: получить доступ к чужому аккаунту в сервисе
Sequence: использует уязвимость/перехвачен токен SSO → логин через SSO → обходит локальную двухфакторную проверку
Preconditions: слабая проверка токенов, отсутствует token-binding, админ-функции без MFA
Impact: доступ к приватным данным, административные действия
Mitigation: верифицировать сигнатуру токена, реализовать защиту от reply-атак, принудительное MFA для чувствительны сценариев, логирование + алерты
Owner: Identity team + AppSec
Здесь классика: уязвимость в SSO позволяет обойти MFA и попасть в чужой аккаунт. Причина — неверная проверка токенов, отсутствие replay-защиты, отсутствие MFA на опасных действиях. Mitigation — правильная проверка токенов, привязка токена к устройству/сессии, MFA, логирование и алерты.
Типичные ошибки при составлении misuse cases:
Описание только сценария, без mitigations.
Слишком абстрактное описание («злоумышленник ломает систему»).
Нет владельца, никто не отвечает.
Слишком много кейсов, которые невозможно обработать.
Сценарии без привязки к реальной архитектуре.
Сколько времени нужно тратить на один misuse case?
В среднем 10-20 минут. Если кейс занимает час, это уже threat-modeling. Главное — не пытаться охватить всё сразу, а сосредоточиться на реально возможных сценариях для конкретной архитектуры.
Приоритизация тоже простая: высокий риск идет сразу в бэклог, средний риск откладывается в план после релиза, низкий риск логируется, фиксируется, и для него планируется автоматизированная проверка позже.
Главное — не игнорировать риски с низким приоритетом. То, что сегодня кажется незначительным, завтра может стать критичным после изменения архитектуры.
Есть несколько дополнительных рекомендаций, которые помогают misuse case реально работать:
Всегда описывайте preconditions - они раскрывают «корень» проблемы
Не пишите сценарий, если он нереалистичен в вашей архитектуре
Проводите короткие воркшопы BA + Dev + QA + AppSec
Не смешивайте misuse cases с багами - это разные сущности
Бывает, что именно misuse cases меняют архитектуру продукта. Часто встречаются примеры, когда команда отказывается от собственного парсера в пользу безопасной библиотеки, внедряет sandbox-окружение перед обработкой файлов, меняет модель авторизации из-за риска обхода SSO, раздельно хранит ключи и конфиденциальные данные, добавляет audit-логи, которых изначально не было.
Misuse-кейс — это тот документ, который часто убеждает команду: «да, это действительно риск».
Все эти методики показывают, что безопасность не появляется сама и не решается словами вроде «давайте просто нормально напишем требования». Есть много критериев и практик для улучшения требований, но что именно использовать решать вам.
В следующей статье мы разберем, как встроить безопасность в процесс разработки, чтобы чек-листы, сценарии и негативные кейсы реально снижали риски и становились частью рабочего потока команды.
Всем, кто дочитал — огромное спасибо! А еще напоминаю о моем Telegram-канале «Крупицы знаний» (там я периодически публикую интересные статьи и ролики), а еще подписывайтесь также на канал Xilant. Увидимся в следующей части!
