Куда я попал?
SECURITM это система для корпоративных служб информационной безопасности, которая автоматизирует ключевые процессы управления: контроль соответствия требованиям, управление рисками, учет активов, планирование работ, задачи, технические уязвимости, опросы и т.д.
SECURITM помогает построить и управлять ИСПДн, КИИ, ГИС, СМИБ/СУИБ, банковскими системами защиты.
А еще SECURITM это место для обмена опытом в рамках сообщества служб безопасности.

Payment Card Industry Data Security Standard (RU)

Framework № PCI DSS 4.0 от 01.03.2022

Requirement 1.2.2

Для проведения оценки соответствия по документу войдите в систему.
1.2.2
Определенные Требования к Подходу:
Все изменения в сетевых подключениях и конфигурациях NSCS утверждаются и управляются в соответствии с процессом управления изменениями, определенным в Требовании 6.5.1.

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

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

Определенные Процедуры Тестирования Подхода:
  • 1.2.2.a Изучить документированные процедуры для проверки того, что изменения в сетевых подключениях и конфигурациях NSCS включены в формальный процесс управления изменениями в соответствии с требованием 6.5.1.
  • 1.2.2.b Изучите параметры конфигурации сети, чтобы определить изменения, внесенные в сетевые подключения. Опросите ответственный персонал и изучите записи контроля изменений, чтобы убедиться, что выявленные изменения в сетевых подключениях были одобрены и управлялись в соответствии с требованием 6.5.1.
  • 1.2.2.c Изучите параметры конфигурации сети для выявления изменений, внесенных в конфигурации NSCs. Опросите ответственный персонал и изучите записи контроля изменений, чтобы убедиться, что выявленные изменения в конфигурациях NSCS были одобрены и управлялись в соответствии с требованием 6.5.1.
Надлежащая практика:
Изменения должны быть одобрены лицами, обладающими соответствующими полномочиями и знаниями, чтобы оценить возможное негативное влияние изменений. Проверка должна обеспечивать уверенность в том, что изменение не оказало отрицательного влияния на безопасность сети и что изменения выполнены должным образом. 
Чтобы избежать необходимости устранять проблемы безопасности, вызванные изменением, все изменения должны быть одобрены до внедрения и проверены после внедрения изменения. После утверждения и проверки сетевая документация должна быть обновлена, чтобы включить изменения и предотвратить несоответствия между сетевой документацией и фактической конфигурацией.

Похожие требования

CIS Critical Security Controls v8 (The 18 CIS CSC):
4.2 
4.2 Establish and Maintain a Secure Configuration Process for Network Infrastructure
Establish and maintain a secure configuration process for network devices. Review and update documentation annually, or when significant enterprise changes occur that could impact this Safeguard. 
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
УЗП.5
УЗП.5 Документарное определение правил предоставления (отзыва) и блокирования логического доступа
ЗУД.9
ЗУД.9 Реализация и контроль информационного взаимодействия внутренних вычислительных сетей финансовой организации и мобильных (переносных) устройств в соответствии с установленными правилами и протоколами сетевого взаимодействия
ЗБС.7
ЗБС.7 Реализация и контроль информационного взаимодействия внутренних вычислительных сетей финансовой организации и сегментов вычисленных сетей, выделенных в соответствии с мерой ЗБС.3 настоящей таблицы, в соответствии с установленными правилами и протоколами сетевого взаимодействия
ЗСВ.17
ЗСВ.17 Реализация и контроль информационного взаимодействия между сегментами (группами сегментов) вычислительных сетей мерами, указанными в пунктах ЗСВ.13 и ЗСВ.14 настоящей таблицы, в соответствии с установленными правилами и протоколами сетевого взаимодействия
NIST Cybersecurity Framework (RU):
PR.IP-3
PR.IP-3: Реализованы процессы контроля изменений конфигурации 
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 1.2.2
1.2.2
Defined Approach Requirements: 
All changes to network connections and to configurations of NSCs are approved and managed in accordance with the change control process defined at Requirement 6.5.1. 

Customized Approach Objective:
Changes to network connections and NSCs cannot result in misconfiguration, implementation of insecure services, or unauthorized network connections. 

Applicability Notes:
Changes to network connections include the addition, removal, or modification of a connection. 
Changes to NSC configurations include those related to the component itself as well as those affecting how it performs its security function. 

Defined Approach Testing Procedures:
  • 1.2.2.a Examine documented procedures to verify that changes to network connections and configurations of NSCs are included in the formal change control process in accordance with Requirement 6.5.1. 
  • 1.2.2.b Examine network configuration settings to identify changes made to network connections. Interview responsible personnel and examine change control records to verify that identified changes to network connections were approved and managed in accordance with Requirement 6.5.1. 
  • 1.2.2.c Examine network configuration settings to identify changes made to configurations of NSCs. Interview responsible personnel and examine change control records to verify that identified changes to configurations of NSCs were approved and managed in accordance with Requirement 6.5.1. 
Good Practice:
Changes should be approved by individuals with the appropriate authority and knowledge to understand the impact of the change. Verification should provide reasonable assurance that the change did not adversely impact the security of the network and that the change performs as expected. 
To avoid having to address security issues introduced by a change, all changes should be approved prior to being implemented and verified after the change is implemented. Once approved and verified, network documentation should be updated to include the changes to prevent inconsistencies between network documentation and the actual configuration. 
NIST Cybersecurity Framework (EN):
PR.IP-3 PR.IP-3: Configuration change control processes are in place
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
УКФ.0 УКФ.0 Регламентация правил и процедур управления конфигурацией информационной (автоматизированной) системы

Связанные защитные меры

Название Дата Влияние
Community
18 10 / 89
Настройка безопасной конфигурации для серверов ОС Linux
Разово Вручную Техническая Превентивная
16.05.2022
16.05.2022 18 10 / 89
Цель: сокращение поверхности атаки.
Часть общего процесса управления безопасностью конфигураций (Hardening).

Общий алгоритм:
  1. Определить, задокументировать требования к безопасности конфигурации.
  2. Применить безопасную конфигурацию на существующих хостах.
  3. Применять безопасную конфигурацию на новых хостах в рамках процесса их ввода в эксплуатацию.
  4. Регулярно проверять конфигурацию хостов на соответствие установленным требованиям.
Источником для формирования требований к безопасности конфигурации служат:
Документирование требований осуществляется в зависимости от принятых подходов в организации.
Вариант реализации: описать требования в карточке защитной меры. Пример документа

Отклонения от выбранной конфигурации документируются вместе с обоснованием и применяемыми компенсирующими мерами.
Вариант реализации: вести учет отклонений в заметках к карточкам активов (хостов) либо защитной мере.

Минимальные требования к безопасной конфигурации:
  • Изменить пароли по умолчанию.
  • Настроить SSH 
  • Настроить сложность паролей
  • Настроить смену (жизненный цикл) паролей 
  • Настроить политику аутентификации
  • Отключить или удалить ненужные учетные записи пользователей
  • Отключить или ограничить ненужные службы, порты и протоколы
  • Удалить ненужное программное обеспечение
  • При необходимости ограничить физические порты
  • Настроить баннеры при входе
В зависимости от выстроенной в компании инфраструктуры к требованиям безопасности конфигурации могут быть отнесены:
  • Подключение хоста к корпоративной системе мониторинга
  • Настройка передачи логов на централизованный сервер (nxlog, SEM / SIEM) 
  • Конфигурация NTP и часового пояса
Настройка может осуществляться вручную, скриптами или с использованием централизованных систем управления конфигурацией (например, Ansible).

Контроль конфигурации может осуществляться скриптами, системами контроля конфигураций, сканерами уязвимостей с соответствующим модулем контроля конфигураций.

Показателем эффективности процесса может являться: 
- общий процент соответствия требованиям (суммарно по всем хостам), 
- процент хостов, соответствующих требованиям.

Рекомендации к заполнению карточки:
  • Каждый из этапов процесса (определение требований, первичная настройка, ввод в эксплуатацию новых хостов, контроль соответствия) может быть описан отдельной защитной мерой.
  • Описать принятый в компании перечень требований к безопасности конфигурации.
  • Если для приведения в соответствие и/или контроля конфигураций используется ПО - зарегистрировать его в реестре активов и привязать к мере как инструмент
  • Если ведется учет (реестр) скриптов - привязать использующиеся скрипты как инструмент 
  • Добавить шаблон регулярной задачи по проверке конфигураций.
  • Добавить шаблон регулярной задачи на пересмотр/актуализацию набора требований безопасности
Community
9 25 / 62
Выделение ключевых систем в отдельную сеть (сегментация сети)
Разово Вручную Техническая Превентивная
03.05.2022
03.05.2022 9 25 / 62
Цель: защита ключевых активов от несанкционированного доступа на сетевом уровне.

Размещение ключевых систем в отдельных безопасных зонах / контурах безопасности и ограничение доступа в эти выделенные сегменты позволяет защитить наиболее критичные системы в случае компрометации основных сегментов сети компании.
В зависимости от особенностей компании в отдельные сегменты выделяют:
  • Технологические, производственные сети
  • Банковские системы
  • Инфраструктуру SWIFT
  • ПК руководства
  • Ключевые бизнес-системы
  • Системы персональных данных
Способы сегментации: 
  • Логический, с помощью технологий VLAN на сетевом оборудовании
  • Логический, на уровне управления виртуальной инфраструктурой
  • Физический, путем создания отдельных ЛВС для ключевых сегментов
Сегментирование предполагает ограничение/контроль доступа между сегментами на базовом уровне. Использование расширенного контроля средствами межсетевого экранирования выделено в отдельную защитную меру.

Рекомендации к заполнению карточки:
  • Указать перечень сегментов и их назначение 
  • Пояснить способы/технологии сегментации
  • Описать как настроено ограничение доступа (ACL)
  • Если сети учитываются в реестре активов - привязать их к карточке в качестве инструментов (тип актива Локальная сеть).