Презентация_Штат_ИБ_дежурства

1.

Защита штата отдела
информационной безопасности
Штат 8 FTE • Модель дежурств 5×2 + on-call • SLA P0 15 мин / P1 1 час
Источник: «Штат отдела ИБ с дежурствами.xlsx» (все листы)

2.

Контекст и цель
Что должен обеспечивать отдел ИБ
Целевые требования
• 24×7 реагирование на P0/P1 через дежурства
(основной + резервный)
• SLA реакции: P0: 15 мин; P1: 1 час
• Единый контур оповещений: SOC (SIEM) + Zabbix →
дежурный (SMS/звонок/мессенджер/почта)
• Регулярная приёмка новых объектов в эксплуатацию и
контроль изменений
• Закрытие комплаенса/КИИ/ПДн + готовность к
проверкам
Ограничения и риски при недоштате
• Не выдерживается SLA по P0/P1 (ночь/выходные)
• Риск «single point of failure» по ключевым областям
(SIEM/IR/IAM/VM)
• Срыв сроков приёмки и ввод объектов с крит.
замечаниями
• Накопление уязвимостей и «повторные находки»
Что считаем успехом
• Стабильная ротация дежурств ≥ 6 участников
• Прозрачная матрица ответственности (RACI) и
измеримые KPI
• Покрытие критических и высоких рисков
выделенными ролями

3.

Штатная модель (8 FTE)
В дежурстве: 6 участников
Роли и уровни
1) Архитектор ИБ — Senior (архитектура/требования)
2) GRC/комплаенс — Middle/Senior (КИИ/ПДн/ОРД)
3) IAM/PAM — Middle (доступы/VPN/2FA/PAM)
4) VM — Middle (уязвимости и контроль устранения)
5) SIEM/SOC — Middle/Senior (логирование/интеграции)
6) IR/DFIR — Middle (реагирование/расследования)
7) Приёмка (Sr) — Senior (ИБ-заключение, CAB)
8) Приёмка (Jr) — Junior/аналитик (реестры/подготовка)
Распределение по направлениям
2
1.8
1.6
1.4
1.2
1
0.8
0.6
0.4
0.2
0
с
ра
ен
ту
а
к
л
е
мп
ит
о
х
/к
Ар
RC
G
Итого: 8 FTE (без руководителя)
A
/P
M
IA
M
VM
и)
ст
о
м
ви
з
я
(у
/S
EM
I
S
C
O
IR
/D
R
FI
Приёмка = 2 FTE, чтобы не блокировать ввод объектов и CAB
а
мк
е
и
Пр

4.

Покрытие функций (RACI)
Где закреплена ответственность (A) и исполнение (R)
Ключевые выводы
• Каждая функция имеет владельца (A) — нет «ничейных» зон
• Исполнение (R) распределено между приёмкой и
профильными инженерами
• Change/CAB и ИБ-заключение: A у Приёмки (Sr), R — у
Приёмки (Jr)
• Архитектор и IR/DFIR вовлечены как C почти во все ключевые
потоки
Сколько A/R на роль
10
9
8
7
6
5
4
3
2
1
0
Архитект
ор
GRC
IAM/PAM
VM
A (ответственность)
SIEM/
SOC
IR/DFIR Приемка Приемка
Sr
Jr
R (исполнение)
Высокая доля R у приёмки — чтобы разгружать профильных инженеров и
держать поток ввода объектов.

5.

Модель дежурств и SLA
5×2 дневной дежурный + on-call ночью/в выходные
Параметры
Дневная смена: 09:00–18:00 (5×2)
On-call ночь: 18:00–09:00 (будни)
On-call выходные: 24×7 (выходные)
SLA реакции: P0: 15 мин; P1: 1 час
Нагрузка (основной дежурный)
3
2.5
2
Пример ротации (8 недель)
Нед 1 (12.01.2026–18.01.2026): Инженер IR/DFIR | рез. Инженер SIEM/SOC
Нед 2 (19.01.2026–25.01.2026): Инженер SIEM/SOC | рез. Инженер VM
Нед 3 (26.01.2026–01.02.2026): Инженер VM | рез. Инженер IAM/PAM
Нед 4 (02.02.2026–08.02.2026): Инженер IAM/PAM | рез. Приёмка (Sr)
Нед 5 (09.02.2026–15.02.2026): Приёмка (Sr) | рез. Приёмка (Jr)
Нед 6 (16.02.2026–22.02.2026): Приёмка (Jr) | рез. Инженер IR/DFIR
Нед 7 (23.02.2026–01.03.2026): Инженер IR/DFIR | рез. Инженер SIEM/SOC
Нед 8 (02.03.2026–08.03.2026): Инженер SIEM/SOC | рез. Инженер VM
1.5
1
0.5
0
IR/DFIR
SIEM/SOC
Приёмка
VM
IAM/PAM
Принцип: равномерная ротация + резервный на каждый период
SLA: P0 15 мин / P1 1 час (для всей ротации)

6.

Оповещение и эскалация
Как подключается дежурный и как фиксируется результат
1. Событие
SOC (SIEM) / Zabbix формируют
P0/P1/P2
2. Уведомление
Дежурный получает
SMS/звонок/мессенджер/почту
3. ACK + работа
Подтверждение и подключение:
чат/созвон, анализ, локализация
Контроль качества канала
• ACK + повторная эскалация → исключаем «тихие пропуски»
• Интеграция с тикетингом → единый учет инцидентов и SLA
• Регулярные тесты канала: целевой показатель успешности ≥ 95%
4. Эскалация
P0 → резервный +
архитектор/владельцы систем
5. Завершение
RCA + задачи на устранение
причин/уязвимостей

7.

План интеграции уведомлений (N-001…N-007)
4 недели до базового контура + постоянные тесты
Дорожная карта
Неделя 1
Неделя 2
Неделя 3
Неделя 4
Постоянно
N-001
N-003
N-005
N-006
N-007
N-002
N-004
Критерии приемки (выдержка)
• N-002: уведомление дежурного < 1 мин
• N-003: повторная эскалация срабатывает на тестах
• N-004: заведено ≥ 20 ключевых триггеров
• N-007: журнал тестов; успешность ≥ 95%

8.

Покрытие рисков
Роли ИБ привязаны к рискам и задачам плана
Портфель рисков (свод)
Сколько рисков покрывает роль
SIEM/SOC
Приемка (Jr)
VM
IAM/PAM
GRC
Приемка (Sr)
IR/DFIR
• Фокус: 1 критический + 14 высоких рисков требуют 24×7 реакции
• Часть мер реализует ИТ/эксплуатация — ИБ задаёт требования и
принимает результат
Архитектор
0
1
2
3
4
5
6
7
Наиболее нагруженные по рискам: Архитектор и IR/DFIR (≈7 рисков
каждый).
8

9.

KPI и измеримость
Метрики по ролям — чтобы управлять качеством и нагрузкой
Примеры KPI (выдержка)
Архитектор ИБ
VM
GRC/комплаенс
SIEM/SOC
IAM/PAM
IR/DFIR
% объектов принятых без замечаний; срок согласования архитектуры; доля
крит. замечаний закрыта
актуальность ОРД (≥95%); выполнение плана корректирующих мероприятий;
срок подготовки пакета документов
% админ-доступов через PAM; срок закрытия заявок на доступ; % ревизий
доступов в срок
% крит. уязвимостей закрыто в SLA; количество повторных находок; покрытие
активов сканом
MTTA; доля алертов с корректной классификацией; % ложных срабатываний
MTTR (P0/P1); % инцидентов с RCA; соблюдение SLA реагирования

10.

Укомплектование и шаги
Что нужно, чтобы модель заработала устойчиво
Статус по позициям (из примечаний)
План на ближайшие 4–6 недель
Закрываем/выходит
В поиске
Требует уточнения
Резерв/по мере роста
• Нед. 1–2: закрыть блок N-001…N-004 (категоризация,
каналы, ACK, триггеры)
• Нед. 3–4: webhook + тикетинг (N-005…N-006), прогон
тест-кейсов
• Собеседования/офферы по ролям «В поиске»
(IAM/VM/SIEM или экв.)
• Уточнить профиль архитектора и младшей приёмки
(встречи/границы ответственности)
• Запустить регулярные тесты канала (N-007) и ретро по
инцидентам
• Минимум для устойчивых дежурств: закрыть 6 участников ротации
• Приёмка (Jr) включается в ротацию после периода адаптации
Результат: дежурства + мониторинг/оповещение начинают работать как
процесс, а не «героизм».