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

Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1

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

Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1
Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1

Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1. На лайв-демо коллеги из R-Vision показали следующие кейсы (см. скриншоты):

🔻 Провели inventory-скан (показали новую карточку скана с фильтрами ошибок), определили хосты Cisco, создали и запустили простое правило для перемещения хостов в группу по типу ОС. В итоге наполнили группу "Сетевое оборудование Cisco".

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

🔻 Добавили уязвимость Cisco, которой не было в базе, через обновление и определили её ретроспективным аудитом на хостах. Проговорили, что в случае детектирования трендовой уязвимости можно автоматически отправлять алерт админу. 🚨

Также они поделились достижениями, статистикой, роадмапом и анонсом мероприятий.

Основное достижение - это перевод R-Vision на новую платформу EVO (до версии 5.4 были на платформе RVN).

R-Vision VM в цифрах (2025-2026):

🔹 +15 новых проектов (есть заказчики с 30k+ активов)
🔹 +50 пилотных проектов у клиентов
🔹 +25 пилотных проектов у партнёров
🔹 +55 обученных технических специалистов
🔹 +133 трендовые уязвимости в базе (дайджесты доступны на сайте R-Vision)
🔹 +180 поддерживаемых продуктов в режиме Audit
🔹 +88 поддерживаемых продуктов в режиме Pentest
🔹 +70 новых стандартов для режима Compliance

Роадмап ("R-Vision VM завтра"):

🔹 Поддержка аудита контейнерных сред
🔹 Поддержка аудита веб-приложений
🔹 Расширение аудита гипервизоров (ESXi, vCenter, …)
🔹 Расширение аудита сетевого оборудования (Qtech, S-Terra, Eltex, VipNET, UserGate, MikroTik, …)
🔹 Мастер первичной настройки
🔹 Сертификат ФСТЭК России (на VM EVO)
🔹 + Секретная функциональность ❗️ (анонс на R-Evolution Conference 2026)

Сам я на R-Evolution Conference, к сожалению, в этом году не попадаю. 😔 Но рекомендую сходить, был там несколько раз, мероприятие душевное.

На R-Evolution Conference будет несколько VM-ных докладов:

🔹 12:55 - 13:15 Смена двигателя на лету: год большой перестройки VM и куда дальше? (Бизнес-трек)
🔹 14:00 - 14:20 Опыт ТМХ: как выстроить управляемый VM на десятках тысяч активов (Бизнес-трек)
🔹 15:20 - 15:40 Где ломается VM: подводные камни инвентаризации в инфраструктуре на 18К+ активов, ЗАО ПАТИО (Технотрек - новинка, в прошлом году технотрека не было 👍)

Плюс обещают демозону с R-Vision VM, работающую весь день. 🔥

В Q&A секции понравились вопросы:

🔹 Какая функциональность будет востребована в системах VM в ближайшие 2-3 года?
"Управление экспозициями" (прямо так и сказали, было приятно услышать именно такую формулировку 😇), пути атаки, ИИ, возможность переваривать большую инфраструктуру, автоматизация.

🔹 Можно ли сейчас использовать решения R-Vision для построения путей атаки?
Сказали, что тема хорошая, но задача сложная, особенно для большой инфраструктуры. Пока они не говорят, что могут это делать, но тренд им нравится.

🔹 Сколько человек, занимающихся VM-ом, требуется для организации с 10k активов?
Ответили, что 10000 активов → минимум 10 человек в IT, минимум 5-7 человек в ИБ. В ИБ люди будут шарить роли. Как минимум нужен один человек, который будет часть времени выделять на VM-ные задачи. Автоматизировать всё можно, но кто-то должен отслеживать сбои.

Compliance-сканирование в R-Vision VM

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

Compliance-сканирование в R-Vision VM

Compliance-сканирование в R-Vision VM. Эта фича была в роадмапе R-Vision на Q1. Уложились. 👍

Пока реализованы только низкоуровневые технические стандарты CIS Benchmarks БЕЗ маппинга на высокоуровневые (PCI DSS, ISO 27001 и т.п.). Полный список не предоставляют, но сообщают, что это стандарты "для различных ОС Linux и Windows, сетевых устройств Cisco, ПО (Apache Tomcat, Microsoft Exchange и др.) и СУБД (Oracle, MSSQL и др.)".

Для примера показывают 16 стандартов для Ubuntu 24.04 , Rocky Linux 8/9, RHEL 8/9, Microsoft Windows Server 2016/2022, Windows 10/11, Cisco NX-OS, Cisco IOS XR7.x/XE17.x/17.x, Cisco ASA.

❗ Есть возможность загружать собственные проверки в YAML файлах. Формат немного напоминает Wazuh SCA, но не он. Вполне вероятно, что формат кастомный. Стандарты CIS из коробки реализованы на таких же ямликах. Формат гибкий. Например, позволяет проверять переменные, инициализируемые результатами выполнения команды на хосте (sshexec). 👍

По случаю пятницы поделюсь одним своим загоном

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

По случаю пятницы поделюсь одним своим загоном

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

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

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

🔸 Просто писать как есть. Слово общеупотребительное, на английском, разница в букву - вроде норм. Или не норм? 🤔
🔸 Написать, что это вот не те, которые запрещённые и в реестре, просто совпадение. Вроде правильно, но мегастранно. 🤷‍♂️
🔸 Вообще не ссылаться на них от греха подальше. 🙈🙂

Послушал четвёртый эпизод подкаста КиберДуршлаг про Управление Уязвимостями и Харденингом в банке

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

Послушал четвёртый эпизод подкаста КиберДуршлаг про Управление Уязвимостями и Харденингом в банке

Послушал четвёртый эпизод подкаста КиберДуршлаг про Управление Уязвимостями и Харденингом в банке. Гостями подкаста в этот раз были Сергей Алешинский и Андрей Исхаков из ПСБ (Промсвязьбанк). Т.к. я тоже 6 лет VM-ом в банке занимался, было интересно послушать. 🙂 Выписал некоторые тезисы.

1. IT стремятся занять позицию "давайте мы сейчас построим, а потом вы к нам придёте, мы вас послушаем и может быть что-то поправим". ИБ должны не допускать такого.
2. VM это прежде всего процесс взаимодействия людей. Важно уметь договариваться, в том числе на уровне руководства. Необходимость VM следует доносить грамотно, аргументированно и регулярно.
3. Доказывать необходимость исправления уязвимостей непросто, но это развивает технически и IT, и ИБ.
4. В ПСБ был выстроенный процесс обновления десктопов (АРМов), но после 22 года он усложнился. Теперь есть команда в составе RedTeam, которая проверяет обновления и новые версии западного ПО на закладки (дополнительно к проверенным обновлениям из БДУ). Также проходят проверки и собственные разработки.
5. Также применяется исправление уязвимостей путем отказа от legacy систем или внедрения компенсирующих мер (аудит сетевых подключений, максимальное урезание интеграций, обслуживание через терминальные станции).
6. Есть проблема с отсутствием бюллетеней безопасности отечественных вендоров. Отечественных вендоров СЗИ/САЗ это тоже касается.
7. Категоризация активов по сегментам, бизнесам, выделение наиболее критичных скоупов (например, DMZ).
8. Категоризация уязвимостей по автоматизированной методике оценки критичности уязвимостей ФСТЭК.
9. В идеале информацию об активах нужно забирать из супер-актуальной CMDB, которую обслуживает IT. А ИБ должна проводить поиск теневых активов в факультативном режиме. На практике вовлеченность ИБ в поиск проблем CMDB выше, в т.ч. приходится самим искать владельцев систем и обслуживающих подразделений. Периодичность рескана фиксируется в документации на IT-систему. Статус комплаенса систем будет виден на уровне CMDB. Необходимо внедрять VM в ITSM.
10. Проводится сканирование периметра извне. Необходимо следить за состоянием внешних сканеров, т.к. они зачастую добавлены в white list. Для внутренних сканеров, проводящих сканирование с аутентификацией, это ещё более критично.
11. У каждого компонента IT-систем есть утвержденный стандарт настроек. Разработка стандартов настроек выполняется внешней организацией. Проверки на соответствие реализуют сами. Конкретные требования зависят от контура, в котором находится сервер. Желательно иметь возможность перенести этот набор скриптов в VM-решение.
12. Этапы процесса Управления Соответствием: утверждение стандарта, тестирование на ограниченном скоупе, расширение скоупа и контроль соответствия. Центр IT-архитектуры утверждает единый тех. стек допустимых технологий. Его необходимо ограничивать и иметь в виде реестра а-ля CMDB. Проблема расширения стека (в глобальном смысле) это и проблема VM-вендора, который должен уметь всё.
13. При наслоении стандартов (например, ОС и СУБД) могут быть конфликты. Отхождения от стандарта должны согласовываться и журналироваться.
14. Трендовые уязвимости на периметре фиксятся оперативно без формального обоснования критичности. Согласование в рамках конфколла. Но тестирование патча на ограниченном скоупе всё равно необходимо выполнять.
15. Еженедельные отчёты: новая инфраструктура введенная в эксплуатацию, какая инфраструктура прошла проверки, какие уязвимости выявлены с приоритизацией. Отчёты также нужны для аудиторов.
16. Нужно стремиться к открытости VM-решений: полнота базы знаний детектов, обязательство поддерживать API-интеграции.

Методические рекомендации по безопасной настройке Linux систем от ФСТЭК

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

Методические рекомендации по безопасной настройке Linux систем от ФСТЭК. Что? 😳 ДА! 🎉Теперь можно ссылаться не на CIS, не на DISA STIGs, не на BSI IT-Grundschutz, а на технические требования нашего отечественного регулятора. Ну круть же! Скачать можно на сайте ФСТЭК.

1. Документ очень компактный, всего 7 страниц. CIS Benchmark для Ubuntu Linux 20.04 LTS, для сравнения, занимает 531 страницу.
2. Рекомендации подлежат реализации в государственных информационных системах (ГИС) и на объектах критической информационной инфраструктуры (КИИ).
3. Рекомендации распространяются на настройку НЕсертифицированных ОС (как раз Debian, Ubuntu, CentOS Stream, Alma Linux, Rocky Linux, openSUSE и прочего) "до их замены на сертифицированные отечественные операционные системы". Т.е. мейнстримные Linux дистрибутивы из КИИ и ГИС придется выносить, если они есть. Сертифицированные же Linux-ы должны настраиваться "в соответствии с эксплуатационной документацией разработчиков".
4. Рекомендации касаются именно настройки. Пример: "2.1.2. Обеспечить отключение входа суперпользователя в систему по протоколу SSH путём установки для параметра PermitRootLogin значения no в файле /etc/ssh/sshd_config." Как проверять не расписывается.
5. Сложность реализации настроек и проверок соответствия по пунктам из этих рекомендаций зависит от конкретности рекомендаций. Часть рекомендаций выглядят достаточно конкретными, часть нет, например "2.3.8. Установить корректные права доступа к исполняемым файлам и библиотекам операционной системы путём анализа корректности прав доступа к утилитам и системным библиотекам, расположенным по стандартным путям (, /usr/bin, , и другим путям), а также к модулям ядра (для Linux: /lib/modules/версия-текущего-ядра)". Понятно, что конкретные настройки могут зависеть от конкретного дистрибутива, но все же хотелось бы большей однозначности, что нужно делать.
6. В некоторых пунктах приводится обоснование зачем это настройка нужна, например "в противном случае это может привести к выполнению произвольного кода от имени владельца задания cron". Но для большей части рекомендаций этого нет. А тоже хотелось бы.

Блоки рекомендаций:
1. Настройка авторизации в операционной системе.
2. Ограничение механизмов получения привилегий.
3. Настройка прав доступа к объектам файловой системы.
4. Настройка механизмов защиты ядра Linux.
5. Уменьшение периметра атаки ядра Linux.
6. Настройка средств защиты пользовательского пространства со стороны ядра Linux.

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

Прикольный чеклист по задачам, которые должны быть реализованы в соответствии с 250-м Указом и подзаконными актами от Алексея Лукацкого и позитехов

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

Прикольный чеклист по задачам, которые должны быть реализованы в соответствии с 250-м Указом и подзаконными актами от Алексея Лукацкого и позитехов

Прикольный чеклист по задачам, которые должны быть реализованы в соответствии с 250-м Указом и подзаконными актами от Алексея Лукацкого и позитехов. Единственное, что PDF-ка по которой нельзя искать это зло. 🙂 По нашей VM-ной части основное, как я понимаю, вот это.