Пришёл новогодний подарок от АЛТЭКС-СОФТ. В коробке сладости. В конверте тоже шоколадка. Маленькая коробочка это "Умный датчик протечки" от Roximo. В чехольчике дождевик.
Очень неожиданно и приятно. Люблю сладкое. 😊 Спасибо большое, коллеги!
С наступающим! 🎄
Результаты сканирования RedCheck и ScanOVAL для Windows хостов. Есть коммерческий VM-продукт RedCheck от АЛТЭКС-СОФТ и бесплатный локальный сканер уязвимостей ScanOVAL от ФСТЭК, который также использует контент от АЛТЭКС-СОФТ. Было интересно посмотреть, а есть ли какая-то разница в результатах сканирования. Возможно какая-нибудь разница в контенте или в работе движка. Сравнение отчетов по CVE-шкам для нескольких тестовых Windows хостов с разной конфигурацией подтвердило: разницы в результатах сканирования нет, совпадение по 100% CVE. Так что, если считать ScanOVAL эталонным сканером, то RedCheck будет полностью соответствовать этому эталону. Уточнение: при сканировании RedCheck-ом использовался транспорт WinRM.
Про RedCheck с web-интерфейсом и агентное сканирование Windows. Занимался на днях разворачиванием и тестированием RedCheck‑а. В принципе всё норм. Единственное, что при установке с Web-интерфейсом и Rest API требуется выполнить довольно много ручных операций:
1. Установка СУБД и создание пользователя
2. Установка Web-сервера IIS
3. Установка Microsoft .NET Framework
4. Установка Microsoft .NET Core
5. Установка серверного компонента
6. Установка консоли управления (пользовательского интерфейса)
7. Включение возможности Windows-авторизации*
8. Включение обработки HTTPS-соединений*
9. Установка службы синхронизации
10. Установка службы сканирования
Кажется, что большую часть операций можно было бы засунуть в один инсталлер. Но понятное дело, что таких доработок делать не будут, т.к. у АЛТЭКС-СОФТа сейчас в первую очередь стоит задача миграции на Linux. В целом, руководство по установке понятное и подробное. Только в одном месте была проблема с ошибкой в PowerShell-скрипте, но надеюсь поправят. Инсталлеры самих компонентов RedCheck удобные, по сути жмёшь "далее-далее". Часть операций (со *) я пропустил, т.к. для теста это не требовалось.
Теперь про агентное сканирование. Это вообще так себе термин, потому что под ним можно понимать разное:
1. Ставишь агент на таргет-хост, агент сам подключается к серверу (облачному или on-prem) и либо сам отдаёт в него какие-то данные для анализа, либо забирает у него какие-то задачки на выполнение и отдаёт результаты. Профит, что вообще не нужно париться учётками и тем доступен ли сейчас таргет-хост в сети для сканирования или нет (в первую очередь ноутбуков касается). Так работает Qualys, Tenable, Defender for Endpoint.
2. Ставишь агент на таргет-хост, агент сам ничего не делает, но когда к нему подключается сервер, то он делает аутентификацию через этого агента с использованием некоторых внутренних сертификатов. Также профит к том, что не нужно париться доменными учётками и их возможными утечками. Так работает Scan Assistant от Rapid7.
3. Ставишь агент на таргет-хост, агент сам ничего не делает, но когда к нему подключается сервер, то аутентификация проходит через локальную учётку хоста или доменную учётку. В этом случае по сути просто реализуется альтернатива традиционным безагентным транспортам WMI и WinRM.
И вот в RedCheck реализуется именно третий тип агентного сканирования. Позиционируется он так:
"Агент сканирования – компонент RedCheck, предназначенный для сканирования хостов, ограниченных политикой ИБ организации (например, запрет или ограничение использования WMI, WinRM, отсутствие возможности использовать УЗ администратора), а также для обеспечения быстродействия и повышенной надёжности сканирования. Данный компонент работает только по запросу от сервера сканирования в рамках назначенной задачи аудита."
Плюсом тут идёт быстрота, экономия канала и максимальная функциональность проверок. Сканирование идёт от имени Системы. Но для подключения учётка (локальная или доменная) всё равно нужна. Эта учётка может не иметь права администратора на хосте, но она должна быть в группе REDCHECK_ADMINS. То есть риски компрометации такой учётки будут ниже, но было бы удобнее, если бы она вовсе не требовалась. С другой стороны, в таком случае появлялись бы вопросы к процедуре аутентификации сервера на таргет-хосте с агентом, всё-таки порт агента наружу выставлен и это теоретически возможный вектор атаки. Процесс аутентификации по учётке всё-таки проще и прозрачнее. В общем, здесь вопрос спорный. 🙂 Ну и, независимо от способа аутентификации, просканировать с помощью такого "транспортного" агента можно будет только те хосты, до которых мы сможем дотянуться непосредственно во время выполнения задачи сканирования, т.е. основная проблема безагентных сканов остаётся.
Поэтому имейте в виду возможные варианты реализации агентного сканирования на уязвимости и заранее задавайте вопросы VM-вендорам. 😉
Разбираю ответы на мои вопросы с эфира 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-вендоров это тоже самостоятельно не сделает. Но если мы объединимся под крышей того же БДУ ФСТЭК, мы теоретически сможем собирать базу проверенных обновлений". Причем более полном виде, чем это есть сейчас в БДУ. Очень хотелось бы, чтобы из этой идеи что-то получилось. 🙏
Уточнение по предоставлению доступа к базе детектов уязвимостей от АЛТЭКС-СОФТ (RedCheck)
Компания дает возможность выгрузки ОVAL feed-ов, используемых для детекта уязвимостей в RedCheck, на следующих условиях:
1. Доступ предоставляется крупным заказчикам и частным исследователям, не аффилированным с конкурентами. Быть клиентом необязательно.
2. Доступ предоставляется для запрашиваемых платформ.
3. Доступ предоставляется на некоторый оговоренный промежуток времени.
4. Доступ предоставляется при условии заключения соглашения на запрещение коммерческого использования, что не запрещает публикацию, критику и сравнение с конкурентами в исследовательских целях.
При этом фиды АЛТЭКС-СОФТ, которые поддерживаются в рамках проекта ScanOVAL ФСТЭК полностью открыты и фактически доступны для изучения.
Спасибо большое Сергею Уздемиру за уточнение! Конкуренция на рынке имеет место и понятно, что есть справедливые опасения. Хотя, имхо, держать такую информацию в секрете довольно бесполезно, т.к. кому надо, тот доступ к ней всё равно получит тем или иным способом, а честное исследование ради общей пользы это усложняет.
Если кто-то ещё из представителей VM-вендоров хочет добавить уточнения по своей позиции — пишите в личку, всегда выкладываю без проблем. 🙂
Разбираю ответы на мои вопросы с эфира AM Live по Vulnerability Management‑у. Часть 1/3. Доступность баз детектов уязвимостей для анализа.
Вопрос был такой:
> 1. Вы предоставляете информацию об уязвимостях (идентификаторы CVE, БДУ), которые может детектировать ваше VM-решение, чтобы клиенты (текущие и потенциальные) могли оценить полноту базы детектов вашего VM-решения?
Зачем я задавал этот вопрос? Хотелось бы делать сравнения отечественных средств детектирования уязвимостей, также как я делал сравнения для Nessus и OpenVAS. Но тут проблема — нет публичных данных, перечней детектируемых CVE-шек для сравнения.
Вопрос задали и на него начали отвечать в 1:00:38:
"Есть у нас вопрос от Александра Леонова, как раз в тему. А насколько вы предоставляете информацию об уязвимостях, которые ваше решение детектирует? Т.е., проще говоря, ваша база данных уязвимостей…"
Вопрос задан достаточно точно, но не полностью, т.к. сразу не обозначена цель для чего это нужно — оценка полноты базы знаний об уязвимостях. Это дало уважаемым представителям VM-вендоров пространство для маневра. 😉
Positive Technologies: "В нашем решении в VM‑е можно с помощью фильтра вывести все уязвимости, которые есть. Если не ошибаюсь, их сейчас там около 100.000, близко к этому. И в режиме real time можно посмотреть какие есть, можно точечно уязвимость проверить. Поэтому никаких секретов в этом нет."
Т.е. список уязвимостей получить можно, если у вас есть приобретенное решение MaxPatrol VM. Или, возможно, если вы запросили эту информацию в ходе пилотного проекта. Какого-то публично доступного файла с детектируемыми CVE-шками нет.
АЛТЭКС-СОФТ: "У нас собственный репозиторий уязвимостей, который могут смотреть все пользователи мира. Наша база данных сканера доступна не только пользователям продукта, но и любому человеку".
Подчеркивается, что одно дело доступность для клиентов, другое публичная доступность. И для АЛТЭКС-СОФТ это действительно в большей степени справедливо — есть поисковый интерфейс OVAL репозитория. В вебинтерфейсе видны уязвимости и их идентификаторы. Но какой-то возможности выгрузить всё для изучения ведь там тоже нет. Только если сделать робота, который всё это сграбит через веб-интерфейс.
Эшелон: "У нас консолидированная база уязвимостей, можно проверить наличие любой уязвимости, которая только вышла. Обновления ежедневно".
Список уязвимостей Сканер-ВС 6 доступен для клиентов, но не является доступным публично. В случае Эшелона дать список всех детектируемых уязвимостей сложно, т.к. для детекта используется поиск по базе. Допустим VM-вендор взял NVD и ищет в ней по продуктовым cpe-идентификаторам. Спроси его: какие он уязвимости может детектить? Да он сам не знает. В принципе всё, что в NVD есть может в каком-то случае найтись. Правда не любые cpe могут прийти на вход от средства инвентаризации. Но поиск может идти не только по cpe. Поэтому получить перечень потенциально детектируемых уязвимостей затруднительно.
Дальше были попытки вывернуть обсуждение в сторону некоторого общего процесса обмена данными по детектируемым уязвимостям между VM-вендорами, но тщетно. Конечно VM-вендорам обмениваться такими данными смысла нет.
Хорошо, что вопрос взяли в обсуждение. Плохо, что не задали четко в лоб: "где ваши публичные данные о детектируемых уязвимостях, доступные для стороннего анализа?" Чтобы получить ответы: "да вот они" или "их нет и вот почему". 🙂 Имхо, основная причина почему их нет в опасениях, что публично доступная информация о НЕдетектируемых уязвимостях может использоваться в маркетинговых бэтл-картах конкурентов. И зачем так делать и дискутировать о возможностях детектирования разных решений, если можно не делать. 😉 Хотя для развития качества детектирования уязвимостей это было бы крайне полезно.
Пока спасение утопающих — дело рук самих утопающих. Запрашивайте данные и делайте сравнение баз детектируемых уязвимостей непосредственно в ходе пилотных проектов. Обращайтесь или используйте мои наработки в проекте VulnKBdiff.
CIS OVAL Repository съехал на GitHub. Обнаружил, что в феврале этого года CIS настроили редирект с oval.cisecurity.org на github.com/CISecurity/OVALRepo. И это так себе новость, т.к. похоже проект окончательно загнулся и CIS утратили к нему интерес. По случаю хочется сделать небольшой экскурс в историю.
Начиная с 2005 года, развитием OVAL (Open Vulnerability and Assessment Language) занималась корпорация MITRE. Как артефакт тех времен остался сайт https://oval.mitre.org/. Там была подробная адекватная документация. Был открытый интерпретатор для OVAL (OVALdi). Был реестр совместимых продуктов. Одним из этих совместимых продуктов там значится сторонний OVAL репозиторий Positive Technologies (ныне не работает, можно в архиве глянуть), я приложил к нему руку. 😉 Ещё прикольная строчка это ALTX-SOFT RedCheck как OVAL-ный сканер.
Ещё там был центральный репозиторий, в который можно было контрибьютить OVAL контент. А компаниям, которые больше всех этим занимались, давали Top Contributor Award. Можно посмотреть, что с 2012 года до 2015 года топовым контрибьютором был наш отечественный ALTX-SOFT.
В 2015 в MITRE что-то произошло. Видимо что-то связанное с финансированием. Всю эту OVAL-ную тему начали резко сворачивать. Разработчики разбежались. Сам стандарт ушел в NIST и кое-как поддерживается теперь в рамках SCAP. А центральный репозиторий отдали в CIS (Center for Internet Security). Веб-репозиторий кое-как повторили. Но на этом всё и закончилось. Какого-то развития от CIS больше не было. Даже Top Contributor Award не восстановили. И вот сейчас даже веб-страницы OVAL Repostory убрали с сайта CIS, сделали редирект на GitHub. И на сайте CIS‑а упоминания проекта OVAL Repostory больше нет. 🤷♂️
А в самом репозитории на GitHub практически нет свежих коммитов. Какие-то коммиты есть только по дефинишенам для уязвимостей. Но, например, более-менее массово уязвимости Windows добавляли последний раз в июне прошлого года.
Почему загнулся центральный репозиторий OVAL контента MITRE/CIS?
1. Пока проект был в MITRE он был достаточно живой. Очевидно потому, что были люди, которые работали над ним на фулл-тайм за гос. финансирование. Как минимум, они неплохо драйвили работу с комьюнити, минутки встреч OVAL Board было интересно почитать.
2. CIS в принципе были мало заинтересованы в этом проекте. Основное у них это CIS Benchmarks и CIS Controls. Да, они используют OVAL-контент для проверок конфигураций Windows хостов в CIS CAT, но и только.
3. Vulnerability Management вендоры не заинтересованы контрибьютить свои детекты уязвимостей. Даже если они у них есть в виде OVAL. Да, для части вендоров интересно было получать Top Contributor Award и использовать это в маркетинге. Но и они в основном контрибьютили не детекты уязвимостей, а детекты установки софтов. Зачем отдавать в открытый доступ то, что могут использовать другие VM-вендоры?
4. Вендоры ОС теоретически могли бы отдавать свой OVAL-контент, но их к этому не обязывали. А генерить полностью свой контент проще чем реюзать существующие объекты в общем репозитории: убирать дубли, разрешать конфликты в описании и т.п. Да и вендоры ОС без внешней стимуляции не особо стремились поддерживать OVAL контент. Взять Microsoft. Когда была программа FDCC/USGCB по контролю инфраструктуры федеральных агентств, они выпускали свой OVAL/SCAP контент. А как только программа прекратилась, перестали.
Так что если наши регуляторы захотят повторить что-то подобное, лучше сразу продумать мотивацию всех участников. 😉