Использование KPI в процессе внедрения контролей ИБ

Актуальность понятна: бизнес всегда пытался измерить ИБ "общим аршином". И не мог. Обосновать штрафом в 5 тыс. руб. внедрение DLP за 5 млн сложно, а лучшие практики – неочевидный аргумент для людей, ничего в ИБ не понимающих. В итоге ИБ-бюджет существенно уступает бюджету ИТ, а сотрудников катастрофически не хватает. Еще один заслуживающий внимания аспект "измерения" ИБ – использование понятных количественных показателей (KPI) для обоснования внедрения и выбора контролей (мер) ИБ.

О правильном целеполагании

Правильно выстроенные KPI могут применяться для постановки задач и контроля результатов в связке бизнес–ИБ и внутри самой ИБ-службы. Нормализованные KPI позволяют сравнить показатели различных подразделений и оценить зрелость системы обеспечения ИБ в компании в целом. А используя неверно сформулированные, нечеткие и неизмеримые показатели, эти процессы можно и похоронить.

KPI как гарант прозрачности

Как же использовать инструмент KPI при выборе и обосновании внедрения контролей ИБ? Рассмотрим алгоритм (см. рис.), направленный на максимальную прозрачность данного процесса для бизнеса (да и для ИБ тоже). l Анализ ключевых бизнес-процессов и целей бизнеса, выявляющий основные показатели, характеризующие бизнес-риски (например, соотношение поставленной продукции с контрактным значением, продолжительность простоя и стоимость восстановления после аварии, уровень травматизма и пр.). Свести риски к нулю невозможно, поэтому нужно определить приемлемый для руководства компании уровень каждого из них.

• Анализ рисков ИБ, чреватых реализацией бизнес-рисков. Например, заражение вредоносным кодом или сетевая атака на SCADA-систему могут привести к аварии и даже человеческим жертвам. Затем по каждому из рисков ИБ формируется перечень уязвимостей, которые могут позволить ему реализоваться. Необходимо максимально четко показать связь: риск бизнеса – риск ИБ – уязвимость ИБ. Надо понимать, что уязвимости типа "Недостатки патч-менеджмента" или "Уязвимость систем аутентификации к перебору пароля" ничего не говорят бизнесу, поэтому подавать их лучше сквозь призму рисков, как детали.

• Формирование KPI, по которым планируется оценивать эффективность внедряемых контролей, стоит начать с перечня параметров оценки. Общие параметры и их желательные значения ("Число установленных патчей безопасности – все") прогоняют через критерий SMART. Используя информацию о приемлемом уровне риска, получают конкретный KPI ("Число успешно установленных проверенных патчей – >95%").

•l Выбор подходящих контролей из "экспертного мнения" превращается в решение системы уравнений. В рамках доступных ресурсов нужно достичь KPI. Можно сравнить бизнес-эффективность совершенно разных контролей. На одной доске оказываются, например, "Повышение осведомленности пользователей" и "Внедрение SIEM". Причем уравнения могут и не сойтись. Тогда можно обратиться к бизнесу, но не с просьбой дать еще денег непонятно на что, а с прозрачным отчетом, показывающим необходимость выделения дополнительных ресурсов или повышения приемлемого уровня бизнес-рисков.

• Внедрение контролей позволяет с помощью разработанной системы метрик делать оценку до окончания всех работ, при необходимости заблаговременно корректируя процесс.

• Оценка результатов на основе KPI производится понятным для всех участников процесса методом. Это те же KPI, что использовались при планировании. Для сбора статистики необязательно ждать реальных атак – можно их смоделировать (например, выполнив тесты на проникновение).

Однако дьявол кроется в деталях: мы рассмотрели лишь общий алгоритм, каждый из шагов которого имеет подводные камни, чье преодоление требует времени и ресурсов. Хотя результат – измеримые и понятные показатели эффективности выбора и внедрения контролей ИБ – стоит затраченных усилий.