Из 12 внутренних аудитов СУИБ, которые я провёл за последние два года, в 9 случаях критические несоответствия были связаны не с отсутствием технических средств защиты, а с разрывом между документированными политиками и тем, что реально происходит в инфраструктуре. Политика управления доступом - в PDF на SharePoint, учётки уволенных сотрудников висят в Active Directory месяцами. Реестр рисков - в Excel на диске CISO, последнее обновление полгода назад. Знакомо?
Построение системы управления ИБ, которая работает, а не существует для галочки, требует другого подхода: от процессов - к конкретным контролям в пайплайне. Не от политик к реальности, а наоборот.
Scope СУИБ: что включаем и почему это первый шаг
Ошибка, которую я вижу в большинстве проектов внедрения: команда начинает с написания политик, не определив scope. Результат - политика информационной безопасности компании покрывает «всю организацию», но на практике не касается ни одного конкретного бизнес-процесса. Красивый фантик без содержимого. Подробнее - в нашем материале про зрелость программы кибербезопасности.ISO/IEC 27001:2022 (clause 4) требует определить контекст организации до начала работы с рисками. На практике это три слоя:
- Внешний контекст: регуляторные требования (ФЗ-152 для ИСПДн, приказы ФСТЭК №17/21 для государственных ИС), договорные обязательства перед контрагентами, ожидания рынка.
- Внутренний контекст: критичные бизнес-процессы, ИТ-хозяйство (on-prem, cloud, hybrid), текущий уровень зрелости ИБ, доступные ресурсы.
- Scope: конкретные подразделения, информационные системы и процессы, которые покрывает система менеджмента ИБ.
Документ, фиксирующий scope - Statement of Applicability (SoA). В нём перечислены все контроли из Annex A ISO 27001:2022 (93 контроля в 4 категориях) с указанием, какие применимы, какие нет и почему. SoA - первый документ, который запросит внешний аудитор.
Оценка рисков ИБ - от абстрактной матрицы до тикета в Jira
Процесс управления рисками ИБ по ISO 27001 формально прост: идентифицировать активы, определить угрозы и уязвимости, оценить вероятность и последствия, выбрать способ обработки. На практике именно здесь проекты внедрения СУИБ буксуют месяцами.Реестр рисков: формат и привязка к MITRE ATT&CK
Реестр рисков информационной безопасности - живой документ, а не таблица, заполненная раз в год перед аудитом. Минимальная структура записи:| Поле | Описание | Пример |
|---|---|---|
| Risk ID | Уникальный идентификатор | RISK-2025-017 |
| Актив | Информационный актив или система | GitLab-сервер (prod) |
| Угроза | Привязка к ATT&CK | Exploit Public-Facing Application (T1190, Initial Access) |
| Уязвимость | Техническая или организационная | Отсутствие WAF, задержка патчинга >30 дней |
| Вероятность | 1-5 | 4 |
| Последствия | 1-5 | 5 |
| Уровень риска | Вероятность x Последствия | 20 (критический) |
| Владелец риска | Кто принимает решение | CTO / DevOps Lead |
| Способ обработки | Снижение / Принятие / Передача / Избежание | Снижение |
| Контроль | Конкретная мера | WAF + автопатчинг через pipeline |
| Статус | Jira-тикет | SEC-417 (In Progress) |
Привязка угроз к MITRE ATT&CK - не академическое упражнение. Она решает три задачи:
- Единый язык при обсуждении рисков с SOC-командой и руководством. Когда инженер и CISO говорят «T1078» - оба понимают одно и то же.
- Маппинг контролей на техники: если в реестре есть риск Valid Accounts (T1078, Initial Access / Persistence / Privilege Escalation) - контролем будет MFA и мониторинг аномальных логинов, что соответствует CIS Control 5 (Account Management) и NIST SP 800-53 IA-1.
- Приоритизация: Vulnerability Scanning (T1595.002, Reconnaissance) - угроза для публичного периметра, Brute Force (T1110, Credential Access) - для всех сервисов с парольной аутентификацией.
Для тех, кто не может позволить SGRC - NIST CSF v2.0 предлагает функции GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, RECOVER как структуру для самооценки. Можно начать с MITRE Caldera или Atomic Red Team для бесплатной валидации контролей.
Impact/Likelihood и приоритизация обработки
Матрица Impact/Likelihood - стандартный инструмент оценки рисков ИБ, но часто применяется формально. Типичная картина: все риски оценены на 3x3 или 4x4, потому что оценщик не хочет принимать ответственность за крайние значения. Удобно, безопасно - и бесполезно.Чтобы матрица работала, нужны чёткие критерии для каждого уровня:
- Последствия (Impact): привязать к бизнес-метрикам. Уровень 5 - остановка основного бизнес-процесса на >4 часа, утечка ПДн >10 000 субъектов (с последствиями по ФЗ-152 ст. 6), штраф от регулятора. Уровень 1 - инцидент без влияния на доступность и конфиденциальность.
- Вероятность (Likelihood): привязать к частоте. Уровень 5 - ежемесячные попытки (Brute Force на публичный RDP - вполне реальный сценарий, проверьте логи своего сервера). Уровень 1 - теоретическая возможность, не зафиксировано за 3 года.
Способы обработки рисков (ISO 27001):
- Снижение - внедрение контроля (WAF, MFA, хардинг по CIS Benchmarks).
- Передача - страхование киберрисков, аутсорс SOC.
- Принятие - осознанное решение владельца риска (документируется в реестре с подписью). Не «забыли про риск», а «знаем, принимаем, вот подпись».
- Избежание - отказ от деятельности, порождающей риск.
Политика информационной безопасности компании как код
Security gate в CI/CD - политика, которая блокирует мердж
Контроль CIS-4 (Secure Configuration of Enterprise Assets and Software) требует поддерживать безопасную конфигурацию. Для DevSecOps это security gate в пайплайне:
YAML:
# .gitlab-ci.yml - security gate
sast_scan:
stage: test
script:
- semgrep --config=auto --error --json -o report.json .
allow_failure: false
dependency_check:
stage: test
script:
- trivy fs --exit-code 1 --severity HIGH,CRITICAL .
allow_failure: falseallow_failure: false - при обнаружении критической уязвимости merge request не проходит. Контроль СУИБ в автоматически исполняемом формате. Не «пожалуйста, проверьте код», а «код не пройдёт, пока не исправите».Маппинг на стандарты:
- CIS Control 16 (Application Software Security) - SAST/DAST в пайплайне
- NIST CSF v2.0 DE.AE-01 (Adverse Event Analysis) - мониторинг результатов сканирования как baseline
- NIST CSF v2.0 PR.AA-01 - контроль доступа к репозиторию через RBAC GitLab
Аудит информационной безопасности: внутренний и подготовка к внешнему
Внутренний аудит СУИБ - обязательное требование ISO 27001 (clause 9.2). Проводится минимум раз в год, в зрелых организациях - ежеквартально по отдельным доменам.Автоматизированный сбор доказательной базы
Главная боль аудита - сбор доказательств (evidence). Аудитор спрашивает: «Покажите, что контроль управления доступом работает». Без автоматизации начинается ручной сбор скриншотов - и это ад. С автоматизацией метрики собираются непрерывно:- HashiCorp Vault - аудит-лог всех операций с секретами (кто запросил, когда, какой secret path). Закрывает CIS-5 (Account Management) и NIST SP 800-53 AC-1.
- GitLab CI/CD - лог прогонов security gates, история merge request reviews. Доказательство исполнения политик - не скриншот, а артефакт пайплайна.
- SonarQube - история quality gate за период. Тренд: количество уязвимостей в коде снижается или растёт.
- OpenSCAP - автоматическая проверка конфигураций на соответствие CIS Benchmarks.
Bash:
# Проверка конфигурации по CIS Benchmark
oscap xccdf eval \
--profile xccdf_org.ssgproject.content_profile_cis \
--results scan-results.xml \
--report scan-report.html \
/usr/share/xml/scap/ssg/content/ssg-centos8-ds.xmlЧек-лист подготовки к сертификационному аудиту ISO 27001
Стандарт ISO 27001 внедрение завершается сертификационным аудитом в два этапа. Stage 1 (документационный): аудитор проверяет полноту документации. Stage 2 (операционный): проверка реальной работы процессов - интервью с сотрудниками, изучение логов, выборочный контроль. После сертификации - два года наблюдательных аудитов, затем ресертификация.Минимальный набор документов для Stage 1:
| Документ | Что проверяется | Источник данных |
|---|---|---|
| Область применения СУИБ | Границы scope | Confluence / Wiki |
| Политика ИБ | Утверждена руководством, актуальна | Git (policy-as-code) |
| Методика оценки рисков | Критерии Impact/Likelihood | Confluence |
| Реестр рисков | Полнота, связь с контролями | Jira + Google Sheets |
| Statement of Applicability | 93 контроля Annex A с обоснованием | Confluence |
| План обработки рисков | Сроки, ответственные, статус | Jira (фильтр по label SEC) |
| Результаты внутреннего аудита | Несоответствия и корректирующие действия | Jira (тип: Audit Finding) |
| Протокол Management Review | Решения руководства по СУИБ | Confluence |
Типичные ошибки при подготовке (видел каждую из них не раз):
- SoA не синхронизирован с реестром рисков - аудитор видит контроль «применим», но в реестре нет связанного риска. Вопрос «почему применили этот контроль?» повисает в воздухе.
- Нет evidence исполнения - политика утверждена, но нет доказательств обучения сотрудников (контроль AT-1 по NIST SP 800-53). Политику подписали, а сотрудники её не читали.
- Корректирующие действия не закрыты - после внутреннего аудита созданы тикеты, но ни один не имеет статуса Done. Аудитор это читает как «проблему нашли, но чинить не стали».
Непрерывное улучшение ИБ: PDCA на практике
ISMS в компании - не проект с финальной датой. ISO 27001 построен на цикле PDCA (Plan-Do-Check-Act), и аудитор оценивает наличие этого цикла, а не идеальное состояние контролей. Можно иметь открытые несоответствия - главное, чтобы по ним были тикеты с дедлайнами.Plan: определение scope, оценка рисков, разработка плана обработки. Артефакт - реестр рисков и план обработки в Jira.
Do: внедрение контролей. Security gates в CI/CD, настройка MFA, хардинг по CIS Benchmarks, обучение сотрудников. Артефакт - закрытые тикеты, настроенные пайплайны, журналы обучения.
Check: внутренний аудит и мониторинг. Сканирование OpenSCAP, анализ логов Vault, метрики SonarQube. Артефакт - отчёты аудита, дашборды.
Act: корректирующие действия. Обновление реестра рисков, корректировка контролей, пересмотр политик. Артефакт - обновлённый реестр, закрытые audit findings.
Модель зрелости ИБ помогает оценить, где вы сейчас:
| Уровень | Описание | Признаки |
|---|---|---|
| 1. Начальный | Процессы отсутствуют или хаотичны | Нет документации, реактивное реагирование |
| 2. Повторяемый | Базовые процессы определены | Политики есть, исполнение не контролируется |
| 3. Определённый | Процессы стандартизированы | Реестр рисков актуален, security gates работают |
| 4. Управляемый | Процессы измеряются | Метрики собираются автоматически, KPI определены |
| 5. Оптимизируемый | Непрерывное улучшение | PDCA-цикл замкнут, корректирующие действия закрываются в срок |
Большинство организаций, с которыми я работал, сидят на уровне 2 - политики написаны, автоматизации контроля исполнения нет. Переход с уровня 2 на уровень 3 даёт наибольший практический эффект: здесь появляются security gates, автоматический сбор метрик и привязка рисков к тикетам. Именно этот переход стоит делать первым.
По данным проекта Infosecurity для производственной компании на 10 000 сотрудников, построение системы управления ИБ заняло 7 месяцев. В средней компании (200-500 человек) реалистичный срок - 6-9 месяцев до первого внешнего аудита: 2 месяца на scope и оценку рисков, 3-4 месяца на внедрение контролей и документацию, 1-2 месяца на внутренний аудит и подготовку к Stage 1. Между аудитами система должна демонстрировать улучшение - и это измеряется конкретно: время закрытия уязвимостей, процент обученных сотрудников, количество инцидентов за период.
Главная проблема системы управления информационной безопасностью в российских компаниях - не отсутствие стандартов или инструментов. Это разрыв между ИБ-командой и разработкой. ISO 27001 описывает внедрение через контроли и процессы, но не говорит, как интегрировать эти контроли в GitLab CI, Terraform или Ansible. CISO пишет политику «все изменения в продуктовой инфраструктуре должны проходить security review» - и она лежит мёртвым грузом, потому что нет механизма enforcement.
Security gate в пайплайне решает эту проблему: SAST-сканер нашёл SQL-инъекцию - merge request не проходит. Это не «осведомлённость» и не «рекомендация». Это механический контроль. На таких контролях и строится СУИБ, которая переживает первый аудит и продолжает работать в рутине.
Большинство провалившихся СУИБ-проектов объединяет одно: команда писала документы для аудитора, а не для себя. Реестр рисков заполнялся формулировками из методички, контроли описывались абстрактно - «обеспечить защиту от несанкционированного доступа». Без привязки к конкретной системе, конкретной технике атаки, конкретному инструменту. Когда аудитор на Stage 2 спрашивал инженера «как вы обеспечиваете этот контроль?» - инженер пожимал плечами.
А теперь другой сценарий. Рисковый сценарий «Использование скомпрометированных учётных данных (T1078, Valid Accounts)» привязан к тикету SEC-312 с описанием «внедрить MFA для VPN и SSH через Keycloak, дедлайн - 15.03». Тикет закрыт с коммитом в Ansible playbook. Аудитор видит замкнутый цикл. Видит систему, а не набор PDF-файлов.
Именно это отличает СУИБ, которая работает, от СУИБ, которая существует. Проверьте свой реестр рисков прямо сейчас: сколько записей привязано к тикетам в Jira? Если ответ «ноль» - вы на уровне 2, и у вас есть конкретная точка роста. На курсе WAPT эту связку «риск → тикет → контроль → evidence» разбирают на практических лабах с реальным CI/CD-пайплайном.
