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

VM-ный миф № 3: специалисты по Управлению Уязвимостями должны всегда стремиться к поиску компромисса с бизнесом и IT

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

Обнаружена критическая уязвимость в сервисе на периметре, который выполняет некоторую бизнес-функцию. Признаков эксплуатации нет. Вендор рекомендует срочно обновить ПО и применить защитные меры. По регламенту устранение уязвимости должно быть выполнено за 24 часа. Руководитель ИТ просит продлить срок до 72 часов, так как команда занята другим релизом. Какое решение будет наиболее правильным с точки зрения процесса VM?

🔹 Предложить внедрить компенсирующие меры в компромиссный срок.
🔹 Апеллировать к регламенту и требовать перенести релиз, эскалируя вопрос руководству.
🔹 Согласиться на 72 часа из-за отсутствия признаков эксплуатации.
🔹 Изучить возможность эксплуатации уязвимости, совместно с SOC срочно ограничить доступ к уязвимому сервису.

Какой ответ считается правильным в тесте, я не скажу. 😉 Но ситуация более чем типичная и на ней, как мне кажется, хорошо демонстрируется правильный VM-ный майндсет.

Когда говорят про VM, обычно подчеркивают необходимость искать компромиссы и выстраивать конструктивное взаимодействие с командами, чтобы вместе достигать общих целей. И это во многом действительно так. Специалистам по VM важно доносить до владельцев систем критичность выявленных проблем и объяснять связанные с ними риски. Однако на другой стороне (в IT и бизнесе) тоже работают компетентные люди, которые действуют в рамках собственных приоритетов. Устранение уязвимостей приоритетной задачей для них, как правило, не является. Поэтому переносы сроков устранения под разными предлогами или даже отказы от устранения уязвимостей - явление вполне обыденное. 🤷‍♂️

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

При реализации такого сценария вопрос уже может стоять не только об увольнении, но и о гораздо более серьезных последствиях. Вплоть до уголовной ответственности. Особенно если вы работаете в государственных организациях, на объектах КИИ или с системно значимыми сервисами. Прежние договоренности с вашими коллегами в этот момент в значительной степени обнулятся. Начнется судорожный поиск виноватых: кто отвечал за устранение злополучной уязвимости и кто недостаточно хорошо выполнил свою работу. И будьте уверены, что ваши коллеги из IT и бизнеса будут говорить примерно следующее:

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

Попробуйте мысленно перенестись еще на один шаг вперед - представьте, что вы сидите на допросе, в весьма некомфортных условиях, вам в глаза светит лампа, и вы понимаете, что в своей работе что-то делали не так. Задайте себе вопрос: "Что помогло бы мне в этой ситуации? Что нужно было сделать, чтобы лично ко мне, VM-щику, не возникло вопросов?"

🔻 Если ваши коллеги из IT и/или бизнеса должны были устранять такого рода уязвимости, значит, должен быть документ, в котором прописано, какие типы уязвимостей они устраняют и в какие сроки. Эти сроки должны быть заранее согласованы и зафиксированы. Этой бумажной частью работы кто-то должен методично заниматься.

🔻 Если вы раньше знали об этой уязвимости (детектировали её в рамках сканов), значит, нужно было донести эту информацию до ответственного за устранение так, чтобы это было неотказуемо. Что значит неотказуемо? Не устно, не через мессенджеры и даже не через почту. По этой уязвимости должна существовать задача на устранение, назначенная на конкретного исполнителя, с указанием крайнего срока. Да, этот срок может быть сложно выдержать в реальных условиях, но формально и по руководящим документам он должен быть установлен. С вашей стороны всё, что нужно, должно было вылететь. Если срок устранения не был выдержан, нужно было показать свое деятельное участие: что вы пытались эскалировать проблему. Возможно, попытки эскалации все равно были бы безуспешными, но эти попытки необходимо фиксировать.

🔻 Если вы раньше не знали об этой уязвимости (НЕ детектировали её в рамках сканов), возникает вопрос: почему? Не занимались планомерным покрытием инфраструктуры регулярными сканами? Вместо качественных средств детектирования использовали быстрые? 😉 Аргумент "мы сканировали, но сканер нам ничего не показал" будет выглядеть в рамках разбирательства весьма слабо. Оценка качества детектирования - ваша задача.

И так далее. Эти формальные меры могут повысить шансы, что в случае неприятного инцидента простого VM-щика не сделают крайним: не посадят и не уволят с волчьим билетом.

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

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

Так что склоняюсь скорее ко второму варианту. И там уж как пойдет. Получится пропушить устранение в нормативное время, отлично. 👍 Не получится пропушить, но инцидента в растянутый срок устранения не произойдет, тоже норм. 👌 Если злодеи все-таки успеют пробить периметр организации в растянутый срок устранения и это приведет к критичному инциденту - плохо. 😔 Но в этой ситуации будет что показать приехавшим разбираться людям в погонах и будет чем аргументировать, что VM-щик сделал все, что мог.

Дефолтный алгоритм такой: представьте, что вы на допросе по инциденту, случившемуся из-за эксплуатации уязвимости. Какие артефакты, по вашему мнению, могут помочь не присесть конкретно вам? 🙂 Обычно такой мысленный эксперимент подсказывает, чего вашему VM-ному процессу на самом деле не хватает. Те же VM-щики, которые всегда готовы на компромисс и не думают о последствиях для себя лично, имхо, рискуют оказаться в неожиданный момент кинутыми буквально всеми и с горячей картошкой в руках.

Инфосистемы Джет выложили "Результаты тестирования решений для управления уязвимостями" по новой версии методики (3.0)

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

Инфосистемы Джет выложили "Результаты тестирования решений для управления уязвимостями" по новой версии методики (3.0). Тестировали следующие продукты:

🔸 MaxPatrol VM v. 2.8 (27.6)
🔸 SecurityVision VM v. 5.0.1773849508
🔸 ScanFactory v. 7.21.9
🔸 R-Vision VM v. 6.2
🔸 AlphaSense v. 4.57.08.04

В отличие от тестирования по второй версии методики, здесь отсутствуют RedCheck и Vulns io VM. Возможно их добавят позже.

Оценка проводилась по 12 группам требований:

⚙️ Нефункциональные требования. Автоматическое и оффлайн обновление базы уязвимостей, открытый доступ к базе, централизованное управление, агентское сканирование и работа с хостами, поддержка изолированных сегментов и распределенной установки компонентов, мультиязычность, мультитенантность, а также соответствие требованиям ФСТЭК и включение в реестр отечественного ПО.

📱 Мобильный сканер. Наличие портативного (мобильного) сканера с возможностью переноса результатов в основную инсталляцию и формирования отчетов.

🗺️ Управление активами. Интерактивная карта сети, управление активами (динамические группы, поиск, карточки), скоринг и дедупликация активов, тегирование, хранение истории изменений, патч-менеджмент и выполнение административных команд на активах.

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

📊 Функционал визуализации и отчетности. Визуализация данных через настраиваемые виджеты и дашборды, создание и планирование отчетов, расширенная кастомизация интерфейса и объектов.

💻 Поддерживаемые типы активов для сканирования. Поддержка сканирования операционных систем (Windows, Linux и отечественных ОС), сетевого и серверного оборудования, СУБД и серверного ПО, а также поддержка периферийных устройств, промышленных систем (ICS/SCADA) и контейнеров.

🔗 Возможности интеграции. Документированный API с управлением доступом через ключи, встроенный мониторинг работоспособности (health-check) и интеграции с внешними системами мониторинга, поддержка доменной аутентификации, интеграции с Service Desk/ITSM и с SIEM, получение данных об активах из смежных систем и отправка оповещений.

🛡️ Управление сканированием и уязвимостями. Кастомизация карточки и тегирование уязвимостей, планирование и управление сканированиями (расписания, профили, ретроскан, исключения, технологические окна, пауза, клонирование), настройка правил и параметров сканирования, проверка доступности и учетных записей, в том числе брутфорс с пользовательскими словарями и несколькими типами учетных записей, управление исключениями, прогресс в реальном времени, расширенная работа с уязвимостями (CVE/CWE/БДУ, CVSS v2–v4 и кастомные метрики, скоринг, дедупликация, эксплуатируемость, вероятность использования, наличие эксплойтов, путь атаки, трендовость), а также рекомендации, внешние ссылки и методики ФСТЭК и НКЦКИ, плюс оповещения о событиях системы.

📏 Оценка соответствия. Проверка активов на соответствие стандартам безопасной конфигурации, создание пользовательских проверок и требований через конструктор, точечная переоценка активов, рекомендации по устранению несоответствий, ведение истории оценок и встроенное сравнение результатов.

🌐 Сканирование веб-ресурсов. Аутентификация в веб-приложениях, сканирование веб-ресурсов (поиск поддоменов, скрытых файлов и директорий), режимы имитации и активной атаки, а также обнаружение широкого спектра уязвимостей (инъекции, CSRF, загрузка файлов и доступ к ФС, клиентские атаки, редиректы, слабая криптография, небезопасные security headers, утечки информации, cookie и сессионные уязвимости, memory corruption).

🔐 Безопасность. Настраиваемая ролевая модель, управление парольной политикой (сложность, история, минимальная длина, срок действия), блокировка учетных записей после неудачных попыток входа, шифрование критичных данных с поддержкой пользовательских ключей и создание/восстановление из резервных копий.

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

Возможные значения для каждого требования: ✅ Да, ❌ Нет, Частично. За исключением "Производительность и эффективность" → "Скорость добавления новых уязвимостей в базу уязвимостей решения…", где указывается значение в часах. По некоторым требованиям доступны 💬 комментарии вендоров.

Работа была проделана, вне всяких сомнений, большая и основательная. 🔥 Но, как и в случае тестирования по первой версии методики, мне не хватает оценки качества детектирования. Большая часть этой функциональности скрывается за пунктом "Поддержка сканирования ОС: Windows Server, Windows, AlmaLinux, Ubuntu, Debian" с галочкой у всех вендоров и без каких-либо комментариев. А ведь там самое интересное, ради чего, собственно, пользователи и покупают САЗы. Очень хотелось бы гораздо большей детализации поддерживаемых типов активов и подробного сравнения результатов детектирования на стендах с детализацией до конкретных CVE-шек, чтобы была видна разница в реализованной логике детектирования. Возможно, когда-нибудь и это сделают. 🙂

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

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

Начну разбирать основной 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: "Участниками процесса управления уязвимостями являются…". Также не вижу большого вреда от отсутствия этого пункта в документе, так как перечень участников процесса и выполняемых ими операций будет сильно зависеть от конкретной организации.

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

Собираем ТОП отговорок, которые слышат VM-специалисты в своей работе

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

Собираем ТОП отговорок, которые слышат VM-специалисты в своей работе. В канале Positive Technologies выложили прикольные картинки по мотивам моего поста про технику саботажа VM-процесса "докажи-покажи". Приглашаю их заценить. 😇🦇

➡️ Также приглашаю поделиться в комментариях возражениями (от IT-шников, овнеров систем, бизнеса и т.д.), с которыми вы сталкиваетесь в процессе Управления Уязвимостями. За самые интересные отговорки Positive Technologies вручит призы. 😉🎁

Совместными усилиями мы соберём базу возможных возражений и научимся эффективно с ними работать. 😏

Докажи - покажи!

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

Докажи - покажи! Сгенерил трек в Suno про популярный способ саботажа Vulnerability Management процесса. Который в итоге приводит к утечкам данных и пошифрованной инфре. 🤷‍♂️ В этот раз схалтурил, так что без рифм. 🙂 Кидайте вашим IT-шникам, если заметили, что они с вами в докажи-покажи начали играть. 😉

Мы уже исправили уязвимость, это сканер наверное фолсит. Да мы уже запатчили всё. Это сканер наверное фолсит… Мы уверены в том, что ваш сканер всё время фолсит. А тыыыы…