Архив метки: VulnerabilityRemediation

Ещё одно размышление после конференции R‑Vision, про таски на исправление уязвимостей

Добавить комментарий

Ещё одно размышление после конференции R-Vision, про таски на исправление уязвимостей

Ещё одно размышление после конференции R‑Vision, про таски на исправление уязвимостей. На этой теме был акцент и в основном выступлении про R‑Vision VM, и в кейсе НРД. Несмотря на то, что таски могут быть предметом долгих разбирательств IT и ИБ, имхо, таски должны быть. Почему?

1. Слова (как и дашборды, доступ для IT-шников в VM-систему, нотификации в почте/мессенджерах и прочее) к делу не пришьёшь. А тут формальная задачка. С критичностью, исполнителем и датой заведения. И для аудитов есть, что показать, и в случае инцидента пригодится. 😏
2. Вполне вероятно, что в организации уже внедрены процессы оценки эффективности работы подразделений на основе анализа статусов тасков, можно и исправление уязвимостей оценивать по аналогии.
3. Руководство ФСТЭК требует заводить таски. Можно, конечно, рассуждать об обязательности этого руководства, но если можно соответствовать, то лучше соответствовать. 😉

Какие это должны быть таски?

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

1. Удобно отслеживать реальный прогресс. Иначе, если сделать связь один ко многим или многие ко многим, как абсолютно справедливо заметил в своём вчерашнем докладе Олег Кусеров, это будет приводить к большому количеству частично выполненных тасков.
2. Удобно менять критичность таска в случае изменения критичности уязвимости или актива.
3. Удобно делать интеграцию с системами управления уязвимостями. По сути таск просто привязывается к статусу уязвимости на активе.

Сколько таких тасков будет? Допустим, у нас для одного Lin­ux хоста за месяц выходят 100 новых уязвимостей. Допустим, у нас 10000 Lin­ux хостов в инфраструктуре. Получается миллион тасков за месяц. 12 миллионов в год. И это только Lin­ux!

Отсюда следует:
1. Система для учёта тасков должна быть готова к таким объемам.
2. Вручную работать с такими тасками практически нереально.

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

✅ Таким образом ITшники, которые будут выполнять регулярный патчинг своих систем, возможно вообще без оглядки на продетектированные уязвимости, будут, в целом, автоматически соответствовать требованиям по исправлению уязвимостей и будут молодцы. 👍

❓А те ITшники, которые считают, что полное регулярное обновление им не подходит, смогут разбираться с каждой уязвимостью отдельно и тем способом, который сочтут нужным. Включая их ручную обработку. 🤷‍♂️ Может в процессе они скорректирую свои взгляды относительно регулярных обновлений. 😏

Способ затормозить Vulnerability Management процесс "ты как челобитную царю подаёшь?!"

2 комментария

Способ затормозить Vulnerability Management процесс ты как челобитную царю подаёшь?!

Способ затормозить Vul­ner­a­bil­i­ty Man­age­ment процесс "ты как челобитную царю подаёшь?!" 👑 Несколько разовью тему с офигиванием IT-шников от VM‑а и того, что они могут придумать в ответ. Данный способ простой, эффективный и без формальных изъянов. Подходит как самая первая мера. ITшники говорят, что, разумеется, они готовы обновлять системы, но для того, чтобы заниматься этим на потоке, им необходимо, чтобы информация об обнаруженных уязвимостях доводилась до них несколько иначе, чем сейчас:

🔻 В виде тасков в таск-треккере (1 уязвимость — 1 хост, сгруппированные по уязвимостям, сгруппированные по хостам)
🔻 В виде REST API вызовов (всё сразу, по хосту, по уязвимости)
🔻 В виде выгрузок на гитлабе, файловой шаре, в монге, кафке (CSV, XML, JSON, YAML)

Требуемое описание уязвимости может содержать в себе любой набор полей, включая, например перевод описания уязвимости. Мы же российская компания — давайте нам всё на русском. 😏 И прямые ссылки на патчи, пожалуйста! И команду для полного обновления хоста! И команду для частичного обновления хоста (только самое критичное)! И прямые ссылки на PoCи (непонятно зачем, но тоже пусть будет — нам интересно 🙂)!

Конкретные требования значения не имеют, т.к. весь расчет на то, что пока вы будете возиться с тасками/выгрузками в том виде, в котором это захочется IT (а каждому отделу может хотеться разного), вы не будете их доставать с патчингом. А после можно будет придумать что-нибудь ещё. 💡

Кроме того, в случае тасков в таск-треккере, они наглядно смогут показать, что в итоге получилась какая-то абсолютно неюзабельная ерунда. Работать вручную с тысячами автогенеренных тасок по уязвимостям будет, естественно, невозможно. Сразу что ли было непонятно, товарищи VM-щики?! 🙃 Но это будет потом, после месяцев потраченных на встречи, обсуждения, согласования и разработку. 😏

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

Постоянное офигивание ITшников это нормальное следствие работающего Vulnerability Management процесса

2 комментария

Постоянное офигивание ITшников это нормальное следствие работающего Vulnerability Management процесса

Постоянное офигивание ITшников это нормальное следствие работающего Vul­ner­a­bil­i­ty Man­age­ment процесса. В чём вообще задача процесса Управления Уязвимостями? В том чтобы в инфраструктуре не было критичных уязвимостей и ими не мог воспользоваться злоумышленник. Именно за это VM-щику платят деньги и за это он отвечает (при плохом раскладе вплоть до уголовки 🤷‍♂️). А для того, чтобы таких уязвимостей в инфраструктуре не было, их нужно (сюрприз-сюрприз!) исправлять. 🙂 Чаще обновлениями, реже переконфигурированием.

Если уж в организации есть какой-никакой процесс управления активами, то покрыть эти активы детектами и открыть бесконечный поток новых обнаруженных уязвимостей дело выполнимое. Насколько мощным будет этот поток? Если брать совсем минимум, то с Patch Tues­day обязательно прилетит KB-шная RCE-шка в Win­dows ядре или стандартном компоненте, а также RCE в Lin­ux-овом ядре или стандартной утилите. По сетевым устройствам возможно пореже — раз в 2 месяца. Вот и считай — ежемесячное обновление всех Linux/Windows хостов и двухмесячное для всех сетевых устройств. И это с необходимостью эти обновления тестировать перед накаткой. 👨‍🏫 Это минимум!

Класс, да? Каждый админ/девопс будет просто счастлив открывающимся перспективам дополнительно свалившейся на него со стороны ИБшников работы! 🙂 Как и его руководители вплоть до CIO/CTO. И будьте уверены, что они приложат все возможные усилия и все доступные меры корпоративной борьбы, чтобы этого замечательного VM-процесса в итоге не случилось. Не говоря уж о таких мелочах как разнообразные "словесные интервенции". 📣😏

Крепись, VM-щик! Не позволяй выхолостить процесс!