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

NIST Cybersecurity Framework (EN)

Framework

PR.IP-3

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

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

NIST Cybersecurity Framework (RU):
PR.IP-3
PR.IP-3: Реализованы процессы контроля изменений конфигурации 
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
УКФ.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.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.
Надлежащая практика:
Изменения должны быть одобрены лицами, обладающими соответствующими полномочиями и знаниями, чтобы оценить возможное негативное влияние изменений. Проверка должна обеспечивать уверенность в том, что изменение не оказало отрицательного влияния на безопасность сети и что изменения выполнены должным образом. 
Чтобы избежать необходимости устранять проблемы безопасности, вызванные изменением, все изменения должны быть одобрены до внедрения и проверены после внедрения изменения. После утверждения и проверки сетевая документация должна быть обновлена, чтобы включить изменения и предотвратить несоответствия между сетевой документацией и фактической конфигурацией.
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
УКФ.2 УКФ.2 Управление изменениями
УКФ.4 УКФ.4 Контроль действий по внесению изменений
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
УКФ.2 УКФ.2 Управление изменениями
УКФ.4 УКФ.4 Контроль действий по внесению изменений

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

3
Название Дата Влияние
Community
2 21 / 118
Ограничение запуска неизвестного ПО с помощью Windows SmartScreen
Постоянно Автоматически Техническая Превентивная
16.02.2022
16.02.2022 2 21 / 118
Цель: запрет выполнения неизвестного ПО на ПК и серверах под управлением ОС Windows. 
Windows SmartScreen повышает безопасность ПК, предупреждая пользователей перед запуском неопознанных программ, загруженных из Интернета. При этом в Майкрософт отправляются сведения о файлах и программах, выполняемых на ПК с включенной функцией SmartScreen.
Если этот параметр политики включен, поведением Windows SmartScreen можно управлять путем установки одного из следующих параметров:
  • Требовать подтверждения администратора, прежде чем запускать загруженное неизвестное ПО
  • Предупреждать пользователя, прежде чем выполнять загруженное неизвестное ПО
  • Выключить SmartScreen
Настройка с помощью групповой политики: 
Конфигурация компьютера\Административные шаблоны\Компоненты Windows\Проводник.
Параметр: Настроить Windows SmartScreen.
Значение: Включено, требовать подтверждения администратора, прежде чем запускать загруженное неизвестное ПО

Подробнее: Фильтр SmartScreen в Microsoft Defender

Рекомендации к заполнению карточки: