Куда я попал?
NIST Cybersecurity Framework (RU)
Framework
PR.DS-6
Для проведения оценки соответствия по документу войдите в систему.
Список требований
Похожие требования
CIS Critical Security Controls v8 (The 18 CIS CSC):
3.14
3.14 Log Sensitive Data Access
Log sensitive data access, including modification and disposal.
Log sensitive data access, including modification and disposal.
2.6
2.6 Allowlist Authorized Libraries
Use technical controls to ensure that only authorized software libraries, such as specific .dll, .ocx, .so, etc., files are allowed to load into a system process. Block unauthorized libraries from loading into a system process. Reassess bi-annually, or more frequently.
Use technical controls to ensure that only authorized software libraries, such as specific .dll, .ocx, .so, etc., files are allowed to load into a system process. Block unauthorized libraries from loading into a system process. Reassess bi-annually, or more frequently.
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
ОЦЛ.1
ОЦЛ.1 Контроль целостности программного обеспечения, включая программное обеспечение средств защиты информации
ОЦЛ.2
ОЦЛ.2 Контроль целостности персональных данных, содержащихся в базах данных информационной системы
Russian Unified Cyber Security Framework (на основе The 18 CIS CSC):
2.6
2.6 Применяются белые списки разрешенных библиотек
Можно запускать процессы только с использованием библиотек из белого списка, с указанием конкретных файлов .dll, .ocx, .so и так далее.
Неавторизованные библиотеки блокируются.
Список пересматривается раз в полгода или чаще.
Можно запускать процессы только с использованием библиотек из белого списка, с указанием конкретных файлов .dll, .ocx, .so и так далее.
Неавторизованные библиотеки блокируются.
Список пересматривается раз в полгода или чаще.
3.14
3.14 Ведется журнал доступа к чувствительным данным
В том числе ведется история изменений и уничтожения конфиденциальных документов.
В том числе ведется история изменений и уничтожения конфиденциальных документов.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 11.6.1
11.6.1
Defined Approach Requirements:
A change- and tamper-detection mechanism is deployed as follows:
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:
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:
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.
Requirement 1.2.8
1.2.8
Defined Approach Requirements:
Configuration files for NSCs are:
Defined Approach Requirements:
Configuration files for NSCs are:
- Secured from unauthorized access.
- Kept consistent with active network configurations.
Customized Approach Objective:
NSCs cannot be defined or modified using untrusted configuration objects (including files).
Applicability Notes:
Any file or setting used to configure or synchronize NSCs is considered to be a “configuration file.” This includes files, automated and system-based controls, scripts, settings, infrastructure as code, or other parameters that are backed up, archived, or stored remotely.
Defined Approach Testing Procedures:
NSCs cannot be defined or modified using untrusted configuration objects (including files).
Applicability Notes:
Any file or setting used to configure or synchronize NSCs is considered to be a “configuration file.” This includes files, automated and system-based controls, scripts, settings, infrastructure as code, or other parameters that are backed up, archived, or stored remotely.
Defined Approach Testing Procedures:
- 1.2.8 Examine configuration files for NSCs to verify they are in accordance with all elements specified in this requirement.
Purpose:
To prevent unauthorized configurations from being applied to the network, stored files with configurations for network controls need to be kept up to date and secured against unauthorized changes.
Keeping configuration information current and secure ensures that the correct settings for NSCs are applied whenever the configuration is run.
Examples:
If the secure configuration for a router is stored in non-volatile memory, when that router is restarted or rebooted, these controls should ensure that its secure configuration is reinstated.
To prevent unauthorized configurations from being applied to the network, stored files with configurations for network controls need to be kept up to date and secured against unauthorized changes.
Keeping configuration information current and secure ensures that the correct settings for NSCs are applied whenever the configuration is run.
Examples:
If the secure configuration for a router is stored in non-volatile memory, when that router is restarted or rebooted, these controls should ensure that its secure configuration is reinstated.
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.14.2.4
A.14.2.4 Ограничения на изменения пакетов программ
Мера обеспечения информационной безопасности: Следует избегать модификаций пакетов программ, ограничиваясь необходимыми изменениями, и строго контролировать все изменения
Мера обеспечения информационной безопасности: Следует избегать модификаций пакетов программ, ограничиваясь необходимыми изменениями, и строго контролировать все изменения
A.12.2.1
A.12.2.1 Меры обеспечения информационной безопасности в отношении вредоносных программ
Мера обеспечения информационной безопасности: Для защиты от вредоносных программ должны быть реализованы меры обеспечения информационной безопасности, связанные с обнаружением, предотвращением и восстановлением, в сочетании с соответствующим информированием пользователей
Мера обеспечения информационной безопасности: Для защиты от вредоносных программ должны быть реализованы меры обеспечения информационной безопасности, связанные с обнаружением, предотвращением и восстановлением, в сочетании с соответствующим информированием пользователей
A.14.1.3
A.14.1.3 Защита транзакций прикладных сервисов
Мера обеспечения информационной безопасности: Информацию, используемую в транзакциях прикладных сервисов, следует защищать для предотвращения неполной передачи, ложной маршрутизации, несанкционированного изменения, раскрытия, дублирования или воспроизведения сообщений
Мера обеспечения информационной безопасности: Информацию, используемую в транзакциях прикладных сервисов, следует защищать для предотвращения неполной передачи, ложной маршрутизации, несанкционированного изменения, раскрытия, дублирования или воспроизведения сообщений
A.12.5.1
A.12.5.1 Установка программного обеспечения в эксплуатируемых системах
Мера обеспечения информационной безопасности: Должны быть реализованы процедуры контроля установки программного обеспечения в системах, находящихся в эксплуатации
Мера обеспечения информационной безопасности: Должны быть реализованы процедуры контроля установки программного обеспечения в системах, находящихся в эксплуатации
A.14.1.2
A.14.1.2 Обеспечение безопасности прикладных сервисов, предоставляемых с использованием сетей общего пользования
Мера обеспечения информационной безопасности: Информация, используемая в прикладных сервисах и передаваемая по сетям общего пользования, должна быть защищена от мошеннической деятельности, оспаривания договоров, а также несанкционированного раскрытия и модификации
Мера обеспечения информационной безопасности: Информация, используемая в прикладных сервисах и передаваемая по сетям общего пользования, должна быть защищена от мошеннической деятельности, оспаривания договоров, а также несанкционированного раскрытия и модификации
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 2.8
CSC 2.8 Implement Application Whitelisting of Libraries
The organization's application whitelisting software must ensure that only authorized software libraries (such as *.dll, *.ocx, *.so, etc.) are allowed to load into a system process.
The organization's application whitelisting software must ensure that only authorized software libraries (such as *.dll, *.ocx, *.so, etc.) are allowed to load into a system process.
CSC 14.9
CSC 14.9 Enforce Detail Logging for Access or Changes to Sensitive Data
Enforce detailed audit logging for access to sensitive data or changes to sensitive data (utilizing tools such as File Integrity Monitoring or Security Information and Event Monitoring).
Enforce detailed audit logging for access to sensitive data or changes to sensitive data (utilizing tools such as File Integrity Monitoring or Security Information and Event Monitoring).
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 1.2.8
1.2.8
Определенные Требования к Подходу:
Файлы конфигурации для NSCs:
Определенные Требования к Подходу:
Файлы конфигурации для NSCs:
- Защищены от несанкционированного доступа.
- Поддерживаются в соответствии с активными сетевыми конфигурациями.
Цель Индивидуального подхода:
NSCS не могут быть определены или изменены с использованием ненадежных объектов конфигурации (включая файлы).
Примечания по применению:
Любой файл или параметр, используемый для настройки или синхронизации NSCS, считается “файлом конфигурации”. Сюда входят файлы, автоматизированные и системные элементы управления, сценарии, настройки, инфраструктура в виде кода или другие параметры, которые копируются, архивируются или хранятся удаленно.
Определенные Процедуры Тестирования Подхода:
NSCS не могут быть определены или изменены с использованием ненадежных объектов конфигурации (включая файлы).
Примечания по применению:
Любой файл или параметр, используемый для настройки или синхронизации NSCS, считается “файлом конфигурации”. Сюда входят файлы, автоматизированные и системные элементы управления, сценарии, настройки, инфраструктура в виде кода или другие параметры, которые копируются, архивируются или хранятся удаленно.
Определенные Процедуры Тестирования Подхода:
- 1.2.8 Проверьте файлы конфигурации для NSCS, чтобы убедиться, что они соответствуют всем элементам, указанным в этом требовании.
Цель:
Чтобы предотвратить применение несанкционированных конфигураций к сети, сохраненные файлы с конфигурациями для сетевых элементов управления должны обновляться и защищаться от несанкционированных изменений.
Сохранение актуальной и безопасной информации о конфигурации гарантирует, что правильные настройки для NSCS применяются при каждом запуске конфигурации.
Примеры:
Если защищенная конфигурация маршрутизатора хранится в энергонезависимой памяти, при перезапуске или перезагрузке этого маршрутизатора эти элементы.
Чтобы предотвратить применение несанкционированных конфигураций к сети, сохраненные файлы с конфигурациями для сетевых элементов управления должны обновляться и защищаться от несанкционированных изменений.
Сохранение актуальной и безопасной информации о конфигурации гарантирует, что правильные настройки для NSCS применяются при каждом запуске конфигурации.
Примеры:
Если защищенная конфигурация маршрутизатора хранится в энергонезависимой памяти, при перезапуске или перезагрузке этого маршрутизатора эти элементы.
Requirement 11.6.1
11.6.1
Определенные Требования к Подходу:
Механизм обнаружения изменений и несанкционированного доступа развертывается следующим образом:
Определенные Требования к Подходу:
Механизм обнаружения изменений и несанкционированного доступа развертывается следующим образом:
- Для предупреждения персонала о несанкционированном изменении (включая признаки компрометации, изменения, добавления и удаления) заголовков HTTP и содержимого платежных страниц, полученных браузером пользователя.
- Механизм настроен на оценку полученного HTTP-заголовка и страницы оплаты.
- Функции механизма выполняются следующим образом:
- Не реже одного раза в семь дней
- ИЛИ
- Периодически (с периодичностью, определенной в целевом анализе рисков организации, который выполняется в соответствии со всеми элементами, указанными в Требовании 12.3.1).
Цель Индивидуального подхода:
Код или методы скимминга электронной коммерции не могут быть добавлены на страницы платежей, полученные браузером потребителя, без своевременного оповещения. Меры по борьбе со скиммингом не могут быть удалены со страниц платежей без создания оперативного предупреждения.
Примечания по применению:
Цель этого требования заключается не в том, чтобы организация устанавливала программное обеспечение в системах или браузерах своих потребителей, а скорее в том, чтобы организация использовала методы, подобные тем, которые описаны в разделе Примеры в колонке Руководства, для предотвращения и обнаружения непредвиденных действий скрипта.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
Код или методы скимминга электронной коммерции не могут быть добавлены на страницы платежей, полученные браузером потребителя, без своевременного оповещения. Меры по борьбе со скиммингом не могут быть удалены со страниц платежей без создания оперативного предупреждения.
Примечания по применению:
Цель этого требования заключается не в том, чтобы организация устанавливала программное обеспечение в системах или браузерах своих потребителей, а скорее в том, чтобы организация использовала методы, подобные тем, которые описаны в разделе Примеры в колонке Руководства, для предотвращения и обнаружения непредвиденных действий скрипта.
Это требование является наилучшей практикой до 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-заголовка и активного содержимого платежных страниц, полученных браузером пользователя, с предыдущими или известными версиями, можно обнаружить несанкционированные изменения, которые могут указывать на атаку скимминга.
Кроме того, при поиске известных признаков компрометации и элементов сценария или поведения, типичных для скиммеров, могут быть подняты подозрительные предупреждения.
Примеры:
Механизмы, которые обнаруживают изменения в заголовках и содержимом платежной страницы и сообщают об этом, включают, но не ограничиваются ими:
Многие веб-страницы теперь полагаются на сборку объектов, включая активный контент (в первую очередь JavaScript), из нескольких интернет-местоположений. Кроме того, содержимое многих веб-страниц определяется с помощью систем управления контентом и управления тегами, которые, возможно, невозможно отслеживать с помощью традиционных механизмов обнаружения изменений.
Таким образом, единственное место, где можно обнаружить изменения или признаки вредоносной активности, - это браузер пользователя при создании страницы и интерпретации всего JavaScript.
Сравнивая текущую версию HTTP-заголовка и активного содержимого платежных страниц, полученных браузером пользователя, с предыдущими или известными версиями, можно обнаружить несанкционированные изменения, которые могут указывать на атаку скимминга.
Кроме того, при поиске известных признаков компрометации и элементов сценария или поведения, типичных для скиммеров, могут быть подняты подозрительные предупреждения.
Примеры:
Механизмы, которые обнаруживают изменения в заголовках и содержимом платежной страницы и сообщают об этом, включают, но не ограничиваются ими:
- О нарушениях Политики безопасности контента (CSP) можно сообщить объекту, используя директивы CSP reportto или report-uri.
- Изменения в самом CSP могут указывать на вмешательство.
- Внешний мониторинг с помощью систем, которые запрашивают и анализируют полученные веб-страницы (также известный как синтетический мониторинг пользователей), может обнаруживать изменения в JavaScript на страницах платежей и предупреждать персонал.
- Внедрение защищенного от несанкционированного доступа скрипта обнаружения несанкционированного доступа на страницу оплаты может предупреждать и блокировать при обнаружении вредоносного поведения скрипта.
- Обратные прокси-серверы и сети доставки контента могут обнаруживать изменения в сценариях и предупреждать персонал.
Часто эти механизмы основаны на подписке или облаке, но также могут основываться на пользовательских и индивидуальных решениях.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
ОЦЛ.1
ОЦЛ.1 Контроль целостности программного обеспечения, включая программное обеспечение средств защиты информации
ОЦЛ.2
ОЦЛ.2 Контроль целостности информации, содержащейся в базах данных информационной системы
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.8.19
А.8.19 Установка программного обеспечения
Должны быть реализованы процедуры и меры безопасного управления установкой программного обеспечения в операционных системах.
Должны быть реализованы процедуры и меры безопасного управления установкой программного обеспечения в операционных системах.
SWIFT Customer Security Controls Framework v2022:
6 - 6.3 Database Integrity
6.3 Database Integrity
6 - 6.2 Software Integrity
6.2 Software Integrity
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
ОЦЛ.1
ОЦЛ.1 Контроль целостности программного обеспечения
ОЦЛ.2
ОЦЛ.2 Контроль целостности информации
NIST Cybersecurity Framework (EN):
PR.DS-6
PR.DS-6: Integrity checking mechanisms are used to verify software, firmware, and information integrity
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
ОЦЛ.1
ОЦЛ.1 Контроль целостности программного обеспечения
ОЦЛ.2
ОЦЛ.2 Контроль целостности информации
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
12.5.1
12.5.1 Установка программного обеспечения в эксплуатируемых системах
12.5.1 Установка программного обеспечения в эксплуатируемых системах
Мера обеспечения ИБ
Должны быть реализованы процедуры контроля установки программного обеспечения в системах, находящихся в эксплуатации.
Руководство по применению
Необходимо принять во внимание следующие рекомендации по управлению изменениями программного обеспечения в эксплуатируемых системах:
- a) обновление эксплуатируемого программного обеспечения, приложений и программных библиотек должны выполнять только обученные администраторы при наличии соответствующего разрешения руководства (см. 9.4.5);
- b) эксплуатируемые системы должны содержать только утвержденный исполняемый код и не должны содержать разрабатываемые коды или компиляторы;
- c) программное обеспечение и приложения следует внедрять в эксплуатируемую систему только после обширного и успешного тестирования; тесты должны охватывать удобство использования, безопасность, влияние на другие системы, дружелюбность интерфейса и должны проводиться на выделенных для этого системах (см. 12.1.4); следует убедиться, что все соответствующие исходные программные библиотеки были обновлены;
- d) должна использоваться система управления конфигурацией для контроля над всем внедренным программным обеспечением и системной документацией;
- e) перед внедрением изменений должна быть разработана стратегия возврата в исходное состояние;
- f) следует вести журнал всех обновлений действующих программных библиотек;
- g) предыдущие версии прикладного программного обеспечения следует сохранять в качестве меры на случай непредвиденных обстоятельств;
- h) старые версии программного обеспечения должны быть заархивированы вместе со всей необходимой информацией и параметрами, процедурами, деталями настройки и вспомогательным программным обеспечением на тот же срок, что и данные.
Поставляемое программное обеспечение, используемое в эксплуатируемых системах, должно поддерживаться на уровне, обеспечиваемом поставщиком. Со временем поставщики программного обеспечения перестанут поддерживать более старые версии программного обеспечения. Организация должна учитывать риски, связанные с использованием неподдерживаемого программного обеспечения.
Любое решение об обновлении до новой версии должно учитывать требования бизнеса по изменению и безопасности новой версии, например введение нового функционала, связанного с ИБ, или количество и серьезность проблем безопасности, связанных с этой версией. Пакеты исправлений программного обеспечения должны применяться тогда, когда они могут помочь устранить или снизить уязвимости ИБ (см. 12.6).
Физический или логический доступ должен предоставляться поставщикам только когда это необходимо для целей поддержки и с одобрения руководства. Действия поставщика следует контролировать (см. 15.2.1).
Компьютерное программное обеспечение может зависеть от поставляемого внешнего программного обеспечения и модулей, которые должны быть контролируемы и управляемы во избежание несанкционированных изменений, которые могут привести к уязвимостям в безопасности.
14.1.3
14.1.3 Защита транзакций прикладных сервисов
Мера обеспечения ИБ
Информацию, используемую в транзакциях прикладных сервисов, следует защищать для предотвращения неполной передачи, ложной маршрутизации, несанкционированного изменения, раскрытия, дублирования или воспроизведения сообщений.
Руководство по применению
Вопросы безопасности для транзакций прикладных сервисов должны включать следующее:
- a) использование электронных подписей каждой из сторон, участвующих в транзакции;
- b) все аспекты транзакции, то есть обеспечение того, что:
- секретная аутентификационная информация пользователей с каждой стороны проверена и действительна;
- транзакция остается конфиденциальной;
- сохраняется конфиденциальность всех вовлеченных сторон;
- c) канал связи между всеми вовлеченными сторонами защищен;
- d) протоколы, используемые для связи между всеми вовлеченными сторонами, защищены;
- e) обеспечение того, чтобы хранение деталей транзакции находилось за пределами какой-либо общедоступной среды, например в хранилище интрасети организации, которое не доступно непосредственно из сети Интернет;
- f) если используется доверенный орган (например, для целей выдачи и поддержки электронных подписей или цифровых сертификатов), обеспечение безопасности интегрируется и становится частью процесса управления сертификатами/подписями на протяжении всего жизненного цикла такого процесса.
Дополнительная информация
Объем принятых мер обеспечения ИБ должен соответствовать уровню риска, связанного с каждой формой транзакции прикладных сервисов.
Транзакции должны соответствовать юридическим и нормативным требованиям той юрисдикции, где их формируют, обрабатывают, завершают или хранят.
12.2.1
12.2.1 Меры обеспечения информационной безопасности в отношении вредоносных программ
Мера обеспечения ИБ
Для защиты от вредоносных программ должны быть реализованы меры обеспечения ИБ, связанные с обнаружением, предотвращением и восстановлением, в сочетании с соответствующим информированием пользователей.
Руководство по применению
Защита от вредоносных программ должна основываться на применении программного обеспечения для обнаружения вредоносных программ и восстановления данных, осведомленности об ИБ, соответствующих мерах контроля доступа к системе и управлению изменениями. Следует принять во внимание следующие рекомендации:
- a) установление формальной политики, запрещающей использование неавторизованного программного обеспечения (см. 12.6.2 и 14.2);
- b) реализация мер обеспечения ИБ, которые предотвращают или обнаруживают использование неавторизованного программного обеспечения (например, белый список приложений);
- c) внедрение мер обеспечения ИБ, которые предотвращают или обнаруживают обращение к известным или предполагаемым вредоносным веб-сайтам (например, ведение черного списка);
- d) установление формальной политики для защиты от рисков, связанных с получением файлов и программного обеспечения из внешних сетей или через них, либо с помощью других способов, с указанием мер по защите;
- e) снижение числа уязвимостей, которые могут быть использованы вредоносными программами, например через менеджмент технических уязвимостей (см. 12.6);
- f) проведение регулярных проверок программного обеспечения и содержимого систем, поддерживающих критические бизнес-процессы; наличие любых несанкционированных файлов или неавторизованных изменений должно быть официально расследовано;
- g) установка и регулярное обновление программного обеспечения для обнаружения вредоносных программ и восстановления, предназначенного для сканирования компьютеров и носителей в качестве предупреждающей меры или на регулярной основе; проводимое сканирование должно включать в себя:
- проверку любых файлов, полученных по сети или через любой другой носитель, на наличие вредоносных программ перед использованием;
- проверку вложений и загружаемых файлов электронной почты на наличие вредоносных программ перед использованием; такое сканирование должно проводиться в разных местах, например на серверах электронной почты, настольных компьютерах и на первой линии сети организации;
- проверку веб-страницы на наличие вредоносных программ;
- h) определение процедур и обязанностей по обеспечению защиты от вредоносных программ в системах, обучению их использованию, составлению отчетов и восстановлению после атак с применением вредоносных программ;
- i) подготовка соответствующих планов обеспечения непрерывности бизнеса для восстановления после атак с применением вредоносных программ, включая все необходимые меры по резервному копированию и восстановлению данных и программного обеспечения (см. 12.3);
- j) внедрение процедур регулярного сбора информации, таких как подписка на списки рассылки или посещение веб-сайтов, предоставляющих информацию о новых вредоносных программах;
- k) внедрение процедур для проверки информации, относящейся к вредоносным программам, и обеспечения уверенности в том, что предупреждающие бюллетени точны и информативны; руководители должны гарантировать, что для дифференциации между реальными вредоносными программами и ложными используются квалифицированные источники, например авторитетные журналы, надежные веб-сайты или поставщики программного обеспечения по защите от вредоносных программ; все пользователи должны быть осведомлены о проблеме ложных вредоносных программ и о том, что необходимо делать при их получении;
- l) изолирование сред, где могут возникнуть катастрофические последствия.
Дополнительная информация
Использование двух или более программных продуктов от разных поставщиков, которые основываются на различных технологиях защиты от вредоносных программ, в среде обработки информации может повысить эффективность защиты от вредоносных программ.
Следует проявлять осторожность при защите от внедрения вредоносного кода во время обслуживания и аварийных процедур, которые могут обойти обычные меры защиты от вредоносного программного обеспечения.
При определенных условиях защита от вредоносных программ может вызвать нарушения в работе средств обработки информации.
Использование в качестве меры защиты от вредоносного программного обеспечения только средства обнаружения и восстановления обычно недостаточно и требует сопровождения эксплуатационными процедурами для предотвращения внедрения вредоносных программ.
14.2.4
14.2.4 Ограничения на изменения пакетов программ
Мера обеспечения ИБ
Следует избегать модификаций пакетов программ, ограничиваться необходимыми изменениями и строго контролировать все изменения.
Руководство по применению
Насколько это возможно и практически осуществимо, пакеты программного обеспечения, приобретаемые у поставщика, следует использовать без изменений. Если требуется модифицировать пакет программ, необходимо учитывать следующее:
- a) возможен риск нарушения встроенных средств контроля целостности;
- b) должно ли быть получено согласие поставщика;
- c) возможность получения необходимых изменений от поставщика в виде стандартных обновлений программы;
- d) возможные последствия в случае, если организация станет ответственной за последующее сопровождение программного обеспечения в результате внесенных изменений;
- e) совместимость с другим используемым программным обеспечением.
При необходимости внесения изменений оригинальное программное обеспечение должно быть сохранено, а изменения должны применяться к четко определенной копии. Процесс управления обновлениями программного обеспечения должен быть реализован для обеспечения того, чтобы для всего разрешенного программного обеспечения устанавливались самые последние утвержденные исправления и обновления (см. 2.6.1). Все изменения должны быть полностью протестированы и задокументированы, чтобы при необходимости их можно было применить к будущим обновлениям программного обеспечения. При необходимости изменения должны быть проверены и подтверждены независимым органом по оценке.
14.1.2
14.1.2 Обеспечение безопасности прикладных сервисов, предоставляемых с использованием сетей общего пользования
Мера обеспечения ИБ
Информация, используемая в прикладных сервисах и передаваемая по сетям общего пользования, должна быть защищена от мошеннической деятельности, оспаривания договоров, а также несанкционированного раскрытия и модификации.
Руководство по применению
ИБ прикладных сервисов, проходящих через общедоступные сети, следует обеспечивать исходя из следующих соображений:
- a) уровень доверия, который требует каждая сторона в отношении друг друга, например посредством аутентификации;
- b) процессы авторизации, связанные с тем, кто может утверждать содержание, выпускать или подписывать ключевые деловые документы;
- c) обеспечение того, чтобы взаимодействующие стороны были полностью проинформированы о своих правах на предоставление и использование сервиса;
- d) определение и соблюдение требований в отношении конфиденциальности, целостности, подтверждения отправки и получения ключевых документов, а также невозможности отказа от совершенных сделок, например связанных с процессами заключения контрактов и проведения тендеров;
- e) уровень доверия, необходимый для целостности ключевых документов;
- f) требования по защите любой конфиденциальной информации;
- g) конфиденциальность и целостность любых операций с заказом, платежной информации, адреса доставки и подтверждения получения;
- h) степень проверки платежной информации, предоставленной клиентом;
- i) выбор наиболее подходящей формы расчета для защиты от мошенничества;
- j) уровень защиты, необходимый для сохранения конфиденциальности и целостности информации о заказе;
- k) предотвращение потери или дублирования информации об операции;
- l) ответственность за мошеннические операции;
- m) страховые требования.
Многие из вышеперечисленных соображений могут быть выполнены с применением криптографических мер обеспечения ИБ (раздел 10), принимая во внимание требования законодательства (раздел 18, особенно 18.1.5 для законодательства о криптографии).
Механизмы предоставления услуг между участниками должны быть закреплены документально оформленным соглашением, в котором обе стороны соглашаются с условиями предоставления сервисов, включая детали авторизации (перечисление b).
Следует учитывать требования устойчивости к атакам, которые могут включать в себя требования по защите используемых серверов приложений или обеспечению доступности сетевых соединений, необходимых для предоставления сервиса.
Дополнительная информация
Приложения, доступные через сети общего пользования, подвержены целому ряду угроз, таких как мошеннические действия, нарушение условий договора или публичное разглашение информации. Поэтому обязательным здесь является детальная оценка риска и правильный выбор мер обеспечения ИБ. Необходимые меры обеспечения ИБ часто включают в себя криптографические методы для аутентификации и защиты данных при передаче.
Прикладные сервисы могут использовать безопасные методы аутентификации, например использование криптографии с открытым ключом и электронных подписей (раздел 10) для снижения рисков. Кроме того, при необходимости, могут быть задействованы доверенные третьи стороны.
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.8.19
А.8.19 Installation of software on operational systems
Procedures and measures shall be implemented to securely manage software installation on operational systems.
Procedures and measures shall be implemented to securely manage software installation on operational systems.
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.