Куда я попал?
NIST Cybersecurity Framework (EN)
Framework
ID.SC-2
Для проведения оценки соответствия по документу войдите в систему.
Похожие требования
ГОСТ Р № 57580.3-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Управление риском реализации информационных угроз и обеспечение операционной надежности. Общие положения.":
ОПР.15
ОПР.15 Установление политикой управления риском реализации информационных угроз требований к привлекаемым в рамках аутсорсинга бизнес- и технологических процессов, а также процессов обеспечения операционной надежности и защиты информации поставщикам услуг, в том числе поставщиков облачных услуг (в части установления требуемого уровня зрелости процессов обеспечения операционной надежности и защиты информации в рамках соглашения об аутсорсинге), а также порядка взаимодействия и распределения ответственности между финансовой организацией и поставщиками услуг, в том числе поставщиками облачных услуг.
ВИО.21
ВИО.21 Оценка риска реализации информационных угроз, которому финансовая организация подвергает или подвергается со стороны причастных сторон (за исключением клиентов финансовой организации), с учетом степени взаимосвязи и взаимозависимости между финансовой организацией и причастными сторонами (за исключением клиентов финансовой организации), в том числе степени взаимосвязи и взаимозависимости между их объектами информатизации.
ВИО.8
ВИО.8 Организация и выполнение на регулярной основе деятельности по определению и анализу возможных информационных угроз: - присущих осуществлению видов деятельности финансовой организации; - присущих взаимодействию финансовой организации с причастными сторонами.
ОПР.1.1
ОПР.1.1 Определение и описание состава процессов управления риском реализации информационных угроз, обеспечения операционной надежности и защиты информации;
Положение Банка России № 787-П от 12.01.2022 "Обязательные для кредитных организаций требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг":
п. 6. п.п. 4
6.4. Кредитные организации должны обеспечивать выполнение следующих требований к взаимодействию с поставщиками услуг в сфере информационных технологий:
- нейтрализация информационных угроз, связанных с привлечением поставщиков услуг в сфере информационных технологий, в том числе защита объектов информационной инфраструктуры от возможной реализации информационных угроз со стороны поставщиков услуг в сфере информационных технологий;
- нейтрализация информационных угроз, обусловленных технологической зависимостью функционирования объектов информационной инфраструктуры кредитной организации от поставщиков услуг в сфере информационных технологий.
ГОСТ Р № 22301 от 01.01.2022 "Надежность в технике. Системы менеджмента непрерывности деятельности. Требования":
Р. 8 п. 3 пп. 2
8.3.2 Идентификация стратегий и решений
Идентификация стратегий и решений должна быть основана на уровне их полезности:
Идентификация стратегий и решений должна быть основана на уровне их полезности:
- а) при выполнении требований к продолжению и восстановлению приоритетных мероприятий в установленные сроки с установленным объемом производства;
- b) обеспечении защиты приоритетных направлений деятельности организации;
- с) снижении вероятности нарушения деятельности организации;
- d) сокращении продолжительности простоя при нарушении деятельности организации;
- е) ограничении влияния нарушения деятельности организации на продукцию и услуги организации;
- f) обеспечении необходимых ресурсов.
Р. 8 п. 2 пп. 2
8.2.2 Анализ воздействий на деятельность
Организация должна использовать процесс анализа воздействий на деятельность для определения приоритетов и требований к обеспечению непрерывности деятельности.
Процесс должен:
Организация должна использовать процесс анализа воздействий на деятельность для определения приоритетов и требований к обеспечению непрерывности деятельности.
Процесс должен:
- а) определить виды воздействий и критерии, соответствующие области применения и специфике организации;
- b) определить виды деятельности, которые поддерживают производство продукции и оказание услуг;
- с) использовать типы и критерии воздействий для оценки воздействий, происходящих в результате нарушения деятельности организации в этих видах деятельности;
- d) определить продолжительность времени, в течение которого невозобновление деятельности становится неприемлемым для организации;
Примечание 1 — Данный период времени можно назвать «максимально допустимым периодом прерывания деятельности».
- е) установить предпочтительную продолжительность времени, указанного в d), для возобновления прерванной деятельности, установленным минимально приемлемым объемом производства продукции;
Примечание 2 — Такой временной интервал можно назвать «целевой продолжительностью восстановления».
- f) использовать данный анализ для определения приоритетных видов деятельности;
- д) определить ресурсы, необходимы для поддержки приоритетных видов деятельности;
- h) определить виды зависимости, в том числе от партнеров и поставщиков, а также взаимозависимости. связанные с приоритетными видами деятельности.
Р. 4 п. 3 пп. 2
4.3.2 Область применения системы менеджмента непрерывности деятельности
Организация должна:
Организация должна:
- а) определить части организации, включаемые в СМНД. с учетом их местоположения, объема, особенностей и сложности;
- b) определить продукцию и услуги, включаемые в СМНД.
При определении области применения СМНД организация должна обосновать и документировать исключения. При этом исключения не должны влиять на возможности и ответственность организации обеспечивать непрерывность деятельности, это определяют путем анализа их воздействия на деятельность или оценки риска и применимых правовых или нормативных требований.
NIST Cybersecurity Framework (RU):
ID.SC-2
ID.SC-2: С использованием процесса оценки рисков в киберцепочке поставок идентфицированы, расставлены приоритеты и оценены поставщики и партнеры критически важных информационных систем, компонентов и услуг
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
ВПУ.3.1
ВПУ.3.1 Определение приоритета в отношении поставщиков услуг, реализующих необходимые процедуры по обеспечению безопасности на этапах жизненного цикла поставляемых объектов информатизации, в том числе обеспечивающих «прозрачность» в отношении реализуемых ими процессов производства и сопровождения объектов информатизации, а также имеющих необходимую зрелость собственных процессов обеспечения безопасности цепи поставок, подтвержденную посредством проведения независимой оценки (внешнего аудита)**;
ВПУ.4.2
ВПУ.4.2 Назначение основного и альтернативного поставщиков услуг (в том числе поставщика услуг, связанных с защитой от информационных угроз) на случай, если основной поставщик услуг не сможет оказывать необходимый уровень услуг в кризисной ситуации****.
ВПУ.5
ВПУ.5 Диверсификация риска нарушения поставок и сопровождения объектов информатизации, в том числе по государственной принадлежности*.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 12.3.1
12.3.1
Defined Approach Requirements:
Each PCI DSS requirement that provides flexibility for how frequently it is performed (for example, requirements to be performed periodically) is supported by a targeted risk analysis that is documented and includes:
Defined Approach Requirements:
Each PCI DSS requirement that provides flexibility for how frequently it is performed (for example, requirements to be performed periodically) is supported by a targeted risk analysis that is documented and includes:
- Identification of the assets being protected.
- Identification of the threat(s) that the requirement is protecting against.
- Identification of factors that contribute to the likelihood and/or impact of a threat being realized.
- Resulting analysis that determines, and includes justification for, how frequently the requirement must be performed to minimize the likelihood of the threat being realized.
- Review of each targeted risk analysis at least once every 12 months to determine whether the results are still valid or if an updated risk analysis is needed.
- Performance of updated risk analyses when needed, as determined by the annual review.
Customized Approach Objective:
Up to date knowledge and assessment of risks to the CDE are maintained.
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:
Up to date knowledge and assessment of risks to the CDE are maintained.
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:
- 12.3.1 Examine documented policies and procedures to verify a process is defined for performing targeted risk analyses for each PCI DSS requirement that provides flexibility for how frequently the requirement is performed, and that the process includes all elements specified in this requirement.
Purpose:
Some PCI DSS requirements allow an entity to define how frequently an activity is performed based on the risk to environment. Performing this risk analysis according to a methodology ensures validity and consistency with policies and procedures.
This targeted risk analysis (as opposed to a traditional enterprise-wide risk assessment) focuses on those PCI DSS requirements that allow an entity flexibility about how frequently an entity performs a given control. For this risk analysis, the entity carefully evaluates each PCI DSS requirement that provides this flexibility and determines the frequency that supports adequate security for the entity, and the level of risk the entity is willing to accept.
The risk analysis identifies the specific assets, such as the system components and data—for example, log files, or credentials—that the requirement is intended to protect, as well as the threat(s) or outcomes that the requirement is protecting the assets from—for example, malware, an undetected intruder, or misuse of credentials. Examples of factors that could contribute to likelihood or impact include any that could increase the vulnerability of an asset to a threat—for example, exposure to untrusted networks, complexity of environment, or high staff turnover—as well as the criticality of the system components, or volume and sensitivity of the data, being protected.
Reviewing the results of these targeted risk analyses at least once every 12 months and upon changes that could impact the risk to the environment allows the organization to ensure the risk analysis results remain current with organizational changes and evolving threats, trends, and technologies, and that the selected frequencies still adequately address the entity’s risk.
Good Practice:
An enterprise-wide risk assessment, which is a point-in-time activity that enables entities to identify threats and associated vulnerabilities, is recommended, but is not required, for entities to determine and understand broader and emerging threats with the potential to negatively impact its business. This enterprise-wide risk assessment could be established as part of an overarching risk management program that is used as an input to the annual review of an organization's overall information security policy (see Requirement 12.1.1).
Examples of risk-assessment methodologies for enterprise-wide risk assessments include, but are not limited to, ISO 27005 and NIST SP 800-30.
Some PCI DSS requirements allow an entity to define how frequently an activity is performed based on the risk to environment. Performing this risk analysis according to a methodology ensures validity and consistency with policies and procedures.
This targeted risk analysis (as opposed to a traditional enterprise-wide risk assessment) focuses on those PCI DSS requirements that allow an entity flexibility about how frequently an entity performs a given control. For this risk analysis, the entity carefully evaluates each PCI DSS requirement that provides this flexibility and determines the frequency that supports adequate security for the entity, and the level of risk the entity is willing to accept.
The risk analysis identifies the specific assets, such as the system components and data—for example, log files, or credentials—that the requirement is intended to protect, as well as the threat(s) or outcomes that the requirement is protecting the assets from—for example, malware, an undetected intruder, or misuse of credentials. Examples of factors that could contribute to likelihood or impact include any that could increase the vulnerability of an asset to a threat—for example, exposure to untrusted networks, complexity of environment, or high staff turnover—as well as the criticality of the system components, or volume and sensitivity of the data, being protected.
Reviewing the results of these targeted risk analyses at least once every 12 months and upon changes that could impact the risk to the environment allows the organization to ensure the risk analysis results remain current with organizational changes and evolving threats, trends, and technologies, and that the selected frequencies still adequately address the entity’s risk.
Good Practice:
An enterprise-wide risk assessment, which is a point-in-time activity that enables entities to identify threats and associated vulnerabilities, is recommended, but is not required, for entities to determine and understand broader and emerging threats with the potential to negatively impact its business. This enterprise-wide risk assessment could be established as part of an overarching risk management program that is used as an input to the annual review of an organization's overall information security policy (see Requirement 12.1.1).
Examples of risk-assessment methodologies for enterprise-wide risk assessments include, but are not limited to, ISO 27005 and NIST SP 800-30.
Requirement 10.7.1
10.7.1
Defined Approach Requirements:
Additional requirement for service providers only: Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of the following critical security control systems:
Defined Approach Requirements:
Additional requirement for service providers only: Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of the following critical security control systems:
- Network security controls.
- IDS/IPS.
- FIM.
- Anti-malware solutions.
- Physical access controls.
- Logical access controls.
- Audit logging mechanisms.
- Segmentation controls (if used).
Customized Approach Objective:
Failures in critical security control systems are promptly identified and addressed.
Applicability Notes:
This requirement applies only when the entity being assessed is a service provider.
This requirement will be superseded by Requirement 10.7.2 as of 31 March 2025.
Defined Approach Testing Procedures:
Failures in critical security control systems are promptly identified and addressed.
Applicability Notes:
This requirement applies only when the entity being assessed is a service provider.
This requirement will be superseded by Requirement 10.7.2 as of 31 March 2025.
Defined Approach Testing Procedures:
- 10.7.1.a Additional testing procedure for service provider assessments only: Examine documentation to verify that processes are defined for the prompt detection and addressing of failures of critical security control systems, including but not limited to failure of all elements specified in this requirement.
- 10.7.1.b Additional testing procedure for service provider assessments only: Observe detection and alerting processes and interview personnel to verify that failures of critical security control systems are detected and reported, and that failure of a critical security control results in the generation of an alert.
Purpose:
Without formal processes to detect and alert when critical security controls fail, failures may go undetected for extended periods and provide attackers ample time to compromise system components and steal account data from the CDE.
Good Practice:
The specific types of failures may vary, depending on the function of the device system component and technology in use. Typical failures include a system ceasing to perform its security function or not functioning in its intended manner, such as a firewall erasing all its rules or going offline.
Without formal processes to detect and alert when critical security controls fail, failures may go undetected for extended periods and provide attackers ample time to compromise system components and steal account data from the CDE.
Good Practice:
The specific types of failures may vary, depending on the function of the device system component and technology in use. Typical failures include a system ceasing to perform its security function or not functioning in its intended manner, such as a firewall erasing all its rules or going offline.
Requirement 12.8.1
12.8.1
Defined Approach Requirements:
A list of all third-party service providers (TPSPs) with which account data is shared or that could affect the security of account data is maintained, including a description for each of the services provided.
Customized Approach Objective:
Records are maintained of TPSPs and the services provided.
Applicability Notes:
The use of a PCI DSS compliant TPSP does not make an entity PCI DSS compliant, nor does it remove the entity’s responsibility for its own PCI DSS compliance.
Defined Approach Testing Procedures:
Defined Approach Requirements:
A list of all third-party service providers (TPSPs) with which account data is shared or that could affect the security of account data is maintained, including a description for each of the services provided.
Customized Approach Objective:
Records are maintained of TPSPs and the services provided.
Applicability Notes:
The use of a PCI DSS compliant TPSP does not make an entity PCI DSS compliant, nor does it remove the entity’s responsibility for its own PCI DSS compliance.
Defined Approach Testing Procedures:
- 12.8.1.a Examine policies and procedures to verify that processes are defined to maintain a list of TPSPs, including a description for each of the services provided, for all TPSPs with whom account data is shared or that could affect the security of account data.
- 12.8.1.b Examine documentation to verify that a list of all TPSPs is maintained that includes a description of the services provided.
Purpose:
Maintaining a list of all TPSPs identifies where potential risk extends outside the organization and defines the organization’s extended attack surface.
Examples:
Different types of TPSPs include those that:
Maintaining a list of all TPSPs identifies where potential risk extends outside the organization and defines the organization’s extended attack surface.
Examples:
Different types of TPSPs include those that:
- Store, process, or transmit account data on the entity’s behalf (such as payment gateways, payment processors, payment service providers (PSPs), and off-site storage providers).
- Manage system components included in the entity’s PCI DSS assessment (such as providers of network security control services, anti-malware services, and security incident and event management (SIEM); contact and call centers; web-hosting companies; and IaaS, PaaS, SaaS, and FaaS cloud providers).
- Could impact the security of the entity’s CDE (such as vendors providing support via remote access, and bespoke software developers).
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.15.2.2
A.15.2.2 Управление изменениями услуг поставщика
Мера обеспечения информационной безопасности: Требуется управлять изменениями в предоставляемых поставщиками услугах, включая поддержку и улучшение существующих политик, процедур, а также мер и средств информационной безопасности, с учетом категории информации бизнеса, задействованных систем и процессов, а также результатов переоценки рисков информационной безопасности
Мера обеспечения информационной безопасности: Требуется управлять изменениями в предоставляемых поставщиками услугах, включая поддержку и улучшение существующих политик, процедур, а также мер и средств информационной безопасности, с учетом категории информации бизнеса, задействованных систем и процессов, а также результатов переоценки рисков информационной безопасности
A.15.2.1
A.15.2.1 Мониторинг и анализ услуг поставщика
Мера обеспечения информационной безопасности: Организация должна регулярно проводить мониторинг, проверку и аудит деятельности поставщика по предоставлению услу
Мера обеспечения информационной безопасности: Организация должна регулярно проводить мониторинг, проверку и аудит деятельности поставщика по предоставлению услу
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 12.3.1
12.3.1
Определенные Требования к Подходу:
Каждое требование PCI DSS, обеспечивающее гибкость в отношении частоты его выполнения (например, требования, которые должны выполняться периодически), подкрепляется целевым анализом рисков, который документируется и включает:
Определенные Требования к Подходу:
Каждое требование PCI DSS, обеспечивающее гибкость в отношении частоты его выполнения (например, требования, которые должны выполняться периодически), подкрепляется целевым анализом рисков, который документируется и включает:
- Идентификация защищаемых активов.
- Идентификация угрозы (угроз), от которой защищает требование.
- Выявление факторов, которые способствуют вероятности и/или воздействию реализуемой угрозы.
- Итоговый анализ, который определяет и включает обоснование того, как часто должно выполняться требование, чтобы свести к минимуму вероятность реализации угрозы.
- Просматривайте каждый целевой анализ рисков не реже одного раза в 12 месяцев, чтобы определить, остаются ли результаты в силе или необходим обновленный анализ рисков.
- Проведение обновленного анализа рисков, когда это необходимо, в соответствии с ежегодным обзором.
Цель Индивидуального подхода:
Поддерживаются актуальные знания и оценка рисков для CDE.
Примечания по применению:
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
Поддерживаются актуальные знания и оценка рисков для CDE.
Примечания по применению:
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
- 12.3.1 Изучите документированные политики и процедуры, чтобы убедиться, что определен процесс для выполнения целевого анализа рисков для каждого требования PCI DSS, который обеспечивает гибкость в отношении того, как часто выполняется требование, и что процесс включает все элементы, указанные в этом требовании.
Цель:
Некоторые требования PCI DSS позволяют организации определять, как часто выполняется та или иная деятельность, исходя из риска для окружающей среды. Выполнение этого анализа рисков в соответствии с методологией обеспечивает обоснованность и согласованность с политиками и процедурами.
Этот целевой анализ рисков (в отличие от традиционной общеорганизационной оценки рисков) фокусируется на тех требованиях PCI DSS, которые позволяют организации гибко выбирать, как часто организация выполняет тот или иной контроль. Для этого анализа рисков организация тщательно оценивает каждое требование PCI DSS, обеспечивающее такую гибкость, и определяет частоту, обеспечивающую надлежащую безопасность для организации, а также уровень риска, который организация готова принять.
Анализ рисков определяет конкретные активы, такие как системные компоненты и данные — например, файлы журналов или учетные данные, — для защиты которых предназначено требование, а также угрозы или последствия, от которых требование защищает активы — например, вредоносное ПО, необнаруженный злоумышленник, или неправильное использование учетных данных. Примеры факторов, которые могут способствовать вероятности или воздействию, включают любые, которые могут повысить уязвимость актива к угрозе, например, подверженность ненадежным сетям, сложность среды или высокая текучесть кадров, а также критичность компонентов системы или объем и критичность данных, поскольку защищенный.
Анализ результатов этих целевых анализов рисков не реже одного раза в 12 месяцев и при изменениях, которые могут повлиять на риск для окружающей среды, позволяет организации убедиться, что результаты анализа рисков остаются актуальными с учетом организационных изменений и развивающихся угроз, тенденций и технологий, а также что выбранные частоты по-прежнему адекватно учитывают риск организации..
Надлежащая практика:
Оценка рисков в масштабах всей организации, которая представляет собой оперативную деятельность, позволяющую организациям выявлять угрозы и связанные с ними уязвимости, рекомендуется, но не требуется, для определения и понимания более широких и возникающих угроз, которые могут негативно повлиять на их бизнес. Эта общеорганизационная оценка рисков может быть создана как часть всеобъемлющей программы управления рисками, которая используется в качестве вклада в ежегодный обзор общей политики информационной безопасности организации (см. Требование 12.1.1).
Примеры методологий оценки рисков для оценки рисков в масштабах предприятия включают, но не ограничиваются ими, ISO 27005 и NIST SP 800-30.
Некоторые требования PCI DSS позволяют организации определять, как часто выполняется та или иная деятельность, исходя из риска для окружающей среды. Выполнение этого анализа рисков в соответствии с методологией обеспечивает обоснованность и согласованность с политиками и процедурами.
Этот целевой анализ рисков (в отличие от традиционной общеорганизационной оценки рисков) фокусируется на тех требованиях PCI DSS, которые позволяют организации гибко выбирать, как часто организация выполняет тот или иной контроль. Для этого анализа рисков организация тщательно оценивает каждое требование PCI DSS, обеспечивающее такую гибкость, и определяет частоту, обеспечивающую надлежащую безопасность для организации, а также уровень риска, который организация готова принять.
Анализ рисков определяет конкретные активы, такие как системные компоненты и данные — например, файлы журналов или учетные данные, — для защиты которых предназначено требование, а также угрозы или последствия, от которых требование защищает активы — например, вредоносное ПО, необнаруженный злоумышленник, или неправильное использование учетных данных. Примеры факторов, которые могут способствовать вероятности или воздействию, включают любые, которые могут повысить уязвимость актива к угрозе, например, подверженность ненадежным сетям, сложность среды или высокая текучесть кадров, а также критичность компонентов системы или объем и критичность данных, поскольку защищенный.
Анализ результатов этих целевых анализов рисков не реже одного раза в 12 месяцев и при изменениях, которые могут повлиять на риск для окружающей среды, позволяет организации убедиться, что результаты анализа рисков остаются актуальными с учетом организационных изменений и развивающихся угроз, тенденций и технологий, а также что выбранные частоты по-прежнему адекватно учитывают риск организации..
Надлежащая практика:
Оценка рисков в масштабах всей организации, которая представляет собой оперативную деятельность, позволяющую организациям выявлять угрозы и связанные с ними уязвимости, рекомендуется, но не требуется, для определения и понимания более широких и возникающих угроз, которые могут негативно повлиять на их бизнес. Эта общеорганизационная оценка рисков может быть создана как часть всеобъемлющей программы управления рисками, которая используется в качестве вклада в ежегодный обзор общей политики информационной безопасности организации (см. Требование 12.1.1).
Примеры методологий оценки рисков для оценки рисков в масштабах предприятия включают, но не ограничиваются ими, ISO 27005 и NIST SP 800-30.
Requirement 12.8.1
12.8.1
Определенные Требования к Подходу:
Ведется список всех сторонних поставщиков услуг (TPSP), с которыми передаются данные учетной записи или которые могут повлиять на безопасность данных учетной записи, включая описание каждой из предоставляемых услуг.
Цель Индивидуального подхода:
Ведется учет TPPS и предоставляемых услуг.
Примечания по применению:
Использование TPSP, совместимого с PCI DSS, не делает организацию совместимой с PCI DSS и не снимает с организации ответственности за ее собственное соответствие требованиям PCI DSS.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Ведется список всех сторонних поставщиков услуг (TPSP), с которыми передаются данные учетной записи или которые могут повлиять на безопасность данных учетной записи, включая описание каждой из предоставляемых услуг.
Цель Индивидуального подхода:
Ведется учет TPPS и предоставляемых услуг.
Примечания по применению:
Использование TPSP, совместимого с PCI DSS, не делает организацию совместимой с PCI DSS и не снимает с организации ответственности за ее собственное соответствие требованиям PCI DSS.
Определенные Процедуры Тестирования Подхода:
- 12.8.1.a Изучить политики и процедуры, чтобы убедиться, что определены процессы для ведения списка TPPS, включая описание для каждой из предоставляемых услуг, для всех TPPS, с которыми передаются данные учетной записи или которые могут повлиять на безопасность данных учетной записи.
- 12.8.1.b Изучите документацию, чтобы убедиться, что ведется список всех TPSP, который включает описание предоставляемых услуг.
Цель:
Ведение списка всех TPSP определяет, где потенциальный риск распространяется за пределы организации, и определяет расширенную зону атаки организации.
Примеры:
Различные типы TPSP включают те, которые:
Ведение списка всех TPSP определяет, где потенциальный риск распространяется за пределы организации, и определяет расширенную зону атаки организации.
Примеры:
Различные типы TPSP включают те, которые:
- Хранить, обрабатывать или передавать данные учетной записи от имени организации (например, платежные шлюзы, платежные процессоры, поставщики платежных услуг (PSP) и сторонние поставщики хранилища).
- Управляйте системными компонентами, включенными в оценку PCI DSS организации (например, поставщиками услуг контроля сетевой безопасности, услуг защиты от вредоносных программ и управления инцидентами и событиями безопасности (SIEM); контактными и колл-центрами; веб-хостинговыми компаниями; и облачными провайдерами IaaS, PaaS, SaaS и FaaS).
- Может повлиять на безопасность CDE организации (например, поставщики, предоставляющие поддержку через удаленный доступ, и разработчики программного обеспечения на заказ).
Requirement 10.7.1
10.7.1
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Сбои в критически важных системах контроля безопасности обнаруживаются, предупреждаются и оперативно устраняются, включая, но не ограничиваясь, сбои в следующих критически важных системах контроля безопасности:
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Сбои в критически важных системах контроля безопасности обнаруживаются, предупреждаются и оперативно устраняются, включая, но не ограничиваясь, сбои в следующих критически важных системах контроля безопасности:
- Средства управления сетевой безопасностью.
- IDS/IPS.
- FIM.
- Решения для защиты от вредоносных программ.
- Контроль физического доступа.
- Логический контроль доступа.
- Механизмы ведения журнала аудита.
- Элементы управления сегментацией (если они используются).
Цель Индивидуального подхода:
Сбои в критически важных системах контроля безопасности оперативно выявляются и устраняются.
Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
Это требование будет заменено Требованием 10.7.2 с 31 марта 2025 года.
Определенные Процедуры Тестирования Подхода:
Сбои в критически важных системах контроля безопасности оперативно выявляются и устраняются.
Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
Это требование будет заменено Требованием 10.7.2 с 31 марта 2025 года.
Определенные Процедуры Тестирования Подхода:
- 10.7.1.дополнительная процедура тестирования только для оценки поставщика услуг: Изучите документацию, чтобы убедиться, что определены процессы для оперативного обнаружения и устранения сбоев критических систем контроля безопасности, включая, но не ограничиваясь отказом всех элементов, указанных в этом требовании.
- 10.7.1.b Дополнительная процедура тестирования только для оценки поставщика услуг: Наблюдайте за процессами обнаружения и оповещения и опрашивайте персонал, чтобы убедиться, что сбои в критически важных системах контроля безопасности обнаружены и сообщены, и что сбой критического контроля безопасности приводит к генерации предупреждения.
Цель:
Без формальных процессов обнаружения и оповещения о сбое критических средств защиты сбои могут оставаться незамеченными в течение длительного времени и предоставлять злоумышленникам достаточно времени для компрометации системных компонентов и кражи данных учетной записи из CDE.
Надлежащая практика:
Конкретные типы отказов могут варьироваться в зависимости от функции системного компонента устройства и используемой технологии. Типичные сбои включают в себя то, что система перестает выполнять свои функции безопасности или не функционирует должным образом, например, брандмауэр стирает все свои правила или переходит в автономный режим.
Без формальных процессов обнаружения и оповещения о сбое критических средств защиты сбои могут оставаться незамеченными в течение длительного времени и предоставлять злоумышленникам достаточно времени для компрометации системных компонентов и кражи данных учетной записи из CDE.
Надлежащая практика:
Конкретные типы отказов могут варьироваться в зависимости от функции системного компонента устройства и используемой технологии. Типичные сбои включают в себя то, что система перестает выполнять свои функции безопасности или не функционирует должным образом, например, брандмауэр стирает все свои правила или переходит в автономный режим.
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.5.22
А.5.22 Мониторинг, проверка и управление изменениями предоставляемых сервисов
Организация должна мониторить, регулярно, анализировать, проверять и управлять изменениями в практиках ИБ в отношении поставщиков и предоставлении ими сервисов.
Организация должна мониторить, регулярно, анализировать, проверять и управлять изменениями в практиках ИБ в отношении поставщиков и предоставлении ими сервисов.
SWIFT Customer Security Controls Framework v2022:
2 - 2.8A Critical Activity Outsourcing
2.8A Critical Activity Outsourcing
Положение Банка России № 779-П от 15.11.2021 "Обязательные для некредитных финансовых организаций требований к операционной надежности при осуществлении видов деятельности, предусмотренных частью первой статьи 76.1 Федерального закона от 10 июля 2002 года N 86-ФЗ "О Центральном банке"":
п. 1.7.
1.7. Некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, в рамках обеспечения операционной надежности должны обеспечивать выполнение следующих требований в отношении взаимодействия с поставщиками услуг:
- управление риском реализации информационных угроз при привлечении поставщиков услуг, в том числе защиту своих объектов информационной инфраструктуры от возможной реализации информационных угроз со стороны поставщиков услуг;
- управление риском технологической зависимости функционирования своих объектов информационной инфраструктуры от поставщиков услуг.
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.5.22
А.5.22 Monitoring, review and change management of supplier services
The organization shall regularly monitor, review, evaluate and manage change in supplier information security practices and service delivery.
The organization shall regularly monitor, review, evaluate and manage change in supplier information security practices and service delivery.
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.