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

Разбор VM-ной вакансии от R-Vision "Инженер-аналитик по выявлению уязвимостей"

Разбор VM-ной вакансии от R-Vision Инженер-аналитик по выявлению уязвимостей

Разбор VM-ной вакансии от R-Vision "Инженер-аналитик по выявлению уязвимостей". Давненько не было у меня постов в этой рубрике. Но вот попалась вакансия в R-Vision, которая очень характерна для VM-вендоров. Я и сам на похожей позиции начинал свой путь в Vulnerability Management. 😇

Типовая задача для этой позиции формулируется так: у клиентов используется некоторый продукт, его поддержку необходимо добавить в наше VM-решение. Для этого нужно получить информацию по уязвимостям продукта: найти публичные бюллетени безопасности или согласовать у вендора этого продукта доступ к непубличным фидам. В описании данной вакансии это формулируют как:

🔻 Проводить поиск, разбор и последующий анализ источников данных, предоставляющих информацию по уязвимостям;

Затем нужно разобраться, как превратить информацию об уязвимостях в чёткую логику их детектирования. И нормально это описать. Иными словами:

🔻 Заниматься разработкой и формированием экспертизы (технические стандарты безопасности и информация по уязвимостям) в области информационной безопасности для продуктов компании;

И наконец, нужно написать скрипт, который будет автоматически генерировать правила детектирования уязвимостей:

🔻 Автоматизировать процессы по формированию экспертизы ИБ;

Таким продуктом при этом может быть всё, что угодно: операционные системы, базы данных, ERP-системы, сетевые устройства, разнообразный прикладной софт. Так как у клиентов, как правило, лютейший зоопарк, загрузка работой обеспечена на годы вперёд. 😉 Хотя с появлением нейроночек процесс упростился и ускорился.

Обратите внимание, что выше было про "технические стандарты безопасности". Это про харденинг. На вход аналитику подаётся стандарт по безопасному конфигурированию какого-то продукта (например, от CIS, ФСТЭК или самого вендора продукта). Задача аналитика - разработать для каждого требования автоматическую проверку конкретной инсталляции продукта на соответствие этому требованию. Пока накидываешь проверки, волей-неволей разбираешься и с безопасным конфигурированием. 👍

Все разработанные проверки будут работать в рамках конкретного решения (видимо, R-Vision VM, но возможно, что и не только), поэтому соискателю неизбежно придётся:

🔻 Взаимодействовать с продуктовыми командами с целью улучшения работы продуктов.

Какие скиллы нужны для этой работы? Ну, очевидно, что нужно уметь как-то кодить:

🔸 Знание Git, Python - ваши хорошие друзья;

Очевидно, что соискатель не должен бояться консоли и должен +- быть в курсе, что из себя представляет современная IT-инфраструктура:

🔸 Наличие навыков администрирования Windows, Linux систем;
🔹 Опыт администрирования сетевого и иного оборудования;

Чёткого ТЗ на такой позиции ждать не приходится. Придётся много копать самому, поэтому:

🔸 Способность работать самостоятельно, но и в команде.

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

🔹 Опыт проведения работ по инструментальному анализу защищенности или опыт работы с одним из сканеров безопасности (Nessus, Nexpose, Qualys, Max Patrol, OpenVas, RedCheck, nmap);
🔹 Навыки работы с режимом "Комплаенс" для оценки соответствия;

Тут не могу не поправить коллег, что MaxPatrol пишется в одно слово, и не "OpenVas", а OpenVAS. 😉

Также было бы неплохо, чтобы и про уязвимости соискатель тоже что-то знал:

🔹 Знание актуальных угроз и уязвимостей на Windows/ Linux платформах;
🔹 Опыт применения методологий по описанию, приоритизации и устранению уязвимостей (CVE, CVSS, VPR, OWASP);

Хотя, честно говоря, увидеть в списке сплошь проприетарный Tenable VPR (Vulnerability Priority Rating) было неожиданно. Интересно, что именно имеют в виду под OWASP. OWASP Top 10? 🤔 И в случае R-Vision странно, что в этом списке нет OVAL.

А в этом пункте коллеги намекнули на внутреннюю кухню:

🔹 Понимание принципов работы инструментов автоматизации (Apache Airflow);

Интересно было бы послушать, как именно они Apache Airflow используют при создании VM-ной экспертизы. 😉

Архитектура Kaspersky Vulnerability Management 1.0

Архитектура Kaspersky Vulnerability Management 1.0Архитектура Kaspersky Vulnerability Management 1.0Архитектура Kaspersky Vulnerability Management 1.0Архитектура Kaspersky Vulnerability Management 1.0Архитектура Kaspersky Vulnerability Management 1.0Архитектура Kaspersky Vulnerability Management 1.0Архитектура Kaspersky Vulnerability Management 1.0Архитектура Kaspersky Vulnerability Management 1.0Архитектура Kaspersky Vulnerability Management 1.0

Архитектура Kaspersky Vulnerability Management 1.0. Две недели назад, 16 июля, прошёл вебинар Kaspersky, на котором представили решение Kaspersky Vulnerability Management 1.0. В этом посте хотелось бы рассмотреть первую часть вебинара, посвящённую архитектуре. Позже планирую разобрать и часть с демо, и блок ответов на вопросы.

Участники вебинара:

🔹 Мария Погребняк - отвечает за развитие бизнеса Vulnerability Management в "Лаборатории Касперского";
🔹 Максим Лызаев - presale, стоял у истоков продукта;
🔹 Дмитрий Волошин - presale, опыт в vulnerability management, в команде VM около полугода.

В декабре вышла бета-версия продукта, которую протестировали партнёры и заказчики - часть их замечаний успели учесть в первом релизе.

Начали с контекста, почему решение выпустили именно сейчас: уже пять лет как минимум треть атак идёт через уязвимости, и это стабильно первое место в рейтинге векторов атак. После 2022 года российский VM-рынок сильно изменился и пополнился новыми вендорами. Последние два года заказчики Kaspersky просили у компании собственное VM-решение.

Заявленные ключевые преимущества:

🔻 Инвентаризация и управление активами - зрелая развитая функциональность за счёт бесшовной интеграции с Kaspersky Security Center; заказчики, уже использующие KSC, отмечают простоту инвентаризационного этапа;

🔻 Несколько способов сканирования - агентный способ (считается преимуществом и более мощным методом) и сетевой скан (альтернатива там, где агент использовать невозможно или не нужно) - охват инфраструктуры с обеих сторон;

🔻 Работа с ошибками конфигураций как с уязвимостями - предустановленные профили ФСТЭК и международные бенчмарки; одна из функциональностей, давшая больше всего положительной обратной связи от партнёров и заказчиков;

🔻 Patch management - функциональность уже была в endpoint-продукте; преимущество в процессной составляющей - возможность пропатчить некоторый перечень ПО, убрав "фоновый шум".

Общая архитектура. Продукт работает в паре с KSC. Для коммерческого релиза VM 1.0 нужен KSC для Linux версии 16.3. VM устанавливается рядом - на том же сервере либо на отдельном. Сам VM (Vulnerability Management) - это несколько сервисов и собственная база данных: у KSC своя база, у VM своя. Используются агенты, подчинённые KSC. Агенты могут устанавливаться на Linux и на Windows - ограничений нет, но версия агентов также должна быть 16.3. У KSC есть веб-консоль. Чтобы добавить в неё разделы, касающиеся VM, устанавливается отдельный плагин.

Сценарий агентного сканирования. Агенты собирают информацию с конечных устройств: список установленного ПО, данные об операционной системе - и отправляют её на сервер по расписанию и по триггеру (триггером служит установка или удаление ПО на устройстве). Эта информация накапливается на сервере, где по расписанию, заданному администратором, запускается отдельная задача. Она сверяет полученные данные с базами уязвимостей и формирует результат, который отображается в консоли и отчётах. Этот сценарий можно назвать асинхронным: агенты отправляют информацию в своём темпе, а задача анализа на сервере работает по расписанию администратора. На практике это означает, что если устройство было доступно вчера, а сегодня офлайн - например, сотрудник ушёл в отпуск - и в тот же день в базах появились новые уязвимости, система всё равно найдёт их на этом устройстве, поскольку данные о нём уже сохранены на сервере. Второй вывод: запуск задачи на сервере не влияет на производительность конечных устройств. Задачу можно запускать хоть каждый час - она работает только с данными, уже имеющимися на сервере, независимо от состояния агентов. Передача списка ПО и данные об ОС занимают килобайты, поэтому нагрузка на сеть и вычислительные ресурсы минимальна и, скорее всего, останется незаметной.

Декларируемые преимущества агентного сканирования:

🔸 Если заказчик уже использует endpoint-агент "Лаборатории Касперского", это тот же агент - к нему просто добавляется функциональность управления уязвимостями. Именно поэтому внедрение простое: основной движок в инфраструктуре компании уже есть.

🔸 Агент передаёт на сервер сканирования данные о том, какие настройки на рабочей станции закрыты, какой порт закрыт или какое ПО "заблокировано". Благодаря этому в сводке уязвимостей не появляются уязвимости для "ПО, к которому нет доступа". Такие детали снижают число ложных срабатываний и делают итоговую картину более точной. Мой комментарий: Это интересный момент. По сути, продукт каким-то образом по умолчанию фильтрует детектируемые уязвимости по дополнительному набору критериев. Какие именно это критерии и насколько такое поведение корректно - нужно будет разбираться отдельно, поэтому здесь ждём подробностей. 😉

🔸 Агент не требует передачи учётных данных, поскольку уже работает под достаточно привилегированной учётной записью на конечном устройстве - передавать креды по сети не нужно. При атаках хакеры в первую очередь охотятся за учёткой сканера, работающего под админскими правами. В случае агентного сканирования единой учётной записи нет - у каждой рабочей станции своя учётка, поэтому этот риск снимается.

Читать далее

Вышел эпизод "Почему компании не закрывают уязвимости?" [Belyaev_Podcast] с моим участием

Вышел эпизод "Почему компании не закрывают уязвимости?" [Belyaev_Podcast] с моим участием. Вместе с Дмитрием Беляевым и Рустамом Гусейновым обсудили Vulnerability Management и Exposure Management, CVSS/EPSS/KEV и приоритизацию уязвимостей, AI-агентов и нейросети в триаже, автоматизированный патчинг, моделирование атак, зашивание безопасности в разработку, проблемы взаимодействия с IT, работу с системами, которые нельзя патчить, будущее VM-специалистов и особенности управления уязвимостями в Linux, Kubernetes, контейнерах и облаках. Классно посидели, мне очень понравилось. Надо будет как-нибудь продолжить общение по теме. 😉

Таймстемпы:

00:00 Приветствие, медиа-партнёры
03:25 Справедливо ли мнение, что CVSS как основная метрика приоритизации - это уже "технология 2002 года"? Почему в 2026 году компании всё ещё живут в логике "сортируем по CVSS", хотя есть EPSS, KEV и трендовые метрики? Это лень, незнание или инерция?
07:49 Насколько вопросы триажа, ранжирования и приоритизации уязвимостей делаются лучше с помощью нейросетей? Будет ли в будущем происходить быстрое сопоставление по разным шкалам и интегральная оценка с учётом искажений, которые есть в тех или иных системах метрик?
10:09 Автономные AI-агенты и VM
12:00 System-hardening и патчинг уязвимостей агентами без участия человека - уже реальность?
15:33 Насколько справедливо утверждение, что Exposure Management - это не просто "VM 2.0", а действительно другой взгляд на управление риском? В твоём понимании это эволюция или всё-таки революция, но с новым ценником? (Я тут попутал "croûton" и "croissant" в известной кино-цитате - сорян 🤦‍♂️🤷‍♂️🙂)
20:32 Про зашивание безопасности в IT/разработку, почему так много Linux-уязвимостей, и нужна ли замена Linux Kernel
30:08 Если завтра появится "идеальный ИИ", который с точностью 99% предсказывает, что уязвимость будет эксплуатирована в течение 30 дней, - правда ли, что роль VM-специалиста всё равно не исчезнет? В чём тогда останется человеческая зона ответственности?
32:31 О реализуемости полного моделирования путей атаки и автоматизированном реагировании
37:46 Насколько справедливо утверждение, что IT-отделы часто фактически саботируют VM? Как это выглядит на практике: это злой умысел, защита своих интересов или просто боль от перегрузки?
42:43 Как выглядит VM-процесс для систем, которые нельзя патчить или даже активно сканировать?
45:51 Как превратить IT-шников в ответственных хозяев своих активов?
48:48 Насколько сильно отличается подход к детектированию и управлению уязвимостями в Linux, контейнерах, Kubernetes и облаках от классического сканирования Windows-хостов? Где сегодня самые большие слепые зоны?
51:30 Детектирование - это только начало, а вся драма начинается после? Какие этапы после детекции чаще всего "рассыпаются" в реальных компаниях?
54:26 Блиц-вопросы
56:11 Заключение

📺 Смотрите на платформах: VK Видео, RUTUBE, YouTube.
🎧 Слушайте на платформах: Яндекс Музыка, Звук, Spotify, Pocket Casts, Deezer, Podcast Addict, Mave.

Поделюсь впечатлениями от прошедшей вчера конференции Территория Безопасности, на которой я выступал и был модератором секции, посвящённой управлению уязвимостями и экспозициями

Поделюсь впечатлениями от прошедшей вчера конференции Территория Безопасности, на которой я выступал и был модератором секции, посвящённой управлению уязвимостями и экспозициями

Поделюсь впечатлениями от прошедшей вчера конференции Территория Безопасности, на которой я выступал и был модератором секции, посвящённой управлению уязвимостями и экспозициями. На мой взгляд, Территория Безопасности - лучшая на текущий момент независимая конференция по информационной безопасности в России. Независимая в том смысле, что за ней не стоит какой-то один вендор или организация. И в то же время это масштабное мероприятие с разнообразной деловой программой (4 параллельных трека!) и множеством вендоров, представленных в выставочной части. Деловая программа фактически формируется усилиями комьюнити, и каждая ИБ-специализация имеет там своё место и возможность пересечься в одном зале, чтобы обсудить актуальные темы и то, что действительно наболело.

Я приложил руку к составлению VM-ной части программы, о которой писал ранее. Как по мне, всё прошло отлично, докладчики выступали бойко, отрепетированно и укладывались в достаточно жёсткий тайминг. Времени всегда хочется как можно больше, но, с другой стороны, такие ограничения (~1,5 часа на все про все) стимулируют делать секцию как можно более динамичной.

🔹 Приятно, что наш "позитеховский" взгляд на Exposure Management, сформулированный мной и продемонстрированный (очень подробно и наглядно 👍) Константином Маньяковым, был хорошо воспринят как представителями клиентов, так и представителями других VM-вендоров.

🔹 Хотелось бы отметить замечательный, динамичный и остроумный доклад Кирилла Евтушенко, генерального директора Кауч, с критикой функциональности по детектированию мисконфигураций в Nessus. Мне, как бывшему активному комплаенсописателю с опытом в .audit- и NASL-скриптинге, эта тема была особенно близка и интересна. 🔥

🔹 Хотелось бы поблагодарить Кирилла Сорокина, директора департамента защиты приложений ПАО «Вымпелком» (Билайн), и Романа Мустаева, начальника отдела обеспечения безопасности инфраструктуры АО «Национальная страховая информационная система», за взгляд со стороны компаний-клиентов различного масштаба. Коллеги очень здорово сбалансировали наш вендорский междусобойчик, подсветив актуальные проблемы существующих решений по работе с уязвимостями (в широком смысле 😉).

🔹 Огромная благодарность Дмитрию Чернякову, директору по развитию продуктов АО «АЛТЭКС-СОФТ» (RedCheck), за участие в дискуссии. Очень рад, что наши взгляды по VM-ным вопросам, как правило, в значительной степени совпадают. 🤝

В выставочной части в этом году стендов VM-вендоров было поменьше, чем в прошлом. Но тем не менее было много интересного.

🔻 Этот год был отмечен полноценным участием в выставке Positive Technologies с большим и красивым стендом, посвящённым именно продуктам для работы с уязвимостями/экспозициями (XSpider PRO, MaxPatrol VM, MaxPatrol HCC, MaxPatrol Carbon). Интерес был большой, и наш PT-шный десант очень активно поработал на стенде. 👍

🔻 На стенде RedCheck я потестировал интерфейс нового RedCheck VM. Выглядит симпатично. Понравилась фишка с назначением конкретных уязвимостей на ответственных. Фактически таски "один хост - одна уязвимость". Постараюсь сделать отдельный пост про это.

🔻 Интересно пообщался на стендах EASM-вендора DeteAct, compliance/hardening-вендора Кауч, "российского Skybox" MIST Insight.

Организовано мероприятие было, как всегда, отлично. 💯 По технике всё работало как надо. Кормили вкусно, и еды было в избытке. Всё способствовало приятному и полезному деловому общению. Организаторы и лично продюсер конференций Екатерина Митина - большие молодцы! Спасибо Территории Безопасности, и надеюсь, что до встречи в следующем году!

На сайте ФСТЭК 10 марта был опубликован документ с рекомендациями по защите сетевого периметра информационных (автоматизированных) систем

На сайте ФСТЭК 10 марта был опубликован документ с рекомендациями по защите сетевого периметра информационных (автоматизированных) систем

На сайте ФСТЭК 10 марта был опубликован документ с рекомендациями по защите сетевого периметра информационных (автоматизированных) систем. Документ на 6 страниц, содержит требования, оформленные в 8 групп (символом ✳️ я отметил то, что непосредственно относится к Управлению Уязвимостями):

1. Администрирование, управление конфигурацией и эксплуатацией сетевых устройств: 1.1 администрировать пограничные устройства с изолированных рабочих мест; 1.2 использовать сертификаты или сложные пароли; 1.3 применять уникальные пароли; 1.4 контролировать и журналировать изменения конфигурации; ✳️ 1.5 выявлять и блокировать нелегитимные внешние сервисы; ✳️ 1.6 вести учёт устройств на сетевом периметре; ✳️ 1.7 управлять устройствами с истекающей поддержкой; 1.8 запретить внешнее удалённое администрирование; 1.9 согласовывать изменения с ИБ; 1.10 использовать безопасные протоколы мониторинга.

2. Повышение устойчивости к DDoS-атакам: 2.1 настроить блокировку неразрешённого трафика; 2.2 фильтровать трафик через WAF; 2.3 включить защиту от DDoS; 2.4 ограничивать подключения с одного IP; 2.5 взаимодействовать с оператором связи для противодействия DDoS.

3. Сегментация сети и контроль доступа для защиты ключевых сегментов: 3.1 сегментировать сеть VLAN и локальными сетями; 3.2 контролировать трафик через ACL; 3.3 внедрить ZTNA; 3.4 запретить удалённое администрирование ядра сети; 3.5 создать DMZ с ограниченным доступом к внутренним сегментам.

4. Резервное копирование конфигов: 4.1 назначить ответственного за резервное копирование; 4.2 хранить ≥3 копий на разных носителях, одну отдельно; 4.3 копировать ежемесячно; 4.4 определить права на копирование; 4.5 сохранять критичные конфигурации (ACL, VLAN, NAT, учетные записи); 4.6 проверять восстановление каждые три месяца.

✳️ 5. Управление уязвимостями: 5.1 реализовать управление уязвимостями по Методике анализа защищенности (ФСТЭК 25.11.2025) и Руководству по управлению уязвимостями (ФСТЭК 17.05.2023); 5.2 устанавливать обновления безопасности на пограничных устройствах и тестировать их по Методике тестирования обновлений безопасности (ФСТЭК 28.10.2022) и Методике оценки критичности уязвимостей (ФСТЭК 30.06.2025).

6. Аутентификация и управление доступом: 6.1 централизованный контроль доступа через NAC и межсетевые экраны; 6.2 многофакторная аутентификация для админ-доступа; 6.3 разграничение ролей с минимальными привилегиями.

7. Регистрация и анализ событий ИБ: 7.1 централизованный сбор и анализ событий через SIEM; 7.2 хранение детальных журналов безопасности с временными метками; 7.3 оповещение администраторов о подозрительных действиях и изменениях.

8. Регулярные учения по реагированию на инциденты для проверки их эффективности и восстановления инфраструктуры.

Интересный и подробный документ. 👍 По VM-ной части весьма примечательно, что VM-процесс для периметра рекомендуют строить в соответствии с

🔹 Руководством по Анализу защищённости. Имеются в виду периодические внешние аудиты периметра сторонней организацией с соответствующими критериями успешности? 🤔

🔹 Руководством по организации процесса управления уязвимостями в органе/организации. Был весьма удивлён, т.к. давненько не встречал прямую ссылку на него в документах ФСТЭК. 😲 Всё больше общие требования к VM-процессу, как в 117 приказе или проекте "Мероприятий и мер". 🤷‍♂️

На сайте ФСТЭК 23 января был опубликован документ с рекомендациями по харденингу виртуальной инфраструктуры на базе VMware

На сайте ФСТЭК 23 января был опубликован документ с рекомендациями по харденингу виртуальной инфраструктуры на базе VMware

На сайте ФСТЭК 23 января был опубликован документ с рекомендациями по харденингу виртуальной инфраструктуры на базе VMware. Документ на 13 страниц содержит 19 рекомендаций различного объёма и детализации:

1. Настройка журналов событий
2. Переадресация журналов событий на удалённый сервер
3. Передача журналов в SIEM (таблица "Перечень журналов событий")
4. Оповещение администраторов безопасности посредством SIEM о наступлении событий (список 9 событий)
5. Резервное копирование
6. Многофакторная аутентификация
7. Отключение доступа по SSH
8. Харденинг доступа по SSH (если п.7 невозможен)
9. Ограничение VMware Network API
10. Блокировка VMware Installation Bundles
11. Ограничение HTTPS, клиента vSphere и vMotion
12. Регулярные обновления ПО (с тестированием)
13. Минимизация привилегий
14. Регулярная смена паролей
15. Безопасный режим ESXi
16. Флаг execInstalledOnly
17. Политики безопасности Portgroup
18. Сетевая сегментация
19. Сетевой доступ по чёрным и белым спискам

На сайте ФСТЭК 9 февраля был опубликован документ с рекомендациями по харденингу общесистемного и прикладного ПО под Windows и Linux

На сайте ФСТЭК 9 февраля был опубликован документ с рекомендациями по харденингу общесистемного и прикладного ПО под Windows и Linux

На сайте ФСТЭК 9 февраля был опубликован документ с рекомендациями по харденингу общесистемного и прикладного ПО под Windows и Linux. Документ на 18 страниц содержит 12 групп рекомендаций:

1. Парольные политики Windows и Linux
2. Доступ и логирование событий в MySQL/MariaDB, PostgreSQL, MS SQL Server
3. Отключение SMBv1 в Windows
4. Отключение NTLMv1 в Windows
5. Удаление учётной записи "Гость" из групп "Администраторы" в Windows
6. Хранение учётных данных и ограничение доступа к конфигурационным файлам Windows и Linux
7. Аудит и блокирование неиспользуемых открытых портов
8. Отключение автовхода пользователя в Windows
9. Безопасная настройка SSH в Linux
10. Назначение прав доступа на файлы и директории в Windows и Linux
11. Отключение неиспользуемых служб и компонентов операционной системы в Windows и Linux
12. Отключение неиспользуемых учётных записей и ограничение записей с избыточными правами в Windows и Linux