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

ГОСТ Р № 57580.1-2017 от 01.01.2018

Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации

УЗП.5

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

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

ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
ФД.1
ФД.1 Документарное определение правил предоставления физического доступа
3-Н 2-О 1-О
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
УПД.5 УПД.5 Назначение минимально необходимых прав и привилегий пользователям, администраторам и лицам, обеспечивающим функционирование информационной системы
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 7.2.3
7.2.3
Defined Approach Requirements: 
Required privileges are approved by authorized personnel 

Customized Approach Objective:
Access privileges cannot be granted to users without appropriate, documented authorization. 

Defined Approach Testing Procedures:
  • 7.2.3.a Examine policies and procedures to verify they define processes for approval of all privileges by authorized personnel. 
  • 7.2.3.b Examine user IDs and assigned privileges, and compare with documented approvals to verify that: 
    • Documented approval exists for the assigned privileges. 
    • The approval was by authorized personnel. 
    • Specified privileges match the roles assigned to the individual. 
Purpose:
Documented approval (for example, in writing or electronically) assures that those with access and privileges are known and authorized by management, and that their access is necessary for their job function. 
Requirement 7.2.1
7.2.1
Defined Approach Requirements: 
An access control model is defined and includes granting access as follows: 
  • Appropriate access depending on the entity’s business and access needs.
  • Access to system components and data resources that is based on users’ job classification and functions.
  • The least privileges required (for example, user, administrator) to perform a job function. 
Customized Approach Objective:
Access requirements are established according to job functions following least-privilege and need-toknow principles 

Defined Approach Testing Procedures:
  • 7.2.1.a Examine documented policies and procedures and interview personnel to verify the access control model is defined in accordance with all elements specified in this requirement. 
  • 7.2.1.b Examine access control model settings and verify that access needs are appropriately defined in accordance with all elements specified in this requirement. 
Purpose:
Defining an access control model that is appropriate for the entity’s technology and access control philosophy supports a consistent and uniform way of allocating access and reduces the possibility of errors such as the granting of excessive rights. 

Good Practice:
A factor to consider when defining access needs is the separation of duties principle. This principle is intended to prevent fraud and misuse or theft of resources. For example, 1) dividing missioncritical functions and information system support functions among different individuals and/or functions, 2) establishing roles such that information system support activities are performed by different functions/individuals (for example, system management, programming, configuration management, quality assurance and testing, and network security), and 3) ensuring security personnel administering access control functions do not also administer audit functions. 
In environments where one individual performs multiple functions, such as administration and security operations, duties may be assigned so that no single individual has end-to-end control of a process without an independent checkpoint. For example, responsibility for configuration and responsibility for approving changes could be assigned to separate individuals. 

Definitions:
Key elements of an access control model include:
  • Resources to be protected (the systems/devices/data to which access is needed), 
  • Job functions that need access to the resource (for example, system administrator, call-center personnel, store clerk), and 
  • Which activities each job function needs to perform (for example, read/write or query). 
Once job functions, resources, and activities per job functions are defined, individuals can be granted access accordingly. 

Examples:
Access control models that entities can consider include role-based access control (RBAC) and attribute-based access control (ABAC). The access control model used by a given entity depends on their business and access needs. 
Guideline for a healthy information system v.2.0 (EN):
9 STANDARD
/STANDARD 
Some of the system’s resources can be a source of invaluable information from the hacher’s point of view (folders containing sensitive data, databases, mailboxes, etc.). It is therefore essential to establish an accurate list of these resources and for each of them:
  • define which group can have access to them;
  • strictly control access, by ensuring that users are authenticated and are part of the target group;
  • avoid their circulation and duplication to uncontrolled areas or areas subject to a less strict access control. 
For example, the folders of administrators bringing together various pieces of sensitive information must be subject to specific access control. The same goes for sensitive information present on network shares: exports of configuration files, information system technical documentation, business databases, etc. A regular review of the access rights must, moreover, be carried out, in order to identify any unauthorised access 
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.9.2.1
A.9.2.1 Регистрация и отмена регистрации пользователей 
Мера обеспечения информационной безопасности: Для назначения прав доступа должна быть реализована формализованная процедура регистрации и отмены регистрации пользователей 
A.9.2.2
A.9.2.2 Предоставление пользователю права доступа 
Мера обеспечения информационной безопасности: Должен быть реализован формализованный процесс назначения или отмены прав доступа пользователей к системам и сервисам 
Положение Банка России № 802-П от 25.07.2022 "О требованиях к защите информации в платежной системе Банка России":
П. 7 п.п. 1
7.1. Участники ССНП, участники СБП, ОПКЦ СБП и ОУИО СБП должны разработать и утвердить внутренние документы, регламентирующие выполнение следующих процессов (направлений) защиты информации в рамках процессов (направлений) защиты информации, предусмотренных подпунктом 7.1.1 пункта 7.1 раздела 7 ГОСТ Р 57580.1-2017:
  • обеспечение защиты информации при управлении доступом;
  • обеспечение защиты вычислительных сетей;
  • контроль целостности и защищенности информационной инфраструктуры;
  • защита от вредоносного кода;
  • предотвращение утечек информации;
  • управление инцидентами защиты информации;
  • защита среды виртуализации;
  • защита информации при осуществлении удаленного логического доступа с использованием мобильных (переносных) устройств.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
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 7.2.1
7.2.1
Определенные Требования к Подходу:
Определена модель управления доступом, которая включает в себя предоставление доступа следующим образом:
  • Соответствующий доступ в зависимости от бизнеса организации и потребностей в доступе.
  • Доступ к системным компонентам и ресурсам данных, основанный на классификации и функциях пользователей.
  • Наименьшие привилегии, необходимые (например, пользователь, администратор) для выполнения рабочей функции.
Цель Индивидуального подхода:
Требования к доступу устанавливаются в соответствии с должностными функциями в соответствии с принципами наименьших привилегий и необходимости знать

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

Надлежащая практика:
Фактором, который следует учитывать при определении потребностей в доступе, является принцип разделения обязанностей. Этот принцип предназначен для предотвращения мошенничества и неправильного использования или кражи ресурсов. Например, 1) разделение критически важных функций и функций поддержки информационной системы между различными лицами и/или функциями, 2) установление ролей таким образом, чтобы деятельность по поддержке информационной системы выполнялась различными функциями/лицами (например, управление системой, программирование, управление конфигурацией, обеспечение качества и тестирование, а также сетевая безопасность), и 3) обеспечение того, чтобы сотрудники службы безопасности, выполняющие функции контроля доступа, не выполняли также функции аудита.
В средах, где один человек выполняет несколько функций, таких как администрирование и операции безопасности, обязанности могут быть распределены таким образом, чтобы ни один отдельный человек не имел сквозного контроля над процессом без независимой контрольной точки. Например, ответственность за настройку и ответственность за утверждение изменений могут быть возложены на отдельных лиц.

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

Примеры:
Модели управления доступом, которые могут учитывать организации, включают управление доступом на основе ролей (RBAC) и управление доступом на основе атрибутов (ABAC). Модель управления доступом, используемая данной организацией, зависит от их бизнеса и потребностей в доступе.
Requirement 7.2.3
7.2.3
Определенные Требования к Подходу:
Необходимые привилегии утверждаются уполномоченным персоналом

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

Определенные Процедуры Тестирования Подхода:
  • 7.2.3.a Изучите политики и процедуры, чтобы убедиться, что они определяют процессы утверждения всех привилегий уполномоченным персоналом.
  • 7.2.3.b Проверьте идентификаторы пользователей и назначенные привилегии и сравните с документально подтвержденными утверждениями, чтобы убедиться, что:
    • Для присвоенных привилегий существует документально подтвержденное утверждение.
    • Одобрение было получено уполномоченным персоналом.
    • Указанные привилегии соответствуют ролям, назначенным данному лицу.
Цель:
Документально оформленное одобрение (например, в письменной или электронной форме) гарантирует, что лица, обладающие доступом и привилегиями, известны и авторизованы руководством, и что их доступ необходим для выполнения их должностных функций.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
УПД.5 УПД.5 Назначение минимально необходимых прав и привилегий пользователям, администраторам и лицам, обеспечивающим функционирование информационной системы
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.5.18
А.5.18 Права доступа
Права доступа к информационным и иным связанным с ней активам должны предоставляться, пересматриваться, изменяться и удаляться в соответствии с специфической тематической политикой и правилами управления доступом организации.
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
УПД.5 УПД.5 Назначение минимально необходимых прав и привилегий
УПД.0 УПД.0 Разработка политики управления доступом
Приказ ФСБ России № 378 от 10.07.2014 "Состав и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации":
Глава II п. 5
5. В соответствии с пунктом 13 Требований к защите персональных данных при их обработке в информационных системах персональных данных, утвержденных постановлением Правительства Российской Федерации от 1 ноября 2012 г. N 1119 (далее - Требования к защите персональных данных), для обеспечения 4 уровня защищенности персональных данных при их обработке в информационных системах необходимо выполнение следующих требований:
  • а) организация режима обеспечения безопасности помещений, в которых размещена информационная система, препятствующего возможности неконтролируемого проникновения или пребывания в этих помещениях лиц, не имеющих права доступа в эти помещения;
  • б) обеспечение сохранности носителей персональных данных;
  • в) утверждение руководителем оператора документа, определяющего перечень лиц, доступ которых к персональным данным, обрабатываемым в информационной системе, необходим для выполнения ими служебных (трудовых) обязанностей;
  • г) использование средств защиты информации, прошедших процедуру оценки соответствия требованиям законодательства Российской Федерации в области обеспечения безопасности информации, в случае, когда применение таких средств необходимо для нейтрализации актуальных угроз.
Глава II п. 6
6. Для выполнения требования, указанного в подпункте "а" пункта 5 настоящего документа, необходимо обеспечение режима, препятствующего возможности неконтролируемого проникновения или пребывания в помещениях, где размещены используемые СКЗИ, хранятся СКЗИ и (или) носители ключевой, аутентифицирующей и парольной информации СКЗИ (далее - Помещения), лиц, не имеющих права доступа в Помещения, которое достигается путем:
  • а) оснащения Помещений входными дверьми с замками, обеспечения постоянного закрытия дверей Помещений на замок и их открытия только для санкционированного прохода, а также опечатывания Помещений по окончании рабочего дня или оборудование Помещений соответствующими техническими устройствами, сигнализирующими о несанкционированном вскрытии Помещений;
  • б) утверждения правил доступа в Помещения в рабочее и нерабочее время, а также в нештатных ситуациях;
  • в) утверждения перечня лиц, имеющих право доступа в Помещения.
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
УПД.0 УПД.0 Регламентация правил и процедур управления доступом
УПД.5 УПД.5 Назначение минимально необходимых прав и привилегий
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.5.18
А.5.18 Access rights
Access rights to information and other associated assets shall be provisioned, reviewed, modified and removed in accordance with the organization’s topic-specific policy on and rules for access control.

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

Ничего не найдено

Заметки

1
11 месяцев назад
В стандартном уровне не меняется