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

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

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

1. Что входит в современное понимание процесса управления уязвимостями (Vulnerability Management)?

Управление уязвимостями это их детектирование и исправление. Остальное всё опционально. Вон Holm Security считают, что в современном Vulnerability Management решении обязательно должен быть Антифишинг встроенный. И чего теперь, не будем VM-решения без встроенного Aнтифишинга за современный VM считать? 🙂 Не ведитесь на маркетинг, обращайте внимание на главное - качество детектирование. А на исправление влияет в первую очередь то, как вы договоритесь со своими админами/девопсами. Коробочное решение за вас это не сделает.

2. Каковы основные драйверы рынка управления уязвимостями?

a. Западные VM-решения отвалились, все кинулись активно импортозамещаться.
b. IT-инфраструктура также импортозамещается. VM-вендоры должны за этим поспевать, поддерживать все эти континенты, 1С-ы, отечественные Linux-ы и прочее. База знаний отечественного VM решения станет сильно отличаться от западного.
c. Регуляторы стали уделять процессу управления уязвимостями гораздо больше внимания.

3. Усложнился ли процесс управления уязвимостями с уходом из России зарубежных вендоров?

Безусловно. Уход VM-вендоров = отвалившиеся VM-процессы. Уход IT-вендоров = поиски решений, которые могут детектировать уязвимости в импортозамещенных продуктах.

4. Обнаруживать уязвимости можно обычным сканером. Что понимается под непосредственно “управлением”?

См. вопрос 1. Управление активами, оценка и приоритизация уязвимостей это всё доп. функциональность. "Если вы надетектили уязвимости как-то и приняли решение, что с ними дальше делать (устранять, смягчать, оставить как есть) и сделали отчет для начальства, то поздравляю, это уже Vulnerability Management."

5. Vulnerability Management — это непрерывный процесс или набор разовых лимитированных активностей?

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

6. Как Vulnerability Management связан с Continuous Penetration Testing?

Continuous Penetration Testing это считай сервис сканирования периметра + обработка результатов аналитиками вендора. VM-решение это продукт, а CPT это, по сути, услуга. Также можно спросить: как связан Vulnerability Management и Bug Bounty. Как-то связан: и там уязвимости, и там. Нужно сливать воедино? Если VM-решение позволяет заносить уязвимости из сторонних источников - почему бы и нет.

7. Какими функциями обладают системы (платформы) управления уязвимостями?

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

8. Можно ли управлять уязвимостями без специальных систем?

Без качественных средств детектирования уязвимостей очень тяжко. Если есть продетектированные уязвимости, остальное можно накодить самим или взять open source решение.

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

ТОП-ы, ИБ-подразделение, ИТ-подразделение. У PT про это хорошо расписано.

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

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

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

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