Управление требов аниями безопасности
Большинство уязвимостей — это не ошибки реализации, а отсутствующие требования. Никто не написал, что токен сброса пароля должен истекать через час. Никто не указал, что API-эндпоинт требует ограничения частоты запросов. Разработчик реализовал то, что было описано. Безопасность описана не была.
Явные, проверяемые требования безопасности решают эту проблему. Когда вместо «пользователь должен аутентифицироваться» написано «пароли хэшируются bcrypt с коэффициентом 12, сессии истекают через 30 минут неактивности, количество попыток входа ограничено пятью в час» — реализацию можно проверить, а не угадывать.
Почему это важно для бизнеса
Без явных требований:
- Разработчики принимают решения по безопасности самостоятельно — несогласованно
- Проверки ИБ выявляют проблемы поздно, когда исправление дорого
- При аудите (ФСТЭК, внешний пентест, запрос корпоративного заказчика) нечего показать в качестве доказательной базы
С явными требованиями:
- Решения принимаются один раз и документируются
- Разработчики знают, что ожидается
- QA тестирует безопасность как любой другой функционал
- Аудит — это верификация существующих требований, а не экстренный проект с нуля
Стоимость обнаружения и исправления уязвимости растёт с каждым этапом. Требование, учтённое при проектировании, стоит почти ничего. То же самое, обнаруженное в продакшне, может потребовать экстренного патчинга, уведомления клиентов и недель работы по устранению последствий. лидер безопасности (лидер безопасности — сотрудник, ответствен ный за вопросы ИБ в команде) управляет этим процессом от лица руководства.
Стандарт OWASP ASVS
OWASP Application Security Verification Standard (ASVS) — исчерпывающий каталог требований безопасности для веб-приложений. Вместо того чтобы изобретать собственный список, используйте ASVS как базу.
Структура ASVS
Требования организованы по темам:
| Раздел | Тема | Примеры требований |
|---|---|---|
| V1 | Архитектура | Анализ угроз, шаблоны безопасного проектирования |
| V2 | Аутентификация | Политика паролей, MFA, хранение учётных данных |
| V3 | Управление сессиями | Токены, тайм-ауты, выход |
| V4 | Контроль доступа | Ролевой доступ, авторизация на уровне объектов |
| V5 | Валидация | Проверка входных данных, кодирование вывода |
| V6 | Криптография | Выбор алгоритмов, управление ключами |
| V7 | Обработка ошибок | Журналирование, сообщения об ошибках |
| V8 | Защита данных | Классификация данных, обработка ПДн |
| V9 | Коммуникации | Конфигурация TLS, проверка сертификатов |
| V10 | Вредоносный код | Целостность зависимостей, ревью кода |
| V11 | Бизнес-логика | Сценарии злоупотреблений, безопасность процессов |
| V12 | Файлы | Загрузка файлов, защита от обхода пути |
| V13 | API | Безопасность REST, GraphQL, WebSocket |
| V14 | Конфигурация | Заголовки безопасности, защита сборки |
Уровни ASVS
ASVS определяет три уровня верификации:
Уровень 1 — минимальный базис. Базовая безопасность для всех приложений. Покрывает наиболее распространённые уязвимости (OWASP Top 10). Может быть верифицирован преимущественно автоматическими инструментами.
Уровень 2 — стандартный. Рекомендуется для большинства приложений, особенно обрабатывающих чувствительные данные. Требует частичного ручного ревью.
Уровень 3 — расширенный. Для приложений с высокими требованиями к безопасности: банки, объекты КИИ, медицинские системы. Требует полного ревью и углублённого тестирования.
Для большинства российских компаний МСБ: начните с уровня 1, расширьте до уровня 2 для функций, работающих с персональными данными.
ASVS и российские требования соответствия
ASVS хорошо пересекается с требованиями российского регулирования. Это делает его удобным единым базисом — один документ закрывает и технические требования команды, и потребности аудиторов.
| Нормативный акт | Релевантные разделы ASVS | Примечание |
|---|---|---|
| 152-ФЗ + Приказ ФСТЭК № 21 (ПДн) | V2, V3, V4, V7, V8, V9 | Защита персональных данных, аутентификация, журналирование |
| ГОСТ Р ИСО/МЭК 27001-2021 (СМИБ) | Все разделы | Полное пересечение |
| ГОСТ Р 57580.1 (финансовый сектор) | V2, V3, V4, V6, V7, V8 | Строгая аутентификация, шифрование, аудит |
| 187-ФЗ + Приказ ФСТЭК № 239 (КИИ) | V1, V2, V4, V7, V9, V14 | Безопасность критической информационной инфраструктуры |
| Приказ ФСТЭК № 17 (ГИС) | V2, V3, V4, V7, V14 | Государственные информационные системы |
Когда аудиторы ФСТЭК или корпоративный заказчик спрашивают «как обеспечивается безопасная аутентификация?» — вы показываете требования раздела V2 и доказательства их выполнения.
Как выбрать требования для вашего проекта
Не нужно сразу внедрять все 286 требований ASVS. Начните с того, что важно для вашего приложения.
Шаг 1: классифицируйте данные
Что обрабатывает приложение?
- Только публичные данные → базовые требования
- Персональные данные пользователей → V8 (Защита данных) критичен, обязателен 152-ФЗ
- Финансовые данные → V6 (Криптография), V2 (Аутентификация) критичны; применим ГОСТ Р 57580.1
- Медицинские данные → 152-ФЗ + 323-ФЗ «Об основах охраны здоровья граждан», полный V8, V2, V3
Шаг 2: начните с базового уровня 1
Для любого веб-приложения первыми должны быть реализованы эти разделы:
- V2 — Аутентификация — политика паролей, защита от перебора
- V3 — Управление сессиями — безопасность токенов, истечение срока действия
- V4 — Контроль доступа — проверка авторизации на сервере
- V5 — Валидация — проверка входных данных, кодирование вывода
- V14 — Конфигурация — заголовки безопасности, HTTPS
Это закрывает самые распространённые векторы атак при разумных затратах. Типичная оценка внедрения для небольшой команды — 2–4 недели.
Шаг 3: добавляйте требования по функциям
При планировании новых функций лидер безопасности определяет применимые разделы ASVS:
| Функция | Применимые разделы ASVS |
|---|---|
| Регистрация пользователей | V2.1 (Парольная безопасность) |
| Вход / SSO | V2.2 (Аутентификация), V3 (Сессии) |
| Загрузка файлов | V12.1 (Загрузка файлов) |
| API-эндпоинты | V13 (API), V4 (Контроль доступа) |
| Платёжные операции | V6 (Криптография), V8 (Защита данных) |
| Сброс пароля | V2.5 (Восстановление учётных данных) |
| Административная панель | V4 (Контроль доступа), V7 (Журналирование) |
Шаг 4: документируйте базу требований
Составьте документ, определяющий, какие требования ASVS применимы к вашему проекту:
- Уровень ASVS для проекта в целом и для критичных функций
- Применимые разделы с обоснованием
- Исключённые разделы с указанием причины (например, «V12 — загрузка файлов не поддерживается»)
- Дата последнего пересмотра и кто ответственен
Это не разовое упражнение — документ обновляется при добавлении функций и при изменении регуляторных требований.
Приоритизация требований по риску
Не все требования одинаково важны. Использу йте простую матрицу для расстановки приоритетов:
Оценка воздействия (при отсутствии требования):
- Критичное (4): прямая утечка данных, компрометация системы, нарушение 152-ФЗ
- Высокое (3): значительная утечка, захват аккаунтов
- Среднее (2): ограниченное воздействие, требует дополнительных условий
- Низкое (1): минимальное воздействие, только глубокая защита
Оценка вероятности эксплуатации:
- Высокая (3): распространённый вектор, лёгкая эксплуатация
- Средняя (2): требуется определённая квалификация
- Низкая (1): редкая атака, значительные усилия атакующего
Итоговый приоритет = Воздействие × Вероятность
| Балл | Приоритет | Действие |
|---|---|---|
| 9–12 | Критичный | Реализовать немедленно |
| 5–8 | Высокий | Реализовать в текущем спринте |
| 3–4 | Средний | Запланировать на следующий квартал |
| 1–2 | Низкий | Бэклог |
Отслеживание требований в рабочем процессе
Требования безопасности должны отслеживаться как любые другие рабочие задачи — в системе управления задачами (Jira, YouTrack, Kaiten, GitFlic Tasks или любом аналоге).
Жизненный цикл требования
Каждое требование проходит несколько состояний:
Не применимо → функциональность отсутствует, требование снято с учётом (обязательно с обоснованием)
Не реализовано → требование применимо, работа не начата
В работе → реализация ведётся
Реализовано → код написан, ожидает верификации
Верифицировано → подтверждено тестами или ревью, зафиксированы дата и ответственный
Привязка требований к функциям
При планировании новой функции лидер безопасности прикрепляет список применимых требований ASVS к задаче разработки. Функция не считается завершённой, пока все прикреплённые требования безопасности не переведены в статус «Верифицировано».
Это встраивает безопасность в критерии приёмки (Definition of Done) — без отдельных ревью «по безопасности» в самом конце.
Пример привязки для функции «Регистрация пользователя»:
Критерии приёмки по безопасности:
- V2.1.1: Пароль минимум 12 символов
- V2.4.1: Пароль хэшируется bcrypt с коэффициентом 12
- V5.1.1: Сер верная валидация всех полей формы
- V7.1.1: Событие регистрации записывается в журнал
Видимость для команды
Результаты проверок полезно выносить на регулярный статус:
- Сообщения в корпоративном мессенджере (VK Teams, eXpress) с еженедельным статусом покрытия требований
- Дашборд: процент верифицированных требований, количество по статусам
- Отметка на демо спринта: какие требования перешли в статус «Верифицировано»
Периодическая верификация
Требования регрессируют: код меняется, конфигурации обновляются, новые сотрудники воспроизводят старые ошибки. Установите расписание:
- Еженедельно (автоматически) — CI/CD-инст рументы сканируют код
- Ежемесячно (лидер безопасности) — проверка новых функций, обновление статусов требований
- Ежеквартально (команда) — полный пересмотр базы требований
- Ежегодно (внешний) — пентест против актуальных требований, аудит при наличии регуляторных обязательств
Опросники заказчиков по безопасности
Когда корпоративный заказчик или партнёр присылает опросник по ИБ, ASVS существенно упрощает ответы.
| Типичный вопрос | Ответ на основе ASVS |
|---|---|
| «Как хранятся пароли?» | Раздел V2.4 + реализация bcrypt |
| «Есть ли шифрование данных в покое?» | V6, V8.3 + детали реализации |
| «Ведутся ли журналы аудита?» | V7 + примеры записей |
| «Как организовано управление сессиями?» | V3 + время истечения |
| «Какое тестирование безопасности проводится?» | Записи о верификации ASVS |
Подготовьте библиотеку доказательств заранее: для каждого основного раздела ASVS — краткая справка с идентификатором требования, статусом реализации и ссылкой на подтверждение.
Работа с устаревшей кодовой базой
Если приложение уже существует и у него нет формальных требований ИБ — не пытайтесь всё исправить за один раз. Практический подход:
- Новые функции — применяйте требования с нуля к любому новому коду
- Критичные требования в первую очередь — начните с V2.4 (хэширование паролей) и V5.3 (защита от XSS): наибольший риск при наименьших затратах
- Инциденты как триггер — если нашли уязвимость, добавьте соответствующее требование и проверьте всю кодовую базу на этот паттерн
- 10–20% ёмкости спринта — системный прогресс лучше, чем разовые героические усилия
Пассворк в управлении требованиями безопасности
Работа с требованиями безопасности генерирует чувствительные артефакты: учётные данные к инструментам сканирования, тестовые аккаунты, отчёты о пентестах, аудиторские свидетельства. Хранить их в общих папках или почтовых цепочках — само по себе нарушение требований безопасности.
Пассворк — российский менеджер паролей и секретов с возможностью размещения на собственном сервере — естественно вписывается в этот процесс:
Хранение чувствительных артефактов. API-ключи инструментов сканирования (SAST, DAST, SCA) с журналом аудита и контролем срока действия. Учётные данные для тестирования и стейджинга. Ключи шифрования.
Организация доступа. Отдельный сейф для инструментов безопасности с доступом только для лидера безопасности и соответствующих руководителей. Гранулярные права позволяют выдать временный доступ к конкретному элементу без открытия всего сейфа.
Документирование. Пассворк поддерживает защищённые заметки и вложения файлов — отчёты о пентестах, аудиторские свидетельства и подтверждения выполнения требований хранятся рядом с соответствующими учётными данными.
Журнал аудита. Каждое обращение, изменение и экспорт фиксируются. Это готовые доказательства контроля доступа для аудитора: кто, когда и к чему имел доступ.
Ротация при увольнении. Когда разработчик с доступом к инструментам безопасности покидает компанию, Пассворк сразу показывает, к каким именно элементам он имел доступ — и вы ротируете только нужные учётные данные.
Инструменты для управления требованиями
Бесплатные инструменты
- Таблица ASVS — каталог ASVS доступен в форматах CSV/Excel на GitHub (github.com/OWASP/ASVS). Выгрузите, отфильтруйте применимые требования, отслеживайте статусы в столбцах.
- OWASP Threat Dragon — open-source инструмент анализа угроз. Помогает идентифицировать применимые требования до начала разработки.
- OWASP Dependency-Track — open-source платформа для отслеживания компонентного состава ПО и уязвимостей в зависимостях. Самостоятельное размещение.
Российские GRC-системы
Для компаний с активными требованиями соответствия (объекты КИИ, ГИС, финансовый сектор): R-Vision, Security Vision, ePlat4m обеспечивают управление требованиями и доказательной базой в привязке к российским нормативным актам.
Для большинства компаний МСБ на старте достаточно трекера задач (Jira, YouTrack, Kaiten) в сочетании с таблицей ASVS.
Типичные ошибки
Все требования сразу. Попытка реализовать все 286 требований ASVS одновременно перегружает команду — и в итоге ничего не делается. Начните с уровня 1 для критичных функций.
Требования без верификации. Статус «Реализовано» выставлен по памяти, без доказательств. Правило: каждый статус «Верифицировано» требует конкретного подтверждения — результатов теста, записи ревью, вывода инструмента.
Безопасность после разработки. Лидер безопасности проверяет готовую функцию. Изменения дорогие и срочные. Исправление: лидер безопасности участвует на этапе проектирования, требования определяются до начала кодирования.
Однократное упражнение. База требований создана, но не обновляется. Новые функции появляются без требований ИБ. Исправление: ежемесячные обзоры и привязка к Definition of Done.
- Лидер безопасности ознакомился с OWASP ASVS и определил применимые разделы для вашего приложения
- Создана база требований с указанием уровня ASVS и обоснованием
- Требования отслеживаются в трекере задач с явными статусами
- Новые функции получают требования безопасности до начала разработки
- В определении готовности (Definition of Done) есть пункт о верификации требований ИБ
- Установлен график периодических проверок: ежемесячно и ежеквартально
- Чувствительные артефакты (ключи, отчёты) хранятся в Пассворке или аналогичном решении
- Подготовлены ответы на стандартные вопросы опросников заказчиков по ИБ
См. также
- Основы безопасного кода — какие риски закрывают эти требования
- Безопасность CI/CD — как проверять выполнение автоматически
- Риск в деньгах и STRIDE — моделирование угроз по STRIDE
Что дальше
Теперь у вас есть фреймворк для определения и отслеживания требований безопасности. Следующий шаг — автоматизировать проверку: как встроить сканирование кода и зависимостей в CI/CD-пайплайн так, чтобы критичные проблемы не могли незаметно уйти в продакшн.