Тема измерения эффективности ИБ — одна из проблемных в отрасли. Как показать бизнесу, что инвестиции в ИБ были вложены не зря? Как убедить, что работа отдела эффективна? Ниже ряд показателей, которые, на наш взгляд, помогут оцифровать деятельность функции ИБ. Параметры могут быть неприменимы к конкретной организации, также их может быть меньше, чем хотелось бы, но все зависит от наличия или отсутствия инструментов. Список показателей является «подвижным, гибким», может расширяться или сужаться в зависимости от пожеланий руководства компании.
Антивирусная защита (АВЗ)
Необходимость антивирусной защиты очевидна. Пожалуй, это бесспорное средство защиты в глазах акционеров, на которое выделят деньги, и вопрос будет в выборе АВЗ. А какие показатели эффективности выделяют в этом направлении?
• Доля ПК/серверов, охваченных средствами АВЗ. В случае, если в компании идет внедрение нового АВЗ, в показатели вносят и динамику (месяц/квартал) миграции на новый АВЗ.
Доля ПК/серверов со статусом «критичный». Подобный статус есть у решения Касперского, который сигнализирует о проблемах с АВЗ. Сам статус устанавливает ряд условий, которые описаны на официальном сайте Support Kaspersky:
Управление уязвимостями
Сложный показатель. Во-первых, в одном продукте может быть выявлено несколько уязвимостей. Во-вторых, информация об уязвимостях появляется регулярно, и в течении недели количество выявленных уязвимостей может увеличиться в разы за счёт обновления базы уязвимостей.
Тем не менее, вести статистику по уязвимостям необходимо — Вы не только будете знать, что происходит в сети, но и получите аргумент для руководства при закупке решений, направленных на работу с уязвимостями.
Деление статистики происходит по параметрам:
• Доля уязвимого ПО на ПК;
• Доля уязвимого ПО на серверах;
• Доля уязвимого ПО на сетевом оборудовании;
• Динамика уязвимого программного обеспечения в разрезе степеней критичности.
Еще один интересный параметр, который можно внедрить – средний срок закрытия уязвимостей, выявленных во время сканирования ресурсов Компании. Показатель зависит от IT отдела, однако станет рычагом для решения вопросов по своевременному обновлению ПО, если ИТ не будет справляться с объемами.
Работа с не рекомендованным программным обеспечением
Не рекомендованное ПО — это ряд рисков: претензии правообладателей, нецелевое использование ресурсов компании, вероятность заражения вирусами в случае скачивания «фейковых» версий известного ПО, недокументированные возможности неизвестного софта.
Сложность выявления показателя в шагах, которые надо предпринять для определения точной цифры нерекомендованного ПО:
- Подобрать инструмент для получения списка программ, установленных на рабочих ПК и серверах;
- Проанализировать полученный список (количество позиций может быть несколько тысяч и даже десятков тысяч);
- Определить, какое программное обеспечение допустимо к установке на АРМ и серверах компании.
- «Узаконить» ПО и правила работы с ним, выпустив документ, регламентирующий соответствующий порядок.
- Оценить количество ПО «вне закона» в компании.
После оценки состояние показателя характеризуется соотношением нерекомендованного к рекомендованному ПО в вашей сети. В дальнейшем это соотношение должно снижаться. Если доля останется такой же или вовсе будет расти, значит ПО не удаляется, либо политики, использующиеся на пользовательских компьютерах, позволяют устанавливать программы невовлеченным сотрудникам.
Актуальность документации
Вся документация должна актуализироваться, пересматриваться с определенной периодичностью. В противном случае, к ней перестанут обращаться или будут регулярно указывать на противоречия в документах и на практике. Это относится не только к политикам, стандартам, регламентам, но и к приказам. Соотношение неактуальной документации к общему количеству нормативных документов — наглядный параметр для показателя.
Повышение осведомленности персонала компании
Направление объемное, и о показателях повышения осведомленности сотрудников, мы писали ранее в статье блога. Повторим некоторые из них еще раз.
Первый показатель — доля сотрудников, обученных курсам по ИБ. Курсы могут быть разные: базовый, безопасность персональных данных, безопасная работа в онлайн-банках, АСУ ТП и тд. Под каждое направление лучше иметь отдельный индикатор.
Второй показатель — доля сотрудников, подверженных социальной инженерии (количество сотрудников, перешедших по «фишинговым» ссылкам, открывших «вредоносные» файлы, оставивших данные на «поддельных страничках») во время проведения провокационных тестирований, целенаправленно проводимых внутри компании с целью оценки ситуации. Этот параметр можно сегментировать: доля сотрудников категории «ТОП», подверженных социальной инженерии, доля сотрудников, работающих с большими объемами конфиденциальной информации и др.. Отдельно выделяют сегмент сотрудников ИТ, так как для пользователей они главные авторитеты в вопросах работы с компьютером. Кроме того, сотрудники ИТ обладают расширенными правами в инфраструктуре компании (локальные администраторы, доменные администраторы и тд).
Третий показатель – количество сотрудников, обратившихся в ИТ\ИБ при получении фишинговых рассылок. Позволяет оценить, насколько хорошо пользователи знают, к кому обращаться при подозрении на попытку мошенничества. Этот же показатель можно рассмотреть в разрезе каналов получения сообщений о подозрительных письмах: 1-я линия техподдержки, личное обращение к менеджеру ИБ, система типа Service Desk и тд.
Работа с инцидентами ИБ
SIEM (Security information and event management) в компании призвана выявлять инциденты ИБ
Вне зависимости от того, установлена она или нет, работа с инцидентами должна вестись постоянно: выявление несанкционированных действий недобросовестных пользователей, работа с информацией, полученной от коллег, инциденты, происходящие в сетях передачи данных и тд. Какими параметрами характеризуется эта работа?
• Скорость реакции на инцидент. Время от момента получения информации об инциденте до начала работы с ним (сбор логов, поиск доказательной базы и др);
• Срок расследования инцидента ИБ. Время от получения информации об инциденте до полного его закрытия. Этап закрытия принимается по-разному, например, в некоторых компаниях закрытие = служебная записка по итогам разбора ситуации с планом мероприятий для предотвращения подобных ситуаций в дальнейшем.
• Доля докладных служебных записок по факту разбора инцидентов, где получена обратная связь от руководителей «провинившихся» сотрудников. Речь не идет о наказании этих сотрудников. Ведь нужно получать обратную связь, иначе работа отдела ИБ уйдет впустую. И дополнительно может страдать авторитет функции ИБ в компании.
• Реализация инвестиционных проектов, направленных на повышение уровня защищенности компаний.
Если собственники бизнеса понимают необходимость инвестиций в ИБ, то необходимо своевременно проделывать работу по реализации всех запланированных проектов. Иначе есть вероятность, что в следующий раз денег на развитие функции не будет. Совет: ведите статистику по общей доле проектов, которые выполняются по плану. Показатель не применяется, если проект один, однако он нагляден в случае портфеля проектов с разными дедлайнами.
Нагрузка на сотрудников (FTE)
Важный показатель для руководства, позволяющий оценить, насколько эффективно нагружены сотрудники подразделения. Для составления FTE необходимы инструменты, позволяющие рассчитывать трудозатраты сотрудников на те или иные работы и вести их учет. К тому же, в подразделении должна быть разработана сервисная модель, в которой находятся услуги, оказываемые подразделением. Руководителю подразделения ИБ эта цифра необходима для обоснования расширения штата по надобности.
Вместо выводов — какие показатели не стоит применять
Выше изложены метрики эффективности информационной безопасности, полезные во многих случаях. Говорить о них больше не будем, лучше отметим параметры, которые не стоит использовать.
- Количество наказанных пользователей. Показатель загонит компанию в «палочную» систему, заставив пользователей бояться, а не уважать ИБ.
- Количество выявленных инцидентов. 10 выявленных инцидентов на первой неделе и 0 на второй (пользователи хорошо себя вели, хакеры не атаковали и т.д.) никак не говорит об эффективности отдела ИБ.
- Снижение количества срабатываний антивирусной защиты. Аналогично предыдущему пункту: не зависит от отдела ИБ напрямую, а, например, от обновления сигнатур антивирусного решения компании.
Иные показатели, которые полностью зависят от внешних факторов и практически не зависят от действий пользователей компании, элементов инфраструктуры компании и действий коллег из ИТ.