В ноябре я выступал на InfoSecurity Russia с докладом об экономической эффективности ИБ. Во время сессии вопросов и ответов Женя Климов спросил меня, как оценивать сканеры безопасности? Тогда я четко ответить не смог, а сейчас смог подготовить некоторый ответ. Возьмем, к примеру, систему MaxPatrol от Positive Technologies. Это уже не простой сканер уязвимостей — это полноценная система мониторинга уровня ИБ, включающая в себя помимо инструмента поиска дыр еще и функции compliance, change management и аудит и т.п. Поэтому оценивать такие продукты надо комплексно, учитывая вклад системы в общее дело. Одна из решаемых такой системой мониторинга задач — контроль изменений. Как оценить этот процесс? Недавно я участвовал в проекте с нашей системой CiscoWorks Network Compliance Manager и там использовались следующие метрики:
- число авторизованных изменений в неделю
- число актуальных изменений, сделанных за неделю
- число несанкционированных изменений, сделанных в обход утвержденного процесса внесений изменений (в среднем — 30-50%; у лидеров — менее 1% от общего числа изменений).
- показатель (коэффициент) неудачных изменений, вычисляемый как отношение несанкционированных изменений к актуальным.
- число срочных изменений
- процент времени, затрачиваемого на незапланированную работу (тут важно учитывать также время на изменение)
- число необъяснимых изменений (вообще, это основной индикатор уровня проблем в данной сфере).
Процент времени, затрачиваемого на незапланированную работу, очень показателен. Среднестатистическая компания тратит на такую работу около 35-45% всего времени. А это приводит к срыву сроков по запуску проектов, переработкам, проблемам с невыполнением требований нормативных актов, неконтролируемым сбоям и т.д. Лидеры в данном направлении тратят не более 5% времени на незапланированные изменения. Вычисляется этот показатель по простой формуле — произведение числа изменений на число неавторизованных изменений на среднее время изменения.
" Поэтому оценивать такие продукты надо комплексно, учитывая вклад системы в общее дело."
Именно в общее дело…
Причем только с учетом политики внесения изменений как связанных с ИБ так и не связанных(если такие бывают).
Наличие собственно хорошего сканера, выявляющего уязвимости мало чего дает, сканера, который формирует угрозы — мало плюсов, сканера который формирует угрозы с учетом политики ИБ — это уже хорошо, сканера формирующего угрозы с учетом политики и формирующего технические решения по апгрейду — уже 4+, сканер с техническими решениями и учетом политики ИБ и предложениями по изменению политики с учетом внедрения заплаток = 5+.
Вот я бы примерно так оценивал…
Всякая статистика с учетом данных сканера и содержащая данные для последующих оценок и оптимизации бизнеса = 6+…
Ну твои предложения надо еще оцифровывать 😉
Да, проходя мимо, еще бы добавил функцию интеграции результатов не только своего сканера но и учет результатов других сканеров(например если есть поддержка единого стандарта описания уязвимостей/угроз) остальное, кажется, по мелочи…(учет лучших практик и т.п.)
Это ты критерии оценки продукта (для сертификации, например) приводишь. А я говорил об оценке эффективности (демонстрации) конкретного продукта писал 😉
Мне кажется, что для функциональной оценки "по крупному". Конкретная оценка применима к конкретному продукту с учетом объекта внедрения.
Учитывать объект внедрения — хм… тут можно утонуть в "если"…