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

Framework № PCI DSS 4.0 от 01.03.2022

Payment Card Industry Data Security Standard (RU)

Requirement 12.3.4

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

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

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

ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 8":
РОН.5
РОН.5  Обеспечение возможности сопровождения аппаратных, программных, аппаратно-программных средств и (или) систем, реализующих технические меры обеспечения операционной надежности в течение всего срока их использования.
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 9. Требования к защите информации на этапах жизненного цикла автоматизированных систем и приложений":
ЖЦ.18
ЖЦ.18 Обеспечение возможности сопровождения технических мер системы защиты информации АС в течение всего срока их использования
3-Н 2-О 1-О
ЖЦ.10
ЖЦ.10 Проведение модернизации АС при изменении требований к составу и содержанию мер системы защиты информации АС (функционально-технические требований к системе защиты информации АС)
3-О 2-О 1-О
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 8. Требования к организации и управлению защитой информации":
РЗИ.10
РЗИ.10 Обеспечение возможности сопровождения технических мер защиты информации в течение всего срока их использования
3-Н 2-О 1-О
РЗИ.6
РЗИ.6 Реализация эксплуатации, использования по назначению технических мер защиты информации
3-О 2-О 1-О
Стандарт Банка России № СТО БР ИББС-1.0-2014 от 01.06.2014 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации - Общие положения":
Р. 7 п. 3 п.п. 6
7.3.6. Эксплуатируемые АБС и (или) их компоненты должны быть снабжены документацией, содержащей описание реализованных в АБС защитных мер, в том числе описание состава и требований к реализации организационных защитных мер, состава и требований к эксплуатации технических защитных мер.
Организации БС РФ следует проводить анализ принятия разработчиком АБС защитных мер, направленных на обеспечение безопасности разработки АБС и безопасности ее поставки.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 12.3.4
12.3.4
Defined Approach Requirements: 
Hardware and software technologies in use are reviewed at least once every 12 months, including at least the following:
  • Analysis that the technologies continue to receive security fixes from vendors promptly. 
  • Analysis that the technologies continue to support (and do not preclude) the entity’s PCI DSS compliance.
  • Documentation of any industry announcements or trends related to a technology, such as when a vendor has announced “end of life” plans for a technology. 
  • Documentation of a plan, approved by senior management, to remediate outdated technologies, including those for which vendors have announced “end of life” plans. 
Customized Approach Objective:
The entity’s hardware and software technologies are up to date and supported by the vendor. Plans to remove or replace all unsupported system components are reviewed periodically. 

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.4 Examine documentation for the review of hardware and software technologies in use and interview personnel to verify that the review is in accordance with all elements specified in this requirement. 
Purpose:
Hardware and software technologies are constantly evolving, and organizations need to be aware of changes to the technologies they use, as well as the evolving threats to those technologies to ensure that they can prepare for, and manage, vulnerabilities in hardware and software that will not be remediated by the vendor or developer. 

Good Practice:
Organizations should review firmware versions to ensure they remain current and supported by the vendors. Organizations also need to be aware of changes made by technology vendors to their products or processes to understand how such changes may impact the organization’s use of the technology. 
Regular reviews of technologies that impact or influence PCI DSS controls can assist with purchasing, usage, and deployment strategies, and ensure controls that rely on those technologies remain effective. These reviews include, but are not limited to, reviewing technologies that are no longer supported by the vendor and/or no longer meet the security needs of the organization. 
Guideline for a healthy information system v.2.0 (EN):
35 STANDARD
/STANDARD
The use of an obsolete system or software package significantly increases the possibilities of a cyberattack. Systems become vulnerable when corrective measures are no longer proposed. Malicious tools exploiting these vulnerabilities can be spread quickly online while the publisher is not offering a security corrective measure. 

To anticipate obsolescence, a certain number of precautions exist:
  • establish an inventory of the information system applications and systems and keep it up to date;
  • choose solutions with support that is ensured for a time period corresponding to their use;
  • ensure monitoring of updates and end of support dates for software;
  • keep an homogeneous software stock (the co-existence of different versions of the same product increases the risks and makes monitoring more complicated);
  • reduce software reliance, in other words, dependency on the operating of a software package compared to another, in particular when its support comes to an end;
  • include in contracts with service providers and suppliers clauses guaranteeing the monitoring of corrective security measures and the management of obsolescence;
  • identify the time periods and resources necessary (material, human, budgetary) for the migration of each software package at the end of its life (non-regression tests, backup procedure, data migration procedure, etc.). 

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

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

Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.