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

Посмотрел вебинар по применению BI.ZONE GRC для управления уязвимостями и комплаенсом

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

Посмотрел вебинар по применению BI.ZONE GRC для управления уязвимостями и комплаенсомПосмотрел вебинар по применению BI.ZONE GRC для управления уязвимостями и комплаенсомПосмотрел вебинар по применению BI.ZONE GRC для управления уязвимостями и комплаенсомПосмотрел вебинар по применению BI.ZONE GRC для управления уязвимостями и комплаенсомПосмотрел вебинар по применению BI.ZONE GRC для управления уязвимостями и комплаенсомПосмотрел вебинар по применению BI.ZONE GRC для управления уязвимостями и комплаенсомПосмотрел вебинар по применению BI.ZONE GRC для управления уязвимостями и комплаенсомПосмотрел вебинар по применению BI.ZONE GRC для управления уязвимостями и комплаенсомПосмотрел вебинар по применению BI.ZONE GRC для управления уязвимостями и комплаенсомПосмотрел вебинар по применению BI.ZONE GRC для управления уязвимостями и комплаенсом

Посмотрел вебинар по применению BI.ZONE GRC для управления уязвимостями и комплаенсом. Очень толковое и насыщенное мероприятие. 👍

🔹 Много времени уделили управлению IT-активами как основе для всех доменов практической безопасности, включая комплаенс, защиту инфраструктуры и данных. Для эффективного учёта активов IT и ИБ необходимо действовать сообща и наращивать автоматизацию.

🔹 Говоря о VM-е Кирилл Карпиевич покритиковал цикл Gartner-а и игру IT-шников в докажи-покажи. 🔥 Я оценил. 🙂👍 Он рассказал, как СберTex использует BI.ZONE GRC для поддержания единого реестра активов, собирая в него данные из изолированных ЦОД-ов с помощью MaxPatrol VM, Kaspersky KSC и Сканер-ВС.

🔹 Андрей Шаврин рассказал, что в комплаенсе важно искать пересечение требований, а работы по внедрению начинать с аудита. С помощью BI.ZONE GRC в дочерних компаниях "МУЗ‑ТВ" автоматизировали работу с ПДН.

Сами интерфейсы GRC-системы не показали, надеюсь на live-демо в следующий раз. 😉

В этот четверг, 27 марта, в 11:00 состоится вебинар по использованию BI.ZONE GRC для управления уязвимостями и комплаенсом

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

В этот четверг, 27 марта, в 11:00 состоится вебинар по использованию BI.ZONE GRC для управления уязвимостями и комплаенсом

В этот четверг, 27 марта, в 11:00 состоится вебинар по использованию BI.ZONE GRC для управления уязвимостями и комплаенсом.

Выступать будут:

🔹 Андрей Быков, руководитель BI.ZONE GRC. Расскажет про само решение.

🔹 Кирилл Карпиевич, специалист по анализу уязвимостей "СберТех". Расскажет о сложностях управления уязвимостями в крупнейшем облачном провайдере.

🔹 Андрей Шаврин, начальник отдела информационной безопасности "МУЗ‑ТВ". Расскажет как выстроить комплаенс по ПДН и КИИ для группы компаний.

Обещают сделать упор на управление активами и рассказать "какие процессы можно автоматизировать минимум на 80%". Звучит интригующе. 🙂

Телеграм-канал "Управление Уязвимостями и прочее" в информационных партнёрах мероприятия. Собираюсь посмотреть и поделиться впечатлениями.

➡️ Регистрация на сайте

Если есть ИБ-бюджет, потрать его в первую очередь на Vulnerability Management и Hardening

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

Если есть ИБ-бюджет, потрать его в первую очередь на Vulnerability Management и Hardening

Если есть ИБ-бюджет, потрать его в первую очередь на Vulnerability Management и Hardening. 😉 По поводу этой картинки Mads Bundgaard Nielsen-а, о которой писали Александр Редчиц и Алексей Лукацкий, у меня вопросов нет. Ну, во всяком случае, по моей части. 😏

Видим у Vulnerability Management-а и Compliance Management-а (Наrdening-а) очень высокую эффективность при средней цене. И это должен быть первый приорититет у CISO. ⚡️

После Firewall-а. 🙄 Тут спорно, но пусть будет так. Без NGFW заниматься безопасностью действительно не сладко.

В общем, одобряю картинку. 🙂👍

Методические рекомендации по безопасной настройке 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.

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