Repository navigation
security processes
Onixus edited this page Sep 9, 2026
·
1 revision
Данный документ содержит формализованное описание четырех ключевых процессов ИБ, реализуемых с использованием платформы Shapoclyack:
- Процесс управления уязвимостями (Vulnerability Management Lifecycle);
- Процесс непрерывного управления поверхностью атаки (EASM);
- Процесс экстренного реагирования на 0-day и активные угрозы (Emergency Response);
- Регламент взаимодействия служб ИБ и ИТ/DevOps (Remediation Workflow).
Цель процесса — систематическое выявление, приоритизация, устранение и контроль закрытия уязвимостей в инфраструктуре компании с минимизацией операционных издержек.
flowchart TD
Start(["Старт процесса<br/>(Расписание / Триггер)"]) --> Scan["1. Сканирование периметра и хостов<br/>(Shapoclyack Scanner & Lariska Agent)"]
Scan --> Enrich["2. Обогащение и скоринг NIST SP 800-30<br/>(EPSS, CISA KEV, Exploit Maturity, Criticality)"]
Enrich --> Triage{"3. Триаж инженера ИБ<br/>(Валидация находки)"}
Triage -->|Ложное срабатывание| FP["Закрытие: False Positive<br/>(Фиксация в аудит-логе)"]
Triage -->|Подтверждено| Ticket["4. Назначение и создание тикета<br/>(Jira / ServiceNow / DefectDojo)"]
Ticket --> Fix["5. Устранение уязвимости<br/>(ИТ / DevOps: патчинг, конфигурация)"]
Fix --> Verify{"6. Инструментальная верификация<br/>(POST /api/vulnerabilities/{id}/verify)"}
Verify -->|Уязвимость осталась| Fix
Verify -->|Уязвимость устранена| Close["7. Закрытие с признаком<br/>machine_verified = true"]
Ticket -.->|Невозможно устранить в срок| Except["Согласование исключения<br/>(Risk Acceptance с дедлайном)"]
Except -.->|Истек срок исключения| Triage
- Обнаружение (Discovery): регулярное сканирование портов, баннеров, скриптов NSE, шаблонов Nuclei и сбор инвентаря ПО агентом Lariska.
- Обогащение (Enrichment): платформа сопоставляет находки с NVD, EPSS, CISA KEV, PoC-репозиториями и базой USN/Debian.
-
Триаж (Triage): первичный разбор инженером ИБ находок в статусе
OPEN. Перевод вACKNOWLEDGEDилиPLANNED. -
Устранение (Remediation): перевод в статус
FIXING, автоматическое создание задачи в таск-трекере ответственной команды. -
Верификация (Verification): перевод в статус
VERIFYINGи автоматический запуск таргетированного пересканирования. -
Закрытие (Closure): перевод в
CLOSEDтолько при получении отрицательного результата проверки (closure_reason = verified_remediated).
Сроки устранения отсчитываются с момента первой регистрации находки платформой (first_seen_at) и зависят от контекстного уровня риска NIST:
| Уровень риска NIST | Нормативный срок (SLA) | Срок взятия в триаж | Предупреждение о просрочке |
|---|---|---|---|
| Critical | 7 календарных дней | 4 часа | За 48 часов до дедлайна |
| High | 14 календарных дней | 24 часа | За 72 часа до дедлайна |
| Moderate (Medium) | 30 календарных дней | 3 рабочих дня | За 5 дней до дедлайна |
| Low / Info | 90 календарных дней | 5 рабочих дней | За 10 дней до дедлайна |
При несоблюдении SLA уязвимость переходит в состояние breached, что фиксируется в отчетах для CISO.
Цель процесса — поддержание 100% видимости всех цифровых активов компании, исключение появления «теневых» серверов (Shadow IT) и предотвращение захвата поддоменов.
flowchart LR
Seeds["Корневые семена<br/>(Домены, ASN, CIDR)"] --> Discovery["Автоматический Discovery<br/>(DNS, CT-логи, RDAP, Cloud)"]
Discovery --> Diff["Контроль изменений (Diff)<br/>(Новые хосты, порты, TLS-сертификаты)"]
Diff --> Classify{"Классификация актива"}
Classify -->|Легитимный ресурс| CMDB["Привязка владельца и ИС<br/>(Обогащение context_source: cmdb)"]
Classify -->|Неизвестный / Shadow IT| Alert["Алерт ИБ: Несанкционированный актив<br/>(Расследование инцидента)"]
CMDB --> Scope["Включение в регулярный скан"]
-
Еженедельный запуск модуля
org_profile:- Мониторинг появления новых связанных доменов (
related_domains); - Аудит DNS-записей на наличие Dangling CNAME (висячих ссылок на отключенные S3/облака);
- Проверка срока действия TLS-сертификатов (уведомление при остатке < 21 дня);
- Контроль записей SPF, DKIM и строгой политики DMARC (
p=reject).
- Мониторинг появления новых связанных доменов (
-
Обработка новых обнаруженных хостов:
- Любой новый IP/FQDN автоматически помечается как
unowned_asset; - Инженер ИБ направляет запрос в ИТ-подразделение для идентификации системы;
- Хосту назначаются атрибуты
owner_email,business_service,environment,asset_criticality.
- Любой новый IP/FQDN автоматически помечается как
Процесс активируется при публичном раскрытии критической уязвимости «нулевого дня» (0-day) или включении уязвимости в каталог активных атак CISA KEV.
sequenceDiagram
autonumber
actor CISO as CISO / Штаб реагирования
actor Eng as Инженер ИБ
participant Shap as Shapoclyack API
actor IT as ИТ-инженеры / DevOps
Note over CISO,IT: T-0: Публикация критической угрозы (0-day / CISA KEV)
CISO->>Eng: Распоряжение на проведение внепланового аудита
Eng->>Shap: Запуск таргетированного скана (intent: vuln, template: CVE-XXXX)
Shap-->>Eng: Отчет: 3 хоста уязвимы (из них 2 в публичном доступе!)
Eng->>CISO: Эскалация: точный перечень затронутых бизнес-систем
Eng->>IT: Создание экстренных задач с готовыми инструкциями
IT->>IT: Установка патча или активация компенсирующих мер (WAF / IP ACL)
IT->>Eng: Отчет об устранении
Eng->>Shap: POST /api/vulnerabilities/{id}/verify (Механическая перепроверка)
Shap-->>Eng: Результат: уязвимость не воспроизводится (machine_verified: true)
Eng->>CISO: Доклад о нейтрализации угрозы
- T+0 ... T+2 часа: идентификация сигнатуры угрозы (Nuclei-шаблон / CVE ID).
-
T+2 ... T+6 часов: запуск экспресс-сканирования всей внешней и внутренней инфраструктуры (
intent: vuln). Оценка достижимости сервиса. - T+6 ... T+12 часов: внедрение компенсирующих мер (блокировка правила на WAF, ограничение доступа сетевыми экранами, изоляция сервиса).
- T+12 ... T+48 часов: установка официального вендорного патча, запуск повторного верификационного скана и закрытие инцидента.
Для обеспечения конструктивного взаимодействия и исключения конфликтов между ИБ и разработкой регламентируются строгие правила обмена задачами.
Любая задача, передаваемая из Shapoclyack в Jira/ServiceNow, обязана содержать исчерпывающий технический контекст:
- Точный адрес и компонент: IP, FQDN, сетевой порт, название сервиса или имя установленного Linux-пакета.
- Доказательство (Evidence): точный вывод сетевого сканера (HTTP-запрос, ответ с уязвимым фрагментом, скриншот).
-
Рекомендация по устранению:
- Ссылка на бюллетень безопасности;
- Готовая консольная команда (для пакетов ОС, например:
apt-get install --only-upgrade <package>); - Либо параметры конфигурационного файла.
- Контрольный срок (SLA): точная дата дедлайна.
- Запрет одностороннего закрытия: перевод задачи в статус «Решено» со стороны ИТ не приводит к автоматическому закрытию уязвимости в Shapoclyack.
- Задача переходит в статус «На проверке ИБ» (In Verification).
- Инженер ИБ инициирует автоматическую перепроверку через
POST /verify. - Если перепроверка не подтвердила исправление, задача возвращается разработчикам с обновленным логом сканирования.
Если патч не может быть установлен в установленный SLA срок:
- Владелец бизнес-системы оформляет заявку на принятие риска через карточку в Shapoclyack.
- Обязательные условия согласования:
- Наличие компенсирующей меры (WAF, VPN, сегментация, мониторинг SIEM);
- Указание конечного срока действия (не более 90 дней);
- Согласование с CISO для уязвимостей уровня Critical/High.
- По истечении срока исключение автоматически аннулируется системой, возобновляя начисление штрафных баллов за просрочку.