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

Начну разбирать основной VM-ный пункт "3.3. Управление уязвимостями (КУ)" из недавно опубликованного методического документа "Мероприятия и меры по защите информации, содержащейся в информационных системах", и сравню его с версией из февральского драфта документа, чтобы отследить принятые правки

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

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

Начну разбирать основной VM-ный пункт "3.3. Управление уязвимостями (КУ)" из недавно опубликованного методического документа "Мероприятия и меры по защите информации, содержащейся в информационных системах", и сравню его с версией из февральского драфта документа, чтобы отследить принятые правки. Также сделаю предположения, откуда были взяты формулировки. Номер и название пункта остались теми же "3.3. Управление уязвимостями", но добавился двухбуквенный маркер "КУ", который, по всей видимости, означает "Контроль Уязвимостей".

Формулировка цели. "Цель: Своевременное выявление уязвимостей информационных систем, оценка их критичности, определение методов и приоритетов устранения уязвимостей, а также контроль за устранением уязвимостей". Она полностью совпадает с тем, что было в драфте. Фактически это перечисление этапов (или подпроцессов) VM-процесса. Имхо, цель должна отвечать на вопрос не "что делаем", а "какого результата достигаем": снижение уровня риска информационной безопасности, уменьшение количества эксплуатабельных уязвимостей или повышение защищенности информационных систем. Но сформулировано как сформулировано. 🤷‍♂️

Требования к реализации. Раздел начинается с перечисления того, что управление уязвимостями должно предусматривать. Это также перечисление этапов (подпроцессов), но несколько по-другому сформулированных. Они совпадают с этапами из "Руководства по организации процесса управления уязвимостями в органе (организации)" от 17 мая 2023 г. (далее для краткости буду обозначать документ как РУУ23).

Распишу маппинг формулировок из требований к реализации / РУУ23 и целей управления уязвимостями:

🔹 мониторинг уязвимостей и оценка их применимости → выявление уязвимостей информационных систем
🔹 оценка уязвимостей → оценка критичности уязвимостей
🔹 определение методов и приоритетов устранения уязвимостей → определение методов и приоритетов устранения уязвимостей ✅
🔹 устранение уязвимостей → ❓
🔹 контроль устранения уязвимостей → контроль за устранением уязвимостей

Как видим, совпадение формулировок есть только по одному этапу (подпроцессу). Это, конечно, не особенно критично, но хотелось бы большего единообразия.

Далее по каждому этапу (подпроцессу) перечисляются требования к реализации.

🔎 Мониторинг уязвимостей и оценка их применимости

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

Очевидно, эта формулировка частично взята из описания соответствующего этапа в РУУ23: "На этапе мониторинга уязвимостей и оценки их применимости осуществляется выявление уязвимостей на основании данных, получаемых из внешних и внутренних источников, и принятие решений по их последующей обработке". Были только добавлены примеры внутренних и внешних источников данных.

В этом пункте регулятор предписывает выстроить полноценную работу по выявлению уязвимостей, в которой автоматизированные средства анализа защищенности (САЗ) являются лишь одним из источников данных. Если детектирование уязвимостей для какого-то класса систем или технологий не поддерживается имеющимися САЗ, это не означает, что детектирование и устранение уязвимостей в них можно вовсе не осуществлять. Для каждой уязвимости, актуальной для инфраструктуры, необходимо понимать, как и чем она будет детектироваться. В случае отсутствия готовых САЗ может потребоваться разработка собственных средств автоматизации либо проведение анализа на наличие уязвимостей вручную. Поэтому использование САЗ с наилучшим качеством детектирования уязвимостей становится в том числе способом снизить объем in-house разработки и ручной работы.

⚖️ Оценка уязвимостей

"В ходе оценки уязвимостей определяется уровень критичности уязвимостей применительно к информационным системам органа (организации)."

Очевидно, эта формулировка полностью взята из описания соответствующего этапа в РУУ23: "На этапе оценки уязвимостей определяется уровень критичности уязвимостей применительно к информационным системам органа (организации)". При этом в драфте было: "В ходе оценки уязвимостей определяется уровень критичности уязвимостей применительно к информационным системам органа (организации) в соответствии с Методикой оценки уровня критичности уязвимостей программных, программно-аппаратных средств, утвержденной ФСТЭК России." В драфте оценка критичности уязвимостей была возможна исключительно по методике ФСТЭК. То есть процесс был жестко регламентирован. В релизе это требование убрано, и осталась только общая обязанность определять уровень критичности уязвимостей.

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

Можно возразить: сроки устранения устанавливаются напрямую 117 приказом. Да, но эти сроки зависят от критичности уязвимости, которая будет определяться непонятно как. 🤷‍♂️ В целом, на мой взгляд, в драфте было сформулировано лучше. Хочется надеяться, что я ошибаюсь и необходимость использовать методику ФСТЭК по оценке уровня критичности уязвимостей всё-таки закрепляется где-то в другом месте. Здесь нужны разъяснения регулятора.

🧭 Определение методов и приоритетов устранения уязвимостей

"В ходе определения методов и приоритетов устранения уязвимостей определяется приоритетность устранения уязвимостей и выбираются методы их устранения: обновление программного обеспечения и (или) применение компенсирующих мер защиты информации." (в оригинальном документе после слова "методы" лишний перенос строки)

Очевидно, эта формулировка полностью взята из описания соответствующего этапа в РУУ23: "На этапе определения методов и приоритетов устранения уязвимостей определяется приоритетность устранения уязвимостей и выбираются методы их устранения: обновление программного обеспечения и (или) применение компенсирующих мер защиты информации". Различий с драфтом нет. Фактически здесь фиксируются только методы устранения уязвимостей: обновление программного обеспечения или применение компенсирующих мер. Про приоритизацию ничего не пишут, но, видимо, предполагается, что она будет выполняться в соответствии с оценкой критичности уязвимости из предыдущего пункта. Добавить несколько слов о приоритизации было бы неплохо. Например, что приоритизация должна проводиться с учетом уровня критичности уязвимостей, их реальной эксплуатабельности и использования в потенциальных путях атаки. При этом приоритет устранения уязвимостей должен определяться с акцентом на разрыв критических путей атаки и предотвращение компрометации ключевых активов.

⚙️ Устранение уязвимостей

"В ходе устранения уязвимостей принимаются меры, направленные на устранение или исключение возможности использования (эксплуатации) нарушителем выявленных уязвимостей. Время, в течение которого должны быть приняты меры по устранению уязвимостей, определяется исходя из уровня критичности уязвимости и в соответствии с требованиями о защите информации, утвержденными ФСТЭК России." (в оригинальном документе после слова "направленные" лишний перенос строки)

Очевидно, первое предложение взято из описания соответствующего этапа в РУУ23: "На этапе устранения уязвимостей принимаются меры, направленные на устранение или исключение возможности использования (эксплуатации) выявленных уязвимостей." Добавлено только слово "нарушителем". Второе предложение - отсылка к требованиям по срокам устранения из 117 приказа. Различий с драфтом в формулировке нет. Этот абзац вызывает вопросы тем, что вводится некое "исключение возможности использования (эксплуатации) нарушителем выявленных уязвимостей", которое формально отличается от "устранения уязвимостей". Хотя по сути речь идет об устранении уязвимостей методом применения компенсирующих мер (см. предыдущий пункт). В результате становится непонятно, определяются ли требования по SLA на "исключение возможности эксплуатации" исходя из уровня критичности уязвимости (непонятно как определяемого 🙄) в соответствии с 117 приказом или нет. Зачем вводить дополнительные сущности и создавать неоднозначности - непонятно. 🤷‍♂️ При этом здесь никак не регламентируется, как должен быть выстроен процесс взаимодействия между VM и IT. Допустимо ли передавать в IT (прямо в почту CTO 😅) огромные отчеты без конкретных рекомендаций по устранению? Формально, исходя из этого пункта, так делать можно. Но насколько это будет эффективно - большой вопрос. 😏

🔭 Контроль устранения уязвимостей

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

Очевидно, эта формулировка полностью взята из описания соответствующего этапа в РУУ23: "На этапе контроля устранения уязвимостей осуществляется сбор и обработка данных о процессе управления уязвимостями и его результатах, а также принятие решений по улучшению данного процесса". В релизе исправлена грамматика: "осуществляется сбор и обработка данных" заменено на "осуществляются сбор и обработка данных". В текущем виде пункт не про контроль устранения уязвимостей и соблюдение SLA как таковых. Он смещён в сторону более высокого уровня и описывает сбор и анализ данных о том, как в целом работает процесс управления уязвимостями, оценку его результатов и принятие решений по его улучшению. То есть речь идёт не об операционном контроле закрытия конкретных уязвимостей, а о мониторинге и повышении эффективности всего VM-процесса. Улучшение процесса - это важно, но хотелось бы, чтобы пункт "контроль устранения уязвимостей" был прежде всего про контроль устранения конкретных уязвимостей, раз уж он так называется.

Итого, что же можно сказать об описании требований к реализации этапов (подпроцессов). Очевидно, авторы хотели описать их так, чтобы РУУ23 им полностью соответствовал, поэтому формулировки были взяты оттуда с небольшими изменениями. Но проблема в том, что для РУУ23 раздел 2.1 - это лишь самое общее описание, а полноценно и подробно требования раскрываются в соответствующих разделах РУУ23. Поэтому неполнота и неточность формулировок в 2.1 РУУ23 вполне простительны, а при перенесении в рассматриваемый документ вызывают вопросы и недоумение. Имхо, правильно было бы формулировки требований переработать и расширить (имея ориентиром всё тот же РУУ23). Ну или прямо предписать использование РУУ23. 😉

🔄 Завершается раздел требованиями по актуализации сведений об уязвимостях:

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

По сравнению с драфтом изменили только орфографическую ошибку. Очевидно, формулировка взята из 2.2 РУУ23: "Процесс управления уязвимостями организуется для всех информационных систем органа (организации) и должен предусматривать постоянную и непрерывную актуализацию сведений об уязвимостях и объектах информационной системы. При изменении статуса уязвимостей (применимость к информационным системам, наличие исправлений, критичность) должны корректироваться способы их устранения". Разница: в релизе "информационные системы оператора", а не "системы органа (организации)". Если это критично, тогда странно, почему в требованиях выше остались "органы (организации)"? 🤔 "Объекты информационной системы" расписаны как "состав программных и программно-аппаратных средств информационных систем", что, наверное, действительно лучше. Изменение "критичность" на "уровень критичности" тоже можно приветствовать.

По сути, если уязвимость была запланирована в задаче на патчинг через месяц, но для неё появились эксплоиты и признаки эксплуатации вживую, её нужно исключить из этой задачи и перепланировать устранение в рамках срочного патчинга. 👍 Единственное, что в отрыве от РУУ23 "корректировка способов устранения уязвимостей" может пониматься по-разному. Было бы лучше, если бы было конкретизировано, что речь о том, что если уязвимость стала объективно более критичной, то это изменение нужно отследить и устранить уязвимость в более сжатые сроки.

❌ И закончить этот пост хотелось бы двумя требованиями к реализации, которые были в драфте, но из релиза были исключены:

🔹 "Процесс управления уязвимостями должен быть взаимоувязан с другими процессами и процедурами деятельности органа (организации) в области защиты информации и информационных технологий."

Это фактически пункт 2.3 РУУ23: "Процесс управления уязвимостями связан с другими процессами и процедурами деятельности органа (организации)". Речь там идёт о процессах мониторинга информационной безопасности, оценки защищенности, оценки угроз безопасности информации, управления конфигурацией, управления обновлениями, применения компенсирующих мер защиты информации. В целом, идея правильная, но, возможно, этому пункту в данном документе действительно не место.

🔹 Управление уязвимостями осуществляется структурным подразделением, специалистами по защите информации с участием подразделений (работников), обеспечивающих эксплуатацию информационных систем. В процессе управления уязвимостями могут быть задействованы другие подразделения и специалисты, в частности, подразделение, ответственное за организацию закупок программных и программно-аппаратных средств, подразделение, ответственное за эксплуатацию инженерных систем.

Это фактически сокращённый пункт 2.4 РУУ23: "Участниками процесса управления уязвимостями являются…". Также не вижу большого вреда от отсутствия этого пункта в документе, так как перечень участников процесса и выполняемых ими операций будет сильно зависеть от конкретной организации.

На этом пост заканчиваю, "Требования к документированию" и "Требования к усилению" рассмотрю в следующей части.

Поделюсь впечатлениями от прошедшей вчера конференции Территория Безопасности, на которой я выступал и был модератором секции, посвящённой управлению уязвимостями и экспозициями

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

Поделюсь впечатлениями от прошедшей вчера конференции Территория Безопасности, на которой я выступал и был модератором секции, посвящённой управлению уязвимостями и экспозициями

Поделюсь впечатлениями от прошедшей вчера конференции Территория Безопасности, на которой я выступал и был модератором секции, посвящённой управлению уязвимостями и экспозициями. На мой взгляд, Территория Безопасности - лучшая на текущий момент независимая конференция по информационной безопасности в России. Независимая в том смысле, что за ней не стоит какой-то один вендор или организация. И в то же время это масштабное мероприятие с разнообразной деловой программой (4 параллельных трека!) и множеством вендоров, представленных в выставочной части. Деловая программа фактически формируется усилиями комьюнити, и каждая ИБ-специализация имеет там своё место и возможность пересечься в одном зале, чтобы обсудить актуальные темы и то, что действительно наболело.

Я приложил руку к составлению VM-ной части программы, о которой писал ранее. Как по мне, всё прошло отлично, докладчики выступали бойко, отрепетированно и укладывались в достаточно жёсткий тайминг. Времени всегда хочется как можно больше, но, с другой стороны, такие ограничения (~1,5 часа на все про все) стимулируют делать секцию как можно более динамичной.

🔹 Приятно, что наш "позитеховский" взгляд на Exposure Management, сформулированный мной и продемонстрированный (очень подробно и наглядно 👍) Константином Маньяковым, был хорошо воспринят как представителями клиентов, так и представителями других VM-вендоров.

🔹 Хотелось бы отметить замечательный, динамичный и остроумный доклад Кирилла Евтушенко, генерального директора Кауч, с критикой функциональности по детектированию мисконфигураций в Nessus. Мне, как бывшему активному комплаенсописателю с опытом в .audit- и NASL-скриптинге, эта тема была особенно близка и интересна. 🔥

🔹 Хотелось бы поблагодарить Кирилла Сорокина, директора департамента защиты приложений ПАО «Вымпелком» (Билайн), и Романа Мустаева, начальника отдела обеспечения безопасности инфраструктуры АО «Национальная страховая информационная система», за взгляд со стороны компаний-клиентов различного масштаба. Коллеги очень здорово сбалансировали наш вендорский междусобойчик, подсветив актуальные проблемы существующих решений по работе с уязвимостями (в широком смысле 😉).

🔹 Огромная благодарность Дмитрию Чернякову, директору по развитию продуктов АО «АЛТЭКС-СОФТ» (RedCheck), за участие в дискуссии. Очень рад, что наши взгляды по VM-ным вопросам, как правило, в значительной степени совпадают. 🤝

В выставочной части в этом году стендов VM-вендоров было поменьше, чем в прошлом. Но тем не менее было много интересного.

🔻 Этот год был отмечен полноценным участием в выставке Positive Technologies с большим и красивым стендом, посвящённым именно продуктам для работы с уязвимостями/экспозициями (XSpider PRO, MaxPatrol VM, MaxPatrol HCC, MaxPatrol Carbon). Интерес был большой, и наш PT-шный десант очень активно поработал на стенде. 👍

🔻 На стенде RedCheck я потестировал интерфейс нового RedCheck VM. Выглядит симпатично. Понравилась фишка с назначением конкретных уязвимостей на ответственных. Фактически таски "один хост - одна уязвимость". Постараюсь сделать отдельный пост про это.

🔻 Интересно пообщался на стендах EASM-вендора DeteAct, compliance/hardening-вендора Кауч, "российского Skybox" MIST Insight.

Организовано мероприятие было, как всегда, отлично. 💯 По технике всё работало как надо. Кормили вкусно, и еды было в избытке. Всё способствовало приятному и полезному деловому общению. Организаторы и лично продюсер конференций Екатерина Митина - большие молодцы! Спасибо Территории Безопасности, и надеюсь, что до встречи в следующем году!

Конференция Территория Безопасности 2026 уже послезавтра, 2 апреля

1 комментарий

Конференция Территория Безопасности 2026 уже послезавтра, 2 апреля

Конференция Территория Безопасности 2026 уже послезавтра, 2 апреля. Финальная программа на сайте. Начало нашей VM-ной секции в 14:40 (трек "PRO КОНТРОЛЬ").

🎤 Начнём с 4 коротких доклада. Сначала я вендоронейтрально расскажу про Exposure Management, а мой коллега из PT Константин Маньяков про реализацию EM конкретно в MaxPatrol Carbon. После чего у нас будет доклад от Кирилла Евтушенко из Кауч про их решение по управлению уязвимостями конфигураций. И, наконец, последний доклад от Кирилла Сорокина из Билайна про связывание VM, ASM и CTEM.

💬 После этого к нам присоединятся Дмитрий Черняков из Алтэкс-Софт и Роман Мустаев из НСИС, и мы полчасика пообсуждаем горячие около-VM-ные темы: Exposures/EM/CTEM, VOC, ASM, использование ИИ. 😉

В этом году у Positive Technologies будет крутой стенд про средства детектирования: XSpider PRO, MaxPatrol VM, MaxPatrol HCC, MaxPatrol Carbon. Не забудьте заглянуть! 🙂

Пара слов про Security Summit, на котором я вчера выступал с докладом про эволюцию Vulnerability Management-а в Exposure Management

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

Пара слов про Security Summit, на котором я вчера выступал с докладом про эволюцию Vulnerability Management-а в Exposure Management

Пара слов про Security Summit, на котором я вчера выступал с докладом про эволюцию Vulnerability Management-а в Exposure Management. Конференция получилась отличная. 👍 Новенький Palmira Art Hotel - весьма комфортен для мероприятий на ~200 человек. Организация от NWComm на высоте: как на этапе планирования, так и на самой площадке. Дельный инструктаж, отличный экран, таймер и спикерский монитор на сцене, надёжно работающий кликер и микрофоны - так бывает не всегда, и я это очень ценю. 🙏 Кормили вкусно. 🍔😋

Моё выступление прошло хорошо. Людей было прилично, слайды фоткали, задавали интересные вопросы: про харденинг и exposure management; про конкурентов в сегменте CTEM в России. 😉 Считаю, что свои целевые мессаджи я донёс успешно. 😌 Отдельно хочу поблагодарить за модерацию Ивана Макарова из MFASOFT. Очень здорово и строго по таймингу. 👏⌚️

Кулуарное общение было приятным и продуктивным. 🙂

Продолжим обсуждать Exposure Management уже в следующий четверг, 2 апреля, на Территории Безопасности. 😉📅

В этот четверг, 26 марта, я собираюсь выступить на московской конференции Security Summit "Стратегия и тактика информационной безопасности"

1 комментарий

В этот четверг, 26 марта, я собираюсь выступить на московской конференции Security Summit Стратегия и тактика информационной безопасности

В этот четверг, 26 марта, я собираюсь выступить на московской конференции Security Summit "Стратегия и тактика информационной безопасности". У меня там будет короткий доклад про эволюцию Vulnerability Management-а в Exposure Management. Буду рассказывать про то, как мы все жили не тужили где-то с начала нулевых: детектировали и приоритизированно устраняли уязвимости и мисконфигурации, называя это "Управление Уязвимостями". А потом бац - в 2017 году маркетологи Tenable придумали для позиционирования своих решений на рынке использовать вместо уязвимостей слово "exposures" - максимально обтекаемое и неконкретное даже на английском, а тем более при попытках перевести его на русский. И эти самые "exposures" настолько зашли консалтерам из Gartner, что где-то с 2022 года они стали использовать их в хвост и гриву в рамках своей концепции "продвинутого VM-а" под аббревиатурой CTEM (Continuous Threat Exposure Management). И т.к. Gartner в деле ИБ-шного маркетинга могущественны и влиятельны, то сейчас на Западе VM практически закончился. 🤷‍♂️ У всех бывших VM-вендоров сплошной CTEM через CTEM, естественно определяемый так, как конкретному вендору выгодно. 😏 И, соответственно, масса сопутствующей маркетинговой активности: новые продуктовые ниши для решений (EAP, AEV, VPT, EASA, CAASM, APM, APA, BAS, Auto PT, CART, APS, TIP, DRPS, ASCA, X-SPM - можно подумать, что я рандомно стучу по клавиатуре, но нет 😅), новые квадранты, масса аналитики на тему (полезной и не очень). Работают люди! 😉

И тут, глядя на это западное маркетингово-консалтинговое пиршество духа из подсанкционной России, возникает вопрос: игнорировать его или интерпретировать (желательно не сильно противореча оригиналу) и попытаться извлечь некоторую практическую пользу (чтобы EM не выхолостился просто в модный синоним VM-а). Учитывая, что мы чай не в лесу живём, игнорировать не выглядит хорошим вариантом - всё это так или иначе сюда придёт и будет использоваться. Получается, следует включаться в это использование, чётко определяя, что такое exposures (экспозиции, "уязвимости в широком смысле"), что такое Exposure Management ("управление экспозициями"), что такое CTEM ("непрерывное управление экспозициями с учётом угроз") и какая функциональность для этих классов решений является ключевой и приносящей реальную пользу.

В общем, примерно таким будет выступление. Заглядывайте на мероприятие, пообщаемся. 🙂 Positive Technologies - генеральный партнёр, поэтому на стенде про PT-шный взгляд на CTEM тоже расскажем и покажем продукты, которые его реализуют. 😉

На прошлой неделе у Jonathan Risto из SANS был занимательный пост о том, что на самом деле определяет, будет ли процесс Управления Уязвимостями/Экспозициями работать в организации или нет - это наличие эффективного принуждения к исполнению (enforcement)

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

На прошлой неделе у Jonathan Risto из SANS был занимательный пост о том, что на самом деле определяет, будет ли процесс Управления Уязвимостями/Экспозициями работать в организации или нет - это наличие эффективного принуждения к исполнению (enforcement)На прошлой неделе у Jonathan Risto из SANS был занимательный пост о том, что на самом деле определяет, будет ли процесс Управления Уязвимостями/Экспозициями работать в организации или нет - это наличие эффективного принуждения к исполнению (enforcement)

На прошлой неделе у Jonathan Risto из SANS был занимательный пост о том, что на самом деле определяет, будет ли процесс Управления Уязвимостями/Экспозициями работать в организации или нет - это наличие эффективного принуждения к исполнению (enforcement). Jonathan описывает ситуацию, когда в организаций вроде как есть всё необходимое для нормального VM/EM процесса: сканеры, дашборды, SLA, процессы эскалации. Но принуждение к исполнению в организации слабое, и система постепенно адаптируется: дедлайны превращаются в рекомендации, ответственность ("ownership") становится предметом обсуждений, а принятые риски годами не пересматриваются ("stops being revisited"). 🫠 При этом вроде какая-то активность есть, но экспозиции практически не устраняются, растёт exposure debt.

Что имеет смысл делать в такой ситуации VM/EM-специалисту?

🔊 Попробовать достучаться до руководства. Подсветить управленческую проблему: решения принимаются, но не исполняются, поэтому экспозиции не снижаются и это приведёт к инцидентам.

📝 Формализовать всё. Фиксировать владельцев активов, конкретные задачи по исправлению, этапы исправления, risk acceptance, нарушения SLA и т.д. Это делает процессы максимально прозрачными и вы, как VM-щик, с меньшей вероятностью окажитесь "крайними".

🎯 Фокусироваться на реальном риске. Если всё не исправить, закрывать то, что действительно эксплуатируется (в первую очередь трендовые уязвимости) на наиболее критичных для бизнеса системах.

🚪 Если система не меняется - задуматься о смене работы. Это весьма грустно, но если в организации сплошная "электрификация" ("всем всё до лампочки" 😉), снизу это исправить практически нереально. А вот стать в итоге "козлом отпущения" можно запросто. Обязательно это учитывайте.

Распишу по поводу "карты достижимости" в Security Vision VM, которую коллеги из Security Vision зарелизили в январе и показали вживую на прошлой неделе на вебинаре

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

Распишу по поводу карты достижимости в Security Vision VM, которую коллеги из Security Vision зарелизили в январе и показали вживую на прошлой неделе на вебинареРаспишу по поводу карты достижимости в Security Vision VM, которую коллеги из Security Vision зарелизили в январе и показали вживую на прошлой неделе на вебинареРаспишу по поводу карты достижимости в Security Vision VM, которую коллеги из Security Vision зарелизили в январе и показали вживую на прошлой неделе на вебинареРаспишу по поводу карты достижимости в Security Vision VM, которую коллеги из Security Vision зарелизили в январе и показали вживую на прошлой неделе на вебинареРаспишу по поводу карты достижимости в Security Vision VM, которую коллеги из Security Vision зарелизили в январе и показали вживую на прошлой неделе на вебинаре

Распишу по поводу "карты достижимости" в Security Vision VM, которую коллеги из Security Vision зарелизили в январе и показали вживую на прошлой неделе на вебинаре. Скриншоты я делал с трансляции, поэтому извините за качество. 🤷‍♂️ Апскейлер не особо помог, но основное там вроде видно. 🙂

Так вот, карта достижимости - это граф с информацией о том, до каких критических активов злоумышленник может дойти в ходе эксплуатации уязвимостей на активах IT-инфраструктуры организации.

Информация для построения карты сети берётся из результатов активного сканирования (инвентаризации) хостов и сетевых устройств. При построении используются собранные таблицы маршрутизации, сетевые службы, порты, протоколы, сетевые интерфейсы. Чем полнее сканируете инфру, тем адекватнее будет карта.

Критичность активов может как задаваться вручную на странице актива (уровень критичности и флаг "стратегического" актива - аналог "целевого" из методологии РКН), так и определяться автоматически (есть ли у актива доступ в Интернет, есть ли у актива привязка к стратегическому активу).

При построении графов достижимости поиск направлен в сторону стратегических активов.

Далее на граф накладывается информация о продетектированных уязвимостях и получается финальная карта достижимости.

🔴 Красные связи показывают достижимость атаки до критических активов через эксплуатацию уязвимостей на хостах.

🟡 Жёлтые связи показывают прерывание атаки на определенном активе и невозможность развития атаки по данному маршруту.

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

Ок, это всё красиво. Но как это использовать для приоритизации активов и уязвимостей? 🤔

В правой части дашбордов есть таблички с ТОПом активов и их уязвимостей с параметром "степень участия". Этот параметр некоторым образом проприетарно высчитывается и характеризует степень участия актива или уязвимости в потенциальной атаке. Соответственно, следует в первую очередь обращать внимание на активы и уязвимости с максимальной степенью участия. Так на скриншоте можно видеть публично доступный Linux хост с Confluence (с.у. 0,5) уязвимый к CVE-2023-22527 (с.у. 0,5) и виндовую RCE CVE-2024-38063 (с.у. 1).

В общем, такая вот новая функциональность. Это, конечно, пока не тянет на полноценное моделирование Attack Paths, т.к.

🔹 На графе отображаются продетектированные уязвимости со зрелыми эксплоитами и сетевым вектором, НО не производится глубокого анализа, как именно конкретные уязвимости эксплуатируются, какие для этого должны выполняться условия, что именно злоумышленники могут достичь через эксплуатацию, как именно они могут развивать атаку и т.п. То есть нет явной симуляции действий злоумышленника в контексте конкретного хоста. Пока демонстрируемая эксплуатабельность носит более теоретический характер, но предвижу развитие продукта в сторону большей конкретики. 😉

🔹 Это всё про уязвимости софта (CVE), а не про экспозиции. Те же проблемы с учётками и мисконфигурации никак не учитываются, но коллеги из Security Vision обещают добавить их на граф уже в ближайших релизах.

Но в любом случае, как некоторые быстрые первые шаги в сторону дополнительной приоритизации уязвимостей на основе сетевой связности - это вполне имеет право на существование. 🙂👍