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

Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022

Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А

А.8.9

Для проведения оценки соответствия по документу войдите в систему.

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

Стандарт Банка России № СТО БР ИББС-1.0-2014 от 01.06.2014 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации - Общие положения":
Р. 8 п. 12 п.п. 1
8.12.1. Должны быть определены, выполняться и регистрироваться процедуры мониторинга ИБ и контроля защитных мер, включая контроль параметров конфигурации и настроек средств и механизмов защиты. Выполнение указанных процедур должно организовываться службой ИБ, охватывать все реализованные и эксплуатируемые защитные меры, входящие в СИБ. 
NIST Cybersecurity Framework (RU):
PR.IP-3
PR.IP-3: Реализованы процессы контроля изменений конфигурации 
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
ЗСВ.7 ЗСВ.7 Контроль целостности виртуальной инфраструктуры и ее конфигураций
УКФ.4 УКФ.4 Документирование информации (данных) об изменениях в конфигурации информационной системы и системы защиты персональных данных
УКФ.2 УКФ.2 Управление изменениями конфигурации информационной системы и системы защиты персональных данных
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. 
Requirement 6.5.1
6.5.1
Defined Approach Requirements: 
Changes to all system components in the production environment are made according to established procedures that include: 
  • Reason for, and description of, the change.
  • Documentation of security impact.
  • Documented change approval by authorized parties. 
  • Testing to verify that the change does not adversely impact system security. 
  • For bespoke and custom software changes, all updates are tested for compliance with Requirement 6.2.4 before being deployed into production. 
  • Procedures to address failures and return to a secure state. 
Customized Approach Objective:
All changes are tracked, authorized, and evaluated for impact and security, and changes are managed to avoid unintended effects to the security of system components. 

Defined Approach Testing Procedures:
  • 6.5.1.a Examine documented change control procedures to verify procedures are defined for changes to all system components in the production environment to include all elements specified in this requirement. 
  • 6.5.1.b Examine recent changes to system components and trace those changes back to related change control documentation. For each change examined, verify the change is implemented in accordance with all elements specified in this requirement. 
Purpose:
Change management procedures must be applied to all changes—including the addition, removal, or modification of any system component—in the production environment. It is important to document the reason for a change and the change description so that relevant parties understand and agree the change is needed. Likewise, documenting the impacts of the change allows all affected parties to plan appropriately for any processing changes. 

Good Practice:
Approval by authorized parties confirms that the change is legitimate and that the change is sanctioned by the organization. Changes should be approved by individuals with the appropriate authority and knowledge to understand the impact of the change. 
Thorough testing by the entity confirms that the security of the environment is not reduced by implementing a change and that all existing security controls either remain in place or are replaced with equal or stronger security controls after the change. The specific testing to be performed will vary according to the type of change and system component(s) affected.
For each change, it is important to have documented procedures that address any failures and provide instructions on how to return to a secure state in case the change fails or adversely affects the security of an application or system. These procedures will allow the application or system to be restored to its previous secure state. 
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 11.3 CSC 11.3 Use Automated Tools to Verify Standard Device Configurations and Detect Changes
Compare all network device configuration against approved security configurations defined for each network device in use, and alert when any deviations are discovered.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
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.
Надлежащая практика:
Изменения должны быть одобрены лицами, обладающими соответствующими полномочиями и знаниями, чтобы оценить возможное негативное влияние изменений. Проверка должна обеспечивать уверенность в том, что изменение не оказало отрицательного влияния на безопасность сети и что изменения выполнены должным образом. 
Чтобы избежать необходимости устранять проблемы безопасности, вызванные изменением, все изменения должны быть одобрены до внедрения и проверены после внедрения изменения. После утверждения и проверки сетевая документация должна быть обновлена, чтобы включить изменения и предотвратить несоответствия между сетевой документацией и фактической конфигурацией.
Requirement 6.5.1
6.5.1
Определенные Требования к Подходу:
Изменения во всех компонентах системы в производственной среде вносятся в соответствии с установленными процедурами, которые включают:
  • Причина и описание изменения. 
  • Документирование воздействия на безопасность.
  • Документально подтвержденное одобрение изменений уполномоченными сторонами.
  • Тестирование, чтобы убедиться, что изменение не оказывает негативного влияния на безопасность системы.
  • При внесении изменений в программное обеспечение по индивидуальному заказу все обновления проверяются на соответствие требованиям 6.2.4 перед внедрением в производство.
  • Процедуры устранения сбоев и возврата в безопасное состояние.
Цель Индивидуального подхода:
Все изменения отслеживаются, санкционируются и оцениваются на предмет воздействия и безопасности, а также управляются изменениями, чтобы избежать непреднамеренных последствий для безопасности компонентов системы.

Определенные Процедуры Тестирования Подхода:
  • 6.5.1.a Изучите документированные процедуры контроля изменений, чтобы убедиться, что процедуры определены для изменений всех компонентов системы в производственной среде, чтобы включить все элементы, указанные в этом требовании.
  • 6.5.1.b Изучите последние изменения в компонентах системы и проследите эти изменения до соответствующей документации по управлению изменениями. Для каждого проверенного изменения убедитесь, что изменение реализовано в соответствии со всеми элементами, указанными в этом требовании.
Цель:
Процедуры управления изменениями должны применяться ко всем изменениям — включая добавление, удаление или модификацию любого компонента системы — в производственной среде. Важно задокументировать причину изменения и описание изменения, чтобы соответствующие стороны поняли и согласились с необходимостью изменения. Аналогичным образом, документирование последствий изменений позволяет всем затронутым сторонам надлежащим образом планировать любые изменения в обработке.

Надлежащая практика:
Одобрение уполномоченными сторонами подтверждает, что изменение является законным и что изменение санкционировано организацией. Изменения должны быть одобрены лицами, обладающими соответствующими полномочиями и знаниями, чтобы понять влияние изменений.
Тщательное тестирование организацией подтверждает, что безопасность среды не снижается при внедрении изменений и что все существующие средства контроля безопасности либо остаются на месте, либо заменяются равными или более сильными средствами контроля безопасности после изменения. Конкретное тестирование, которое необходимо выполнить, будет варьироваться в зависимости от типа изменения и затронутого(ых) компонента(ов) системы.
Для каждого изменения важно иметь документированные процедуры, которые устраняют любые сбои и предоставляют инструкции о том, как вернуться в безопасное состояние в случае сбоя изменения или отрицательного влияния на безопасность приложения или системы. Эти процедуры позволят восстановить приложение или систему в прежнее безопасное состояние.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
ЗСВ.7 ЗСВ.7 Контроль целостности виртуальной инфраструктуры и ее конфигураций
Методика экспресс-оценки уровня кибербезопасности организации РезБез:
7.1.1.
Разработаны и применяются стандарты безопасных конфигураций
7.1.1.2.
Требования к настройке безопасных конфигураций регулярно пересматриваются и поддерживаются в актуальном состоянии
7.1.1.1.
Осуществляется непрерывный автоматизированный контроль соответствия конфигураций установленным требованиям безопасности
NIST Cybersecurity Framework (EN):
PR.IP-3 PR.IP-3: Configuration change control processes are in place
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.8.9
А.8.9 Configuration management
Configurations, including security configurations, of hardware, software, services and networks shall be established, documented, implemented, monitored and reviewed.

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

Ничего не найдено

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