Куда я попал?
Приказ ФСТЭК России № 21 от 18.02.2013
Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных
УКФ.2
Для проведения оценки соответствия по документу войдите в систему.
Список требований
-
УКФ.2 Управление изменениями конфигурации информационной системы и системы защиты персональных данныхОбязательно для уровня защищенности УЗ1 УЗ2 УЗ3
Похожие требования
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 9. Требования к защите информации на этапах жизненного цикла автоматизированных систем и приложений":
ЖЦ.4
ЖЦ.4 Реализация управления версиями (сборками) и изменениями создаваемого (модернизируемого), в том числе тестируемого, прикладного ПО АС, осуществляемого для цели:
- контроля реализации функций защиты информации в определенной версии (сборке) прикладного ПО;
- принятия мер, препятствующих несанкционированному внесению изменений в версии (сборки) прикладного ПО
3-Н 2-О 1-О
Положение Банка России № 787-П от 12.01.2022 "Обязательные для кредитных организаций требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг":
п. 6. п.п. 2
6.2. Кредитные организации должны обеспечивать выполнение следующих требований к управлению изменениями критичной архитектуры:
- управление уязвимостями в критичной архитектуре, из-за которых могут реализоваться информационные угрозы и которые могут повлечь превышение значений целевых показателей операционной надежности;
- планирование и внедрение изменений в критичной архитектуре, направленных на обеспечение недопустимости неоказания или ненадлежащего оказания банковских услуг;
- управление конфигурациями (настраиваемыми параметрами) объектов информационной инфраструктуры;
- управление уязвимостями и обновлениями (исправлениями) объектов информационной инфраструктуры.
NIST Cybersecurity Framework (RU):
PR.IP-3
PR.IP-3: Реализованы процессы контроля изменений конфигурации
PR.IP-1
PR.IP-1: С учетом соответствующих принципов безопасности (например, концепция минимальной функциональности) создается и поддерживается базовая конфигурация информационных технологий / промышленных систем управления
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
УИ.4
УИ.4 Привлечение службы ИБ, а также, при необходимости, иных подразделений, формирующих «вторую линию защиты», в рамках процесса управления изменениями для:
- выявления и идентификации риска реализации информационных угроз;
- участия в разработке мероприятий, направленных на уменьшение негативного влияния от выявленного и идентифицированного риска реализации информационных угроз;
- контроля за реализацией мероприятий, направленных на уменьшение негативного влияния от выявленного и идентифицированного риска реализации информационных угроз.
УИ.7
УИ.7 Реализация механизма последующего контроля внесенных изменений в критичную архитектуру, в том числе в части соблюдения установленных требований к процессу внесения изменений.
УИ.6.4
УИ.6.4 Контроля отсутствия известных (описанных) уязвимостей объектов информатизации.
УИ.6.1
УИ.6.1 Контроля соответствия заявленным целям внесения изменений;
УИ.6.2
УИ.6.2 Контроля требований безопасности вносимых изменений;
УИ.21
УИ.21 Управление конфигурациями объектов информатизации на этапах жизненного цикла, связанных с установкой (внедрением), обновлением (модификацией) и удалением (уничтожением) объектов информатизации.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
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:
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:
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.
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 18.11
CSC 18.11 Use Standard Hardening Configuration Templates for Databases
For applications that rely on a database, use standard hardening configuration templates. All systems that are part of critical business processes should also be tested.
For applications that rely on a database, use standard hardening configuration templates. All systems that are part of critical business processes should also be tested.
CSC 11.2
CSC 11.2 Document Traffic Configuration Rules
All configuration rules that allow traffic to flow through network devices should be documented in a configuration management system with a specific business reason for each rule, a specific individual’s name responsible for that business need, and an expected duration of the need.
All configuration rules that allow traffic to flow through network devices should be documented in a configuration management system with a specific business reason for each rule, a specific individual’s name responsible for that business need, and an expected duration of the need.
CSC 11.1
CSC 11.1 Maintain Standard Security Configurations for Network Devices
Maintain documented security configuration standards for all authorized network devices.
Maintain documented security configuration standards for all authorized network devices.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 6.5.1
6.5.1
Определенные Требования к Подходу:
Изменения во всех компонентах системы в производственной среде вносятся в соответствии с установленными процедурами, которые включают:
Определенные Требования к Подходу:
Изменения во всех компонентах системы в производственной среде вносятся в соответствии с установленными процедурами, которые включают:
- Причина и описание изменения.
- Документирование воздействия на безопасность.
- Документально подтвержденное одобрение изменений уполномоченными сторонами.
- Тестирование, чтобы убедиться, что изменение не оказывает негативного влияния на безопасность системы.
- При внесении изменений в программное обеспечение по индивидуальному заказу все обновления проверяются на соответствие требованиям 6.2.4 перед внедрением в производство.
- Процедуры устранения сбоев и возврата в безопасное состояние.
Цель Индивидуального подхода:
Все изменения отслеживаются, санкционируются и оцениваются на предмет воздействия и безопасности, а также управляются изменениями, чтобы избежать непреднамеренных последствий для безопасности компонентов системы.
Определенные Процедуры Тестирования Подхода:
Все изменения отслеживаются, санкционируются и оцениваются на предмет воздействия и безопасности, а также управляются изменениями, чтобы избежать непреднамеренных последствий для безопасности компонентов системы.
Определенные Процедуры Тестирования Подхода:
- 6.5.1.a Изучите документированные процедуры контроля изменений, чтобы убедиться, что процедуры определены для изменений всех компонентов системы в производственной среде, чтобы включить все элементы, указанные в этом требовании.
- 6.5.1.b Изучите последние изменения в компонентах системы и проследите эти изменения до соответствующей документации по управлению изменениями. Для каждого проверенного изменения убедитесь, что изменение реализовано в соответствии со всеми элементами, указанными в этом требовании.
Цель:
Процедуры управления изменениями должны применяться ко всем изменениям — включая добавление, удаление или модификацию любого компонента системы — в производственной среде. Важно задокументировать причину изменения и описание изменения, чтобы соответствующие стороны поняли и согласились с необходимостью изменения. Аналогичным образом, документирование последствий изменений позволяет всем затронутым сторонам надлежащим образом планировать любые изменения в обработке.
Надлежащая практика:
Одобрение уполномоченными сторонами подтверждает, что изменение является законным и что изменение санкционировано организацией. Изменения должны быть одобрены лицами, обладающими соответствующими полномочиями и знаниями, чтобы понять влияние изменений.
Тщательное тестирование организацией подтверждает, что безопасность среды не снижается при внедрении изменений и что все существующие средства контроля безопасности либо остаются на месте, либо заменяются равными или более сильными средствами контроля безопасности после изменения. Конкретное тестирование, которое необходимо выполнить, будет варьироваться в зависимости от типа изменения и затронутого(ых) компонента(ов) системы.
Для каждого изменения важно иметь документированные процедуры, которые устраняют любые сбои и предоставляют инструкции о том, как вернуться в безопасное состояние в случае сбоя изменения или отрицательного влияния на безопасность приложения или системы. Эти процедуры позволят восстановить приложение или систему в прежнее безопасное состояние.
Процедуры управления изменениями должны применяться ко всем изменениям — включая добавление, удаление или модификацию любого компонента системы — в производственной среде. Важно задокументировать причину изменения и описание изменения, чтобы соответствующие стороны поняли и согласились с необходимостью изменения. Аналогичным образом, документирование последствий изменений позволяет всем затронутым сторонам надлежащим образом планировать любые изменения в обработке.
Надлежащая практика:
Одобрение уполномоченными сторонами подтверждает, что изменение является законным и что изменение санкционировано организацией. Изменения должны быть одобрены лицами, обладающими соответствующими полномочиями и знаниями, чтобы понять влияние изменений.
Тщательное тестирование организацией подтверждает, что безопасность среды не снижается при внедрении изменений и что все существующие средства контроля безопасности либо остаются на месте, либо заменяются равными или более сильными средствами контроля безопасности после изменения. Конкретное тестирование, которое необходимо выполнить, будет варьироваться в зависимости от типа изменения и затронутого(ых) компонента(ов) системы.
Для каждого изменения важно иметь документированные процедуры, которые устраняют любые сбои и предоставляют инструкции о том, как вернуться в безопасное состояние в случае сбоя изменения или отрицательного влияния на безопасность приложения или системы. Эти процедуры позволят восстановить приложение или систему в прежнее безопасное состояние.
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.8.32
А.8.32 Управление изменениями
Изменения в средствах обработки информации и информационных системах должны быть объектом процедур управления изменениями.
Изменения в средствах обработки информации и информационных системах должны быть объектом процедур управления изменениями.
А.8.9
А.8.9 Управление конфигурацией
Должны быть установлены, задокументированы, внедрены, быть объектом мониторинга и пересмотра конфигурации, включая конфигурации безопасности, аппаратного и программного обеспечения, а также конфигурации услуг и сетей.
Должны быть установлены, задокументированы, внедрены, быть объектом мониторинга и пересмотра конфигурации, включая конфигурации безопасности, аппаратного и программного обеспечения, а также конфигурации услуг и сетей.
SWIFT Customer Security Controls Framework v2022:
2 - 2.3 System Hardening
2.3 System Hardening
2 - 2.10 Application Hardening
2.10 Application Hardening
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
УКФ.2
УКФ.2 Управление изменениями
Положение Банка России № 779-П от 15.11.2021 "Обязательные для некредитных финансовых организаций требований к операционной надежности при осуществлении видов деятельности, предусмотренных частью первой статьи 76.1 Федерального закона от 10 июля 2002 года N 86-ФЗ "О Центральном банке"":
п. 1.5.
1.5. Некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, в рамках обеспечения операционной надежности должны обеспечивать выполнение следующих требований в отношении управления изменениями критичной архитектуры:
- управление уязвимостями в критичной архитектуре, с использованием которых могут реализоваться информационные угрозы и которые могут повлечь отклонение от значений целевых показателей операционной надежности, указанных в пункте 1.3 настоящего Положения;
- планирование и внедрение изменений в критичной архитектуре, направленных на обеспечение непрерывного оказания финансовых услуг;
- управление конфигурациями объектов информационной инфраструктуры некредитных финансовых организаций;
- управление уязвимостями и обновлениями (исправлениями) объектов информационной инфраструктуры некредитных финансовых организаций.
NIST Cybersecurity Framework (EN):
PR.IP-3
PR.IP-3: Configuration change control processes are in place
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
УКФ.2
УКФ.2 Управление изменениями
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
12.1.2
12.1.2 Процесс управления изменениями
Мера обеспечения ИБ
Необходимо обеспечить управление изменениями в организации, бизнес-процессах, средствах обработки информации и системах, влияющих на ИБ.
Руководство по применению
В частности, необходимо принять во внимание следующее:
- a) идентификацию и регистрацию существенных изменений;
- b) планирование и тестирование изменений;
- c) оценку потенциального влияния от реализации существенных изменений, включая влияние на ИБ;
- d) процедуры утверждения предлагаемых изменений;
- e) подтверждение того, что выполняются требования по ИБ;
- f) информирование об изменении всех заинтересованных лиц;
- g) процедуры по возврату в исходное состояние, включая процедуры и обязанности по прерыванию процесса и последующего восстановления после неудачных изменений и непредвиденных событий;
- h) установление процесса экстренного изменения для обеспечения быстрой и управляемой реализации изменений, необходимых для разрешения инцидента (см. 16.1).
С целью обеспечения уверенности в надлежащем контроле всех изменений должна быть формально определена ответственность и разработаны соответствующие процедуры управления. При внесении изменений вся необходимая информация должна быть сохранена в контрольном журнале.
Дополнительная информация
Неадекватный контроль над изменениями в средствах и системах обработки информации является распространенной причиной системных сбоев или нарушений безопасности (см. 14.2.2).
Стандарт № 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.
Configurations, including security configurations, of hardware, software, services and networks shall be established, documented, implemented, monitored and reviewed.
А.8.32
А.8.32 Change management
Changes to information processing facilities and information systems shall be subject to change management procedures.
Changes to information processing facilities and information systems shall be subject to change management procedures.
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.