Причины провала проектов по тестированию (внедрению) систем управления уязвимостями

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




Причина 1. Проведение тестирования без устранения выявленных уязвимостей.
Это может быть связано со следующими обстоятельствами:

• Первичное сканирование сканирование выявило слишком много уявимостей (проблем безопасности). Не знают с чего начать, бояться показать руководству как все плохо, думают, что до этого как-то жили и дальше проживут.
• Несогласованность действий заказчиков систем, например, подразделений ИБ и ответственных за устранение уязвимостей, обычно подразделений ИТ. 

Таким образом получаем отчет, с которым ни кто не работает, и сама цель внедрения (Снижение рисков ИБ, связанных с эсплуатацией уязвимостей элементов ИТ-инфраструктуры) таких систем не достигается.


Решение:

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

Причина 2. Отсутствие "быстрых побед" (quick wins).

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

Решение:

1. Обязательно провести полный цикл управления уязвимостями, желательно несколько раз, для получения определенной динамики изменений.

Причина 3. Слабое обоснование результатов руководству.

Недостаточно просто внедрить и попробовать систему, важно показать результаты руководству, убедить руководство в необходимости, результативности и эффективности системы управления уязвимостями.

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

Обоснованием могут быть: 

• ссылка на лучшие практики, например эти.
• ссылка на требования стандартов (например, СТО БР ИББС, ISO 27001, PCI DSS) и руководящих документов регуляторов (документы ФСТЭК России), обязывающих использовать средства анализа уязвимостей.
• краткая оценка рисков, связанных с эксплуатацией выявленных уязвимостей в ИТ-инфраструктуре компании, некая "страшилка" о том, как будет плохо, если не устранять уязвимости, которых "вот как много выявлено".

При этом необходимые тезисы могут помочь подготовить и вендор, и привлекаемые для тестирования консультанты. 

Решение:

1. Подготовить хорошие отчет и обоснование для руководства.

Причина 4. Завышенные ожидания от решения.

Решение по управлению уязвимостями может не понравится, если не будут удовлетворены первоначальные ожидания от проекта или в ходе проекта появятся непридвиденные сложности. Это могут быть, например, сбои в работе системы, невозможность получения результатов по определенным хостам, и т.д.

Решение:

1. Уточнить особенности\возможности решения до начала проекта. Это могут быть:
• стоимость первоначальная (внедрение решения и закупка лицензий); 
• стоимость (дальнейшая (продление лицензий и тех.поддержка);
• простота внедрения, настройки и управления;
• перечень возможных отчетов;
• перечень функциональных настроек/возможностей сканирования;
• масштабируемость решения;
• сравнение с аналогами (например, это)
• техническая поддержка;
• язык интерфейса;
• наличие дополнительных модулей;
• интеграция с другими средствами и системами ИБ
• и т.д.
2. Если есть желание и возможность, то провести самостоятельное сравнение и тестирование аналогичных других систем управления уязвимостями.
3. Понять и принять тот факт, что в ходе тестирования могут возникнуть некоторые сложности, например невозможность проверки определенных хостов, на которых установлена специфическая ОС и/или процедура аутентификации. Также могут возникнуть сложности с нестандартными "фишками" настройки сетевого оборудования. Конечно, для современных и качественных систем управления уязвимостями,  вероятность ошибок будет небольшой, но тем не менее такое бывает. Ориентироваться следует на итоговые результаты всего проекта, насколько хорошо будут достигнуты поставленные заранее цели и задачи.