До онлайн-конференции AM Live по Vulnerability Management-у осталось всего несколько часов. Начало в 11:00 по Москве. До встречи в чатике трансляции! 😉

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

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

1. Как будут развиваться системы управления уязвимостями в ближайшее время?

Здесь хотелось бы разделить на 2 части:

- Как хотелось бы, чтобы развивались?

Про это писал в "Трендах/драйверах Vulnerability Management рынка". Всё повторять здесь не буду. Ключевым направлением мне кажется анализируемость баз детектов уязвимостей. Чтобы можно было делать сравнения (хотя бы по CVE) и делать выводы по возможностям детектирования у тех или иных решений. Если в этом отношении ситуация улучшится, можно будет даже со стороны клиента пропушивать улучшение качества детекта.

- Как скорее всего будут развиваться?

Кажется, что основное, куда кидаются ресурсы это не улучшение качества детектирования, а дальнейшие интеграции со сторонними системами и высокоуровневая аналитика для ТОПов. Желательно, чтобы ещё и работало автоматически.

Алексей Лукацкий в своём канале это так недавно описал:

"Мечта ИБшника - средство защиты с одной кнопкой «защити меня», а не вот это вот все с тысячами настроек… Само смотрит телеметрию, само коррелирует и выстраивает цепочки атак, само оценивает опасность, само реагирует, само генерит и отправляет отчет об успехе с привязкой к бизнес-целям предприятия (недопустимым событиям). Сказка, а не ИБ. […] Так что думаю не за горами тот момент, когда в одном решении будет и SIEM, и SOAR, и сканер уязвимостей, и встроенная CMDB, и ASM, и много чего еще"

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

2. Можно ли будет полностью автоматизировать процесс управления уязвимостями в организации?

Можно. Когда будут полностью автоматизированы (и формализованы) процессы IT. 😏

3. Как можно будет использовать в этом процессе искусственный интеллект?

Уже сейчас используются для анализа уязвимостей, например в EPSS. Вполне вероятно, что AI будет активно использоваться при анализе состояния защищенности активов и построение цепочек атак.

Часть 2

Раз уж меня не будет на онлайн-конференции 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