Раз уж меня не будет на онлайн-конференции AM Live по Vulnerability Management-у, поотвечаю на вопросы из программы здесь (2/3). 😉

Часть 2. ПРАКТИКА УПРАВЛЕНИЯ УЯЗВИМОСТЯМИ

1. С чего начать построение процесса управления уязвимостями?

Имхо, самое важное сразу решить: вы будете использовать полноценное коробочное решение или попробуете обойтись без него, комбинируя разные средства детектирования уязвимостей и разрабатывая что-то самостоятельно. Первый путь - дорого и много боданий с вендором, чтобы пропушивать нужные фичи и багфиксы. Второй путь - дольше стартовать, гораздо более трудоемко, но гибче и, как правило, дешевле.

2. Какие регламенты нужно разработать в компании?

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

4. Как правильно составить SLA для такого процесса?

Единого правильного пути нет. Прогрессивным считается согласовать требования по регулярным безусловным обновлениям в заданные сроки и согласовать процесс "пожарного" патчинга супер-критичных уязвимостей.

5. Как правильно определить границы процесса управления уязвимостями?

Фиг знает что понимается под границами. Имхо, всё что является технической уязвимостью можно подгрести под Управление Уязвимостями, т.е. аппсечные темы тоже (см. карту). Но VM-вендоры под VM-ом понимают, как правило, только управление уязвимостями инфраструктуры.

6. На какие параметры обращать внимание при выборе системы управление уязвимостями?

В первую очередь оценить качество детектирования уязвимостей, всё остальное сильно вторично.

7. С какими типами ресурсов могут работать системы управления уязвимостями?

Правильнее задать вопрос: то VM-решение, которое вы покупаете, покрывает ли все типы активов, которые есть у вас в организации. И если нет, то что делать с непокрываемыми. Выяснить это ваша задача.

8. Обязательно ли идентифицировать все активы в инфраструктуре? И как проще это сделать?

Безусловно. Имхо, это задача IT и логично это делать в рамках CMDB системы. Но если есть уговор делать это в рамках VM-а, почему бы нет.

9. Кто и как правильно оценивает приоритет уязвимостей?

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

10. Откуда сейчас можно получать данные о трендовых уязвимостях и оперативно их учитывать?

"Нигде кроме как в Моссельпроме!" © Видимо правильный ответ подразумевается "в платном фиде VM-вендора". 😏 На самом деле CISA KEV и бюллетени регуляторов вполне адекватно подсвечивают критичное.

11. Можно ли в рамках процесса определять ошибки конфигурации и проводить контроль целостности?

Можно рассматривать мисконфигурации как уязвимости, но вообще правильный Hardening это отдельная непростая тема. А контроль целостности это скорее SOC-овская тема.

12. В каких случаях возможен автопатчинг или переконфигурирование?

В тех случаях, когда VM-вендор может его безопасно делать. 😏 В первую очередь это должно касаться third-party софта на десктопах: браузеры, pdf-читалки, архиваторы, офисные продукты, java и т.п.

13. Какие метрики эффективности на практике лучше применять для управления уязвимостями?

Вкусовщина. Имхо, важно смотреть в разрезе подразделений, насколько они выполняют требования по регулярному патчингу и по "пожарному" патчингу. Также важно понимать какие активы у нас не охвачены VM-ом и почему.

Часть 1