Обзор рынка Vulnerability Management систем от Anti-Malware: велика ли разница между "обычным сканером" и "VM-решением"?

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

Обзор рынка Vulnerability Management систем от Anti-Malware: велика ли разница между "обычным сканером" и "VM-решением"? Обзор вышел 27 января. Я естественно побежал его читать, так как и сам занимаюсь похожей темой.

Основное, что бросилось в глаза: а почему такой скромный набор решений?

Российские
Positive Technologies MaxPatrol VM
Фродекс VulnsIO VM

Зарубежные
Qualys VMDR
Tenable SC
Rapid7 Insight VM
Holm Security

Конечно, все эти решения могут быть в таком обзоре. Но почему только они? Почему среди российских нет АЛТЭКС-СОФТ RedCheck или НПО "Эшелон" Сканер-ВС. А среди зарубежных нет Greenbone GVM, SecPod SanerNow, Outpost24. Дело тут похоже в следующем. В 2020 на Anti-Malware вышел аналогичный обзор "Сканеры уязвимостей — обзор мирового и российского рынков". Значительная часть решений, которых нет в отчете по VM, есть в отчете по сканерам уязвимостей:

Российские
Positive Technologies MaxPatrol 8
Positive Technologies XSpider
АЛТЭКС-СОФТ RedCheck
АЛТЭКС-СОФТ/ФСТЭК ScanOVAL
НПО "Эшелон" Сканер-ВС
Профиль Защиты "Ревизор сети"

Зарубежные
Qualys Vulnerability Management
Tenable Nessus Professional
Tenable IO
Rapid7 Nexpose Vulnerability Scanner
F-Secure Radar
GFI LanGuard
Tripwire IP360
Skybox Vulnerability Control

Можно предположить, что раз продукты уже отнесли к сканерам, то в отчет по VM-решениям их решили не брать. Это последовательная позиция. Почему бы нет, хозяин-барин.

Но насколько такое разделение вообще оправдано?

В обзоре читаем:

"Резкий рост количества выявляемых брешей, необходимость их приоритизации и контроля за их устранением привели к появлению нового класса продуктов — VM (Vulnerability Management). Подобные комплексы не только имеют в своём составе сканер уязвимостей, но также позволяют расставлять приоритеты при устранении изъянов в зависимости от выбранных параметров и контролировать этот процесс в дальнейшем."

Ок, допустим есть такой параметр связанный с уязвимостью - CVSS (векторы и скоры). Любое решение для детектирования уязвимостей их показывает (ведь подтянуть их из NVD/БДУ тривиально) и чуть менее чем любое позволяет по ним фильтровать прямо в интерфейсе. При таком подходе любой сканер это VM-решение. Разве нет? 😉

Я, конечно, понимаю о чем тут речь. Об общем дашбордике со статистикой по уязвимостям и активам. Ну да, когда продукт может не только сканы отображать, но и как-то общую картину из них собирает это прикольно. Особенно если с динамикой. Но по сравнению с огромной проблемой именно детектирования уязвимостей это все сущая мелочь. Ну допустим нет дашбордика, выгрузите результаты и нарисуйте какие хотите дашборды в любой платформе для аналитики (ELK, Grafana, Splunk, Tableau). Или просто в специализированное решение экспортните (Faraday, Kenna), там автоматом всё разберется. Просто скриптиками попарсите наконец. Тем более это практически неизбежно в ситуации, когда ни одно решение не может покрыть детектами всю инфраструктуру целиком, придется как-то соотносить уязвимости из разных источников.

Обращать столько внимание на второстепенные функции типа дашбордов и интерфейса для приоритизации это все равно что при обсуждении автомобилей обращать внимания только на дворники. Делить все автомобили на те, у которых есть бескаркасные стеклоочистители и те, у которых их нет. Ну да, дворники это прикольно и важно. Дворники какие-то должны быть. И лучше чтобы они были хорошие, надежные. Но дворники же не должны быть определяющим фактором при оценке и выборе автомобиля! Если машина не ездит толком, то какая разница какие у неё там дворники. 🙃

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

Про дипломную работу, написанную ChatGPT

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

Про дипломную работу, написанную ChatGPT. Прочитал оригинальный тред biblikz (ссылку давать не буду, чтобы не рекламировать). Если кто-то слышал мельком новость и думает, что ChatGPT сам смог выдать структурированный осмысленный текст, который хотя бы издали был похож на дипломную работу, тот ошибается. Если кто-то думает, что студент использовал ChatGPT для развития собственных мыслей, что это какое-то совместное творчество человека и машины, тот тоже ошибается. Все гораздо проще и гнуснее.

1. Студент несколько раз пытался сдать своему научному руководителю сгенерированный ChatGPT текст как план дипломной бакалаврской работы "Анализ и совершенствование управления игровой организацией", принципиально не желая написать его нормально по методичке. "И на четвертый раз ломаю научницу, она присылает план моего диплома". План ему написали.
2. Чтобы получить введение, студент вводил в ChatGPT план диплома целиком (!) в качестве запроса, получал какой-то бред (потому что релевантный ответ на "это" получить нельзя), а потом переводил его яндекс-переводчиком.
3. Для теоретической части студент генерил текст в ChatGPT на тему "5 принципов менеджмента", а потом переводил это опять же яндекс-переводчиком.
4. Практическая часть это рерайт текста из чужого дипломного проекта про мясокомбинат. 😐
5. Проверку научного руководителя полученный текст не прошел, студент приводил текст до более-менее читаемого вида вручную и с помощью ChatGPT. Основной критерий, на который смотрели это уникальность текста по антиплагиату.
6. Отзывы студенту написали нормальные.
7. На защите диплома студент устроил клоунаду, его выгоняли из аудиториии, но в итоге трояк поставили.

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

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

Некоторые заметки по итогам митапа Яндекс-а

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

Некоторые заметки по итогам митапа Яндекс-а. Зафиксирую, чтобы не забылось. Для тех, кто не смотрел, полное видео уже доступно.

1. Прикольная тема из Яндекс Финтех про "одна команда - один Golden Image":

"У нас большой стек. У нас сервисы пишутся и на Kotlin, и на плюсах, и для разных языков мы используем разные Golden Image-ы. Но стараемся, чтобы внутри команды, которая пишет на одном фреймворке и на одном языке сформировался какой-то единый образ, который будет использоваться внутри этой команды. У нас есть набор этих золотых образов, которые используются конкретными командами. Все контейнеры, которые получаются мы пушим в наш registry. Вопрос сколько их сложный, т.к. у нас микросервисная архитектура и у нас очень много микросервисов."

➡️ Вопрос: Используете ли вы distroless образы в Банке, да и в Яндексе в целом, к примеру Google distroless, чтобы минимизировать поверхность атаки и уменьшить размер самих образов?
Ответ: нет, но очень хотим к этому прийти
➡️ Вопрос: Если не секрет, что у вас за базовый образ? Аstra Linux? 😉
Ответ: отвечу, что такой же как и во всем Яндексе )

Вполне возможно это секрет полишинеля на основе какого Linux-дистрибутива базовые образы в Яндексе делают, но я не знаю. Если кто знает - шепните в личку, любопытно. 😉

2. То, что Яндекс Финтеху комфортно в Яндекс Облаке это понятное дело. Но будет ли так же комфортно другим банкам и финтехам?

➡️Вопрос: Возвращаясь к сертификации банка в облаке по стандартам PCI DSS и ГОСТам. Я смогу запустить такой банк в я.облаке и получить содействие при прохождении аудита со стороны Команды облака или это единичный случай для «родственной» компании?
Ответ: Можно это получить как отдельную услугу в Облаке.
➡️ Вопрос: прям услуга Облака или рекомендованная внешняя команда?
Ответ: В Облаке есть архитекторы и premium support.

3. В Wildberries и Яндекс Финтех для организации привилегированного доступа к Linux-инфраструктуре используют Teleport. Почему именно его? Как минимум половина доклада команды Wildberries была про обоснование этого выбора. Очень подробно и убедительно. Единственное жаль, что тема в основном крутилась про то как безопасно дать доступ до нужных серверов и дать/не дать root-а, но не про хитрое ограничение прав пользователя на хосте. А это у Wildberries есть, т.к. Teleport у них сильно допиленный:

"Команда переписала админку Teleport-а полностью с нуля. Написала свой PAM-модуль, который учитывает роли, которые передаются телепортом при аутентификации и на основе этого настраивает sudo. Но мы сегодня про это подробно не рассказывали, потому что оно опять же не поместилось."

Про sudo тема интересная, будем ждать следующего раза. 🙂

SQL-инъекция в сетевых хранилищах QNAP (CVE-2022-27596)

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

SQL-инъекция в сетевых хранилищах QNAP (CVE-2022-27596)

SQL-инъекция в сетевых хранилищах QNAP (CVE-2022-27596). CVSS 9.8. До какого состояния докрутят эту SQLi сказать сложно, но угрозу конфиденциальности и целостности данных можно смело предположить. Нужно патчить. Хоть эксплоита и признаков эксплуатации вживую пока не видно.

QNAP это тайваньский вендор. В основном они выпускают NAS-ы (Network-attached storage) различного класса: от "для дома для семьи" до серьезных энтерпрайзных решений. Используют свои операционные системы QTS (для устройств попроще) и QuTS hero (для навороченных). Эти ОС и предлагается обновить на устройствах для исправления уязвимости.

NAS-ы это излюбленные мишени для ransomware. Во-первых, там хранятся ценные данные компаний. Во-вторых, их частенько выставляют прямо в Интернет. 🙃

Судя по тому, что у QNAP есть вполне актуальный русскоязычный сайт и активная группа в ВК, продаются они в России неплохо. А значит и в инфраструктуре вашей организации они вполне могут найтись. Дайте знать своим админам! 😉

Парень нашел "уязвимость" в VK и ему стали массово писать в личку заинтересованные девушки

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

Парень нашел "уязвимость" в VK и ему стали массово писать в личку заинтересованные девушки. 🙂 Этот забавный кейс я увидел в канале Standoff News. Технически там не очень интересно. Но как пример простой "уязвимости" для иллюстрации почему искать уязвимости это прикольно и как противостоять эксплуатации уязвимостей - вполне норм (студентам младших курсов, школьникам на профориентации т.п.).

В чем там было дело:

1. В VK пользователи могут видеть кто смотрел их сторисы (формат вертикальных публикаций, которые исчезают из ленты через 24 часа). В отличие от обычных сообщений в ленте, для которых видно только тех, кто полайкал.
2. В VK не было лимита на просмотр сторисов. Было возможно автоматически "просматривать" хоть миллионы чужих сторисов в день. (не конкретизируется как)
3. Было возможно массово получить идентификаторы пользователей из групп типа "любители котиков". (не конкретизируется как)
4. Было возможно автоматически получить сторисы для идентификаторов пользователей. (не конкретизируется как)

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

Далее конверсия: миллионы просмотренных сторисов -> десятки тысяч заходов от любопытных пользователей на страницу Накрутчика -> сотни сообщений от тех, кому совсем уж любопытно. Profit.

Вопросы, которые можно задать аудитории:
1. Что можно было бы предусмотреть на стороне VK, чтобы так было делать нельзя? Возможный ответ: установить лимиты, при превышении таймаут или показывать капчу.
2. Что ждет Накрутчика, когда это обнаружится? Возможный ответ: как минимум забанят профиль, т.к. автоматизация действий нарушает пользовательское соглашение.
*3. Как можно подвести действия Накрутчика под УК РФ? Возможный ответ: по факту это скрэпинг, можно в теории натянуть на 272 и 273.

После этого можно поставить риторический вопрос. Что лучше: сдать уязвимость в VK и получить $100/спасибо, или пытаться эксплуатировать и подставляться? Каждый сам для себя решает.

Программу мероприятия подкрутили, круглый стол убрали

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

Программу мероприятия подкрутили, круглый стол убрали. А жаль. 🙂 Но остальные доклады на месте.

Свести к минимуму непредсказуемый интерактивчик в текущей ситуации и правда выглядит весьма разумным решением. Мало ли что журналисты по итогам свободной дискуссии ИБшников могли себе додумать и нагенерить. Яндексу сейчас такое точно ни к чему. 🤫

Сканировать принтеры на уязвимости следует с осторожностью

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

Сканировать принтеры на уязвимости следует с осторожностью

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

Некоторые Vulnerability Management вендоры вообще не рекомендуют активно сканировать принтеры. Например, в #Tenable относят принтеры к "хрупким устройствам" ("fragile devices") и рекомендуют использовать для обнаружения уязвимостей на них пассивные детекторы. Т.е. перехватывать трафик и определять по нему версию устройств и связанные уязвимости. Продвигают этим Nessus Network Monitor (NNM), бывший Passive Vulnerability Scanner (PVS), но тем не менее.

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