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

Framework № PCI DSS 4.0 от 01.03.2022

Payment Card Industry Data Security Standard (RU)

Requirement 6.3.3

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

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

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

Стандарт Банка России № СТО БР ИББС-1.0-2014 от 01.06.2014 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации - Общие положения":
Р. 7 п. 3 п.п. 9
7.3.9. На стадии эксплуатации АБС должны быть определены, выполняться и регистрироваться процедуры:
  • контроля работоспособности (функционирования, эффективности) реализованных в АБС защитных мер, в том числе контроль реализации организационных защитных мер, контроль состава и параметров настройки применяемых технических защитных мер;
  • контроля отсутствия уязвимостей в оборудовании и программном обеспечении АБС;
  • контроля внесения изменений в параметры настройки АБС и применяемых технических защитных мер;
  • контроля необходимого обновления программного обеспечения АБС, включая программное обеспечение технических защитных мер.
CIS Critical Security Controls v8 (The 18 CIS CSC):
7.4
7.4 Perform Automated Application Patch Management
Perform application updates on enterprise assets through automated patch management on a monthly, or more frequent, basis. 
7.3
7.3 Perform Automated Operating System Patch Management
Perform operating system updates on enterprise assets through automated patch management on a monthly, or more frequent, basis. 
Положение Банка России № 787-П от 12.01.2022 "Обязательные для кредитных организаций требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг":
п. 6. п.п. 2
6.2. Кредитные организации должны обеспечивать выполнение следующих требований к управлению изменениями критичной архитектуры:
  • управление уязвимостями в критичной архитектуре, из-за которых могут реализоваться информационные угрозы и которые могут повлечь превышение значений целевых показателей операционной надежности;
  • планирование и внедрение изменений в критичной архитектуре, направленных на обеспечение недопустимости неоказания или ненадлежащего оказания банковских услуг;
  • управление конфигурациями (настраиваемыми параметрами) объектов информационной инфраструктуры;
  • управление уязвимостями и обновлениями (исправлениями) объектов информационной инфраструктуры.
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
ЦЗИ.13
ЦЗИ.13 Контроль размещения и своевременного обновления на АРМ пользователей и эксплуатационного персонала ПО средств и систем защиты информации, прикладного ПО, ПО АС и системного ПО, в том числе с целью устранения выявленных уязвимостей защиты информации
3-О 2-О 1-Т
ЦЗИ.12
ЦЗИ.12 Контроль размещения и своевременного обновления на серверном и сетевом оборудовании ПО средств и систем защиты информации, прикладного ПО, ПО АС, системного ПО и сигнатурных баз средств защиты информации, в том числе с целью устранения выявленных уязвимостей защиты информации
3-О 2-О 1-Т
ЦЗИ.28
ЦЗИ.28 Регистрация установки, обновления и (или) удаления ПО АС, ПО средств и систем защиты информации, системного ПО на серверном и сетевом оборудовании
3-Н 2-Т 1-Т
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
АНЗ.2 АНЗ.2 Контроль установки обновлений программного обеспечения, включая обновление программного обеспечения средств защиты информации
Russian Unified Cyber Security Framework (на основе The 18 CIS CSC):
7.4
7.4 Применяется автоматизированное управление исправлениями прикладного программного обеспечения
Применять автоматическое управление патчами прикладного программного обеспечения
7.3
7.3 Применяется автоматизированное управление исправлениями операционных систем
Применять автоматическое управление патчами операционной системы
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 6.3.3
6.3.3
Defined Approach Requirements: 
All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows:
  • Critical or high-security patches/updates (identified according to the risk ranking process at Requirement 6.3.1) are installed within one month of release.
  • All other applicable security patches/updates are installed within an appropriate time frame as determined by the entity (for example, within three months of release). 
Customized Approach Objective:
System components cannot be compromised via the exploitation of a known vulnerability. 

Defined Approach Testing Procedures:
  • 6.3.3.a Examine policies and procedures to verify processes are defined for addressing vulnerabilities by installing applicable security patches/updates in accordance with all elements specified in this requirement. 
  • 6.3.3.b Examine system components and related software and compare the list of installed security patches/updates to the most recent security patch/update information to verify vulnerabilities are addressed in accordance with all elements specified in this requirement. 
Purpose:
New exploits are constantly being discovered, and these can permit attacks against systems that have previously been considered secure. If the most recent security patches/updates are not implemented on critical systems as soon as possible, a malicious actor can use these exploits to attack or disable a system or gain access to sensitive data. 

Good Practice:
Prioritizing security patches/updates for critical infrastructure ensures that high-priority systems and devices are protected from vulnerabilities as soon as possible after a patch is released. 
An entity’s patching cadence should factor in any re-evaluation of vulnerabilities and subsequent changes in the criticality of a vulnerability per Requirement 6.3.1. For example, a vulnerability initially identified as low risk could become a higher risk later. Additionally, vulnerabilities individually considered to be low or medium risk could collectively pose a high or critical risk if present on the same system, or if exploited on a low-risk system that could result in access to the CDE. 
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. 
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 3.4 CSC 3.4 Deploy Automated Operating System Patch Management Tools
Deploy automated software update tools in order to ensure that the operating systems are running the most recent security updates provided by the software vendor.
CSC 3.5 CSC 3.5 Deploy Automated Software Patch Management Tools
Deploy automated software update tools in order to ensure that third-party software on all systems is running the most recent security updates provided by the software vendor.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
АНЗ.2 АНЗ.2 Контроль установки обновлений программного обеспечения, включая обновление программного обеспечения средств защиты информации
Strategies to Mitigate Cyber Security Incidents (EN):
1.2.
Patch applications (e.g. Flash, web browsers, Microsoft Office, Java and PDF viewers). Patch/mitigate computers with ‘extreme risk’ security vulnerabilities within 48 hours. Use the latest version of applications.
Relative Security Effectiveness:  Essential | Potential User Resistance:  Low | Upfront Cost:  High | Ongoing Maintenance Cost:  High
2.2.
Patch operating systems. Patch/mitigate computers (including network devices) with ‘extreme risk’ security vulnerabilities within 48 hours. Use the latest operating system version. Don’t use unsupported versions.
Relative Security Effectiveness:  Essential | Potential User Resistance:  Low | Upfront Cost:  Medium | Ongoing Maintenance Cost:  Medium
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
ОПО.4 ОПО.4 Установка обновлений программного обеспечения
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
ОПО.4 ОПО.4 Установка обновлений программного обеспечения

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

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