27.06.2011

Как измерить систему контроля конфигураций?

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


5 коммент.:

Евгений Родыгин комментирует...

" Поэтому оценивать такие продукты надо комплексно, учитывая вклад системы в общее дело."
Именно в общее дело...
Причем только с учетом политики внесения изменений как связанных с ИБ так и не связанных(если такие бывают).
Наличие собственно хорошего сканера, выявляющего уязвимости мало чего дает, сканера, который формирует угрозы - мало плюсов, сканера который формирует угрозы с учетом политики ИБ - это уже хорошо, сканера формирующего угрозы с учетом политики и формирующего технические решения по апгрейду - уже 4+, сканер с техническими решениями и учетом политики ИБ и предложениями по изменению политики с учетом внедрения заплаток = 5+.
Вот я бы примерно так оценивал...
Всякая статистика с учетом данных сканера и содержащая данные для последующих оценок и оптимизации бизнеса = 6+...

Алексей Лукацкий комментирует...

Ну твои предложения надо еще оцифровывать ;-)

Евгений Родыгин комментирует...

Да, проходя мимо, еще бы добавил функцию интеграции результатов не только своего сканера но и учет результатов других сканеров(например если есть поддержка единого стандарта описания уязвимостей/угроз) остальное, кажется, по мелочи...(учет лучших практик и т.п.)

Алексей Лукацкий комментирует...

Это ты критерии оценки продукта (для сертификации, например) приводишь. А я говорил об оценке эффективности (демонстрации) конкретного продукта писал ;-)

Евгений Родыгин комментирует...

Мне кажется, что для функциональной оценки "по крупному". Конкретная оценка применима к конкретному продукту с учетом объекта внедрения.
Учитывать объект внедрения - хм... тут можно утонуть в "если"...