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

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

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

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

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

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

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

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

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

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

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

Послушал четвёртый эпизод подкаста КиберДуршлаг про Управление Уязвимостями и Харденингом в банке. Гостями подкаста в этот раз были Сергей Алешинский и Андрей Исхаков из ПСБ (Промсвязьбанк). Т.к. я тоже 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-ной части основное, как я понимаю, вот это.