Куда я попал?
Приказ ФСТЭК России № 21 от 18.02.2013
Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных
ОЦЛ.2
Для проведения оценки соответствия по документу войдите в систему.
Список требований
-
ОЦЛ.2 Контроль целостности персональных данных, содержащихся в базах данных информационной системыНеобязательное требование
Похожие требования
NIST Cybersecurity Framework (RU):
PR.DS-6
PR.DS-6: Механизмы проверки целостности используются для проверки программного обеспечения, встроенного программного обеспечения и целостности информации.
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.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
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 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
ОЦЛ.2
ОЦЛ.2 Контроль целостности информации, содержащейся в базах данных информационной системы
Федеральный Закон № 152 от 27.07.2006 "О персональных данных":
Статья 5. Пункт 6.
6. При обработке персональных данных должны быть обеспечены точность персональных данных, их достаточность, а в необходимых случаях и актуальность по отношению к целям обработки персональных данных. Оператор должен принимать необходимые меры либо обеспечивать их принятие по удалению или уточнению неполных или неточных данных.
SWIFT Customer Security Controls Framework v2022:
6 - 6.3 Database Integrity
6.3 Database Integrity
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
ОЦЛ.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 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
ОЦЛ.2
ОЦЛ.2 Контроль целостности информации
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.