Архив рубрики: Регуляторика

В двух словах о Security Vision Vulnerability Scanner

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

В двух словах о Security Vision Vulnerability Scanner

В двух словах о Security Vision Vulnerability Scanner. Коллеги из Security Vision запустили видео-рубрику "В двух словах", в рамках которой рассказывают о ключевых возможностях продуктов компании, о том, как они защищают бизнес и помогают ему развиваться. В первом выпуске Альбина Михалёва, менеджер по работе с партнёрами, рассказала о Security Vision Vulnerability Scanner (VS).

Видео, естественно, высокоуровневое и маркетинговое. Но для понимания позиционирования решения компании - весьма любопытное. 😉

Security Vision Vulnerability Scanner - это инструмент для поиска уязвимостей в вашей инфраструктуре, использующий собственный движок. Он проверяет: операционные системы, прикладное ПО, сетевые устройства, базы данных, контейнеры. Сканирование можно проводить с агентом или без него. Поддерживаются российские ОС (Астра Линукс, Альт Линукс, РЕД ОС). Работает на основе ведущих баз уязвимостей (ФСТЭК, NVD и других).

🔑 5 ключевых особенностей продукта

1. Продвинутые режимы сканирования. Белый ящик для аудита защищённости. Чёрный ящик (пентест) с более чем 80 экспертных скриптов для проверки эксплуатации уязвимостей, подбора слабых паролей и проверки устаревших алгоритмов шифрования. Мой коммент: если всего 80 сейфчеков, то звучит как-то недостаточно. 🤷‍♂️

2. Специализированные проверки. Сканирование веб-приложений на XSS, SQL-инъекции и другие уязвимости из OWASP Top 10. Проверки контейнеров Docker и Kubernetes. Retro Scan - мгновенный поиск по ранее собранным данным без повторного подключения к активам.

3. Мультисканер и работа в изолированных сетях. Поддерживается одновременная работа с любыми (Мой коммент: тут, естественно, не совсем с любыми, а с теми, для которых интеграции запилены 😉) сторонними решениями (MaxPatrol, Tenable, Nessus, Qualys и др.). Для изолированных сегментов без прямого доступа есть отчуждаемый агент и цепочка прокси-компонентов.

4. Граф достижимости уязвимостей. Система анализирует правила межсетевых экранов и маршрутизацию, показывает, какие уязвимости реально доступны атакующему. Это помогает точнее оценивать реальные риски.

5. Умная приоритизация. Система смотрит не только на формальную оценку опасности уязвимости, но и оценивает, насколько реально ей можно воспользоваться прямо сейчас. Для этого используются данные из внешних источников и собственная аналитика Security Vision.

Мой коммент: видим, что в первых трёх пунктах перечисляются режимы детектирования и поддерживаемые системы; в двух последних пунктах методы приоритизации уязвимостей с закосом в CTEM.

🎯 Какую выгоду получает ваш бизнес?

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

2. Снижение рисков. Граф достижимости помогает понять реальную угрозу, а приоритизация по EPSS и CISA KEV сфокусироваться на том, что действительно опасно.

3. Экономия ресурсов. Автоматизация сканирования и гибкие расписания снижают нагрузку на команду, а возможность точечного ретроскана экономят время.

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

Мой коммент: "проактивная защита", отчёты, EPSS/CISA KEV выглядят как универсальные фичи практически для всех VM-вендоров; а вот ретросканы и граф достижимости - довольно редки.

Заключительный мессадж: "Security Vision VS - это рентген для IT-инфраструктуры. Он помогает видеть слабые места, оценивать реальные риски и защищать бизнес до того, как атака произойдёт. Просто, быстро, эффективно!"

Мой коммент: тут тоже мессадж более-менее универсальный.

В целом, мне ролик понравился, отторжения никакие тезисы не вызвали. 👍

Архитектура Kaspersky Vulnerability Management 1.0

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

Архитектура Kaspersky Vulnerability Management 1.0Архитектура Kaspersky Vulnerability Management 1.0Архитектура Kaspersky Vulnerability Management 1.0Архитектура Kaspersky Vulnerability Management 1.0Архитектура Kaspersky Vulnerability Management 1.0Архитектура Kaspersky Vulnerability Management 1.0Архитектура Kaspersky Vulnerability Management 1.0Архитектура Kaspersky Vulnerability Management 1.0Архитектура Kaspersky Vulnerability Management 1.0

Архитектура Kaspersky Vulnerability Management 1.0. Две недели назад, 16 июля, прошёл вебинар Kaspersky, на котором представили решение Kaspersky Vulnerability Management 1.0. В этом посте хотелось бы рассмотреть первую часть вебинара, посвящённую архитектуре. Позже планирую разобрать и часть с демо, и блок ответов на вопросы.

Участники вебинара:

🔹 Мария Погребняк - отвечает за развитие бизнеса Vulnerability Management в "Лаборатории Касперского";
🔹 Максим Лызаев - presale, стоял у истоков продукта;
🔹 Дмитрий Волошин - presale, опыт в vulnerability management, в команде VM около полугода.

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

Начали с контекста, почему решение выпустили именно сейчас: уже пять лет как минимум треть атак идёт через уязвимости, и это стабильно первое место в рейтинге векторов атак. После 2022 года российский VM-рынок сильно изменился и пополнился новыми вендорами. Последние два года заказчики Kaspersky просили у компании собственное VM-решение.

Заявленные ключевые преимущества:

🔻 Инвентаризация и управление активами - зрелая развитая функциональность за счёт бесшовной интеграции с Kaspersky Security Center; заказчики, уже использующие KSC, отмечают простоту инвентаризационного этапа;

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

🔻 Работа с ошибками конфигураций как с уязвимостями - предустановленные профили ФСТЭК и международные бенчмарки; одна из функциональностей, давшая больше всего положительной обратной связи от партнёров и заказчиков;

🔻 Patch management - функциональность уже была в endpoint-продукте; преимущество в процессной составляющей - возможность пропатчить некоторый перечень ПО, убрав "фоновый шум".

Общая архитектура. Продукт работает в паре с KSC. Для коммерческого релиза VM 1.0 нужен KSC для Linux версии 16.3. VM устанавливается рядом - на том же сервере либо на отдельном. Сам VM (Vulnerability Management) - это несколько сервисов и собственная база данных: у KSC своя база, у VM своя. Используются агенты, подчинённые KSC. Агенты могут устанавливаться на Linux и на Windows - ограничений нет, но версия агентов также должна быть 16.3. У KSC есть веб-консоль. Чтобы добавить в неё разделы, касающиеся VM, устанавливается отдельный плагин.

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

Декларируемые преимущества агентного сканирования:

🔸 Если заказчик уже использует endpoint-агент "Лаборатории Касперского", это тот же агент - к нему просто добавляется функциональность управления уязвимостями. Именно поэтому внедрение простое: основной движок в инфраструктуре компании уже есть.

🔸 Агент передаёт на сервер сканирования данные о том, какие настройки на рабочей станции закрыты, какой порт закрыт или какое ПО "заблокировано". Благодаря этому в сводке уязвимостей не появляются уязвимости для "ПО, к которому нет доступа". Такие детали снижают число ложных срабатываний и делают итоговую картину более точной. Мой комментарий: Это интересный момент. По сути, продукт каким-то образом по умолчанию фильтрует детектируемые уязвимости по дополнительному набору критериев. Какие именно это критерии и насколько такое поведение корректно - нужно будет разбираться отдельно, поэтому здесь ждём подробностей. 😉

🔸 Агент не требует передачи учётных данных, поскольку уже работает под достаточно привилегированной учётной записью на конечном устройстве - передавать креды по сети не нужно. При атаках хакеры в первую очередь охотятся за учёткой сканера, работающего под админскими правами. В случае агентного сканирования единой учётной записи нет - у каждой рабочей станции своя учётка, поэтому этот риск снимается.

Читать далее →

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

О правильном понимании термина "exposure" ("экспозиция") в контексте Exposure Management (Управление Экспозициями) и Continuous Threat Exposure Management (CTEM, Непрерывное Управление Экспозициями с учётом Угроз)

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

О правильном понимании термина exposure (экспозиция) в контексте Exposure Management (Управление Экспозициями) и Continuous Threat Exposure Management (CTEM, Непрерывное Управление Экспозициями с учётом Угроз)

О правильном понимании термина "exposure" ("экспозиция") в контексте Exposure Management (Управление Экспозициями) и Continuous Threat Exposure Management (CTEM, Непрерывное Управление Экспозициями с учётом Угроз). Я решил вернуться к этому вопросу, более-менее подробно описать историю использования термина "exposure", а также обосновать, почему я считаю корректным определять термин "exposure" как "уязвимость в широком смысле". Сделаю я это на основе своих выступлений и дискуссий на конференциях Security Summit, Территория Безопасности и Периметр, а также семинаре компании "Киберпротект", проходивших этой весной.

Повторюсь, что у меня к термину "exposure" отношение непростое. Был период, когда он мне категорически не нравился, и я выступал против его использования. Но постепенно, как в знаменитой книге Дейла Карнеги, я перестал беспокоиться и научился с ним жить. 🙂

🎓 (НЕ)Использование в академической ИБ

Когда мы говорим об уязвимостях ("vulnerability"), мы обычно понимаем под этим ошибки программного обеспечения, "баги", которые злоумышленники могут использовать для реализации своих зловредных целей. Всё у чего есть CVE или БДУ идентификатор - это уязвимость. При этом если посмотреть формальное определение уязвимости, то оно окажется гораздо более широким. У ФСТЭК это "слабость актива или управления, эксплуатация которой приведёт к реализации одной или нескольких угроз" (ISO/IEC 27000:2014) или "Недостаток (слабость) программного (программно-технического) средства или информационной системы в целом, который (которая) может быть использована для реализации угроз безопасности информации" (ГОСТ Р 56545-2015). В глосарии NIST самое популярное определение уязвимости, используемое в 17 документах, звучит так: "слабость в информационной системе, процедурах обеспечения безопасности системы, внутренних контролях или реализации, которая может быть эксплуатирована или задействована источником угрозы".

А откуда взялось "exposure"? Это слово очень многозначное как в самом английском языке, так и при переводе на русский. В зависимости от контекста его могут переводить как подвергание, выставление, выставка, местоположение, обнажение, вид и т.д.

В академической информационной безопасности термин "exposure" практически не используется. Если термин "vulnerability", согласно глоссарию NIST встречается в 39 документах, то термин "exposure" только в двух:

🔹 В документе NIST SP 800-161r1-upd1 Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations под "exposure" понимается "степень, в которой организация и/или заинтересованная сторона подвержена риску".

🔹 В документе NISTIR 8286 Integrating Cybersecurity and Enterprise Risk Management (ERM) под "exposure" понимается "комбинация уровней вероятности и воздействия для риска".

Несмотря на низкую академическую востребованность, термин "exposure" в настоящее время активно используется индустриальной ИБ-экосистемой (Gartner, крупные вендоры, консалтинговые и платформенные игроки), но в иных смыслах.

⚙️ Эпоха Tenable

Одним из главных популяризаторов термина стала компания Tenable, которая с 2017 года начала продвигать концепт "Cyber Exposure" как "новую развивающуюся дисциплину управления и измерения современной поверхности атаки, позволяющую точно понимать и снижать киберриски" (Tenable Delivers Record Results in Q2 and the First Half of 2017). Однако при описании этого "Cyber Exposure" они используют термин "exposure", не определяя его. 🤷‍♂️ "Cyber Exposure также обеспечивает непрерывную видимость того, где активы защищены, а где они находятся в состоянии exposure и в какой степени, а также приоритизирует устранение проблем на основе критичности актива для бизнеса и степени выраженности exposure". Себя Tenable начали называть "Cyber Exposure company".

Также в 2017 году Tenable представили Cyber Exposure ecosystem - интеграционную экосистему, объединяющую инструменты безопасности и IT (ServiceNow, AWS, Splunk и другие) для сквозного управления киберриском за счёт обмена данными, автоматического обнаружения активов и ускорения приоритизации и устранения уязвимостей на всей современной поверхности атаки.

К 2019 году у Tenable "Cyber Exposure" уже используется как измеряемая модель киберриска: в Tenable Lumin они вводят Cyber Exposure Score, который объединяет вероятность эксплуатации уязвимостей и критичность активов, позволяет количественно оценивать уровень "exposure", сравнивать его во времени и между организациями и использовать это для приоритизации устранения рисков и принятия риск-ориентированных решений.

Таким образом, можно сказать, что до начала 2020-х годов термин "exposure" в рамках материалов Tenable не имел единого фиксированного самостоятельного определения и использовался как "плавающий" термин-оболочка, которому в разных контекстах придавались различные значения: от обозначения новой дисциплины управления и измерения киберриска, до общей подверженности риску, состояния уязвимости активов, степени их "открытости" атаке, агрегированного риска (с учётом вероятности и ущерба), интеграции уязвимостей и конфигураций в единую модель, а также количественного скоринга для ранжирования и приоритизации устранения проблем. 🤯

Читать далее →

В Ведомостях вчера вышла статья с моими комментариями по поводу развития Vulnerability Management рынка в России и мире

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

В Ведомостях вчера вышла статья с моими комментариями по поводу развития Vulnerability Management рынка в России и мире

В Ведомостях вчера вышла статья с моими комментариями по поводу развития Vulnerability Management рынка в России и мире. Сама статья за paywall-ом, и мои комментарии там, вполне естественно и ожидаемо, были сильно сокращены, поэтому я приведу их здесь в развёрнутом виде.

Насколько адекватно делать выводы о динамике раскрытия уязвимостей, основываясь только на БДУ ФСТЭК России? (такую статистику привели коллеги из ЛК, привязав к ней анонс Kaspersky VM 😉)

Говоря о базе уязвимостей БДУ ФСТЭК России, важно учитывать, что она методологически не предназначена для учёта всех существующих уязвимостей: в неё включаются данные об уязвимостях отечественных продуктов, а также иностранных коммерческих и опенсорсных решений, применяемых в ГИС и на объектах КИИ. Поэтому БДУ не покрывает весь спектр уязвимостей, актуальных для российских инфраструктур, и её данных недостаточно для анализа глобальных трендов; для этого лучше использовать более полные источники, такие как PT DBugs или NIST NVD. Для визуализации статистики NVD удобно использовать дашборды, такие как CVE ICU. Текущие данные NVD показывают значительное увеличение скорости добавления новых CVE: за одинаковый период в 2025 году было зарегистрировано 22 041 уязвимость, а в 2026 году уже 31 917, что соответствует увеличению на 44,8%.

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

Что сейчас происходит с Vulnerability Management рынком?

Рынок Vulnerability Management в последние годы растёт как в России, так и в мире. В России важным фактором стал уход западных вендоров в 2022 году, что привело к появлению новых отечественных игроков. Внутренняя конкуренция стимулирует развитие функциональности решений, повышение качества детектирования, точности приоритизации и расширение интеграций с другими средствами защиты и ИТ-системами. Отдельно стоит отметить внимание ФСТЭК России к этой теме: разработка методических документов и требований способствует формированию более структурированного подхода к управлению уязвимостями.

Если смотреть ретроспективно, рынок Vulnerability Management прошёл путь от массового сканирования и детектирования CVE-уязвимостей к платформенному управлению защищённостью инфраструктуры. Полный и качественный поиск уязвимостей остаётся важной базовой функциональностью, однако сегодня всё больше учитывается контекст: критичность затронутых активов и возможность реальной компрометации через комбинацию выявленных уязвимостей. На Западе всё чаще говорят не о классическом Vulnerability Management, а о более широком подходе - Exposure Management или Continuous Threat Exposure Management (CTEM), где объектом управления становятся не только уязвимости с CVE/BDU-идентификаторами, но и уязвимости в широком смысле ("экспозиции"): ошибки конфигурации, проблемы с учётками, небезопасные настройки, избыточная сетевая связность активов и т.п. Обнаруженные проблемы используются CTEM-решениями для моделирования возможных путей развития атаки (attack paths), что позволяет выявлять и приводить в порядок наиболее проблемные участки инфраструктуры, повышая сложность и стоимость реальной атаки для злоумышленников.

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

На сайте Anti-Malware 25 мая вышел аналитический отчёт "Сканеры уязвимостей: обзор российского рынка и отечественных решений"

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

На сайте Anti-Malware 25 мая вышел аналитический отчёт Сканеры уязвимостей: обзор российского рынка и отечественных решений
На сайте Anti-Malware 25 мая вышел аналитический отчёт Сканеры уязвимостей: обзор российского рынка и отечественных решенийНа сайте Anti-Malware 25 мая вышел аналитический отчёт Сканеры уязвимостей: обзор российского рынка и отечественных решенийНа сайте Anti-Malware 25 мая вышел аналитический отчёт Сканеры уязвимостей: обзор российского рынка и отечественных решенийНа сайте Anti-Malware 25 мая вышел аналитический отчёт Сканеры уязвимостей: обзор российского рынка и отечественных решенийНа сайте Anti-Malware 25 мая вышел аналитический отчёт Сканеры уязвимостей: обзор российского рынка и отечественных решенийНа сайте Anti-Malware 25 мая вышел аналитический отчёт Сканеры уязвимостей: обзор российского рынка и отечественных решенийНа сайте Anti-Malware 25 мая вышел аналитический отчёт Сканеры уязвимостей: обзор российского рынка и отечественных решенийНа сайте Anti-Malware 25 мая вышел аналитический отчёт Сканеры уязвимостей: обзор российского рынка и отечественных решенийНа сайте Anti-Malware 25 мая вышел аналитический отчёт Сканеры уязвимостей: обзор российского рынка и отечественных решений

На сайте Anti-Malware 25 мая вышел аналитический отчёт "Сканеры уязвимостей: обзор российского рынка и отечественных решений". В обзоре были рассмотрены следующие сканеры уязвимостей:

🔻 BITsignal
🔻 Hscan
🔻 Security Vision VS
🔻 ScanOVAL
🔻 RedCheck
🔻 XSpider PRO
🔻 METASCAN
🔻 Ревизор Сети
🔻 Сканер-ВС

Для каждого решения приводятся характеристики, иллюстрации (для всех, кроме Security Vision VS, это скриншот), возможности сканера, информация о нахождении в реестрах и наличии сертификатов, а также ссылки на дополнительную информацию.

Сделал выжимку из отчёта:

💡 Предпосылки развития рынка сканеров уязвимостей. Сканеры уязвимостей давно стали одним из базовых инструментов специалистов ИБ. Их значение растёт вместе с количеством выявляемых уязвимостей и расширением ИТ-инфраструктуры организаций, особенно учитывая, что злоумышленники активно эксплуатируют не только новые, но и давно известные недостатки безопасности. Современные сканеры позволяют автоматически выявлять активы и уязвимости, сопоставлять результаты с базами CVE и БДУ ФСТЭК, помогают снижать риски информационной безопасности. Сегодня решения этого класса предлагают не только крупные международные вендоры, но и российские разработчики.

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

🌍 Как развивается мировой рынок сканеров уязвимостей. Мировой рынок сканеров уязвимостей продолжает уверенно расти как в сегменте сервисов сканирования (Vulnerability Scanning Service), так и в сегменте программных продуктов (Vulnerability Scanner Software). По оценкам аналитиков, к 2033 году объём этих рынков увеличится в несколько раз благодаря распространению облачных и гибридных инфраструктур, внедрению практик DevSecOps, развитию контейнерной безопасности и автоматизации, а также использованию технологий искусственного интеллекта и машинного обучения. Среди наиболее известных решений этого класса можно выделить Nessus и Tenable.io (актуальное название - Tenable One Vulnerability Management), Qualys, Nexpose, Acunetix и Burp Suite.

🇷🇺 Как развивается российский рынок сканеров уязвимостей. Уход зарубежных сканеров уязвимостей, таких как Qualys, Nexpose и Nessus, не привёл к образованию пустоты на российском ИБ-рынке: отечественные вендоры и новые игроки VS-сегмента активно включились в процессы импортозамещения, усилив конкуренцию и расширив выбор решений для заказчиков - от классических сетевых сканеров до платформ с функциями комплаенса и поддержкой требований российских регуляторов. При этом, несмотря на развитие рынка, в отраслевых исследованиях фиксируются сохраняющиеся проблемы отечественных решений. Дополнительно аналитические материалы указывают на постепенное размывание границы между сканерами уязвимостей и системами Vulnerability Management, при этом классические сканеры остаются базовым инструментом VM-экосистем.

🧩 Альтернативные решения на рынке. Решения для управления уязвимостями (Vulnerability Management, VM) представляют собой отдельный класс систем, однако сканирование уязвимостей является их неотъемлемой частью, поэтому такие продукты часто рассматриваются вместе со сканерами уязвимостей; к ним относятся MaxPatrol VM, Security Vision VM, R-Vision VM, ScanFactory VM и Vulns.io VM. Наряду с коммерческими решениями существует большое количество сканеров с открытым исходным кодом, которые требуют высокой экспертизы и используются либо как вспомогательные инструменты, либо как источник данных в комплексных системах. Среди наиболее известных open source решений можно выделить Nikto, Nmap, Nuclei и OpenVAS, а также специализированные инструменты для контейнеров, веб-приложений, кода и баз данных. Дополнительно для задач выявления уязвимостей могут использоваться смежные классы систем, включая платформы управления поверхностью атаки (EASM) и решения для симуляции кибератак (BAS).

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

Материал интересный. Единственное: список решений довольно неоднородный. В основном там инфраструктурные сканеры уязвимостей, но есть и периметровые сканеры (BITsignal, METASCAN), и даже бесплатный локальный хостовый сканер от ФСТЭК ScanOVAL. Не уверен, что собирать их все в одну группу "сканеров" - это правильный подход, слишком уж разные решения. Свою, на мой взгляд, более удачную классификацию я представлял в рамках проекта карты отечественных VM-вендоров.

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

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

Инфосистемы Джет выложили Результаты тестирования решений для управления уязвимостями по новой версии методики (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-шек, чтобы была видна разница в реализованной логике детектирования. Возможно, когда-нибудь и это сделают. 🙂