Куда я попал?
SECURITM это система для корпоративных служб информационной безопасности,
которая автоматизирует ключевые процессы управления:
контроль соответствия требованиям, управление рисками, учет активов, планирование работ,
задачи, технические уязвимости, опросы и т.д.
SECURITM помогает построить и управлять ИСПДн, КИИ, ГИС, СМИБ/СУИБ, банковскими системами защиты.
А еще SECURITM это место для обмена опытом в рамках сообщества служб безопасности.
SECURITM помогает построить и управлять ИСПДн, КИИ, ГИС, СМИБ/СУИБ, банковскими системами защиты.
А еще SECURITM это место для обмена опытом в рамках сообщества служб безопасности.
Цель: сокращение поверхности атаки.
Часть общего процесса управления безопасностью конфигураций (Hardening).
Общий алгоритм:
Часть общего процесса управления безопасностью конфигураций (Hardening).
Общий алгоритм:
- Определить, задокументировать требования к безопасности конфигурации.
- Применить безопасную конфигурацию на существующих хостах.
- Применять безопасную конфигурацию на новых хостах в рамках процесса их ввода в эксплуатацию.
- Регулярно проверять конфигурацию хостов на соответствие установленным требованиям.
Источником для формирования требований к безопасности конфигурации служат:
- Руководства по настройке безопасности от производителя (например, Red Hat Enterprise Linux Security guide);
- Руководства по настройке безопасности (например, CIS CentOS Linux Benchmarks, CIS Debian Linux Benchmarks, CIS Red Hat Enterprise Linux Benchmarks, CIS Ubuntu Linux Benchmarks, SCAP Security Guide Project, FIPS for Ubuntu);
- Рекомендации регулирующих органов и отрасли;
- Собственные наработки и решения.
Документирование требований осуществляется в зависимости от принятых подходов в организации.
Вариант реализации: описать требования в карточке защитной меры. Пример документа
Отклонения от выбранной конфигурации документируются вместе с обоснованием и применяемыми компенсирующими мерами.
Вариант реализации: вести учет отклонений в заметках к карточкам активов (хостов) либо защитной мере.
Вариант реализации: описать требования в карточке защитной меры. Пример документа
Отклонения от выбранной конфигурации документируются вместе с обоснованием и применяемыми компенсирующими мерами.
Вариант реализации: вести учет отклонений в заметках к карточкам активов (хостов) либо защитной мере.
Минимальные требования к безопасной конфигурации:
- Изменить пароли по умолчанию.
- Настроить SSH
- Настроить сложность паролей
- Настроить смену (жизненный цикл) паролей
- Настроить политику аутентификации
- Отключить или удалить ненужные учетные записи пользователей
- Отключить или ограничить ненужные службы, порты и протоколы
- Удалить ненужное программное обеспечение
- При необходимости ограничить физические порты
- Настроить баннеры при входе
В зависимости от выстроенной в компании инфраструктуры к требованиям безопасности конфигурации могут быть отнесены:
- Подключение хоста к корпоративной системе мониторинга
- Настройка передачи логов на централизованный сервер (nxlog, SEM / SIEM)
- Конфигурация NTP и часового пояса
Настройка может осуществляться вручную, скриптами или с использованием централизованных систем управления конфигурацией (например, Ansible).
Контроль конфигурации может осуществляться скриптами, системами контроля конфигураций, сканерами уязвимостей с соответствующим модулем контроля конфигураций.
Показателем эффективности процесса может являться:
- общий процент соответствия требованиям (суммарно по всем хостам),
- процент хостов, соответствующих требованиям.
Контроль конфигурации может осуществляться скриптами, системами контроля конфигураций, сканерами уязвимостей с соответствующим модулем контроля конфигураций.
Показателем эффективности процесса может являться:
- общий процент соответствия требованиям (суммарно по всем хостам),
- процент хостов, соответствующих требованиям.
Рекомендации к заполнению карточки:
- Каждый из этапов процесса (определение требований, первичная настройка, ввод в эксплуатацию новых хостов, контроль соответствия) может быть описан отдельной защитной мерой.
- Описать принятый в компании перечень требований к безопасности конфигурации.
- Если для приведения в соответствие и/или контроля конфигураций используется ПО - зарегистрировать его в реестре активов и привязать к мере как инструмент
- Если ведется учет (реестр) скриптов - привязать использующиеся скрипты как инструмент
- Добавить шаблон регулярной задачи по проверке конфигураций.
- Добавить шаблон регулярной задачи на пересмотр/актуализацию набора требований безопасности
Область действия: Вся организация
Классификация
Тип
Техническая
?
Превентивная
?
Реализация
Вручную
Периодичность
Разово
Ответственный
Не определено
Инструменты
Не определено
Исполнение требований
CIS Critical Security Controls v8 (The 18 CIS CSC):
16.7
16.7 Use Standard Hardening Configuration Templates for Application Infrastructure
Use standard, industry-recommended hardening configuration templates for application infrastructure components. This includes underlying servers, databases, and web servers, and applies to cloud containers, Platform as a Service (PaaS) components, and SaaS components. Do not allow in-house developed software to weaken configuration hardening.
Use standard, industry-recommended hardening configuration templates for application infrastructure components. This includes underlying servers, databases, and web servers, and applies to cloud containers, Platform as a Service (PaaS) components, and SaaS components. Do not allow in-house developed software to weaken configuration hardening.
Положение Банка России № 787-П от 12.01.2022 "Обязательные для кредитных организаций требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг":
п. 6. п.п. 2
6.2. Кредитные организации должны обеспечивать выполнение следующих требований к управлению изменениями критичной архитектуры:
- управление уязвимостями в критичной архитектуре, из-за которых могут реализоваться информационные угрозы и которые могут повлечь превышение значений целевых показателей операционной надежности;
- планирование и внедрение изменений в критичной архитектуре, направленных на обеспечение недопустимости неоказания или ненадлежащего оказания банковских услуг;
- управление конфигурациями (настраиваемыми параметрами) объектов информационной инфраструктуры;
- управление уязвимостями и обновлениями (исправлениями) объектов информационной инфраструктуры.
NIST Cybersecurity Framework (RU):
PR.IP-1
PR.IP-1: С учетом соответствующих принципов безопасности (например, концепция минимальной функциональности) создается и поддерживается базовая конфигурация информационных технологий / промышленных систем управления
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.14.1.1
A.14.1.1 Анализ и спецификация требований информационной безопасности
Мера обеспечения информационной безопасности: Требования, относящиеся к информационной безопасности, должны быть включены в перечень требований для новых информационных систем или для усовершенствования существующих информационных систем
Мера обеспечения информационной безопасности: Требования, относящиеся к информационной безопасности, должны быть включены в перечень требований для новых информационных систем или для усовершенствования существующих информационных систем
SWIFT Customer Security Controls Framework v2022:
2 - 2.3 System Hardening
2.3 System Hardening
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
УКФ.0
УКФ.0 Разработка политики управления конфигурацией информационной (автоматизированной) системы
Положение Банка России № 779-П от 15.11.2021 "Обязательные для некредитных финансовых организаций требований к операционной надежности при осуществлении видов деятельности, предусмотренных частью первой статьи 76.1 Федерального закона от 10 июля 2002 года N 86-ФЗ "О Центральном банке"":
п. 2.1.
2.1. Оператор информационной системы, в которой осуществляется выпуск цифровых финансовых активов, оператор обмена цифровых финансовых активов в целях обеспечения операционной надежности в дополнение к установленным пунктами 1.1 - 1.15 настоящего Положения требованиям к операционной надежности, в рамках выпуска и обращения цифровых финансовых активов должны обеспечивать выполнение следующих мероприятий:
- обеспечение безопасности программной среды исполнения сделки, указанной в части 2 статьи 4 Федерального закона от 31 июля 2020 года N 259-ФЗ "О цифровых финансовых активах, цифровой валюте и о внесении изменений в отдельные законодательные акты Российской Федерации" (Собрание законодательства Российской Федерации, 2020, N 31, ст. 5018), в том числе настройки программной среды исполнения указанной сделки, обеспечивающей функциональность программной среды в условиях сбоев при обработке данных, установление ограничений на доступ к системным ресурсам, оперативной памяти и файловой системе для программной среды исполнения указанной сделки;
- применение механизмов, реализующих обработку информационных угроз, связанных с недоступностью функций компонентов информационной системы, в которой осуществляется выпуск цифровых финансовых активов, а также недоступностью функций удостоверяющего центра, указанного в статье 13 Федерального закона от 6 апреля 2011 года N 63-ФЗ "Об электронной подписи" (Собрание законодательства Российской Федерации, 2011, N 15, ст. 2036; 2020, N 26, ст. 3997), и (или) функций иных информационных систем, взаимодействующих с информационной системой, в которой осуществляется выпуск цифровых финансовых активов.
п. 1.5.
1.5. Некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, в рамках обеспечения операционной надежности должны обеспечивать выполнение следующих требований в отношении управления изменениями критичной архитектуры:
- управление уязвимостями в критичной архитектуре, с использованием которых могут реализоваться информационные угрозы и которые могут повлечь отклонение от значений целевых показателей операционной надежности, указанных в пункте 1.3 настоящего Положения;
- планирование и внедрение изменений в критичной архитектуре, направленных на обеспечение непрерывного оказания финансовых услуг;
- управление конфигурациями объектов информационной инфраструктуры некредитных финансовых организаций;
- управление уязвимостями и обновлениями (исправлениями) объектов информационной инфраструктуры некредитных финансовых организаций.
NIST Cybersecurity Framework (EN):
PR.IP-1
PR.IP-1: A baseline configuration of information technology/industrial control systems is created and maintained incorporating security principles (e.g. concept of least functionality)
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
УКФ.0
УКФ.0 Регламентация правил и процедур управления конфигурацией информационной (автоматизированной) системы
Требования по защите информации к конфигурации Linux Ubuntu
Мониторинг
Конфигурация
Логирование событий
Конфигурация
/etc/rsyslog.d/50-default.conf:
Примечание
В зависимости от назначения актива рекомендуется расширить перечень логируемых событий.
Настройка SSH
Сложность паролей
Жизненный цикл паролей
Пароли должны меняться раз в 90 дней
В файле /etc/login.defs необходимо изменить значения следующих опций:
Примечание
Политика аутентификации
Конфигурация
Учетные записи
Конфигурация
У заблокированных учетных записей вместо поля pass_hash должно быть установлено ! или *
Конфигурация NTP и часового пояса
Настройка баннера
Должен быть включен и настроен баннер входа.
Banner (/etc/issue, /etc/issue.net):