Соответствие требованиям

Куда я попал?

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

Подробнее

Наш канал

Payment Card Industry 3-D Secure (PCI 3DS)

Стандарт

Requirement 4

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

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

3DS SDK Vendor Security Requirements and Assessment Procedures
Security Objective 4: Manage Risks and Vulnerabilities
A critical aspect of secure software is the software vendor’s ability to identify and resolve vulnerabilities before they can be exploited. To be effective at this, the software vendor must have well-structured and repeatable processes in place to identify potential risks, to design and implement security controls to address those risks, and to resolve any vulnerabilities that are identified post-release. The implemented processes should include analyzing any risks associated with the use of third-party components or services, preventing the reintroduction of previously addressed vulnerabilities, and should result in the timely release of security updates.
Requirement 4: Risks and vulnerabilities affecting the 3DS SDK are minimized and addressed in a timely manner.
Requirements:
4.1 Threat and Vulnerability Analysis
Threats, attack scenarios and/or attack vectors applicable to the 3DS SDK are known, analyzed, documented, and described in terms of their exploitability, impact, and residual risk.
Assessment Procedures:
T.4.1.1 The tester shall examine vendor materials and other evidence to confirm that a process is implemented by the 3DS SDK Vendor for identifying, documenting, and analyzing threats, vectors, and attack scenarios applicable to the 3DS SDK.
T.4.1.2 The tester shall confirm that the process required is sufficiently detailed for it to be repeatable across different personnel and locations.
T.4.1.3 The tester shall confirm that the process clearly outlines the individuals or teams responsible for determining and investigating new threats. It is acceptable if a group or job title is referenced, but the tester must ensure that there is a clear line of responsibility for this item.
T.4.1.4 The tester shall interview a sample of the personnel identified in T.4.1.3 and confirm that they are aware of the policy and procedure requirements for the analysis of new threats. The tester shall also examine vendor materials and other evidence produced by these interviewees to confirm that defined processes are being followed.
T.4.1.5 The tester shall confirm from the evidence identified in T.4.1.1 that methods are defined and used for categorizing and ranking threats. The tester shall confirm that a documented methodology exists, which can be reasonably assumed to produce the same results each time it is enacted (assuming the same threat and threat environment). It is not a requirement that a public ranking method is used; it is acceptable for the vendor to implement its own method if this provides sufficient assurance and repeatability.
T.4.1.6 The tester shall interview a sample of the personnel identified in T.4.1.3 and confirm that they understand and can apply the categorizing and ranking methodology employed by the vendor.
T.4.1.7 For a sample of threats identified in T.4.1.4, the tester shall obtain the categorizing and ranking results for the sample and confirm that they align with the documented process.
Guidance:
The design of the 3DS SDK should be evaluated to identify common attack scenarios and/or potential attack vectors applicable to the 3DS SDK, and the results of that analysis documented. Documentation should describe the various aspects of the code that could be attacked (including things that frameworks and libraries do on behalf of the 3DS SDK), the difficulty in mounting a successful attack, how widely the program will be distributed, what mitigation techniques are used (for example, how the security functionality of the operating system is leveraged), and identify or define a methodology for measuring the likelihood and impact of an exploit. Those individuals making the residual risk determinations should be independent of those individuals responsible for the development of the 3DS SDK. The need for independence is to ensure that only disinterested individuals make assessments and not individuals with objectives that may be in conflict with security concerns.
Requirements:
4.2 Development of Defensive Strategies
Defensive strategies and mechanisms to protect against attack vectors and/or scenarios are designed and implemented. Attack scenarios that are applicable to the 3DS SDK but are not specifically addressed are justified.
Assessment Procedures:
T.4.2.1 The tester shall examine vendor materials and other evidence to confirm that there are clear, documented vendor policy and procedure statements regarding the remediation of identified vulnerabilities in the 3DS SDK. These statements must tie together with the identification and ranking process covered under Requirement 4.1, “Threat and Vulnerability Analysis.”
T.4.2.2 The tester shall determine whether the vendor explicitly allows for potential threats to remain un-addressed and, if so, the tester shall confirm that ranking/categorization levels are considered acceptable for this (as assessed in Requirement 4.1, “Threat and Vulnerability Analysis”), and that either this ranking process or another process explicitly involves a step to document and justify why it is acceptable to not address this vulnerability specifically.
T.4.2.3 The tester shall interview personnel responsible for the implementation of defensive strategies and confirm that they know of and understand the policy and procedure requirements for this process.
T.4.2.4 Referencing the documented threats and vulnerabilities sampled in Requirement 4.1, “Threat and Vulnerability Analysis,” the tester shall determine whether any vulnerabilities have been not specifically remediated and, if so, confirm that this is due to the correct and documented steps involved in the policy and procedures identified in T.4.2.1. Where all vulnerabilities have been addressed, the tester shall obtain more evidence to address this testing requirement. If vendor policy is to mitigate all threats and vulnerabilities, the tester shall require an increased sample size to confirm that each and every threat has been addressed.
Guidance:
Once threats, attack vectors, and attack scenarios are identified, they should be mitigated. 3DS SDK Vendors should define and implement mechanisms to protect the 3DS SDK from those risks and reduce the likelihood and impact of their exploitation. Any known risks that are not addressed or do not reduce the likelihood and impact of the exploitation of those risks to a reasonable level should be justified.
Requirements:
4.3 Software Security Testing
Software security testing is an integral part of the 3DS SDK’s life cycle and is performed throughout the software life cycle to confirm that risks and attack scenarios are addressed, defensive mechanisms are implemented properly, and the propagation of design flaws or vulnerabilities into production code is prevented.
Assessment Procedures:
T.4.3.1 The tester shall examine vendor materials and other evidence to confirm that the vendor has written policy and procedures requiring internal security review and testing that accounts for the entire 3DS SDK code base, including detecting vulnerabilities in code developed by the vendor, as well as vulnerabilities in third-party, open source, or shared components or libraries.
T.4.3.2 The tester shall confirm that the process for testing of internal code involves both manual and automated means.
T.4.3.3 The tester shall confirm that the process clearly outlines the individuals or teams responsible for this testing. It is acceptable if a group or job title is referenced, but the tester must ensure that there is a clear line of responsibility for this item.
T.4.3.4 The tester shall confirm that the process includes ensuring that the processes for identification and mitigation of threats are correctly performed prior to the release of any production code.
T.4.3.5 The tester shall confirm that the process includes ensuring that any test, debug, or other code that is intended only for internal use is removed prior to release to production.
T.4.3.6 Referencing threats sampled in the tests for Requirement 4.1, “Threat and Vulnerability Analysis,” the tester shall examine vendor materials and other evidence, interview personnel, and test the 3DS SDK to confirm that threats identified and noted as required to be mitigated were addressed before the 3DS SDK was released.
Guidance:
Software security testing is a fundamental practice to ensure that software cannot be exploited through known vulnerabilities or common attacker techniques. Performing security testing throughout the development process and during development of future updates using a variety of testing techniques mitigates the risk that vulnerabilities may be introduced during updates. Testing tools and techniques may include manual code reviews, static code analysis, dynamic code analysis, software composition analysis, fuzz testing, penetration testing, etc., where appropriate. Organizations are responsible for understanding common vulnerabilities associated with the technologies they are using and for implementing testing practices specific to addressing those vulnerabilities.
Requirements:
4.4 Vulnerability Identification and Monitoring
The 3DS SDK and its components are monitored for vulnerabilities. In addition to their own processes, 3DS SDK Vendors provide mechanisms to enable third parties to report vulnerabilities. Information on identified vulnerabilities is maintained. Vulnerabilities are addressed and software updates are made available to all stakeholders in a timely manner. All exceptions are documented and justified. The reoccurrence of previously addressed vulnerabilities is tracked and minimized.
Assessment Procedures:
T.4.4.1 The tester shall examine vendor materials and other evidence to confirm that there is a documented release policy for the 3DS SDK, and that this ensures the processes outlined in previous 4.x requirements are followed before the SDK is released to production.
T.4.4.2 The tester shall confirm that the release policy clearly outlines the acceptable period of time after which patches are made available for the different rankings of vulnerabilities as defined in previous 4.x requirements.
T.4.4.3 The tester shall examine vendor materials and other evidence, and interview personnel to confirm that the vendor has an explicit procedure in place for the acceptance and processing of new vulnerabilities through external communications. Although not mandated, this requirement can be met by a properly administered bug bounty program. It does require that reported vulnerabilities are formally registered and processed according to the documented process previously assessed in the 4.x requirements.
T.4.4.4 The tester shall examine vendor materials and other evidence, and interview personnel to confirm that there is a public-facing procedure for the reporting of vulnerabilities in the 3DS SDK. This procedure must implement methods to ensure the confidentiality of the vulnerability as it is reported. For example, a process that requires the reporting of a vulnerability to a shared “info@[company]” e-mail address, without additional encryption, would be non-compliant to this requirement.
Note: Use of a specific web portal secured with TLS (using acceptable ciphersuites), and/or e-mails secured with strong cryptography are examples of acceptable methods to secure the confidentiality of vulnerability reporting.
T.4.4.5 The tester shall examine vendor materials and other evidence, and interview personnel to confirm that, where any such third-party vulnerability reports have been accepted and processed, the process appears correct⎯e.g., through validation of any special e-mail address or portal that is to be used for public vulnerability reporting.
T.4.4.6 The tester shall examine vendor materials and other evidence to confirm that there is a process to validate that new releases have not re-introduced older vulnerabilities. This may involve the process being updated to specifically check for vulnerabilities as they are discovered, or ensuring that older and un-patched software components and libraries are removed from the development environment as they are updated.
T.4.4.7 The tester shall examine vendor materials and other evidence, and interview personnel to confirm that the process as documented is understood and followed. Where previously sampled vulnerabilities identified the need for an update to internal libraries or components, the tester shall confirm through these interviews and evidence that these have been correctly updated and the older, unpatched versions have been removed.
T.4.4.8 Where not covered under previous requirements, the tester shall examine vendor materials and other evidence, and interview personnel to confirm that any decisions not to address vulnerabilities are reasonably justified and documented.
Guidance:
The identification and management of vulnerabilities in the 3DS SDK and its components is not a one-time exercise. New vulnerabilities can be introduced at any time; therefore, it is imperative that the 3DS SDK is continuously monitored for vulnerabilities and appropriate action is taken when vulnerabilities are identified. 3DS SDK Vendors should have processes in place to identify vulnerabilities in the 3DS SDK and its components, including vulnerabilities identified by third parties, and resolve those vulnerabilities in a timely manner such that the integrity, confidentiality, and the overall confidence in the security of the 3DS SDK are maintained. It is understood that some vulnerabilities may not pose a risk to the application software or environment. However, regardless of the criticality or the impact of the vulnerability, it is important that all vulnerabilities are identified, their risk is known and that there is a process that recognizes, evaluates and (if necessary), assumes the risk. The process should include management review and approval.
Requirements:
4.5 Updates During Transaction Processing
The 3DS SDK Vendor does not enable updates or changes to 3DS SDK functionality to be pushed to the 3DS SDK during 3DS transaction processing.
Assessment Procedures:
T.4.5.1 The tester shall examine vendor materials and other evidence to confirm that the 3DS SDK does not accept updates during 3DS transaction processing.
T.4.5.2 The tester shall examine vendor materials and other evidence, including source code, to confirm that methods are implemented to prevent the SDK from being updated during 3DS transaction processing.
T.4.5.3 Where the operating systems and platforms targeted by the 3DS SDK do not allow for the applications to prevent or delay updates themselves, the tester shall confirm that other protections have been put in place by the vendor to mitigate interruption of the 3DS transaction process during updates.
T.4.5.4 The tester shall test the 3DS SDK by performing a series of 3DS transactions within a test host/harness that allows for updates to be pushed to the 3DS SDK, to confirm that the 3DS SDK does not accept updates during the transaction processing, and that the outcome of this testing aligns with the vendor materials and evidence provided in T.4.5.1 through T.4.5.3.
Guidance:
Updates to 3DS SDK functionality during 3DS transaction processing should not be permitted to ensure the integrity of those transactions. 3DS SDK Vendors should implement functionality within the 3DS SDK to preserve the integrity of the 3DS SDK code during 3DS transaction processing, while still enabling the 3DS Requestor App to push automatic updates to the consumer device when necessary.

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