Раздел PR.IP-3 NIST CSF (ru) - Контроль соответствия

ГОСТ Р № 22301 от 01.01.2022 "Надежность в технике. Системы менеджмента непрерывности деятельности. Требования":

Р. 6 п. 3

6.3 Планирование изменений в системе менеджмента непрерывностью деятельности
Если организация определяет необходимость изменений в СМНД, включая определенные в разделе 10, изменения должны быть выполнены в плановом порядке.
Организация должна учитывать:

а) цель изменений и их возможные последствия;
b) обеспечение целостности СМНД;
с) наличие ресурсов;
d) распределение или перераспределение обязанностей и полномочий.

Р. 8 п. 4 пп. 1

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

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

Организация должна определить и документировать планы и процедуры обеспечения непрерывности деятельности на основе выбранных стратегий и решений.
Процедуры должны:

а) быть конкретными е отношении немедленных действий, которые должны быть выполнены в период нарушения деятельности организации;
b) гибкими, чтобы реагировать на изменяющиеся внутренние и внешние условия в период нарушения деятельности организации;
с) фокусироваться на воздействии инцидентов, которые потенциально могут привести к нарушению деятельности организации;
d) результативно минимизировать воздействия путем выполнения соответствующих решений;
е) устанавливать функции и обязанности по выполнению задач внутри процедур.

Р. 8 п. 4 пп. 4 ппп. 2

8.4.4.2 В совокупности планы обеспечения непрерывности деятельности должны содержать:

а) подробное описание действий, которые команды должны предпринимать:

1) для продолжения или восстановления приоритетных видов деятельности в течение заранее установленного периода времени;
2) проведения мониторинга воздействия на нарушение деятельности организации и реагирования организации на них;

b) ссылки на предварительно установленные пороговые значения и процесс инициирования ответных действий;
с) процедуры, позволяющие доставлять товары и оказывать услуги в согласованном объеме;
d) детали управления непосредственными последствиями нарушения деятельности организации с учетом:

1) благосостояния физических лиц;
2) предупреждения дальнейших потерь или недоступности приоритетных видов деятельности;
3) воздействия на окружающую среду.

Р. 9 п. 3 пп. 3 ппп.1

9.3.3.1 Результаты анализа со стороны руководства должны включать решения, касающиеся возможностей постоянного улучшения и необходимости внесения изменений в СМНД для повышения ее результативности и эффективности, включая следующее:

а) изменения в области применения СМНД;
b) обновление анализа воздействий на деятельность, оценки риска, стратегий и решений и планов в области обеспечения непрерывности;
с) изменение процедур и средств управления для реагирования на внутренние или внешние проблемы, воздействующие на СМНД;
d) методы измерения результативности управления.

Р. 8 п. 1

8.1 Оперативное планирование и управление
Организация должна планировать, выполнять и контролировать процессы, необходимые для выполнения требований и осуществления действий, определенных в 6.1:

а) путем установления критериев состояния процессов;
b) осуществления контроля и управления процессами в соответствии с критериями;
с) хранения документированной информации в объеме, необходимом для уверенности в том. что процессы выполнены в соответствии с планом.

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

Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":

УКФ.2 УКФ.2 Управление изменениями конфигурации информационной системы и системы защиты персональных данных

УКФ.4 УКФ.4 Документирование информации (данных) об изменениях в конфигурации информационной системы и системы защиты персональных данных

ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":

УИ.4

УИ.4 Привлечение службы ИБ, а также, при необходимости, иных подразделений, формирующих «вторую линию защиты», в рамках процесса управления изменениями для:

выявления и идентификации риска реализации информационных угроз;
участия в разработке мероприятий, направленных на уменьшение негативного влияния от выявленного и идентифицированного риска реализации информационных угроз;
контроля за реализацией мероприятий, направленных на уменьшение негативного влияния от выявленного и идентифицированного риска реализации информационных угроз.

УИ.20

УИ.20 Разработка планов управления конфигурациями****** на первоначальных этапах жизненного цикла (разработка или приобретение) объектов информатизации, входящих в критичную архитектуру.

УИ.6.3

УИ.6.3 Реализации отдельных сред разработки, тестирования и постоянной эксплуатации, включая контроль переноса и целостности информации (данных) при переносе между указанными средами;

УИ.6.4

УИ.6.4 Контроля отсутствия известных (описанных) уязвимостей объектов информатизации.

УИ.6.1

УИ.6.1 Контроля соответствия заявленным целям внесения изменений;

УИ.15

УИ.15 Определение процедур по установлению, применению и контролю стандартов конфигурирования, определяющих заданный уровень и необходимые политики (режимы) защиты информации.

УИ.6.2

УИ.6.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.4

6.5.4
Defined Approach Requirements:
Roles and functions are separated between production and pre-production environments to provide accountability such that only reviewed and approved changes are deployed.

Customized Approach Objective:
Job roles and accountability that differentiate between pre-production and production activities are defined and managed to minimize the risk of unauthorized, unintentional, or inappropriate actions.

Applicability Notes:
In environments with limited personnel where individuals perform multiple roles or functions, this same goal can be achieved with additional procedural controls that provide accountability. For example, a developer may also be an administrator that uses an administrator-level account with elevated privileges in the development environment and, for their developer role, they use a separate account with user-level access to the production environment.

Defined Approach Testing Procedures:

6.5.4.a Examine policies and procedures to verify that processes are defined for separating roles and functions to provide accountability such that only reviewed and approved changes are deployed.
6.5.4.b Observe processes and interview personnel to verify implemented controls separate roles and functions and provide accountability such that only reviewed and approved changes are deployed.

Purpose:
The goal of separating roles and functions between production and pre-production environments is to reduce the number of personnel with access to the production environment and account data and thereby minimize risk of unauthorized, unintentional, or inappropriate access to data and system components and help ensure that access is limited to those individuals with a business need for such access.
The intent of this control is to separate critical activities to provide oversight and review to catch errors and minimize the chances of fraud or theft (since two people would need to collude in order to hide an activity).
Separating roles and functions, also referred to as separation or segregation of duties, is a key internal control concept to protect an entity’s assets.

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.

ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":

A.12.1.2

A.12.1.2 Процесс управления изменениями
Мера обеспечения информационной безопасности: Необходимо обеспечить управление изменениями в организации, бизнеспроцессах, средствах обработки информации и системах, влияющих на информационную безопасность

A.14.2.4

A.14.2.4 Ограничения на изменения пакетов программ
Мера обеспечения информационной безопасности: Следует избегать модификаций пакетов программ, ограничиваясь необходимыми изменениями, и строго контролировать все изменения

A.14.2.2

A.14.2.2 Процедуры управления изменениями системы
Мера обеспечения информационной безопасности: Необходимо управлять изменениями в системах в течение жизненного цикла разработки посредством применения формализованных процедур управления изменениями

A.12.5.1

A.12.5.1 Установка программного обеспечения в эксплуатируемых системах
Мера обеспечения информационной безопасности: Должны быть реализованы процедуры контроля установки программного обеспечения в системах, находящихся в эксплуатации

A.14.2.3

A.14.2.3 Техническая экспертиза приложений (прикладных программ) после изменений операционной платформы
Мера обеспечения информационной безопасности: При внесении изменений в операционные платформы критически важные для бизнеса приложения должны быть проверены и протестированы, чтобы обеспечить уверенность в отсутствии неблагоприятного воздействия на деятельность или безопасность организации

A.12.6.2

A.12.6.2 Ограничения на установку программного обеспечения
Мера обеспечения информационной безопасности: Должны быть установлены и реализованы правила, регулирующие установку программного обеспечения пользователями

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 6.5.4

6.5.4
Определенные Требования к Подходу:
Роли и функции разделены между производственной и предпроизводственной средами для обеспечения подотчетности таким образом, чтобы внедрялись только проверенные и утвержденные изменения.

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

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

Определенные Процедуры Тестирования Подхода:

6.5.4.a Изучите политики и процедуры, чтобы убедиться, что процессы определены для разделения ролей и функций для обеспечения подотчетности таким образом, чтобы внедрялись только проверенные и одобренные изменения.
6.5.4.b Наблюдать за процессами и проводить собеседования с персоналом для проверки внедренных средств контроля, разделения ролей и функций и обеспечения подотчетности таким образом, чтобы внедрялись только проверенные и одобренные изменения.

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

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 Изучите последние изменения в компонентах системы и проследите эти изменения до соответствующей документации по управлению изменениями. Для каждого проверенного изменения убедитесь, что изменение реализовано в соответствии со всеми элементами, указанными в этом требовании.

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

Надлежащая практика:
Одобрение уполномоченными сторонами подтверждает, что изменение является законным и что изменение санкционировано организацией. Изменения должны быть одобрены лицами, обладающими соответствующими полномочиями и знаниями, чтобы понять влияние изменений.
Тщательное тестирование организацией подтверждает, что безопасность среды не снижается при внедрении изменений и что все существующие средства контроля безопасности либо остаются на месте, либо заменяются равными или более сильными средствами контроля безопасности после изменения. Конкретное тестирование, которое необходимо выполнить, будет варьироваться в зависимости от типа изменения и затронутого(ых) компонента(ов) системы.
Для каждого изменения важно иметь документированные процедуры, которые устраняют любые сбои и предоставляют инструкции о том, как вернуться в безопасное состояние в случае сбоя изменения или отрицательного влияния на безопасность приложения или системы. Эти процедуры позволят восстановить приложение или систему в прежнее безопасное состояние.

Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":

А.8.25

А.8.25 Жизненный цикл безопасной разработки
Должны быть установлены и применяться правила безопасной разработки программного обеспечения и систем.

А.8.32

А.8.32 Управление изменениями
Изменения в средствах обработки информации и информационных системах должны быть объектом процедур управления изменениями.

А.8.9

А.8.9 Управление конфигурацией
Должны быть установлены, задокументированы, внедрены, быть объектом мониторинга и пересмотра конфигурации, включая конфигурации безопасности, аппаратного и программного обеспечения, а также конфигурации услуг и сетей.

Методика экспресс-оценки уровня кибербезопасности организации РезБез:

7.1.1.

Разработаны и применяются стандарты безопасных конфигураций

7.1.2.

Осуществляется периодический контроль соответствия конфигураций установленным требованиям безопасности

Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":

УКФ.2 УКФ.2 Управление изменениями

УКФ.4 УКФ.4 Контроль действий по внесению изменений

NIST Cybersecurity Framework (EN):

PR.IP-3 PR.IP-3: Configuration change control processes are in place

Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":

УКФ.2 УКФ.2 Управление изменениями

УКФ.4 УКФ.4 Контроль действий по внесению изменений

Стандарт № 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.

А.8.32

А.8.32 Change management
Changes to information processing facilities and information systems shall be subject to change management procedures.

А.8.25

А.8.25 Secure development life cycle
Rules for the secure development of software and systems shall be established and applied.

NIST Cybersecurity Framework (RU)

Framework

PR.IP-3

Список требований

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

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