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

Эффективная защита КИИ, часть 1

Эффективная защита КИИ, часть 1. Посмотрел вебинар компании К2 Кибербезопасность «Миссия выполнима: как эффективно защитить КИИ». В основном там было в контексте АСУ ТП, но проблемы вполне характерны и для более привычных сфер КИИ, таких как, банки или связь (все сферы приведены в 187 ФЗ пункт 2.8)

Что вообще нужно сделать по безопасности КИИ:

🔻 Идентифицировать субъекты КИИ и обеспечить безопасность объектов КИИ (187-ФЗ, уголовная ответственность, срок до 10 лет для должностных лиц).
🔻 Создать специальные отделы по защите информации и перестать использовать западные СЗИ до 1 января 2025 (Указ Президента № 250, штраф до 100 000 руб.)
🔻 Перейти на отечественное ПО для КИИ до 1 января 2025 (Указ Президента № 166)
🔻 Перейти на доверенные ПАК до 1 января 2030 согласно правилам перехода (Постановление Правительства РФ № 1912)

Как прогресс по работам? По исследованию К2 Кибербезопасность 90% компаний приступили к выполнению требований 187-ФЗ, но завершили проекты по защите КИИ только 8%. Каждая 5-ая компания не успеет реализовать проекты к 2025 году. 🤷‍♂️

Что по инцидентам? 65000 кибератак нa КИИ в 2023 году. Рост за год на 7%. Больше всего атак (28%) связаны с эксплуатацией уязвимостей инфраструктуры.

Дальше на вебинаре рассматривали разные сложности.

Сложности с интеграцией различных решений

🔹 Общий срок проектирования систем защиты очень сильно сокращается, если решения от одного вендора (из одной экосистемы), включая интеграцию с общими системами ИБ, например, SIEM.

Сложности при обследовании объектов КИИ

🔹 Данные об объектах устарели или были не полностью собраны при обследовании. Рекомендуют собрать информацию об объектах АСУ ТП, о смежных системах, о готовности инженерной инфраструктуры, уточнить отраслевую специфику, организовать встречи с представителями технического блока.

Сложности с инженерной инфраструктурой

🔹 Инфраструктура не готова к внедрению средств защиты: нужно проложить СКС (структурированная кабельная система), в шкафах нет места для оборудования средств защиты, не хватает питания и охлаждения для оборудования средств защиты. Рекомендуют обследовать инженерную инфраструктуру для размещения оборудования средств защиты и заложить в сметы необходимое оборудование на этапе техно-рабочего проектирования.

🔹 В АСУ ТП используются устаревшие АРМ и серверы. Хосты работают на пределе возможностей. Дополнительная нагрузка в виде средств защиты может снизить производительность и время отклика. Рекомендуют сделать гибкую настройку средств защиты: настроить только базовые функции защиты, а дополнительные — отключить. Устаревшее оборудование лучше, по возможности, заменить.

🔹 Трудно сегментировать сеть (корпоративная и технологическая сети физически находятся в одной плоской сети, нет межсетевых экранов и маршрутизаторов ИЛИ ЗОКИИ находятся в единой сети с другими системами АСУ ТП). Рекомендуют выполнить физическое разделение корпоративной и технологической сетей, провести сегментацию технологической сети с учетом категорирования АСУ ТП (инвентаризировать оборудования АСУ ТП и перепроектировать сети).

В следующей части будет про сложности с настройкой, с персоналом и выбором подрядчика.

Upd. Вторая (заключительная) часть

Как СберКорус с помощью TS Solution с нуля выстраивали у себя VM-процесс на MaxPatrol VM (часть 3)

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

Как СберКорус с помощью TS Solution с нуля выстраивали у себя VM-процесс на MaxPatrol VM (часть 3). Завершаю серию постов про выступление Романа Журавлева из TS Solution и Никиты Аристова из СберКоруса на конференции СФЕРА Cybersecurity. В прошлый раз было про кастомные виджеты и прокачку MaxPatrol VM, а сейчас будет про планы СберКоруса на будущее.

Технические планы

🔸 В идеальной картине мира хотят получать в VM уязвимости из контейнеров. Тестируют PT Container Security.
🔸 Уязвимости из VM планируют передавать в Threat Intelligence. Там создастся репутационный список индикаторов компрометации, связанных с эксплуатацией уязвимостей. Этот список будет блокироваться на межсетевых экранах. Этот же список уйдёт в SOC для упрощения расследований. Уязвимости также планируют передавать в SOC (наличие некоторых уязвимостей это инцидент сам по себе и они должны мониториться 24/7 и оперативно исправляться).
🔸 Автоматизировать создание задач на ответственных в ITSM системах Jira и Naumen.
🔸 В SGRC передавать список активов и список уязвимостей на этих активах. В процессе пилотирования. Сейчас в MPVM нет функциональности по постановке задач, поэтому нужно решать это интеграциями.
🔸Хотят получать список активов из CMDB. Если актив есть в CMDB, помечаем в VM-е как легитимный. Если нет - разбираемся с Shadow IT. Также хотят обогащать активы CMDB техническими данными из VM-а.

После прикручивания интеграций к MaxPatrol VM в СберКорус могут смело сказать, что "Инвестиция нашего руководства в безопасность окупается. Продукт реально работает, на него завязано много процессов, которые делают много полезного и все счастливы, все улыбаются, даже наш коммерческий директор". 🙂

Q/A: Можно ли контролировать виртуализацию облачного провайдера (компания спрашивающего пострадала от эксплуатации такой уязвимости)? Конечно нет. По договору никто туда не пустит. [ На эту тему в КиберДуршлаге с Алексеем Лукацким было хорошо ].

Очень классное выступление, побольше бы таких! 👍 🙂

Как СберКорус с помощью TS Solution с нуля выстраивали у себя VM-процесс на MaxPatrol VM (часть 2)

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

Как СберКорус с помощью TS Solution с нуля выстраивали у себя VM-процесс на MaxPatrol VM (часть 2). Продолжаю отсматривать выступление Романа Журавлева из TS Solution и Никиты Аристова из СберКоруса на конференции СФЕРА Cybersecurity. В прошлый раз остановились на кастомных виджетах.

📊 Кастомные виджеты. Разработали около 50 кастомных виджетов, которые позволяют отслеживать процессы, и чуть больше 100 PDQL-запросов.

🔹 На скриншоте видны однотипные виджеты "Статистика по аудиту" для разных групп активов (ARM онлайн за 7 дней, ARM, VDI, Windows Серверы, Сетевое оборудование, 2 замазанные группы по принадлежности к системам). Возможные значения: "Аудит не проводился", "Аудит в течение 7 дней", "Аудит старше 7 дней".
🔹 Также виден виджет "Доля активов с неустраняемой уязвимостью" со значениями "Активы с устраняемыми уязвимостями" и "Активы с неустраняемыми уязвимостями".

🥄 Ложка дёгтя - непобеждённая проблема. При серьёзной нагрузке выяснилось, что не справляется база данных PostgreSQL. Полной победы за год не достигли, как временное решение в 4 раза увеличили ресурсы. 🤷‍♂️

🚙 Прокачка MaxPatrol VM

"MaxPatrol VM как метафорические Жигули. Свою базовую функцию он выполняет: активы ищет, уязвимости рассчитывает. Но дальнейший процесс [тюнинга] никогда не закончится. Его абсолютно точно есть куда развивать, у него много возможностей. Дальше будет как превратить Жигули в Мерседес, при том что Мерседес для каждой компании будет свой".

[ От себя скажу: полностью согласен. Vulnerability Management - это прежде всего процесс выстроенный с использованием какого-либо продукта. Считать, что купил продукт и всё само заведётся, а в компании сам собой появится рабочий процесс довольно наивно. Нужно работать, затачивать его под себя. С другой стороны, базовую функциональность по работе с активами, уязвимостями, аналитике тоже недооценивать не следует. Если она в продукте так себе, то будет классическое "мусор на входе - мусор на выходе". ]

🔻 Показали схему Security Gate по выводу продуктов на периметр, включающий проверки AppSec (проверка кода) и инфраструктурного VM-а. Про то, что эти 2 направления имеют пересекающиеся функции в рамках, например, DAST сканирования, я писал ранее.
🔻 "В MaxPatrol VM неплохой модуль BI (Business intelligence)". Считают покрытие сканированиями, покрытие СЗИ (антивирусы и EDR для Linux и Windows), динамику уязвимостей за неделю.
🔻 Контроль активов: контроль работы служб СЗИ (запущена и добавлена в автозапуск), контроль состава установленного ПО (нелегитимное, нежелательное), дубликаты активов, переустановки ОС, SSH (контроль перевода на аутентификацию по ключам), свободное место на жёстких дисках (выгружают за 5 минут).
🔻 Контроль пользователей: привязка администраторской УЗ к АРМy, контроль сеансовой работы под УЗ с правами администратора (контроль активных пользователей; админская учётка должна использоваться только для повышения привилегий, а не для постоянной работы), контроль нелегитимных прав локального администратора (завели резервную учётку или временная учётка стала постоянной), смена пароля после киберучений (для попавшихся на учебные фишинговые рассылки).
🔻 Инциденты ИБ ("MaxPatrol VM - это осколок от MaxPatrol SIEM, какие-то инциденты можно смотреть в VM-е"): сотрудник снял образ своего АРМ-а и развернул виртуальный АРМ из образа на своём личном ноутбуке и с него работал (проверка по ID установки и является ли хост виртуалкой), подключение по RDP в обход PAM (контроль коммерческого SOC).

Заключительная третья часть будет про планы по развитию VM-процесса в СберКорусе.

upd. Третья заключительная часть

Критическая уязвимость Remote Code Execution - PHP на Windows хостах (CVE-2024-4577) с публичным эксплоитом

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

Критическая уязвимость Remote Code Execution - PHP на Windows хостах (CVE-2024-4577) с публичным эксплоитом. CVSS 9.8. 6 июня разработчики PHP выпустили обновление для устранения RCE-уязвимости, которая связана с функцией преобразования кодировки Best-Fit в операционной системе Windows. Уязвимость позволяет неаутентифицированному злоумышленнику, выполняющему argument injection атаку, обойти защиту от старой активно эксплуатируемой RCE-уязвимости CVE-2012-1823 с помощью определенных последовательностей символов и выполнить произвольный код. Эксплоиты для уязвимости уже доступны на GitHub. Shadowserver Foundation отмечает активные сканирования, направленные на обнаружения уязвимых хостов. 👾

Уязвимость затрагивает все версии PHP, установленные в операционной системе Windows.

🔻 PHP 8.3 8.3.8
🔻 PHP 8.2 8.2.20
🔻 PHP 8.1 8.1.29 Версии PHP 8.0, PHP 7 и PHP 5 также уязвимы, но они уже в End-of-Life и не поддерживаются. 🤷‍♂️ Отдельно подчеркивается, что все инсталляции XAMPP также уязвимы по умолчанию. XAMPP - это популярная кроссплатформенная сборка локального веб-сервера, содержащая Apache, MariaDB, PHP, Perl и большое количество дополнительных библиотек. В случае, если обновление до актуальной версии PHP невозможно, исследователи из компании DEVCORE предлагают конфигурации для противодействия эксплуатации уязвимости. Однако эти рекомендации касаются инсталляций на Windows с определенными языковыми локалями (Traditional Chinese, Simplified Chinese, Japanese), для которых эксплуатация уязвимости была подтверждена. На других локалях из-за широкого спектра сценариев использования PHP в настоящее время невозможно полностью перечислить и исключить все потенциальные сценарии эксплуатации уязвимости. Поэтому пользователям рекомендуется провести комплексную оценку активов, проверить сценарии использования PHP и обновить PHP до последней версии.

Думаю о том, что пора бы уже обновить карту отечественных вендоров Средств Управления Уязвимостями (СУУ)

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

Думаю о том, что пора бы уже обновить карту отечественных вендоров Средств Управления Уязвимостями (СУУ). Какие изменения напрашиваются с прошлого года:

🔹 В R-Vision VM теперь есть свои детекты уязвимостей. Значит следует добавить это решение и в категорию СДУИ.

🔹 Также в СДУИ стоит добавить SolidLab VMS.

🔹 Логотип Фродекс стоит заменить на VulnsIO для большей информативности, т.к. в основном у них этот бренд используется для VM-а.

Если есть какие-то идеи по изменениям в карте (чего-то добавить, чего-то убрать, поменять описание и т.д.), пишите, пожалуйста, в личку. 🙂

Основная фича грядущего июньского релиза MaxPatrol VM 2.5 - новый сканер веб-приложений

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

Основная фича грядущего июньского релиза MaxPatrol VM 2.5 - новый сканер веб-приложений. И здесь речь не только о детектах для известных CVE уязвимостей, например, для Confluence или GitLab, которые, безусловно, очень важны для любого VM-продукта, о чём я уже писал ранее. Речь о полноценном DAST-сканере уязвимостей, с такой же функциональностью как в решениях PT BlackBox и PT AI.

Вообще вопрос о месте DAST-сканирования WEB-приложений дискуссионный. Этим нужно заниматься в рамках инфраструктурного VM-а или в рамках процессов AppSec-а? Рассмотрим аргументы.

Аргументы за AppSec:

🔻 Таргеты различаются. DAST-ом обычно сканят собственные разработки, а не чужие (коммерческие и опенсурсные) продукты. Если собственная разработка, значит AppSec.
🔻 Таски на исправление найденных уязвимостей летят в разработчиков, а не в админов. Опять же, разработка = AppSec.
🔻 Если же сканировались чужие продукты и при этом были найдены уязвимости, то по-хорошему нужно довести эту инфу до вендора и не попасть при этом под какие-нибудь юридические ограничения (анализ приложения может быть запрещён в лицензионном соглашении). Эти активности также более привычны AppSec-ам.
🔻 Одного DAST-а для полноценного анализа приложений всё равно не хватит, нужен SAST, IAST. Давайте не будем заниматься ерундой и будем анализировать приложения полноценно в рамках процессов AppSec.

Аргументы за инфраструктурный VM:

🔹 Вот сканируем мы хост и видим там веб-сервис (нашу разработку или не нашу - не суть важно). Почему бы не проверить его на ту же XSS-ку? Как-то глупо ограничивать себя только детектом CVE-шных уязвимостей. Тем более, что AppSec-и могут этот веб-сервис своими процессами вообще не покрывать, а мы может что-то массовыми сканами и продетектим.
🔹 Вот выстроили мы в рамках инфраструктурного VM-а процесс по поиску и исправлению известных уязвимостей. Почему бы не переиспользовать его и для web-уязвимостей? И там уязвимости, и там уязвимости. Удобно ведь будет работать со всеми уязвимостями в рамках одной единой системы, разве нет? 😏

В общем, есть аргументы у обеих сторон. В реальных организациях скорее это зависит от развития AppSec и VM отделов, кто кого подомнёт. 🙂 Моё мнение, что сканить веб-приложения DAST-ом должны и AppSec-и, и инфраструктурные VM-щики. Хуже не будет. А база для хранения продетектированных уязвимостей должна быть у них, в идеале, единой.

Но как бы ни выглядел итоговый процесс, его можно будет реализовать с помощью продуктов Positive Technologies. 😉

➡️ Более подробно о фичах нового MaxPatrol VM 2.5, включая сканирование веб-приложений, можно будет узнать на вебинаре 13 июня в 14:00. Регистрируйтесь!

Elevation of Privilege (Local Privilege Escalation) - Linux Kernel (CVE-2024-1086) добавили в CISA KEV

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

Elevation of Privilege (Local Privilege Escalation) - Linux Kernel (CVE-2024-1086) добавили в CISA KEV. Сама уязвимость относительно старая, январская. Я уже писал про неё в марте, когда вышел write-up и публичный эксплоит.

Несмотря на тривиальную эксплуатацию, запустил утилиту - получил рута, до недавнего времени признаков активной эксплуатации этой уязвимости не фиксировали. Что довольно странно, такой полезный эксплоит должен сразу попадать в инструментарий злоумышленников. Тут либо практическая эксплуатация всё же чем-то осложнена, либо использующие её злоумышленники не оставляли следов. 🤔

Как бы то ни было, 30 мая уязвимость добавили в CISA KEV, а значит факт использования её в атаках всё-таки был установлен. Но подробностей по атакам пока нет. Обратите внимание на эту уязвимость при обновлении Linux хостов.

Александр В. Леонов

Управление Уязвимостями и прочее