Почему техническая оценка не заменяет оценку риска
Технический отчет отвечает на вопрос, насколько мы защищены. Управленческое решение требует ответа на другой вопрос, что произойдет с бизнесом, если защита не сработает. Между этими вопросами лежит перевод, который чаще всего никто не делает.
Перевод строится через сценарий. Не «уязвимость в системе учета», а «система учета недоступна семь дней, отгрузки останавливаются, потери составляют столько-то в сутки, договорные штрафы начинаются с третьего дня». Такая формулировка попадает в реестр рисков и обсуждается на уровне, где выделяют бюджет.
Из чего складывается ущерб
Учитывать нужно все четыре составляющие, иначе оценка занижена в разы.
| Составляющая | Что входит |
|---|---|
| Простой | Недополученная выручка, простой персонала, срыв обязательств перед клиентами |
| Восстановление | Работы по восстановлению, привлечение внешних специалистов, сверхурочные |
| Регуляторные последствия | Штрафы за утечку персональных данных, предписания, проверки |
| Репутация | Отток клиентов, ухудшение условий с контрагентами, снижение цены будущих сделок |
Что должно попадать в корпоративный реестр рисков
Не все, а то, что требует решения руководства.
- Недоступность критичной системы дольше допустимого времени восстановления
- Утечка персональных данных клиентов или сотрудников
- Компрометация учетных записей с расширенными правами
- Потеря данных из-за отсутствия проверенных резервных копий
- Зависимость от поставщика, прекращение поддержки которого останавливает процесс
- Атака на подрядчика, имеющего доступ в вашу сеть
Вероятность или защищенность
Для большинства рисков информационной безопасности оценка вероятности малосодержательна. Частота атак на компанию мало зависит от нее самой, а зависит от общего фона. Содержательнее оценивать другое, насколько система устойчива к типовому воздействию и как быстро восстанавливается.
Практический вывод. В шкале для этой группы рисков разумно заменить вопрос «как часто» на два вопроса, «пройдет ли типовая атака» и «за сколько восстановимся». Оба ответа проверяются испытанием, а не экспертным мнением.
Где заканчивается безопасность и начинается непрерывность
Информационная безопасность снижает вероятность инцидента, управление непрерывностью снижает последствия того инцидента, который все же произошел. Обе функции нужны, и провал обычно случается на стыке, когда каждая считает, что смежную часть закрывает другая.
Разбор границы ролей, зоны обязательного пересечения и типичных перекосов вынесен на отдельный сайт направления непрерывности, материал BCM и информационная безопасность. Практическая работа с этой группой рисков разбирается в программе управление рисками в ИТ.
Защита данных и восстановление после атаки это две разные задачи с разными владельцами. Почему ИТ-отдел сам по себе бизнес не защищает и кто отвечает за возврат к работе: разбор на bcm.risk-place.ru.
Частые вопросы
Владелец процесса или системы, а не служба безопасности. Служба задает требования и контролирует, но решение о вложениях и допустимом уровне защиты принимает бизнес.
Не реже раза в квартал и обязательно при изменении ландшафта: новая система, новый подрядчик с доступом, изменение регуляторных требований.
Отдельная шкала не нужна, нужна корректная формулировка сценария в бизнес-терминах. Тогда риск оценивается по общей шкале компании и сравним с остальными.
Проверьте зрелость своей системы управления рисками
Тринадцать вопросов по пяти уровням ГОСТ Р 70350, результат сразу: уровень, три главных пробела и следующий шаг.
