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

Что за зверь "Vulnerability Operation Center"?

Что за зверь Vulnerability Operation Center?

Что за зверь "Vulnerability Operation Center"? VOC - не самый распространённый термин, но на западе встречается. Одни компании (небольшие вендоры, такие как Hackuity, Patrowl, YOGOSHA) определяют его как платформу или утилиту для управления уязвимостями, которая имеет преимущества перед "традиционными VM-решениями". Другие (сервис-провайдеры, такие как Orange Cyberdefense и Davidson), определяют VOC как структурные подразделения организаций.

Между VOC и VM примерно такая же смысловая неразбериха, как была межу SOC и SIEM. 🙂 И я склонен разрешать её аналогичным образом. VOС - структурное подразделение организации, специалисты которого реализуют VM-процесс, используя одно или несколько VM-решений для детектирования, приоритизации и устранения уязвимостей (с одним решением удобнее 🙂). VM-процесс может быть выстроен, например, в соответствии с "Руководством по организации процесса управления уязвимостями в органе (организации)" ФСТЭК и расширен с учётом БОСПУУ. 😉

Мартовский выпуск "В тренде VM": уязвимости Microsoft, PAN-OS, СommuniGate и кто должен патчить хосты с развёрнутым прикладом

Мартовский выпуск "В тренде VM": уязвимости Microsoft, PAN-OS, СommuniGate и кто должен патчить хосты с развёрнутым прикладом.

📹 Ролик на VK Видео, RUTUBE, YouTube
🗞 Пост на Хабре
🗒 Дайджест на сайте PT

Содержание:

🔻 00:00 Вступление
🔻 00:41 Elevation of Privilege - Windows Ancillary Function Driver for WinSock (CVE-2025-21418)
🔻 01:22 Elevation of Privilege - Windows Storage (CVE-2025-21391)
🔻 02:04 Authentication Bypass - PAN-OS (CVE-2025-0108)
🔻 03:19 Remote Code Execution - CommuniGate Pro (BDU:2025-01331)
🔻 04:37 VM-ная загадка: кто должен патчить хосты с развёрнутым прикладом
🔻 07:21 Про дайджест трендовых уязвимостей

Кстати, продакшн нам делают ребята из brocast.team. Очень толковые и внимательные к деталям. 👍 Сложные приколюшечки типа 03:49 сами придумывают и реализуют. 😮 А склеечки какие аккуратненькие делают - ммм. Работать с ними одно удовольствие. 😇 Рекомендую!

Поздравляю всех подписчиц канала "Управление Уязвимостями и прочее" с праздником 8 марта!

Поздравляю всех подписчиц канала Управление Уязвимостями и прочее с праздником 8 марта!

Поздравляю всех подписчиц канала "Управление Уязвимостями и прочее" с праздником 8 марта! Пусть всё у вас всегда складывается самым наилучшим образом и в рабочем, и в личном!

Со сборкой детской теплицы без какого-либо мануала, кроме двух итоговых изображений на коробке и мотивирующих надписей на китайском, более-менее справился. 😅 Очень похоже на внедрение VM-процесса. Смотришь на то, как оно у других, пытаясь разобраться в неочевидных взаимосвязях, чтобы хоть как-то это у себя повторить. И с каждым шагом у тебя всё ломается и разъезжается в самых неожиданных местах. 😫 Плюс постоянные запоздалые озарения: "а, так вот для чего нужна была эта странная штука". 💡 Жаль только, что для её установки нужно всё разбирать и заново переделывать. 😓 Обилие лишних деталек по итогу тоже несколько смущает, но в целом норм. 😅 К высадке и ведению наблюдений готовы. 🙂

Обновление хостов с прикладом: альтернативное мнение

Обновление хостов с прикладом: альтернативное мнение

Обновление хостов с прикладом: альтернативное мнение. Пришёл комментарий от подписчика к VM-ной задачке про 2 подразделения и обновление хостов с развёрнутыми приложениями. С любезного разрешения выкладываю текст полностью. 🙂

"Имея опыт работы с обоих сторон ("общей инфры" и админа приклада — как раз того самого Postgres), хотел бы заметить следующее. Всё же обновлением ОС должна заниматься команда, которая заведует ОС и обще-инфраструктурными сервисами, крутящимися на хостах. А админы прикладного ПО — должны следить за своим ПО.

Но все вместе они — должны согласовывать свои действия.

На хосте, помимо условного постгреса, может крутиться много всякого другого. О чём "прикладные админы" могут знать, но не факт, что могут этим грамотно управлять и правильно оценить последствия обновления пакетов. Пример навскидку — на хосте наверняка будут установлены агенты систем мониторинга — как ИТ-шного, так и ИБ-шного. И передать на админов условного постгреса ответственность за обновление хоста со всем этим набором… А "прикладники" точно должны этим заниматься? 😊 Тогда как мимо линуксовых админов установка, настройка и эксплуатация всех этих дополнительных сервисов на хостах с прикладом точно не пройдёт.

По опыту банка, в котором я работал — хосты обновляли линуксовые админы, а "прикладные" — только тот приклад, который в их зоне ответственности. Пакеты, относящиеся к прикладу, ставились на hold сразу при установке приклада, и их обновление было невозможно при обновлении хоста.

Ну и само собой, обновления сначала выполнялись на тестовых средах, чтобы понять, не приедут ли какие-то обновы зависимостей, которые могут сломать приклад. Если не приедут — хост смело обновлялся отдельно, а приклад — отдельно. Если зависимости ломали приклад — либо пакеты зависимостей дополнительно замораживались, либо, если это ломало остальное обновление — обновление откладывалось до ̶л̶у̶ч̶ш̶и̶х̶ ̶в̶р̶е̶м̶ё̶н̶ тех пор, пока приклад не сможет это поддержать. В тестировании, само собой, участвовали обе команды — и "хостовая" и "прикладная". Но на проде, при использовании этой схемы, их работы по обновлению, по большей части происходили независимо."

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

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

В любом случае, главное, чтобы обновления ставились и уязвимости устранялись (желательно с соблюдением SLA). А как именно это происходит и чьими силами не так уж важно. 😉

VM-ная загадка: есть 2 подразделения

VM-ная загадка: есть 2 подразделения

VM-ная загадка: есть 2 подразделения. 🙂 В одном Linux-админы на золотые образы и харденинг заточенные, в другом IT-шники исключительно работой приклада озабоченные (например, PostgreSQL).

Кому из них регулярный патчинг Linux-хостов (ядро и пакеты) с этим развёрнутым прикладом поручишь?

Имхо, обновлением хостов должны заниматься те же сотрудники, что обслуживают приклад на этих хостах. Иначе они будут постоянно вешать проблемы с прикладом на команду, которая делала обновление ОС: "вы опять нам всё сломали". Пусть лучше сами полностью обновляются и тестируются. 😇

А если прикладники брать это на себя не захотят, можно намекнуть, что Linux-админы будут тогда катать обновления ОС без всякого тестирования. А за сбои крайними будут прикладники, т.к. сами на такую схему подписались. 😉

➡️ Кстати, 24 февраля стартует новый поток курса "VM от теории к практике", где мы и такие вопросы тоже обсуждаем. 🙂 А ещё есть моя статья про работу VM-щиком, если кто не видел.

Методические рекомендации ЦБ по управлению уязвимостями и пентестам

Методические рекомендации ЦБ по управлению уязвимостями и пентестам

Методические рекомендации ЦБ по управлению уязвимостями и пентестам. 21 января был утверждён документ "Методические рекомендации Банка России по проведению тестирования на проникновение и анализа уязвимостей информационной безопасности объектов информационной инфраструктуры организаций финансового рынка".

Документ на 21 страницу. Он содержит общие положения и рекомендации:

🔹 по проведению пентестов
🔹 по проведению анализа уязвимостей
🔹 по самостоятельному проведению этих работ и с привлечением сторонней организации
🔹 по информированию ЦБ о результатах работ (с формой отчёта)

В части Управления Уязвимостями наиболее важными видятся рекомендации:

🔻 3.7. проводить работы по анализу и устранению уязвимостей по руководству ФСТЭК по организации VM-процесса от 17.05.2023 ‼️
🔻 3.4. оценивать критичность уязвимостей по методике ФСТЭК от 28.10.2022
🔻 использовать сертифицированные ФСТЭК средства детектирования уязвимостей инфраструктуры 3.3. и исходного кода 3.5.

Итоги 2024 года

Итоги 2024 года

Итоги 2024 года. Вчера всем семейством делали традиционные печеньки. 😇

Для меня год был замечательный. Тяжести не ощущаю. Ощущаю только радость, удовлетворение и благодарность Создателю за всё. 🙏 Чего и всем желаю!

Много чего делал в этом году. Публичными результатами я делился в канале, о непубличных знают те, кому нужно. 😉 Были и направления, которые я подзабросил. Но и это я делал осознанно, исходя из понимания своих интересов, своевременности, полезности и ограниченности собственных ресурсов. 😌

Число подписчиков канала выросло за год с 3482 до 8200. В 2.3 раза! 😲 Я хоть и склоняюсь к тому, что в обозримом будущем Тележеньку ждёт эффективная блокировка, но очень рад, что все мы здесь сегодня собрались. 🙂 Спасибо вам всем! Подписывайтесь ещё на VK и вступайте там в группу.

➡️ Своими самыми важными материалами года считаю интервью про VM для CISOCLUB и GTD заметку про А6СПК. 😉

На следующий год ничего не загадываю. Пусть будет как будет. 😇