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

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

Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости

ОПО.0

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

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

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

Положение Банка России № 787-П от 12.01.2022 "Обязательные для кредитных организаций требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг":
п. 6. п.п. 2
6.2. Кредитные организации должны обеспечивать выполнение следующих требований к управлению изменениями критичной архитектуры:
  • управление уязвимостями в критичной архитектуре, из-за которых могут реализоваться информационные угрозы и которые могут повлечь превышение значений целевых показателей операционной надежности;
  • планирование и внедрение изменений в критичной архитектуре, направленных на обеспечение недопустимости неоказания или ненадлежащего оказания банковских услуг;
  • управление конфигурациями (настраиваемыми параметрами) объектов информационной инфраструктуры;
  • управление уязвимостями и обновлениями (исправлениями) объектов информационной инфраструктуры.
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
ЦЗИ.28
ЦЗИ.28 Регистрация установки, обновления и (или) удаления ПО АС, ПО средств и систем защиты информации, системного ПО на серверном и сетевом оборудовании
3-Н 2-Т 1-Т
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
УИ.23.4
УИ.23.4 Документарное определение процедур, связанных с применением обновлений (исправлений).
УИ.25.3
УИ.25.3 Реализации процедур запрета применения обновлений (исправлений), которые предварительно не согласованы.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 6.1.2
6.1.2
Defined Approach Requirements: 
Roles and responsibilities for performing activities in Requirement 6 are documented, assigned, and understood. 

Customized Approach Objective:
Day-to-day responsibilities for performing all the activities in Requirement 6 are allocated. Personnel are accountable for successful, continuous operation of these requirements. 

Defined Approach Testing Procedures:
  • 6.1.2.a Examine documentation to verify that descriptions of roles and responsibilities for performing activities in Requirement 6 are documented and assigned. 
  • 6.1.2.b Interview personnel responsible for performing activities in Requirement 6 to verify that roles and responsibilities are assigned as documented and are understood. 
Purpose:
If roles and responsibilities are not formally assigned, systems will not be securely maintained, and their security level will be reduced. 

Good Practice:
Roles and responsibilities may be documented within policies and procedures or maintained within separate documents. 
As part of communicating roles and responsibilities, entities can consider having personnel acknowledge their acceptance and understanding of their assigned roles and responsibilities. 

Examples:
A method to document roles and responsibilities is a responsibility assignment matrix that includes who is responsible, accountable, consulted, and informed (also called a RACI matrix). 
Guideline for a healthy information system v.2.0 (EN):
34 STANDARD
/STANDARD
New flaws are regularly discovered at the heart of systems and software. These are generally access doors that a hacker can exploit for a successful intrusion into the information system. It is, therefore, vital to stay informed of new vulnerabilities (follow CERT- FR alerts) and to apply the corrective security actions over all of the components of the system within the month following their publication. An update policy must therefore be defined and be a part of operational procedures. 

These must specify:
  • the way in which the inventory of the information system components is carried out;
  • the sources of information relating to the publication of updates; 
  • the tools to deploy the corrective actions over the stock (for examples WSUS for updates for Microsoft components, free or paid tools for third party components and other operating systems);
  • the possible qualification of corrective measure and their gradual deployement over the stock. 
The obsolete components which are no longer supported by their manufacturers must be isolated from the rest of the system. This recommendation applies as much on the network level, by strict filtering of flows, as it does as regards the authentication secrets which must be dedicated to these systems. 
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.14.2.4
A.14.2.4 Ограничения на изменения пакетов программ 
Мера обеспечения информационной безопасности: Следует избегать модификаций пакетов программ, ограничиваясь необходимыми изменениями, и строго контролировать все изменения 
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 6.1.2
6.1.2
Определенные Требования к Подходу:
Роли и обязанности для выполнения действий, указанных в Требовании 6, задокументированы, распределены и поняты.

Цель Индивидуального подхода:
Распределяются повседневные обязанности по выполнению всех действий, указанных в Требовании 6. Персонал несет ответственность за успешное и непрерывное выполнение этих требований.

Определенные Процедуры Тестирования Подхода:
  • 6.1.2.a Изучите документацию, чтобы убедиться, что описания ролей и обязанностей для выполнения действий в Требовании 6 задокументированы и распределены. 
  • 6.1.2.b Провести собеседование с персоналом, ответственным за выполнение действий, указанных в Требовании 6, чтобы убедиться, что роли и обязанности распределены в соответствии с документацией и поняты.
Цель:
Если роли и обязанности официально не распределены, системы не будут надежно обслуживаться, и уровень их безопасности будет снижен.

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

Примеры:
Метод документирования ролей и обязанностей - это матрица распределения обязанностей, которая включает в себя, кто несет ответственность, подотчетен, консультируется и информируется (также называемая матрицей RACI).
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
ОПО.0 ОПО.0 Разработка политики управления обновлениями программного обеспечения
Положение Банка России № 779-П от 15.11.2021 "Обязательные для некредитных финансовых организаций требований к операционной надежности при осуществлении видов деятельности, предусмотренных частью первой статьи 76.1 Федерального закона от 10 июля 2002 года N 86-ФЗ "О Центральном банке"":
п. 1.5.
1.5. Некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, в рамках обеспечения операционной надежности должны обеспечивать выполнение следующих требований в отношении управления изменениями критичной архитектуры:
  • управление уязвимостями в критичной архитектуре, с использованием которых могут реализоваться информационные угрозы и которые могут повлечь отклонение от значений целевых показателей операционной надежности, указанных в пункте 1.3 настоящего Положения;
  • планирование и внедрение изменений в критичной архитектуре, направленных на обеспечение непрерывного оказания финансовых услуг;
  • управление конфигурациями объектов информационной инфраструктуры некредитных финансовых организаций;
  • управление уязвимостями и обновлениями (исправлениями) объектов информационной инфраструктуры некредитных финансовых организаций.