Архив метки: РезБез

VM-ный миф № 4: можно значительно улучшить процесс Управления Уязвимостями, если найти правильные слова для руководства

VM-ный миф № 4: можно значительно улучшить процесс Управления Уязвимостями, если найти правильные слова для руководства

VM-ный миф № 4: можно значительно улучшить процесс Управления Уязвимостями, если найти правильные слова для руководства. Довольно часто поступают вопросы в духе: "как аргументированно обосновать необходимость выстраивания полноценного процесса Vulnerability Management в организации, а не выборочного устранения отдельных находок сканера?" Когда от руководства при этом звучат возражения вроде "у нас были инциденты только через фишинг, а не через эксплуатацию уязвимостей", "построение процесса требует новой штатной единицы и бюджета", "безусловный патчинг создаст огромные трудозатраты" и т.д.

Нет, ну в целом можно посоветовать использовать методологию результативной кибербезопасности и вместе с руководителем определить, что именно "болит" в организации - какие недопустимые события (слив критичных данных, кража денег, остановка бизнес-процессов, для реального сектора вплоть до техногенных катастроф) могут реализовать злоумышленники на целевых активах. Суть в том, что затраты на выстраивание процесса будут несопоставимо меньше потенциальных потерь от инцидента, способного обрушить прибыль компании на 30-40%, вынудить сокращать штат или закрыться. На возражение "нас ломали только через фишинг, а не через уязвимости" можно объяснить, что попав внутрь через фишинг, злоумышленник продвигается к важным системам именно через уязвимости. Можно предложить пентест, чтобы оффенсив-специалисты показали реальность проблем на практике. Для компаний, подпадающих под требования регулятора, можно апеллировать к нормативке, требующей постоянного выявления и устранения уязвимостей.

Да-да, это всё можно пробовать транслировать! Но возымеет ли "цыганочка с выходом" перед руководством в исполнении простого VM-щика какой-то эффект? Не хочу обесценивать вербальную коммуникацию как таковую, но, положа руку на сердце, я бы особенно не рассчитывал, что вы "слова найдёте такие нежные", способные кардинально изменить ситуацию с VM-ом в организации. По моему глубокому убеждению, Vulnerability Management снизу в принципе не внедряется. Нигде и никогда. Устранение уязвимостей для бизнеса и IT-шников - крайне невыгодная тема и огромный объём дополнительной работы, которую они готовы выполнять исключительно из-под палки, по прямому указанию высшего руководства.

На то, что ТОП-менеджмент организации может чего-то там не понимать, я бы тоже не вёлся. 😏 Люди, добравшиеся до этого уровня - как правило, умные, циничные и с отличным кругозором. Во всяком случае CIO и CTO. А уж тем более ваш родной CISO. Всё они понимают: и про атаки, и про уязвимости, и про возможный ущерб. Поэтому если VM-ная тема в организации недофинансируется и фактически саботируется - значит, всех всё устраивает. 😉 На этом сознательно экономят, рассчитывая на то, что:

🔻 VM-щик из подручного материала соберёт что-то похожее на работающий процесс и будет носиться как белка-истеричка, поддерживая его и затыкая собой дыры; 🤪

🔻 в случае инцидента сам же VM-щик и станет крайним. F 🫡

Поэтому, ИМХО, если руководство организации принципиально не готово выделять ресурсы на VM и насаждать его сверху, углубляться в разъяснения нерационально. "Если надо объяснять, то не надо объяснять". © Не хотят ТОПы работающего VM-процесса - значит, его не будет. Хотят пройти через критичный киберинцидент прежде чем внедрять базовые ИБ-процессы - значит, будет так. Плетью обуха не перешибёшь. VM-щику в такой организации вместо отчаянного евангелизма лучше потратить время на что-то более полезное. Резюме обновить например. 😉 А если смена работы не вариант - как минимум осознавать положение вещей, границы своих возможностей и стараться самому не подставляться почём зря.

Выписал тезисы по статье Алексея Лукацкого про методы приоритизации уязвимостей

Выписал тезисы по статье Алексея Лукацкого про методы приоритизации уязвимостей

Выписал тезисы по статье Алексея Лукацкого про методы приоритизации уязвимостей.

🔹 Количество CVE уязвимостей растёт с большим ускорением; считается, что на одну зарегистрированную уязвимость есть 3 незарегистрированных.
🔹 Исходя из статистики, устранение уязвимостей осуществляется гораздо позже, чем эти уязвимости начинают использовать атакующие.
🔹 Отсутствие выстроенного процесса приоритизации уязвимостей - одна из причин задержек в их устранении.
🔹 Единственного правильного метода приоритизации уязвимостей нет: у каждого свои преимущества, недостатки и область применения.
🔹 Выбор у корпоративных пользователей небогат: довериться методам приоритизации VM-вендора, либо пилить свой процесс (собирая temporal и environmental данные самостоятельно).
🔹 Можно попробовать разработать собственную методику, однако всё равно нужно где-то брать исходные данные. Большинство компаний берут за основу CVSS Base Score + временные метрики (EPSS, Coalition ESS, AI Score, CVE Shield, CISA KEV и т.п.). Каверзные вопросы. Что делать с новыми уязвимостями, по которым еще нет данных? И что делать с уязвимостями, для которых нет, и возможно, не будет данных в CVE (например, с уязвимостями в российских продуктах)? 🤔 Информации по их эксплуатабельности в западных источниках не будет. 😏
🔹 "Уникальная и революционная система приоритизации уязвимостей" = учёт информации о наличии эксплойта, использовании уязвимости в реальных атаках, активности обсуждения в СМИ и соцсетях и т.д. + обработка ML-ем.
🔹 Упрощённые критерии принятия решений (НКЦКИ, SSPP, CISA) всё равно требуют автоматизации и источника информации об активности эксплуатации уязвимостей вживую.

На прошлой неделе на сайте РезБеза вышел большой обзор методов приоритизации уязвимостей от Алексея Лукацкого

На прошлой неделе на сайте РезБеза вышел большой обзор методов приоритизации уязвимостей от Алексея Лукацкого

На прошлой неделе на сайте РезБеза вышел большой обзор методов приоритизации уязвимостей от Алексея Лукацкого. Нашлось там место и для предложенной мной альтернативы CVSS под названием ОСОКА ("Общая Система Оценки Критичности Автоматизируемая"), а также там упоминается моя утилита для приоритизации уязвимостей Vulristics. Видимо действительно пора доводить ОСОКу от разрозненных заметок до спецификации, делать калькулятор и интегрировать её в Vulristics. 🤔

Рассматриваемые в статье методы разбиты на 3 группы:

🔹Зарубежные: CVSS, EPSS, CISA SSVC, CISA KEV, CVEShield (CVE Crowd, CVETrends), CMU SSVC, CVE Prioritizer, Vulners AI Score, Zoom VISS, SSPP

🔹 Российские: методика ФСТЭК, алгоритм НКЦКИ, трендовые уязвимости Positive Technologies, ОСОКА

🔹Проприетарные / закрытые: Coalition ESS, Tenable VPR, Qualys TruRisk, MVSF, PRIOn. Здесь же упоминаются внедряемые технологии приоритизации (VPT): Vulnera VSCORE, Outpost24 VPT, Vulcan, Ridge RidgeBot