Приказ ФСТЭК России № 31 от 14.03.2014

РЗИ.5 Определение лиц, которым разрешены действия по внесению изменений в конфигурацию информационной инфраструктуры
3-О 2-О 1-О

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

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

ID.GV-1:  Установлена политика информационной безопасности организации 

УИ.2 Классификация в целях приоритизации изменений (например, плановые, срочные и критичные изменения) в критичную архитектуру.

УИ.1 Планирование, информирование вовлеченных подразделений о вносимых изменениях и контроль внесения изменений в критичную архитектуру.

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

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

УИ.3 Выявление, оценка и утверждение срочных и критичных изменений.

6.5.1
Defined Approach Requirements: 
Changes to all system components in the production environment are made according to established procedures that include: 

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:

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. 

2.1.1 
Defined Approach Requirements: 
All security policies and operational procedures that are identified in Requirement 2 are: 

Customized Approach Objective:
Expectations, controls, and oversight for meeting activities within Requirement 2 are defined and adhered to by affected personnel. All supporting activities are repeatable, consistently applied, and conform to management’s intent. 

Defined Approach Testing Procedures:

Purpose:
Requirement 2.1.1 is about effectively managing and maintaining the various policies and procedures specified throughout Requirement 2. While it is important to define the specific policies or procedures called out in Requirement 2, it is equally important to ensure they are properly documented, maintained, and disseminated. 

Good Practice:
It is important to update policies and procedures as needed to address changes in processes, technologies, and business objectives. For this reason, consider updating these documents as soon as possible after a change occurs and not only on a periodic cycle 

Definitions:
Security policies define the entity’s security objectives and principles. 
Operational procedures describe how to perform activities, and define the controls, methods, and processes that are followed to achieve the desired result in a consistent manner and in accordance with policy objectives. 

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

2.1.1
Определенные Требования к Подходу:
Все политики безопасности и операционные процедуры, указанные в Требовании 2:

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

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

Цель:
Требование 2.1.1 касается эффективного управления и поддержания различных политик и процедур, указанных в Требовании 2. Хотя важно определить конкретные политики или процедуры, указанные в Требовании 2, не менее важно обеспечить их надлежащее документирование, поддержание и распространение.

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

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

6.5.1
Определенные Требования к Подходу:
Изменения во всех компонентах системы в производственной среде вносятся в соответствии с установленными процедурами, которые включают:

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

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

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

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

А.8.28 Безопасная разработка
При разработке программного обеспечения должны применяться принципы безопасной разработки программного обеспечения.

А.5.1 Политики в области ИБ
Политика ИБ, а также специфические тематические политики должны быть определены, утверждены руководством, опубликованы, доведены до сведения соответствующего персонала и заинтересованных сторон, признаны ими; также эти политики должны пересматриваться через запланированные интервалы времени и в случае возникновения существенных изменений.

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

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

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

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

Если разработка осуществляется на аутсорсинге, организация должна получить гарантии того, что внешняя сторона соблюдает правила по безопасной разработке (см. 14.2.7).

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

А.8.28 Secure coding
Secure coding principles shall be applied to software development.

А.5.1 Policies for information security
Information security policy and topic-specific policies shall be defined, approved by management, published, communicated to and acknowledged by relevant personnel and relevant interested parties, and reviewed at planned intervals and if significant changes occur.

7.9.1. В целях обеспечения информационной безопасности: