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

Приказ ФСТЭК России № 31 от 14.03.2014

Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления

УКФ.4

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

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

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

ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 8. Требования к организации и управлению защитой информации":
КЗИ.11
КЗИ.11 Регистрация операций по изменению параметров настроек технических мер защиты информации и информационной инфраструктуры, предназначенных для размещения технических мер защиты информации
3-Н 2-Т 1-Т
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
ЦЗИ.29
ЦЗИ.29 Регистрация установки, обновления и (или) удаления прикладного ПО, ПО АС, ПО средств и систем защиты информации, системного ПО на АРМ пользователей и эксплуатационного персонала
3-Н 2-Т 1-Т
NIST Cybersecurity Framework (RU):
PR.IP-3
PR.IP-3: Реализованы процессы контроля изменений конфигурации 
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 11.5.2
11.5.2
Defined Approach Requirements: 
A change-detection mechanism (for example, file integrity monitoring tools) is deployed as follows:
  • To alert personnel to unauthorized modification (including changes, additions, and deletions) of critical files.
  • To perform critical file comparisons at least once weekly 
Customized Approach Objective:
Critical files cannot be modified by unauthorized personnel without an alert being generated. 

Applicability Notes:
For change-detection purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. Changedetection mechanisms such as file integrity monitoring products usually come pre-configured with critical files for the related operating system. Other critical files, such as those for custom applications, must be evaluated and defined by the entity (that is, the merchant or service provider). 

Defined Approach Testing Procedures:
  • 11.5.2.a Examine system settings, monitored files, and results from monitoring activities to verify the use of a change-detection mechanism. 
  • 11.5.2.b Examine settings for the change-detection mechanism to verify it is configured in accordance with all elements specified in this requirement. 
Purpose:
Changes to critical system, configuration, or content files can be an indicator an attacker has accessed an organization’s system. Such changes can allow an attacker to take additional malicious actions, access cardholder data, and/or conduct activities without detection or record. 
A change detection mechanism will detect and evaluate such changes to critical files and generate alerts that can be responded to following defined processes so that personnel can take appropriate actions.
If not implemented properly and the output of the change-detection solution monitored, a malicious individual could add, remove, or alter configuration file contents, operating system programs, or application executables. Unauthorized changes, if undetected, could render existing security controls ineffective and/or result in cardholder data being stolen with no perceptible impact to normal processing. 

Good Practice:
Examples of the types of files that should be monitored include, but are not limited to:
  • System executables.
  • Application executables.
  • Configuration and parameter files.
  • Centrally stored, historical, or archived audit logs.
  • Additional critical files determined by entity (for example, through risk assessment or other means). 
Examples:
Change-detection solutions such as file integrity monitoring (FIM) tools check for changes, additions, and deletions to critical files, and notify when such changes are detected. 
Requirement 6.5.4
6.5.4
Defined Approach Requirements: 
Roles and functions are separated between production and pre-production environments to provide accountability such that only reviewed and approved changes are deployed. 

Customized Approach Objective:
Job roles and accountability that differentiate between pre-production and production activities are defined and managed to minimize the risk of unauthorized, unintentional, or inappropriate actions. 

Applicability Notes:
In environments with limited personnel where individuals perform multiple roles or functions, this same goal can be achieved with additional procedural controls that provide accountability. For example, a developer may also be an administrator that uses an administrator-level account with elevated privileges in the development environment and, for their developer role, they use a separate account with user-level access to the production environment. 

Defined Approach Testing Procedures:
  • 6.5.4.a Examine policies and procedures to verify that processes are defined for separating roles and functions to provide accountability such that only reviewed and approved changes are deployed.
  •  6.5.4.b Observe processes and interview personnel to verify implemented controls separate roles and functions and provide accountability such that only reviewed and approved changes are deployed. 
Purpose:
The goal of separating roles and functions between production and pre-production environments is to reduce the number of personnel with access to the production environment and account data and thereby minimize risk of unauthorized, unintentional, or inappropriate access to data and system components and help ensure that access is limited to those individuals with a business need for such access. 
The intent of this control is to separate critical activities to provide oversight and review to catch errors and minimize the chances of fraud or theft (since two people would need to collude in order to hide an activity). 
Separating roles and functions, also referred to as separation or segregation of duties, is a key internal control concept to protect an entity’s assets. 
Requirement 6.5.1
6.5.1
Defined Approach Requirements: 
Changes to all system components in the production environment are made according to established procedures that include: 
  • Reason for, and description of, the change.
  • Documentation of security impact.
  • Documented change approval by authorized parties. 
  • Testing to verify that the change does not adversely impact system security. 
  • For bespoke and custom software changes, all updates are tested for compliance with Requirement 6.2.4 before being deployed into production. 
  • Procedures to address failures and return to a secure state. 
Customized Approach Objective:
All changes are tracked, authorized, and evaluated for impact and security, and changes are managed to avoid unintended effects to the security of system components. 

Defined Approach Testing Procedures:
  • 6.5.1.a Examine documented change control procedures to verify procedures are defined for changes to all system components in the production environment to include all elements specified in this requirement. 
  • 6.5.1.b Examine recent changes to system components and trace those changes back to related change control documentation. For each change examined, verify the change is implemented in accordance with all elements specified in this requirement. 
Purpose:
Change management procedures must be applied to all changes—including the addition, removal, or modification of any system component—in the production environment. It is important to document the reason for a change and the change description so that relevant parties understand and agree the change is needed. Likewise, documenting the impacts of the change allows all affected parties to plan appropriately for any processing changes. 

Good Practice:
Approval by authorized parties confirms that the change is legitimate and that the change is sanctioned by the organization. Changes should be approved by individuals with the appropriate authority and knowledge to understand the impact of the change. 
Thorough testing by the entity confirms that the security of the environment is not reduced by implementing a change and that all existing security controls either remain in place or are replaced with equal or stronger security controls after the change. The specific testing to be performed will vary according to the type of change and system component(s) affected.
For each change, it is important to have documented procedures that address any failures and provide instructions on how to return to a secure state in case the change fails or adversely affects the security of an application or system. These procedures will allow the application or system to be restored to its previous secure state. 
Requirement 11.6.1
11.6.1
Defined Approach Requirements: 
A change- and tamper-detection mechanism is deployed as follows: 
  • To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the HTTP headers and the contents of payment pages as received by the consumer browser.
  • The mechanism is configured to evaluate the received HTTP header and payment page.
  • The mechanism functions are performed as follows: 
    • At least once every seven days 
    • OR
    • Periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1). 
Customized Approach Objective:
E-commerce skimming code or techniques cannot be added to payment pages as received by the consumer browser without a timely alert being generated. Anti-skimming measures cannot be removed from payment pages without a prompt alert being generated. 

Applicability Notes:
The intention of this requirement is not that an entity installs software in the systems or browsers of its consumers, but rather that the entity uses techniques such as those described under Examples in the Guidance column to prevent and detect unexpected script activities. 
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:
  • 11.6.1.a Examine system settings, monitored payment pages, and results from monitoring activities to verify the use of a change- and tamperdetection mechanism. 
  • 11.6.1.b Examine configuration settings to verify the mechanism is configured in accordance with all elements specified in this requirement. 
  • 11.6.1.c If the mechanism functions are performed at an entity-defined frequency, examine the entity’s targeted risk analysis for determining the frequency to verify the risk analysis was performed in accordance with all elements specified at Requirement 12.3.1. 
  • 11.6.1.d Examine configuration settings and interview personnel to verify the mechanism functions are performed either: • At least once every seven days OR • At the frequency defined in the entity’s targeted risk analysis performed for this requirement. 
Purpose:
Many web pages now rely on assembling objects, including active content (primarily JavaScript), from multiple internet locations. Additionally, the content of many web pages is defined using content management and tag management systems that may not be possible to monitor using traditional change detection mechanisms. 
Therefore, the only place to detect changes or indicators of malicious activity is in the consumer browser as the page is constructed and all JavaScript interpreted. 
By comparing the current version of the HTTP header and the active content of payment pages as received by the consumer browser with prior or known versions, it is possible to detect unauthorized changes that may indicate a skimming attack. 
Additionally, by looking for known indicators of compromise and script elements or behavior typical of skimmers, suspicious alerts can be raised. 

Examples:
Mechanisms that detect and report on changes to the headers and content of the payment page include but are not limited to: 
  • Violations of the Content Security Policy (CSP) can be reported to the entity using the reportto or report-uri CSP directives.
  • Changes to the CSP itself can indicate tampering. 
  • External monitoring by systems that request and analyze the received web pages (also known as synthetic user monitoring) can detect changes to JavaScript in payment pages and alert personnel.
  • Embedding tamper-resistant, tamper-detection script in the payment page can alert and block when malicious script behavior is detected.
  • Reverse proxies and Content Delivery Networks can detect changes in scripts and alert personnel. 
Often, these mechanisms are subscription or cloud-based, but can also be based on custom and bespoke solutions. 
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 6.5.4
6.5.4
Определенные Требования к Подходу:
Роли и функции разделены между производственной и предпроизводственной средами для обеспечения подотчетности таким образом, чтобы внедрялись только проверенные и утвержденные изменения.

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

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

Определенные Процедуры Тестирования Подхода:
  • 6.5.4.a Изучите политики и процедуры, чтобы убедиться, что процессы определены для разделения ролей и функций для обеспечения подотчетности таким образом, чтобы внедрялись только проверенные и одобренные изменения.
  • 6.5.4.b Наблюдать за процессами и проводить собеседования с персоналом для проверки внедренных средств контроля, разделения ролей и функций и обеспечения подотчетности таким образом, чтобы внедрялись только проверенные и одобренные изменения.
Цель:
Целью разделения ролей и функций между производственной и предпроизводственной средами является сокращение числа сотрудников, имеющих доступ к производственной среде и данным учетной записи, и тем самым минимизация риска несанкционированного, непреднамеренного или ненадлежащего доступа к данным и компонентам системы, а также обеспечение того, чтобы доступ был ограничен лицами, имеющими бизнес- необходимость в таком доступе.
Цель этого контроля состоит в том, чтобы разделить критические действия для обеспечения надзора и проверки, чтобы выявить ошибки и свести к минимуму вероятность мошенничества или кражи (поскольку два человека должны были бы вступить в сговор, чтобы скрыть действие).
Разделение ролей и функций, также называемое разделением или разделением обязанностей, является ключевой концепцией внутреннего контроля для защиты активов организации.
Requirement 11.6.1
11.6.1
Определенные Требования к Подходу:
Механизм обнаружения изменений и несанкционированного доступа развертывается следующим образом:
  • Для предупреждения персонала о несанкционированном изменении (включая признаки компрометации, изменения, добавления и удаления) заголовков HTTP и содержимого платежных страниц, полученных браузером пользователя.
  • Механизм настроен на оценку полученного HTTP-заголовка и страницы оплаты.
  • Функции механизма выполняются следующим образом:
    • Не реже одного раза в семь дней
    • ИЛИ
    • Периодически (с периодичностью, определенной в целевом анализе рисков организации, который выполняется в соответствии со всеми элементами, указанными в Требовании 12.3.1).
Цель Индивидуального подхода:
Код или методы скимминга электронной коммерции не могут быть добавлены на страницы платежей, полученные браузером потребителя, без своевременного оповещения. Меры по борьбе со скиммингом не могут быть удалены со страниц платежей без создания оперативного предупреждения.

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

Определенные Процедуры Тестирования Подхода:
  • 11.6.1.a Изучить системные настройки, отслеживаемые платежные страницы и результаты действий по мониторингу, чтобы проверить использование механизма обнаружения изменений и несанкционированного доступа.
  • 11.6.1.b Проверьте параметры конфигурации, чтобы убедиться, что механизм настроен в соответствии со всеми элементами, указанными в этом требовании.
  • 11.6.1.c Если функции механизма выполняются с определенной организацией периодичностью, изучите целевой анализ рисков организации для определения периодичности, чтобы убедиться, что анализ рисков был выполнен в соответствии со всеми элементами, указанными в Требовании 12.3.1.
  • 11.6.1.d Изучите параметры конфигурации и опросите персонал, чтобы убедиться, что функции механизма выполняются либо: • Не реже одного раза в семь дней, ЛИБО • С периодичностью, определенной в целевом анализе рисков организации, выполняемом для этого требования.
Цель:
Многие веб-страницы теперь полагаются на сборку объектов, включая активный контент (в первую очередь JavaScript), из нескольких интернет-местоположений. Кроме того, содержимое многих веб-страниц определяется с помощью систем управления контентом и управления тегами, которые, возможно, невозможно отслеживать с помощью традиционных механизмов обнаружения изменений.
Таким образом, единственное место, где можно обнаружить изменения или признаки вредоносной активности, - это браузер пользователя при создании страницы и интерпретации всего JavaScript.
Сравнивая текущую версию HTTP-заголовка и активного содержимого платежных страниц, полученных браузером пользователя, с предыдущими или известными версиями, можно обнаружить несанкционированные изменения, которые могут указывать на атаку скимминга.
Кроме того, при поиске известных признаков компрометации и элементов сценария или поведения, типичных для скиммеров, могут быть подняты подозрительные предупреждения.

Примеры:
Механизмы, которые обнаруживают изменения в заголовках и содержимом платежной страницы и сообщают об этом, включают, но не ограничиваются ими:
  • О нарушениях Политики безопасности контента (CSP) можно сообщить объекту, используя директивы CSP reportto или report-uri.
  • Изменения в самом CSP могут указывать на вмешательство.
  • Внешний мониторинг с помощью систем, которые запрашивают и анализируют полученные веб-страницы (также известный как синтетический мониторинг пользователей), может обнаруживать изменения в JavaScript на страницах платежей и предупреждать персонал.
  • Внедрение защищенного от несанкционированного доступа скрипта обнаружения несанкционированного доступа на страницу оплаты может предупреждать и блокировать при обнаружении вредоносного поведения скрипта.
  • Обратные прокси-серверы и сети доставки контента могут обнаруживать изменения в сценариях и предупреждать персонал.
Часто эти механизмы основаны на подписке или облаке, но также могут основываться на пользовательских и индивидуальных решениях.
Requirement 11.5.2
11.5.2
Определенные Требования к Подходу:
Механизм обнаружения изменений (например, средства мониторинга целостности файлов) развертывается следующим образом:
  • Для предупреждения персонала о несанкционированном изменении (включая изменения, добавления и удаления) важных файлов.
  • Для выполнения критических сравнений файлов не реже одного раза в неделю
Цель Индивидуального подхода:
Критически важные файлы не могут быть изменены неавторизованным персоналом без создания предупреждения.

Примечания по применению:
Для целей обнаружения изменений критическими файлами обычно являются те, которые регулярно не изменяются, но изменение которых может указывать на компрометацию системы или риск компрометации. Механизмы обнаружения изменений, такие как продукты мониторинга целостности файлов, обычно поставляются с предварительно настроенными критически важными файлами для соответствующей операционной системы. Другие важные файлы, например файлы для пользовательских приложений, должны быть оценены и определены организацией (то есть продавцом или поставщиком услуг).

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

Надлежащая практика:
Примеры типов файлов, которые следует отслеживать, включают, но не ограничиваются ими:
  • Системные исполняемые файлы.
  • Исполняемые файлы приложений.
  • Файлы конфигурации и параметров.
  • Централизованно хранимые, исторические или архивированные журналы аудита.
  • Дополнительные критические файлы, определенные организацией (например, с помощью оценки рисков или другими способами).
Примеры:
Решения для обнаружения изменений, такие как средства мониторинга целостности файлов (FIM), проверяют наличие изменений, дополнений и удалений в критически важных файлах и уведомляют об обнаружении таких изменений.
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.8.32
А.8.32 Управление изменениями
Изменения в средствах обработки информации и информационных системах должны быть объектом процедур управления изменениями.
NIST Cybersecurity Framework (EN):
PR.IP-3 PR.IP-3: Configuration change control processes are in place
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.8.32
А.8.32 Change management
Changes to information processing facilities and information systems shall be subject to change management procedures.

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

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