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

Сегодня на тест-драйве MaxPatrol VM

Сегодня на тест-драйве MaxPatrol VM
Сегодня на тест-драйве MaxPatrol VMСегодня на тест-драйве MaxPatrol VMСегодня на тест-драйве MaxPatrol VM

Сегодня на тест-драйве MaxPatrol VM. Заявлена насыщенная программа на весь день. Будет как подробный обзор продукта, так и несколько часов практических занятий. В предвкушении. 🤩 В зале 30 столов на двоих, на момент публикации где-то на процентов 90 заполнилось. Знакомых из слушателей никого. А ведь это все VM-щики видимо. Надо активнее нетворкиться. 🙂

Разбираю ответы на мои вопросы с эфира AM Live по Vulnerability Management-у

Разбираю ответы на мои вопросы с эфира AM Live по Vulnerability Management-у

Разбираю ответы на мои вопросы с эфира AM Live по Vulnerability Management-у. Часть 3/3. Поддержка методик ФСТЭК.

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

> 5. Что вы думаете о проекте "Руководства по управлению уязвимостями программного обеспечения и программно-аппаратных средств в органе (организации)" ФСТЭК? Ваше VM-решение позволит работать по этому процессу?

Сложно комментировать поддержку документа, который на момент эфира существовал только в проекте (но сейчас уже официально опубликован). 🙂 По факту обсуждения руководства и не было. Был только ответ Сергея Уздемира из АЛТЭКС-СОФТ (1:07:37), что есть такой документ и с ним нужно ознакомиться. В своем ответе Сергей упомянул также и методику оценки критичности уязвимостей ФСТЭК. Поэтому когда последовал следующий вопрос "насколько вы в своих решениях сейчас им [методикам] соответствуете?", то представители VM-вендоров стали отвечать про методику оценки критичности, а про руководство по управлению уязвимостями больше не вспоминали. 😉 А жаль, в руководстве есть что пообсуждать.

> 3. Ваше VM-решение позволяет проводить приоритизацию уязвимостей с использованием "Методики оценки уровня критичности уязвимостей программных, программно-аппаратных средств" ФСТЭК?

Ответ начиная с 1:10:05. Четыре вендора заявили о поддержке этой методики. Для Positive Technologies MaxPatrol VM я смотрел текущую реализацию, для R-Vision VM, АЛТЭКС-СОФТ RedCheck и Фродекс VulnsIO пока нет.

Основной проблемой видится то, что для приоритизации по методике ФСТЭК необходимо каким-то образом получать Temporal и Environmental метрики CVSS. Теоретически это можно как-то автоматически генерировать из дополнительной информации об уязвимостях и инфраструктуре, но на практике я пока этого не видел. Так что если вам будут рассказывать про реализацию этой методики, то задавайте вопросы про CVSS. 😉

> 4. Когда ваше VM-решение рекомендует установку апдейтов западного софта, учитывается ли при этом "Методика тестирования обновлений безопасности программных, программно-аппаратных средств" ФСТЭК? Является ли тестирование обновлений по методике частью VM-процесса?

Напрямую этот вопрос не задавался, но темы проверки обновлений несколько раз касались. Причем в основном при обсуждении автопатчинга. В том смысле, что автопатчинг вещь может и хорошая, но необходимость проверки обновления западного ПО как в рамках алгоритма НКЦКИ, так и по методологии ФСТЭК никто не отменял (2:29:29). И там же была реплика "Но это же не наша зона ответственности, по идее это зона ответственности IT" (2:30:15). Это конечно же не так, потому что IT уж точно не смогут оценить безопасность патчей по сложному процессу.

Поэтому варианта 2: либо VM-вендор возьмет задачу анализа обновлений на себя, либо это так и останется проблемой на стороне клиента.

В 2:51:02 Владимир Михайлов из Фродекс/VulnsIO предложил идею проверки обновлений на стороне гипотетического консорциума VM-вендоров: "заказчик, перед тем как накатить патч, установить новую версию ПО, должен проверить его по рекомендациям ФСТЭК. Он маловероятно это сам сделает. Ни один из VM-вендоров это тоже самостоятельно не сделает. Но если мы объединимся под крышей того же БДУ ФСТЭК, мы теоретически сможем собирать базу проверенных обновлений". Причем более полном виде, чем это есть сейчас в БДУ. Очень хотелось бы, чтобы из этой идеи что-то получилось. 🙏

Часть 2

Послушал выступление Алексея Андреева, управляющего директора Positive Technologies, о движений компании в Open Source

Послушал выступление Алексея Андреева, управляющего директора Positive Technologies, о движений компании в Open Source

Послушал выступление Алексея Андреева, управляющего директора Positive Technologies, о движений компании в Open Source.

Начиная с 2:15:19:

"Вся индустрия страдает от простой вещи - нет доступных оцифрованных знаний, чтобы ими все могли пользоваться. И как будто бы сейчаc мы очень хорошо чувствуем, что это всё неправильно. Кто-то скажет, это ведь конкурентное преимущество! И наверное для какой-то другой компании это было бы так: наше знание, наше конкурентное преимущество. Но, чёрт побери, если мы заявляемся, что мы лидер Cyber Security и хотим стать мировым гигантом нельзя заниматься такими подходами.

Для нас, наверное, сейчас самое время, чтобы мы дали в Open Community и средства, которые позволяют собирать экспертизу, и внесли свою экспертизу в Open Source. У нас большой проект сейчас в этом направлении движется. Мы хотим с помощью наших телодвижений в Open Source создать такой прецедент, когда крупнейшая компания в области безопасности вывела и набор средств, необходимых для работы со знаниями, и поделилась всеми своими знаниями. И мы не хотим конкурировать в этой плоскости. Хочется поделиться всем, чем мы владеем и призвать всех остальных делиться.

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

Я не особо понимаю о каких именно знаниях здесь идет речь, но звучит интересно и многообещающе. 🙂 Я, конечно, сразу думаю в сторону баз уязвимостей и детектов. Очень хотелось бы, раз уж взят такой курс на открытость, чтобы знания о том какие уязвимости умеет детектировать MaxPatrol 8 / MaxPatrol VM были доступны в виде открытого фида. Хотя бы в виде одного только набора CVE идентификаторов. А если бы целиком правила детектирования уязвимостей открыли, вот это было бы реально круто! 😊

Вчера на PHDays 12 посетил "тайную комнату", в которой показывали продукты PT

Вчера на PHDays 12 посетил тайную комнату, в которой показывали продукты PTВчера на PHDays 12 посетил тайную комнату, в которой показывали продукты PTВчера на PHDays 12 посетил тайную комнату, в которой показывали продукты PTВчера на PHDays 12 посетил тайную комнату, в которой показывали продукты PTВчера на PHDays 12 посетил тайную комнату, в которой показывали продукты PTВчера на PHDays 12 посетил тайную комнату, в которой показывали продукты PT

Вчера на PHDays 12 посетил "тайную комнату", в которой показывали продукты PT. Приятно пообщались про MaxPatrol VM, в основном в части реализации оценки критичности уязвимостей по методике ФСТЭК.

Сейчас это реализовано через PDQL запросы, в которые добавили математические функции. Есть 2 варианта:

1. Через активы и группы. За счёт группы можно показать находится ли хост в DMZ, либо внутри. Но если с этим бардак и опубликованные активы могут находиться в произвольных сетках, то тут уж сами виноваты. 😏
2. Через пользовательские поля в карточке уязвимости. Практически ручной способ.

Основная проблема в CVSS. Методика требует "расчета базовых, временных и контекстных метрик". Базовые есть в NVD/БДУ. Временные иногда предоставляет вендор или их можно пробовать генерить. Контекстных по определению готовых нет и генерить их сложно. Поэтому, строго говоря, требования методики по учёту CVSS в MaxPatrol VM пока не реализуются в полной мере.

Средства Детектирования Уязвимостей Инфраструктуры (СДУИ)

Средства Детектирования Уязвимостей Инфраструктуры (СДУИ).

1. Средства Детектирования Уязвимостей Инфраструктуры (СДУИ)

Позволяют детектировать известные уязвимости CVE/БДУ и мисконфигурации CIS/CCE для инфраструктурных активов. Для сбора информации об активах может использоваться установка агентов, активное сетевое сканирование, интеграция с системами инвентаризации, перехват сетевого трафика. Анализируемые объекты включают операционные системы, различные программные продукты, сетевые устройства, контейнеры и базовые образы.

Positive Technologies - MaxPatrol 8, XSpider, MaxPatrol VM. Специализированные продукты для детектирования уязвимостей и мисконфигураций. Очень большая база детектов: Windows, Linux/Unix, сетевое оборудование, виртуализация, СУБД, веб-сервера, сервера веб-приложений, ERP системы, АСУ ТП. MaxPatrol 8 развивается с 2009 г., привязан к Windows (сервер, клиент). XSpider - урезанная версия MaxPatrol 8, сканирование с аутентификацией поддерживается только для Windows хостов, остальное только без аутентификации. MaxPatrol VM представлен в 2020 г., содержит расширенные возможности по работе с активами и уязвимостями, а также позволяет контролировать процесс их устранения, но имеет несколько меньшую базу детектов по сравнению с MaxPatrol 8.

АЛТЭКС-СОФТ - RedCheck. Специализированный продукт для детектирования уязвимостей и мисконфигураций. Большая база детектов: Windows, Linux/Unix, сетевое оборудование, виртуализация, СУБД, веб-сервера, сервера веб-приложений, АСУ ТП. Позволяет проводить комплексный аудит безопасности для образов и Docker-контейнеров, а также Kubernetes. Поддерживает сканирование с аутентификацией и без. Имеет возможности по приоритизации уязвимостей и контролю их устранения. Является OVAL-совместимым продуктом, позволяет использовать сторонний OVAL-контент для детектов.

НПО «Эшелон» - Сканер-ВС. Linux дистрибутив содержащий утилиты для решения задач анализа защищённости, в том числе сетевой сканер уязвимостей. Для детекта уязвимостей в Сканер-ВС версии 5 и более ранних использовался движок СПО проекта OpenVAS. Начиная с версии 6 Сканер-ВС содержит локальную обновляемую базу уязвимостей и собственный движок на Go, который ищет в этой базе по данным о системах.

Фродекс - Vulns. io VM, облачный API. Специализированные продукты для детектирования уязвимостей. Vulns. io VM может сканировать Windows, Linux (большой набор, в т.ч. сертифицированные дистрибутивы), сетевое оборудования, Docker-контейнеры и реестры контейнеров. Сканирование в агентном и безагентном режиме. Может работать на российских Linux дистрибутивах. Облачный API позволяет детектировать уязвимости "по запросу" на основе имеющейся инвентаризационной информации о хостах/контейнерах, например по данным из CMDB или SIEM.

Газинформсервис - Efros Config Inspector. Продукт для контроля конфигураций и состояний IT-активов имеющий, кроме прочего, функциональность по детекту уязвимостей. Позволяет детектировать уязвимости для большой номенклатуры сетевых устройств, Linux, Windows, систем виртуализации.

Kaspersky - Security Center. Продукт для управления безопасностью IT-инфраструктуры с дополнительной функциональностью по детекту уязвимостей на Windows хостах.

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

Картинка "Средства Детектирования Уязвимостей Инфраструктуры (СДУИ)" в рамках проекта карты российских около-VM-ных вендоров

Картинка Средства Детектирования Уязвимостей Инфраструктуры (СДУИ) в рамках проекта карты российских около-VM-ных вендоров

Картинка "Средства Детектирования Уязвимостей Инфраструктуры (СДУИ)" в рамках проекта карты российских около-VM-ных вендоров.

Помимо логотипов добавил краткие характеристики благодаря каким продуктам каждый из вендоров попал в категорию. Характеристику не нужно воспринимать как описание всех особенностей и возможностей продукта! Тем более не стоит сравнивать продукты между собой только на основе этой характеристики. Если расписывать как каждый продукт детектирует уязвимости, какие именно системы в какой степени поддерживает, какие уникальные проверки и фичи реализует, то по каждому можно книгу написать, а то и не одну. Оставим это маркетологам уважаемых вендоров. 🙂 Здесь задача была другая.

Если какого-то вендора забыл в этой категории или есть вопросы по характеристикам, пишите в личку - обсудим, добавлю/поправлю.