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

NIST Cybersecurity Framework (RU)

Framework

PR.PT-3

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

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

Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
УПД.5 УПД.5 Назначение минимально необходимых прав и привилегий пользователям, администраторам и лицам, обеспечивающим функционирование информационной системы
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 7.2.5
7.2.5
Defined Approach Requirements: 
All application and system accounts and related access privileges are assigned and managed as follows:
  • Based on the least privileges necessary for the operability of the system or application. 
  • Access is limited to the systems, applications, or processes that specifically require their use. 
Customized Approach Objective:
Access rights granted to application and system accounts are limited to only the access needed for the operability of that application or system. 

Applicability Notes:
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. 
Defined Approach Testing Procedures:
  • 7.2.5.a Examine policies and procedures to verify they define processes to manage and assign application and system accounts and related access privileges in accordance with all elements specified in this requirement. 
  • 7.2.5.b Examine privileges associated with system and application accounts and interview responsible personnel to verify that application and system accounts and related access privileges are assigned and managed in accordance with all elements specified in this requirement. 
Purpose:
It is important to establish the appropriate access level for application or system accounts. If such accounts are compromised, malicious users will receive the same access level as that granted to the application or system. Therefore, it is important to ensure limited access is granted to system and application accounts on the same basis as to user accounts. 

Good Practice:
Entities may want to consider establishing a baseline when setting up these application and system accounts including the following as applicable to the organization:
  • Making sure that the account is not a member of a privileged group such as domain administrators, local administrators, or root.
  • Restricting which computers the account can be used on.
  • Restricting hours of use.
  • Removing any additional settings like VPN access and remote access. 
Requirement 2.2.3
2.2.3 
Defined Approach Requirements: 
Primary functions requiring different security levels are managed as follows:
  • Only one primary function exists on a system component, 
OR
  • Primary functions with differing security levels that exist on the same system component are isolated from each other, 
OR
  • Primary functions with differing security levels on the same system component are all secured to the level required by the function with the highest security need. 

Customized Approach Objective:
Primary functions with lower security needs cannot affect the security of primary functions with higher security needs on the same system component. 
Defined Approach Testing Procedures:
  • 2.2.3.a Examine system configuration standards to verify they include managing primary functions requiring different security levels as specified in this requirement. 
  • 2.2.3.b Examine system configurations to verify that primary functions requiring different security levels are managed per one of the ways specified in this requirement. 
  • 2.2.3.c Where virtualization technologies are used, examine the system configurations to verify that system functions requiring different security levels are managed in one of the following ways:
    • Functions with differing security needs do not co-exist on the same system component.
    • Functions with differing security needs that exist on the same system component are isolated from each other. 
    • Functions with differing security needs on the same system component are all secured to the level required by the function with the highest security need. 
Purpose:
Systems containing a combination of services, protocols, and daemons for their primary function will have a security profile appropriate to allow that function to operate effectively. For example, systems that need to be directly connected to the Internet would have a particular profile, like a DNS server, web server, or an e-commerce server. Conversely, other system components may operate a primary function comprising a different set of services, protocols, and daemons that performs functions that an entity does not want exposed to the Internet. This requirement aims to ensure that different functions do not impact the security profiles of other services in a way which may cause them to operate at a higher or lower security level. 

Good Practice:
Ideally, each function should be placed on different system components. This can be achieved by implementing only one primary function on each system component. Another option is to isolate primary functions on the same system component that have different security levels, for example, isolating web servers (which need to be directly connected to the Internet) from application and database servers. 
If a system component contains primary functions that need different security levels, a third option is to implement additional controls to ensure that the resultant security level of the primary function(s) with higher security needs is not reduced by the presence of the lower security primary functions. Additionally, the functions with a lower security level should be isolated and/or secured to ensure they cannot access or affect the resources of another system function, and do not introduce security weaknesses to other functions on the same server. 
Functions of differing security levels may be isolated by either physical or logical controls. For example, a database system should not also be hosting web services unless using controls like virtualization technologies to isolate and contain the functions into separate sub-systems. Another example is using virtual instances or providing dedicated memory access by system function. Where virtualization technologies are used, the security levels should be identified and managed for each virtual component. Examples of considerations for virtualized environments include:
  • The function of each application, container, or virtual server instance.
  • How virtual machines (VMs) or containers are stored and secured. 
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.9.1.2
А.9.1.2 Доступ к сетям и сетевым сервисам 
Мера обеспечения информационной безопасности: Пользователям следует предоставлять доступ только к тем сетям и сетевым сервисам, на использование которых они получили конкретное разрешение 
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 4.7 CSC 4.7 Limit Access to Script Tools
Limit access to scripting tools (such as Microsoft® PowerShell and Python) to only administrative or development users with the need to access those capabilities.
CSC 13.4 CSC 13.4 Only Allow Access to Authorized Cloud Storage or Email Providers
Only allow access to authorized cloud storage or email providers.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 2.2.3
2.2.3
Определенные Требования к Подходу:
Основные функции, требующие различных уровней безопасности, управляются следующим образом:
  • В системном компоненте существует только одна основная функция,
или
  • Основные функции с различными уровнями безопасности, существующие в одном и том же системном компоненте, изолированы друг от друга,
или
  • Все основные функции с различными уровнями безопасности в одном и том же системном компоненте защищены до уровня, требуемого функцией с наивысшими требованиями к безопасности.

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

Определенные Процедуры Тестирования Подхода:
  • 2.2.3.a Изучите стандарты конфигурации системы, чтобы убедиться, что они включают управление основными функциями, требующими различных уровней безопасности, как указано в этом требовании.
  • 2.2.3.b Изучите конфигурации системы, чтобы убедиться, что основные функции, требующие различных уровней безопасности, управляются одним из способов, указанных в этом требовании.
  • 2.2.3.c Там, где используются технологии виртуализации, изучите системные конфигурации, чтобы убедиться, что системные функции, требующие различных уровней безопасности, управляются одним из следующих способов:
    • Функции с различными требованиями к безопасности не могут сосуществовать в одном и том же системном компоненте.
    • Функции с различными требованиями к безопасности, существующие в одном и том же системном компоненте, изолированы друг от друга.
    • Функции с различными требованиями к безопасности в одном и том же системном компоненте защищены на уровне, требуемом функцией с самыми высокими требованиями к безопасности.
Цель:
Системы, содержащие комбинацию служб, протоколов и демонов для их основной функции, будут иметь профиль безопасности, соответствующий для обеспечения эффективной работы этой функции. Например, системы, которые должны быть напрямую подключены к Интернету, будут иметь определенный профиль, например DNS-сервер, веб-сервер или сервер электронной коммерции. И наоборот, другие системные компоненты могут выполнять основную функцию, содержащую другой набор служб, протоколов и демонов, которые выполняют функции, которые объект не хочет предоставлять в Интернет. Это требование направлено на обеспечение того, чтобы различные функции не влияли на профили безопасности других служб таким образом, который может привести к их работе на более высоком или более низком уровне безопасности.

Надлежащая практика:
В идеале каждая функция должна быть размещена на разных компонентах системы. Это может быть достигнуто путем реализации только одной основной функции для каждого компонента системы. Другим вариантом является изоляция основных функций в одном и том же системном компоненте, которые имеют разные уровни безопасности, например, изоляция веб-серверов (которые должны быть напрямую подключены к Интернету) от серверов приложений и баз данных.
Если системный компонент содержит основные функции, которым требуются разные уровни безопасности, третьим вариантом является внедрение дополнительных средств управления, чтобы гарантировать, что результирующий уровень безопасности основной функции (функций) с более высокими требованиями к безопасности не снижается из-за наличия основных функций с более низким уровнем безопасности. Кроме того, функции с более низким уровнем безопасности должны быть изолированы и/или защищены, чтобы гарантировать, что они не могут получить доступ к ресурсам другой системной функции или повлиять на них, и не создают слабых мест в безопасности для других функций на том же сервере.
Функции с различными уровнями безопасности могут быть изолированы с помощью физических или логических элементов управления. Например, система баз данных не должна также размещать веб-службы, если только не используются элементы управления, такие как технологии виртуализации, для изоляции и разделения функций на отдельные подсистемы. Другим примером является использование виртуальных экземпляров или предоставление доступа к выделенной памяти с помощью системной функции. Там, где используются технологии виртуализации, уровни безопасности должны быть определены и управляться для каждого виртуального компонента. 
Примеры соображений, касающихся виртуализированных сред, включают:
  • Функции каждого приложения, контейнера или экземпляра виртуального сервера. 
  • Как хранятся и защищаются виртуальные машины (виртуальные машины) или контейнеры.
Requirement 7.2.5
7.2.5
Определенные Требования к Подходу:
Все учетные записи приложений и системы и связанные с ними права доступа назначаются и управляются следующим образом:
  • На основе наименьших привилегий, необходимых для работоспособности системы или приложения.
  • Доступ ограничен системами, приложениями или процессами, которые конкретно требуют их использования.
Цель Индивидуального подхода:
Права доступа, предоставляемые учетным записям приложений и систем, ограничены только доступом, необходимым для работоспособности этого приложения или системы.

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

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

Надлежащая практика:
Организации могут захотеть рассмотреть возможность установления базовой линии при настройке этих учетных записей приложений и систем, включая следующее, если это применимо к организации:
  • Убедитесь, что учетная запись не является членом привилегированной группы, такой как администраторы домена, локальные администраторы или root.
  • Ограничение того, на каких компьютерах можно использовать учетную запись.
  • Ограничение часов использования.
  • Удаление любых дополнительных настроек, таких как VPN-доступ и удаленный доступ.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
УПД.5 УПД.5 Назначение минимально необходимых прав и привилегий пользователям, администраторам и лицам, обеспечивающим функционирование информационной системы
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.8.18
А.8.18 Использование привилегированных приложений
Должно быть ограничено и строго контролироваться использование приложений, способных преодолеть средства управления ИБ систем и приложений.
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
УПД.5 УПД.5 Назначение минимально необходимых прав и привилегий
NIST Cybersecurity Framework (EN):
PR.PT-3 PR.PT-3: The principle of least functionality is incorporated by configuring systems to provide only essential capabilities
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
УПД.5 УПД.5 Назначение минимально необходимых прав и привилегий
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.8.18
А.8.18 Use of privileged utility programs
The use of utility programs that can be capable of overriding system and application controls shall be restricted and tightly controlled.

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

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