Архив рубрики: Уязвимость

Я являюсь большим сторонником использования статьи 274.1 УК РФ (ч.3 нарушение правил эксплуатации КИИ) в качестве ультимативного аргумента в разговорах об устранении уязвимостей инфраструктуры

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

Я являюсь большим сторонником использования статьи 274.1 УК РФ (ч.3 нарушение правил эксплуатации КИИ) в качестве ультимативного аргумента в разговорах об устранении уязвимостей инфраструктуры

Я являюсь большим сторонником использования статьи 274.1 УК РФ (ч.3 нарушение правил эксплуатации КИИ) в качестве ультимативного аргумента в разговорах об устранении уязвимостей инфраструктуры. Не стоит начинать любой разговор с "давай быстро патчься, а то посадят 😡". Достаточно ненавязчиво упомянуть, что такая статья существует. И зачем под этой статьёй ходить, если можно пропатчиться и спать спокойно. 🤷‍♂️😉

Эту статью хотят обновить:

🔹 Довольно размытый "вред КИИ" хотят уточнить как "уничтожение, блокирование, модификация или копирование информации в КИИ".

🔹 Добавят освобождение от уголовной ответственности, тем, кто "активно способствовал раскрытию и расследованию преступления". Возможно, в том числе тем, кто первый расскажет про грешки коллег. 😉

🔹 Добавят аналогичную статью в КоАП РФ, если нарушение не содержит признаков преступления. Будут штрафовать граждан от 5 до 10 тыс. р., должностных лиц от 10 до 50 тыс. р., юрлица от 100 до 500 тыс. р.

Если отвлечься от недавно принятой методики и поразмышлять, каким образом следовало бы определять успешность прохождения Анализа Защищённости (АЗ)?

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

Если отвлечься от недавно принятой методики и поразмышлять, каким образом следовало бы определять успешность прохождения Анализа Защищённости (АЗ)?

Если отвлечься от недавно принятой методики и поразмышлять, каким образом следовало бы определять успешность прохождения Анализа Защищённости (АЗ)? Понимая под АЗ детектирование уязвимостей в инфраструктуре организации третьей стороной. Для исполнителя критерии успеха: найти максимум уязвимостей с минимумом FP и FN. А для заказчика? 🤔 Обычно для него успехом считают отсутствие обнаруженных критичных уязвимостей. А если такие есть - их нужно срочно устранить или доказать, что они некритичные. 👌

Однако организациям без работающего VM-процесса такое разовое латание дыр не особо поможет - через полгода в инфре снова будет адище. 😈 А организациям с работающим VM-процессом требование устранять уязвимости в пожарном режиме, игнорируя SLA по существующим задачам на устранение, внесёт неразбериху и может сломать VM-процесс. 🤷‍♂️

Имхо, по-хорошему, АЗ должен проверять не текущее состояние инфры (постоянно меняющееся), а состояние VM-процесса. С соответствующими критериями успеха. 😉

У Security Vision вышла новая версия Vulnerability Scanner

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

У Security Vision вышла новая версия Vulnerability ScannerУ Security Vision вышла новая версия Vulnerability ScannerУ Security Vision вышла новая версия Vulnerability ScannerУ Security Vision вышла новая версия Vulnerability Scanner

У Security Vision вышла новая версия Vulnerability Scanner. Прошлый релиз был в сентябре-октябре.

🔹 Реализовали построение графа достижимости уязвимостей на основе сетевой топологии инфраструктуры.

🔹 Улучшили карточки уязвимостей: добавили оценку вероятности эксплуатации (EPSS), данные об обнаружении уязвимых систем в публичном интернете (Shodan CVEDB и тренд по регистрации хостов в Shodan; отображается в тегах, как и EPSS), рекомендации по устранению уязвимостей от НКЦКИ.

🔹 Реализовали динамические группы активов на основе заданных критериев (типа ОС, версии, наличия уязвимостей, баннеров сервисов и т.д.).

Также добавили расчёт рекомендованных сроков устранения по методике оценки уровня критичности ФСТЭК (от 30.05.2025), улучшили экспертизу (расширили BlackBox, поддержали WMI-сканы Windows, Gentoo Linux, Modbus, устройства Palo Alto Networks), переработали управление сканами и журнал сканов.

Palo Alto Networks подробно пишут про RCE-уязвимость в трёх open-source AI/ML-проектах на Python

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

Palo Alto Networks подробно пишут про RCE-уязвимость в трёх open-source AI/ML-проектах на Python

Palo Alto Networks подробно пишут про RCE-уязвимость в трёх open-source AI/ML-проектах на Python. Уязвимость вызвана использованием библиотеки Hydra (разрабатывается экстремистской компанией Meta) для загрузки конфигураций из метаданных модели. Злоумышленник может внедрять произвольный код в метаданные модели, который будет автоматически выполнен в момент загрузки модифицированной модели уязвимыми проектами:

🔻 NeMo - фреймворк на базе PyTorch, разработан NVIDIA. CVE-2025-23304 исправлена в версии 2.3.2.

🔻 Uni2TS - библиотека PyTorch, используемая в Morai от Salesforce - foundation‑модели для анализа временных рядов. CVE-2026-22584 исправлена 31 июля 2025 года.

🔻 FlexTok - фреймворк на Python, позволяющий AI/ML‑моделям обрабатывать изображения; разработан исследователями Apple и VILAB@EPFL. Уязвимость исправлена без CVE в июне 2025 года.

👾 Признаков эксплуатации вживую пока нет.

Январский Microsoft Patch Tuesday

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

Январский Microsoft Patch Tuesday

Январский Microsoft Patch Tuesday. Всего 114 уязвимостей, в два раза больше, чем в декабре. Есть одна уязвимость с признаком эксплуатации вживую:

🔻 InfDisc - Desktop Window Manager (CVE-2026-20805)

Также есть две уязвимости с публичными эксплоитами:

🔸 RCE - Windows Deployment Services (CVE-2026-0386)
🔸 EoP - Windows Agere Soft Modem Driver (CVE-2023-31096)

Из остальных уязвимостей можно выделить:

🔹 RCE - Microsoft Office (CVE-2026-20952, CVE-2026-20953), Windows NTFS (CVE-2026-20840, CVE-2026-20922)
🔹 EoP - Desktop Windows Manager (CVE-2026-20871), Windows Virtualization-Based Security (VBS) Enclave (CVE-2026-20876)
🔹 SFB - Secure Boot Certificate Expiration (CVE-2026-21265)

Отдельно хотелось бы выделить уязвимость, зарепорченную Positive Technologies:

🟥 EoP - Windows Telephony Service (CVE-2026-20931)

🗒 Полный отчёт Vulristics

Прочитал вчера забавную статью на тему, которую я уже поднимал в канале - уход Cisco с Vulnerability Management рынка

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

Прочитал вчера забавную статью на тему, которую я уже поднимал в канале - уход Cisco с Vulnerability Management рынка

Прочитал вчера забавную статью на тему, которую я уже поднимал в канале - уход Cisco с Vulnerability Management рынка. Автор статьи предполагает, что менеджмент Cisco могли купить Kenna как инструмент для детектирования уязвимостей. Т.е. даже в лендинг не заглядывая. 😅 Ну, сомнительно. 😏

Далее автор рассуждает, почему "legacy-вендоры" (Tenable, Qualys, Rapid7) уже 20+ лет в топе VM-рынка, связывая это с лучшим детектированием уязвимостей в legacy-системах (Windows 2000, Server 2008 и т.п.). Как будто, кому-то интересен полный список уязвимостей в EoL-системах, для которых патчи не выпускаются и с которых можно только мигрировать. 😅 Аргумент, что смена цифр в отчётах при смене VM-вендора так уж критична, тоже неубедителен. 😏

Имхо, реальная причина неизменности лидеров VM - ниша не sexy. 🤷‍♂️ Бесконечная пахота, связанная с детектированием ВСЕХ IT/OT-активов, получением инфы обо ВСЕХ уязвимостях в них и написанием правил детектирования. Нет халявы - мало кто туда идёт. 😉

В самом конце прошлого года, 30 декабря, был опубликован приказ ФСБ № 554 от 26 декабря, устанавливающий требования к средствам противодействия компьютерным атакам (КА) на КИИ, среди которых есть средства предупреждения КА - фактически средства Непрерывного Управления Экспозициями с Учётом Угроз (CTEM)

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

В самом конце прошлого года, 30 декабря, был опубликован приказ ФСБ № 554 от 26 декабря, устанавливающий требования к средствам противодействия компьютерным атакам (КА) на КИИ, среди которых есть средства предупреждения КА - фактически средства Непрерывного Управления Экспозициями с Учётом Угроз (CTEM)

В самом конце прошлого года, 30 декабря, был опубликован приказ ФСБ № 554 от 26 декабря, устанавливающий требования к средствам противодействия компьютерным атакам (КА) на КИИ, среди которых есть средства предупреждения КА - фактически средства Непрерывного Управления Экспозициями с Учётом Угроз (CTEM). По сравнению с приказом № 196 (06.05.2019), требования стали яснее и лаконичнее. 👍

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

Помимо уязвимостей и мисконфигов необходимо собирать (п.14) инфу об инструментах атак, тактиках и техниках, малварях, IOC-и, репутацию IP/доменов/адресов email, C&C и ботнетах и т.д. Все сведения должны (п.15) агрегироваться, коррелироваться и визуализироваться в форме графов.

Есть требования к поддержке актуальности данных и возможности интеграций.