Я решил поделиться своим впечатлением, некоторыми материалами данного мероприятия (не нарушая авторских прав), а также прокомментировать их в части, касающейся.
Самое приятное, что в мероприятии было 2
1-ый доклад был связан с COBIT 5.
Здесь отмечу только то, что если взять «COBIT for Information Security», то «Vulnerability Management» встроен в процесс «Manage Configuration», а его выход идет в «Manage Problems».

На своей практике данную схему реализации я не проверял, поэтому комментировать ее не готов.
2-ой доклад был в разрезе ITIL.
Автором было выделено 5 этапов в процессе «Vulnerability Management»:
- подготовка к сканированию;
- сканирование уязвимостей;
- определение способов устранения;
- устранение уязвимостей;
- проверка исправлений.
Что меня насторожило в обоих докладах, это сужение Vulnerability Management только до техники. Связана это настороженность с тем, что, на мой взгляд, уязвимость – это более широкое понятие.

Если взглянуть на определения, то коллеги акцентировали свое внимание на уязвимостях систем, оставив «за скобками» уязвимости (слабости / недостатки) в процессах и людях.
Например, в процессе управления доступом заявку на предоставление прав реализует и контролирует один и то же человек, это уязвимость процесса.
Или, например, в службе информационной безопасности работает специалист, который регулярно «выпадает на больничный» в самый ответственный момент, это уязвимость в людях.
На мой взгляд, в рамках методологии нужно расширять scope of process в данные области то же.
В практической части я бы выделил следующие моменты:
- даже если у вас есть лучший сканер безопасности – это не значит, что процессе «Vulnerability Management» готов;

- нужно быть готовым к далеко неполной и разной зоне покрытия разными сканерами безопасности;

- нужно быть готовым вести еженедельную борьбу с false positive (были озвучены цифры, что они могут достигать 30%).
Был отмечен интересный момент отношения к данному вопросу со стороны ИТ-специалистов, с которым я так же сталкивался на практике, после демонстрации отчета по результатам сканирования, коллеги из ИТ
Каждый выходит из данной ситуации по-своему, кто-то демонстрирует сам, кто-то привлекает профильных коллег, кто-то эскалирует наверх, кто-то не делает ничего.
Со своей стороны, отмечу, что этот момент, в первую очередь, затрагивает вопрос доверия и авторитета ИБ-подразделения, а во-вторую, участия владельца уязвимого актива в принятии окончательного решения по дальнейшим действиям.
В заключении отмечу, что вопрос, которым я сам активно занимаюсь, а именно приоритизации действий при устранении уязвимостей (за что хвататься в первую очередь!), отмечен абсолютно всеми как нетривиальный и у каждого свои пути его решения, «серебренной пули» ждать не стоит.
Успехов в реализации вашего Vulnerability Management!