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

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

Процент времени, затрачиваемого на незапланированную работу, очень показателен. Среднестатистическая компания тратит на такую работу около 35-45% всего времени. А это приводит к срыву сроков по запуску проектов, переработкам, проблемам с невыполнением требований нормативных актов, неконтролируемым сбоям и т.д. Лидеры в данном направлении тратят не более 5% времени на незапланированные изменения. Вычисляется этот показатель по простой формуле — произведение числа изменений на число неавторизованных изменений на среднее время изменения.

Оцените статью
Бизнес без опасности
Есть что добавить? Добавьте!

Нажимая кнопку "Отправить", я даю свое согласие на обработку персональных данных (если вдруг они указаны в комментарии) в соответствие с политикой конфиденциальности. Также я соглашаюсь с тем, что в своем комментарии не раскрываю никаких сведений, составляющих государственную тайну, а также никакой иной информации, охраняемой законом (для этого используйте иные способы :-) ), если это не разрешено ее владельцем. Ваш комментарий может появиться не сразу, а после модерации (так бывает не всегда, но бывает).

  1. Анонимный

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

    Ответить
  2. Алексей Лукацкий

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

    Ответить
  3. Анонимный

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

    Ответить
  4. Алексей Лукацкий

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

    Ответить
  5. Анонимный

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

    Ответить