Document Comparison
PCI-Secure-SLC-Standard-v1_0.pdf
→
PCI-Secure-SLC-Standard-v1_1.pdf
92% similar
35 → 35
Pages
12227 → 12449
Words
151
Content Changes
Content Changes
151 content changes. 38 administrative changes (dates, page numbers) hidden.
Added
p. 5
All guidance the software vendor is expected to provide its customers and other stakeholders to ensure that customers know how to implement and configure its software in a secure manner.
Some software vendors may have multiple software products covered by different software lifecycle management programs. Prior to assessment against the PCI Secure SLC Requirements, software vendors should identify the software products and associated software lifecycle management program(s) to be covered under the assessment. For more information on defining the scope of the Secure SLC assessment, refer to the PCI Secure SLC Program Guide.
4. Security Communications Within each of the sections defined above, the PCI Secure SLC Requirements are further subdivided into the following components:
Some software vendors may have multiple software products covered by different software lifecycle management programs. Prior to assessment against the PCI Secure SLC Requirements, software vendors should identify the software products and associated software lifecycle management program(s) to be covered under the assessment. For more information on defining the scope of the Secure SLC assessment, refer to the PCI Secure SLC Program Guide.
4. Security Communications Within each of the sections defined above, the PCI Secure SLC Requirements are further subdivided into the following components:
Added
p. 9
Where a third-party service can affect the software vendor’s software lifecycle management practices or the security of the software vendor’s software, the applicable PCI Secure SLC requirements will need to be identified and implemented for that service. The software vendor and service provider will need to understand which software lifecycle management functions are affected by the service provider and identify which PCI Secure SLC Requirements are the responsibility of the service provider and which are the responsibility of the software vendor.
Performing due diligence prior to engagement; Clear definition of security responsibilities; Periodic verification that agreed-upon responsibilities are being met; and A written agreement to ensure both parties understand and acknowledge their security responsibilities.
Performing due diligence prior to engagement; Clear definition of security responsibilities; Periodic verification that agreed-upon responsibilities are being met; and A written agreement to ensure both parties understand and acknowledge their security responsibilities.
Added
p. 18
2.6.b For a sample of the security assurance processes identified in Control Objective 2.4, the assessor shall interview personnel and examine any additional evidence necessary to determine if any failures or weaknesses in those security processes occurred, and to confirm that weak or ineffective processes were updated, augmented or replaced.
Added
p. 22
Evidence to support this control objective may include software- specific requirements documentation, feature lists, security control inventories, change-management documentation, risk assessment reports, test results, or any other evidence or information that clearly and consistently illustrates that the software vendor implements and maintains security controls in software to address the risks to that software.
Security testing should be performed by appropriately skilled vendor personnel or third parties. In addition, security testing personnel should be able to conduct tests in an objective manner and be authorized to escalate any identified vulnerabilities to appropriate management or development personnel so they can be properly addressed.
Security testing should be performed by appropriately skilled vendor personnel or third parties. In addition, security testing personnel should be able to conduct tests in an objective manner and be authorized to escalate any identified vulnerabilities to appropriate management or development personnel so they can be properly addressed.
Added
p. 30
To protect the confidentiality of any sensitive production data
•that is, sensitive data that is owned by an entity other than the software vendor
• and stored on software vendor systems, such data should never be used for purposes other than those for which the data was originally collected. If the software vendor provides services to its stakeholders that could result in the collection of sensitive production data⎯for example, for troubleshooting or debugging purposes⎯then the software vendor should record which specific data elements it collects and retains, and clearly communicate what data elements are collected and why they are collected to its customers and other relevant stakeholders.
•that is, sensitive data that is owned by an entity other than the software vendor
• and stored on software vendor systems, such data should never be used for purposes other than those for which the data was originally collected. If the software vendor provides services to its stakeholders that could result in the collection of sensitive production data⎯for example, for troubleshooting or debugging purposes⎯then the software vendor should record which specific data elements it collects and retains, and clearly communicate what data elements are collected and why they are collected to its customers and other relevant stakeholders.
Modified
p. 1
Payment Card Industry Software Security Framework Secure Software Lifecycle (Secure SLC) Requirements and Assessment Procedures Version 1.0
Payment Card Industry (PCI) Software Security Framework Secure Software Lifecycle Requirements and Assessment Procedures Version 1.1
Modified
p. 4
The PCI Secure SLC Standard is intended for use as part of the PCI Software Security Framework. Vendors wishing to validate payment software under the PCI Software Security Framework may optionally choose to validate their Secure SLC practices for that payment software to this PCI Secure SLC Standard.
The PCI Secure SLC Standard is intended for use as part of the PCI Software Security Framework. Under this framework, software vendors wishing to validate their software lifecycle management practices to this PCI Secure SLC Standard may optionally choose to do so. For more information on PCI Secure SLC validation, please refer to the PCI Secure SLC Program Guide.
Modified
p. 4
Terminology A list of applicable terms and definitions specific to the PCI Software Security Framework is provided in the PCI Software Security Framework Glossary of Terms, Abbreviations, and Acronyms, available in the PCI SSC Document Library: https://www.pcisecuritystandards.org/document_library.
Terminology A list of applicable terms and definitions is provided in the PCI Software Security Framework Glossary of Terms, Abbreviations, and Acronyms, available in the PCI SSC Document Library: https://www.pcisecuritystandards.org/document_library.
Removed
p. 5
• Vendor-provided guidance for customers and integrators/resellers to ensure that customers are aware how to implement and configure the payment software in a secure manner. The guidance may need to cover configurations and settings that cannot be controlled by the vendor once the payment software is installed by the customer.
Some vendors may have multiple software products covered by different software lifecycle management programs. Prior to assessment against the requirements within this standard, vendors should identify the payment software products and associated software lifecycle management program(s) to be covered under the assessment. For more information on defining the scope of the Secure SLC assessment, refer to the PCI Secure SLC Program Guide.
Some vendors may have multiple software products covered by different software lifecycle management programs. Prior to assessment against the requirements within this standard, vendors should identify the payment software products and associated software lifecycle management program(s) to be covered under the assessment. For more information on defining the scope of the Secure SLC assessment, refer to the PCI Secure SLC Program Guide.
Modified
p. 5
The policies and processes that govern how the software vendor manages its software throughout the software lifecycle.
Modified
p. 5
The tools, technologies, and techniques used by the software vendor in the development and management of its software.
Modified
p. 5
The software-testing methods and technologies used by the software vendor and the results of such testing.
Modified
p. 5
All people involved in the management of the software vendor’s software, including applicable vendor personnel and third-party contributors.
Modified
p. 5
All processes supporting the software vendor’s software lifecycle management activities, including change management, vulnerability management, and risk management.
Modified
p. 5
The software vendor’s software versioning methodology.
Modified
p. 5
All software vendor communications to its stakeholders.
Modified
p. 6
For this approach to be successful, vendors must possess a robust risk-management practice as an integral part of their “business as usual” operational processes. The specific software security controls needed to meet certain requirements in this standard⎯for example, additional data elements identified by the vendor as sensitive data2⎯will depend on the vendor’s risk-management priorities and processes. While this approach provides the vendor with flexibility to implement software security controls based on identified risk, the vendor must be able to demonstrate …
For this approach to be successful, software vendors must possess a robust risk-management practice as an integral part of their “business as usual” operational processes. The specific security controls needed to meet certain requirements in this standard⎯for example, additional data elements identified by the software vendor as sensitive data2⎯will depend on the software vendor’s risk-management priorities and processes. While this approach provides the software vendor with flexibility to implement the appropriate security controls based on identified risk, the software vendor …
Modified
p. 6
Where a PCI SSLC requirement does not define a specific level of rigor or a minimum frequency for periodic or recurring activities⎯for example, frequency of reviewing security strategy performance⎯the vendor may define the level of rigor or frequency as appropriate for its business. The rigor and frequency defined by the vendor must be supported by documented risk assessments and the resultant risk-management decisions. The vendor should be able to demonstrate that its implementation provides ongoing assurance that the activity is …
Where a PCI Secure SLC Requirement does not define a specific level of rigor or a minimum frequency for periodic or recurring activities⎯for example, the required frequency the software vendor must review security strategy performance⎯the software vendor may define the level of rigor or frequency as appropriate for its business. The rigor and frequency defined by the software vendor must be supported by documented risk assessments and the resultant risk-management decisions. The software vendor must be able to demonstrate that …
Modified
p. 6
Equally important is the need for vendors to understand all the requirements in this document and consider how they work together as a whole rather than focusing on any single requirement in isolation.
Equally important is the need for software vendors to understand all the security requirements in this document and consider how the software vendor’s software security controls and processes work together as a whole to satisfy the security requirements rather than focusing on any single requirement in isolation.
Removed
p. 7
4. Security Communications Each security objective includes a description of its intent and is further subdivided as follows:
Modified
p. 7
• The specific software security controls and outcomes required to satisfy the parent security objective. While all control objectives must be met in order to be validated to this PCI Secure SLC Standard, vendors may define the specific controls, tools, methods and techniques they use to meet each control objective.
Control Objectives
• The security outcomes that must be achieved. While all control objectives must be met in order to be validated to this PCI Secure SLC Standard, software vendors may define the specific controls, tools, methods and techniques they use to meet each control objective.
• The security outcomes that must be achieved. While all control objectives must be met in order to be validated to this PCI Secure SLC Standard, software vendors may define the specific controls, tools, methods and techniques they use to meet each control objective.
Modified
p. 7
•The validation activities to be performed by an assessor to confirm whether a specific control objective has been met. If an assessor determines that alternative testing methods are appropriate to validate a particular control objective, they
Test Requirements
•The validation activities to be performed by an assessor to confirm whether a specific control objective has been met. If an assessor determines that alternative testing methods are appropriate to validate a particular control objective, they must justify and document their testing approach as described in the Assessment Procedures and Test Requirements section.
•The validation activities to be performed by an assessor to confirm whether a specific control objective has been met. If an assessor determines that alternative testing methods are appropriate to validate a particular control objective, they must justify and document their testing approach as described in the Assessment Procedures and Test Requirements section.
Modified
p. 7
• Additional information to help vendors and assessors further understand the intent of the control objective and how it could be met. The guidance may include best practices to be considered as well as examples of controls or methods that, when properly implemented, could meet the intent of the control objective. This guidance is not intended to preclude other methods that a vendor may use to meet a control objective, nor does it replace or amend the control objective to …
Guidance
• Additional information to help software vendors and assessors further understand the intent of each control objective and how it could be met. The guidance may include best practices to be considered as well as examples of controls or methods that, when properly implemented, could meet the intent of the control objective. This guidance is not intended to preclude other methods that a software vendor may use to meet a control objective, nor does it replace or amend the control …
• Additional information to help software vendors and assessors further understand the intent of each control objective and how it could be met. The guidance may include best practices to be considered as well as examples of controls or methods that, when properly implemented, could meet the intent of the control objective. This guidance is not intended to preclude other methods that a software vendor may use to meet a control objective, nor does it replace or amend the control …
Modified
p. 8
Examine: The assessor critically evaluates data evidence. Common examples of evidence include software design and architecture documents (electronic or physical), source code, configuration and metadata files, bug tracking data and other output from software development systems, and security-testing results.
Modified
p. 8
Observe: The assessor watches an action or views something in the environment. Examples of observation subjects include personnel performing tasks or processes, software or system components performing a function or responding to input, system configurations/settings, environmental conditions, and physical controls.
Modified
p. 8
Interview: The assessor converses with individual personnel. The purpose of such interviews may include determining how an activity is performed, whether an activity is performed as defined, and whether personnel have particular knowledge or understanding of applicable policies, processes, responsibilities, or concepts.
Modified
p. 8
The test requirements provide both the vendor and assessors with a common understanding of the expected validation activities to be performed. The specific items or processes to be examined or observed and personnel to be interviewed should be appropriate for the control objective being validated as well as for each vendor’s organization structure, culture, and business practices. It is at the discretion of the assessor to determine the appropriateness or adequacy of the evidence provided by the vendor to support …
The test requirements provide both software vendors and assessors with a common understanding of the expected validation activities to be performed. The specific items or processes to be examined or observed and the personnel to be interviewed should be appropriate for the control objective being validated as well as for each software vendor’s unique organizational structure, culture, and business practices.
Modified
p. 8
When documenting the assessment results, the assessor identifies the testing activities performed and the result of each activity. While it is expected that an assessor will perform all the test requirements identified for each control objective, it may also be possible for a control objective to be validated using different or additional testing methods. In such cases, the assessor should document why testing methods that differed from those identified in this document were used, and how the methods utilized provide …
When documenting the assessment results, the assessor identifies the testing activities performed and the result of each activity. While it is expected that an assessor will perform all the test requirements identified for each control objective, it may also be possible for a control objective to be validated using different or additional testing methods. In such cases, the assessor should document and justify why other testing methods were used and how those methods provide at least the same level of …
Removed
p. 9
Where a third-party service impacts the vendor’s SSLC practices or affects the security of the payment software, the applicable PCI SSLC requirements will need to be identified and implemented for that service. The vendor and service provider will need to understand which SSLC functions can be impacted by the service provider and identify which SSLC requirements are the responsibility of the service provider and which are the responsibility of the vendor.
• Performing due diligence prior to engagement
• Clear definition of security responsibilities
• Periodic verification that agreed-upon responsibilities are being met
• Performing due diligence prior to engagement
• Clear definition of security responsibilities
• Periodic verification that agreed-upon responsibilities are being met
Modified
p. 9
Third-Party Service Providers Vendors often rely on outsourced, third-party service providers for certain SSLC functions•e.g., for software development (excluding the use of open-source code), performing code reviews or other testing of the vendor’s software, hosting for the vendor’s software-development or delivery platforms, or integration and installation of the vendor’s software products.
Third-Party Service Providers Software vendors often rely on outsourced, third-party service providers for certain software lifecycle management functions•e.g., for software development (excluding the use of open-source code), performing code reviews or other testing of the software vendor’s software, hosting for the software vendor’s software development or delivery platforms, or integrating and installing the software vendor’s products.
Modified
p. 9
The vendor is expected to have processes in place to manage risks associated with third-party service providers, including (as applicable for each service):
The software vendor is expected to have processes in place to manage risks associated with third-party service providers, including (as applicable for each service):
Modified
p. 9
While the ultimate responsibility for the security of the software lies with the software vendor, service providers may be required to demonstrate compliance with the applicable PCI Secure SLC Requirements based on the provided service. The service provider may do so by either:
Modified
p. 9
(a) Undergoing its own PCI SSLC assessment for the applicable product(s) or service(s) provided to the vendor, and providing evidence to the vendor that demonstrates its compliance to the applicable SSLC requirements for that product/service; or (b) Having the applicable product(s) or service(s) included in the vendor’s PCI SSLC assessment, and allowing the vendor’s assessor to evaluate whether the product/service meets the applicable requirements.
(a) Undergoing its own PCI Secure SLC assessment for the applicable product(s) or service(s) provided to the software vendor, and providing evidence to the software vendor that demonstrates its compliance to the applicable Secure SLC requirements for that product/service; or (b) Having the applicable product(s) or service(s) included in the software vendor’s PCI Secure SLC assessment, and allowing the software vendor’s assessor to evaluate whether the product/service meets the applicable PCI Secure SLC Requirements.
Modified
p. 11
Control Objectives Test Requirements Guidance Control Objective 1: Security Responsibility and Resources The vendor’s senior leadership team establishes formal responsibility and authority for the security of the vendor’s products and services. The vendor allocates resources to execute the strategy and ensure that personnel are appropriately skilled.
Control Objectives Test Requirements Guidance Control Objective 1: Security Responsibility and Resources The software vendor’s senior leadership team establishes formal responsibility and authority for the security of the software vendor’s products and services. The software vendor allocates resources to execute the strategy and ensure that personnel are appropriately skilled.
Modified
p. 11
• Accountability for ensuring the security of the vendor’s products and services is formally assigned to an individual or team by the vendor’s senior leadership.
• Accountability for ensuring the security of the software vendor’s products and services is formally assigned to an individual or team by the software vendor’s senior leadership.
Modified
p. 11
• Responsibilities include keeping senior leadership informed of security updates, issues, and other matters related to the security of the vendor’s products and services.
• Responsibilities include keeping senior leadership informed of security updates, issues, and other matters related to the security of the software vendor’s products and services.
Modified
p. 11
• Updates are provided to senior leadership at least annually on the performance of and changes to the vendor’s software security policy and strategy (as described in Control Objective 2).
• Updates are provided to senior leadership at least annually on the performance of and changes to the software vendor’s software security policy and strategy described in Control Objective 2.
Modified
p. 11
The formal assignment of responsibility by the vendor’s senior leadership team ensures strategic-level visibility into and influence over the vendor’s software security practices. Senior leadership typically represents those individuals or teams with the responsibility and authority to make strategic business decisions for the vendor organization. In many cases, senior leadership teams are comprised of members of the executive team such as the chief executive officer (CEO), chief financial officer (CFO), chief technology officer (CTO), chief information officer (CIO), chief risk …
The formal assignment of responsibility by the software vendor’s senior leadership team ensures strategic-level visibility into and influence over the vendor’s software security practices. Senior leadership typically represents those individuals or teams with the responsibility and authority to make strategic business decisions for the software vendor organization. In many cases, senior leadership teams are comprised of members of the executive team such as the chief executive officer (CEO), chief financial officer (CFO), chief technology officer (CTO), chief information officer (CIO), …
Modified
p. 11
Assignment of overall responsibility for the vendor’s software security program should include the authority to enforce and execute the organization’s software security strategy. Without appropriate authority, those responsible for the security of the vendor’s products and services cannot be reasonably held accountable for ensuring the organization’s security strategy is followed. Those responsible for the vendor’s software security should provide periodic updates on the state of the vendor’s software security program and the performance of its strategy to senior leadership. This …
Assignment of overall responsibility for the vendor’s software security program should include the authority to enforce and execute the organization’s software security strategy. Without appropriate authority, those responsible for the security of the software vendor’s products and services cannot be reasonably held accountable for ensuring the organization’s security strategy is followed. Those responsible for the vendor’s software security should provide periodic updates on the state of the vendor’s software security program and the performance of its strategy to senior leadership. …
Modified
p. 12
• Software security responsibilities are clearly defined and assigned to appropriate individuals or teams, including software- development personnel.
• Software security responsibilities are clearly defined and assigned to appropriate individuals or teams, including software development personnel.
Modified
p. 12
• Assignment of responsibilities for ensuring the security of the vendor’s products and services covers the entire software lifecycle.
• Assignment of responsibilities for ensuring the security of the software vendor’s products and services covers the entire software lifecycle.
Modified
p. 12
Individuals (including third-party personnel) involved in the design, development, testing and maintenance of the vendor’s products and services should be assigned responsibility and accountability for ensuring that its software is designed and maintained in accordance with its security strategy and all applicable security requirements, including software-specific requirements. Responsibilities can be assigned to an individual, group, or role; however, individuals assigned to a particular group or role should clearly understand how those software security responsibilities affect their individual job functions, the …
Individuals (including third-party personnel) involved in the design, development, testing and maintenance of the software vendor’s products and services should be assigned responsibility and accountability for ensuring that software is designed and maintained in accordance with the software vendor’s security strategy and all applicable security requirements, including software-specific requirements. Responsibilities can be assigned to an individual, group, or role; however, individuals assigned to a particular group or role should clearly understand how those software security responsibilities affect their individual job …
Modified
p. 12
1.2.b The assessor shall interview a sample of responsible individuals, including software- development personnel, to confirm they are clearly aware of and understand their software security responsibilities.
1.2.b The assessor shall interview a sample of responsible individuals, including software development personnel, to confirm they are clearly aware of and understand their software security responsibilities.
Modified
p. 13
• A mature process is implemented and maintained for managing and maintaining software security skills for software- development personnel.
• A mature process is implemented and maintained for managing and maintaining software security skills for software development personnel.
Modified
p. 13
• The process includes a review at least annually to ensure software-development personnel are maintaining the necessary skills for the security responsibilities they have been assigned.
• The process includes a review at least annually to ensure software development personnel are maintaining the necessary skills for the security responsibilities they have been assigned.
Modified
p. 13
To be effective in meeting their software security responsibilities, software-development personnel should be trained or have experience in performing such responsibilities and maintain the appropriate skills to properly carry out those responsibilities.
To be effective in meeting their software security responsibilities, software development personnel must be trained or have experience in performing such responsibilities and must maintain the appropriate skills to properly carry out those responsibilities.
Modified
p. 13
At a minimum, all software-development personnel should have a basic understanding of general software security concepts and best practices. Individuals with specialized roles and responsibilities should additionally possess specialized skills relevant to the functions they perform. Examples of specialized skills include secure software design (software architects), secure coding techniques (software developers), and security-testing techniques (software testers).
At a minimum, all software development personnel must have a basic understanding of general software security concepts and best practices. Individuals with specialized roles and responsibilities should additionally possess specialized skills relevant to the functions they perform. Examples of specialized skills include secure software design (software architects), secure coding techniques (software developers), and security-testing techniques (software testers).
Modified
p. 13
Efforts to maintain those skills may include vendor-provided training, ongoing participation in local or regional user groups, or the achievement and maintenance of industry-specific certifications. It is up to the vendor to define the necessary criteria for maintaining appropriate job-specific skills and confirm individual adherence at least annually.
Efforts to maintain those skills may include software vendor- provided training, ongoing participation in local or regional user groups, or the achievement and maintenance of industry-specific certifications. It is up to the software vendor to define the necessary criteria for maintaining appropriate job-specific skills and confirm individual adherence at least annually.
Modified
p. 13
Evidence to support this control objective might include policies and processes, training materials or content, records of on-the-job training or course attendance, individual qualification certificates, continuing education credits, or any other documentation or evidence that clearly and consistently demonstrates that software- development personnel possess and maintain appropriate skills and knowledge for their specific job function and responsibilities.
Evidence to support this control objective might include policies and processes, training materials or content, records of on-the-job training or course attendance, individual qualification certificates, continuing education credits, or any other documentation or evidence that clearly and consistently demonstrates that software development personnel possess and maintain appropriate skills and knowledge for their specific job function and responsibilities.
Modified
p. 13
1.3.b For a sample of software-development personnel, examine vendor evidence and interview personnel to confirm the following:
1.3.b For a sample of software development personnel, examine vendor evidence and interview personnel to confirm the following:
Modified
p. 14
Software vendors should maintain awareness of evolving industry and regulatory requirements applicable to their operations and products. Maintaining ongoing awareness of external security and compliance obligations allows the software vendor to ensure its processes adequately address those requirements at all times, including whenever those requirements are updated or new requirements are introduced.
Modified
p. 14
Evidence to support this control objective might include documented policies and processes, internal standards, requirement mappings, internal presentations, training materials, or any other documentation or records that clearly and consistently illustrate that the vendor has made reasonable efforts to understand and monitor its external security and compliance requirements.
Evidence to support this control objective might include documented policies and processes, internal standards, requirement mappings, internal presentations, training materials, or any other documentation or records that clearly and consistently illustrate that the software vendor has made reasonable efforts to understand and monitor its external security and compliance requirements.
Modified
p. 14
• A software security policy exists and is communicated to appropriate vendor personnel and business partners, including all software-development personnel.
• A software security policy exists and is communicated to appropriate software vendor personnel and business partners, including all software development personnel.
Modified
p. 14
• At a minimum, the policy covers all security and control objectives within this standard (either explicitly or implicitly).
• At a minimum, the policy covers all control objectives within this standard (either explicitly or implicitly).
Modified
p. 14
• The vendor’s senior leadership team has approved the software security policy.
• The software vendor’s senior leadership team has approved the software security policy.
Modified
p. 14
Software vendors must establish a company-wide software security policy to ensure that all individuals or teams⎯including relevant business partners⎯involved in software design, development, and maintenance are aware and have a consistent understanding of how the vendor’s software products and services should be securely built and maintained, and how any critical assets should be handled. The software security policy (or policies) should be known and thoroughly understood by those with the responsibility to ensure they are met, as well as those …
Modified
p. 15
• A strategy for ensuring the security of the vendor’s products and services is defined.
• A strategy for ensuring the security of the software vendor’s products and services is defined.
Modified
p. 15
• The security strategy is based on or aligned with industry-accepted methodologies.
• The software security strategy is based on or aligned with industry-accepted methodologies.
Modified
p. 15
• The software security strategy covers the entire lifecycle of the vendor’s software products and services.
• The software security strategy covers the entire lifecycle of the software vendor’s products and services.
Modified
p. 15
• The security strategy is communicated to appropriate personnel, including software- development personnel.
• The software security strategy is communicated to appropriate personnel, including software development personnel.
Modified
p. 15
• The security strategy is reviewed at least annually and updated as needed (such as when business needs, external drivers, and products and services evolve).
• The software security strategy is reviewed at least annually and updated as needed (such as when business needs, external drivers, and products and services evolve).
Modified
p. 15
A software security strategy is a high-level plan, roadmap, or methodology for ensuring the secure design, development, and maintenance of the vendor’s products and services, and adherence to the vendor’s software security policy.
A software security strategy is a high-level plan, roadmap, or methodology for ensuring the secure design, development, and maintenance of the software vendor’s products and services, and adherence to the software vendor’s software security policy.
Modified
p. 15
Software vendors should either adopt existing or develop their own frameworks or methodologies in accordance with industry-accepted practices for secure software lifecycle management. By aligning its software security strategy with industry-accepted methodologies, the software vendor is less likely to overlook important aspects of secure software lifecycle management.
Modified
p. 15
Software vendors that develop their own methodologies should understand how they differ from industry-accepted methodologies, identify any gaps, and ensure that sufficient evidence is maintained to clearly illustrate how their methodologies are at least as effective as those accepted by the industry. Examples of industry-accepted methodologies that are commonly used as benchmarks for secure software development and management include, but are not limited to, current versions of:
Modified
p. 15
• Building Security In Maturity Model (BSIMM))
• Building Security In Maturity Model (BSIMM)
Modified
p. 15
• NIST Special Publication 800-160 and its Appendixes (continued on next page)
• NIST Special Publication 800-160 and its Appendixes
Modified
p. 16
• such as the vendor’s business strategy or product/service offerings
•or external factors
•such as external security and compliance requirements
•evolve. Therefore, the software security strategy is not static and should be periodically reviewed and updated to maintain alignment with business needs and priorities.
•or external factors
•such as external security and compliance requirements
•evolve. Therefore, the software security strategy is not static and should be periodically reviewed and updated to maintain alignment with business needs and priorities.
• such as the software vendor’s business strategy or product/service offerings
•or external factors
•such as external security and compliance requirements
•evolve. Therefore, the software security strategy is not static and should be periodically reviewed and updated to maintain alignment with business needs and priorities.
•or external factors
•such as external security and compliance requirements
•evolve. Therefore, the software security strategy is not static and should be periodically reviewed and updated to maintain alignment with business needs and priorities.
Modified
p. 16
Software security assurance processes are activities that are implemented to carry out the vendor’s software security strategy and to facilitate secure software design, development, and maintenance. To ensure that security and compliance requirements are met, software security policy is satisfied, and the vendor’s products and services are secure and resistant to attack, vendors need to define such processes throughout all phases of the software lifecycle. These may include security “checkpoints,” which are distinct points within the software-development process where software …
Software security assurance processes are activities that are implemented to carry out the software vendor’s software security strategy and to facilitate secure software design, development, and maintenance. To ensure that security and compliance requirements are met, software security policy is satisfied, and the software vendor’s products and services are secure and resistant to attack, software vendors need to define such processes throughout all phases of the software lifecycle. These may include security “checkpoints,” which are distinct points within the software …
Modified
p. 17
• Software security assurance processes clearly address specific rules and goals within the vendor’s software security policy.
• Software security assurance processes clearly address the specific rules and goals within the software vendor’s software security policy.
Modified
p. 17
• Software security assurance processes are aligned with the vendor’s software security strategy.
• Software security assurance processes are aligned with the software vendor’s software security strategy.
Modified
p. 17
• Vendor personnel, including software- development personnel, are assigned responsibility and accountability for the execution and performance of the security assurance process in accordance with Control Objective 1.2.
• Software vendor personnel, including software development personnel, are assigned responsibility and accountability for the execution and performance of the security assurance process in accordance with Control Objective 1.2.
Modified
p. 17
• The results or outcomes of each security assurance process are monitored in accordance with Control Objective 2.5.
• The results or outcomes of each security assurance process are monitored in accordance with Control Objective 2.6.
Modified
p. 17
2.5.a The assessor shall examine vendor evidence, including the inventory of software security assurance processes, and interview personnel to confirm that evidence is generated and maintained for each security assurance process specified in the inventory described in 2.4.a.
2.5.a The assessor shall examine vendor evidence, including the inventory of software security assurance processes described in Test Requirement 2.4.a, and interview personnel to confirm that evidence is generated and maintained for each security assurance process.
Removed
p. 18
2.6.b For a sample of security assurance processes (as defined in Control Objective 2.4), the assessor shall interview personnel and examine evidence, including that generated by the security process (as described in Control Objective 2.5), to identify any failures or weaknesses in those security processes and to confirm that weak or ineffective processes were updated, augmented or replaced.
Modified
p. 18
Software vendors should monitor their security assurance processes to confirm that they remain appropriate (i.e., fit for purpose) and effective for their intended purpose and function. For example, the use of manual code reviews may be sufficient to detect all coding errors and vulnerabilities for software with a very limited code base. However, as the code base grows, the use of manual code reviews for the same purpose becomes increasingly impractical or insufficient, and automated testing tools (such as automated …
Modified
p. 18
Evidence to support this requirement might include process- generated evidence, security test results, root-cause analysis, documented remediation actions, or any other evidence that clearly and consistently illustrates that the effectiveness of software security assurance processes is monitored, failures and weaknesses are detected, and security assurance processes are updated, augmented or replaced when no longer effective or satisfying their intended purpose.
Evidence to support this requirement might include process- generated evidence, security test results, root-cause analysis, documented remediation actions, or any other evidence that clearly and consistently illustrates that the effectiveness of software security assurance processes is monitored, failures and weaknesses are detected, and security assurance processes are updated, augmented or replaced when no longer effective at satisfying their intended purpose.
Modified
p. 19
Control Objectives Test Requirements Guidance Control Objective 3: Threat Identification and Mitigation The vendor continuously identifies, assesses, and manages risk to its payment software and services.
Control Objectives Test Requirements Guidance Control Objective 3: Threat Identification and Mitigation The software vendor continuously identifies, assesses, and manages risk to its software and services.
Modified
p. 19
Before the vendor can determine how to effectively secure and defend software against attacks, it first requires a thorough understanding of the specific assets applicable to the software that could be targeted by attackers.
Before the software vendor can determine how to effectively secure and defend its software against attacks, it must first develop a thorough understanding of the software’s critical assets that could be targeted by attackers.
Modified
p. 19
Critical assets include any sensitive data collected, stored, processed, or transmitted by the software, as well as any sensitive functions and sensitive resources within or used by the software. Examples of analysis techniques that could be used to identify critical assets include, but are not limited to, Mission Impact Analysis (MIA), Functional Dependency Network Analysis (FDNA), and Mission Threat Analysis.
Critical assets include any sensitive data collected, stored, processed, or transmitted by the vendor’s software, as well as any sensitive functions and sensitive resources within or used by the software. Examples of analysis techniques that could be used to identify critical assets include, but are not limited to, Mission Impact Analysis (MIA), Functional Dependency Network Analysis (FDNA), and Mission Threat Analysis.
Modified
p. 20
• The assessment accounts for all software inputs/outputs, process/data flows, trust boundaries and decision points, and how they may be exploited by an attack.
• The assessment accounts for all software inputs/outputs, process/data flows, trust boundaries and decision points, and how they may be exploited by an attacker.
Modified
p. 20
• The motivations an attacker may have for attacking a particular software application;
• The motivations an attacker may have for attacking software;
Modified
p. 20
• The weaknesses in the design of the software that an attacker might attempt to exploit;
• Weaknesses in the software design that an attacker might attempt to exploit;
Modified
p. 20
This information helps the vendor to identify the threats and design flaws that present the most significant and immediate risk, and to prioritize remediation activities necessary to address them.
This information helps the software vendor to identify the threats and design flaws that present the most significant and immediate risk, and to prioritize remediation activities necessary to address them.
Removed
p. 21
• including up-to-date security patches
•is available (whether provided by an internal or external entity) for the open-source component. The use of open-source components should be supported by a clear policy about how those components are evaluated and implemented. A reliable support system should be in place to identify errors or problems and evaluate and address them in a timely manner.
•is available (whether provided by an internal or external entity) for the open-source component. The use of open-source components should be supported by a clear policy about how those components are evaluated and implemented. A reliable support system should be in place to identify errors or problems and evaluate and address them in a timely manner.
Modified
p. 21
• An inventory of open-source components used in the software is maintained.
• An inventory of open-source components used in the vendor’s software is maintained.
Modified
p. 21
• The vendor monitors vulnerabilities in open- source components throughout their use or inclusion in the vendor’s software to determine when new vulnerabilities are identified.
• The software vendor monitors vulnerabilities in open-source components throughout their use or inclusion in the vendor’s software.
Modified
p. 21
• An appropriate patching strategy for the open- source components is defined.
• An appropriate patching strategy for open- source components is defined.
Modified
p. 21
Where open-source software components are used, the vendor should consider any risks associated with the use of the open- source components and the extent to which the open-source software provider manages the security of those components. Additionally, the vendor will need to confirm that support
Where open-source software components are used, the software vendor should consider any risks associated with the use of the open-source components and the extent to which the open-source software provider manages the security of those components. Additionally, the software vendor will need to confirm that support •including up-to-date security patches
•is available (whether provided by an internal or external entity) for the open-source component. The use of open-source components should be supported by a clear policy about how those components are …
•is available (whether provided by an internal or external entity) for the open-source component. The use of open-source components should be supported by a clear policy about how those components are …
Modified
p. 21
Where vulnerabilities are identified in open-source components that are applicable to software, vendors should have processes in place to analyze those vulnerabilities and update the components to appropriate, non-vulnerable versions in a timely manner. When patches for open-source components are no longer available, those components should be replaced by actively supported ones. Vendors should identify and establish sources and processes for managing vulnerabilities in open- source components that are appropriate for the particular design methods and release frequency for their …
Where vulnerabilities are identified in open-source components that are applicable to their software, software vendors should have processes in place to analyze those vulnerabilities and update the components to appropriate, non-vulnerable versions in a timely manner. When patches for open-source components are no longer available, those components should be replaced by actively supported ones. Vendors should identify and establish sources and processes for managing vulnerabilities in open-source components that are appropriate for their software design and release frequency.
Modified
p. 21
3.2.c For a sample of vendor payment software, the assessor shall examine assessment results for the selected software to confirm the following:
3.2.c For a sample of vendor software, the assessor shall examine assessment results for the selected software to confirm the following:
Removed
p. 22
Evidence to support this control objective may include software- specific requirements documentation, feature lists, software- specific security control inventories, change-management documentation, risk assessment reports, software-specific test results, or any other evidence or information that clearly and consistently illustrates that security controls are implemented and maintained in software to address the software-specific risks identified in Control Objective 3.2.
Modified
p. 22
To ensure software applications are resistant to attacks, software-specific controls or countermeasures must be implemented in the software to mitigate specific threats and design weaknesses. Examples of such controls include the use of multi-factor authentication mechanisms to prevent unauthorized individuals gaining access to critical assets, and logging mechanisms to detect if and when authentication mechanisms might have been circumvented. Other examples include the use of input validation routines or parameterized queries to protect software from SQL-injection attacks. Except where specific …
To ensure that its software is resistant to attacks, software vendors must implement software-specific controls or countermeasures in their software to mitigate the specific threats and design weaknesses. Examples of such controls include the use of multi-factor authentication mechanisms to prevent unauthorized individuals gaining access to critical assets, and logging mechanisms to detect if and when authentication mechanisms might have been circumvented. Other examples include the use of input validation routines or parameterized queries to protect software from SQL-injection attacks. …
Modified
p. 22
3.3.c The assessor shall examine vendor evidence, including software-specific assessment results, security requirements, and the implemented software security controls to confirm that security controls have been implemented to mitigate all identified threats and design flaws.
3.3.c The assessor shall examine vendor evidence to confirm that security controls have been implemented to mitigate all identified threats and design flaws.
Modified
p. 23
• A mature process exists to identify weak or ineffective security controls and to update, augment, or replace them.
• A mature process exists to identify weak or ineffective software security controls and to update, augment, or replace them.
Modified
p. 23
• Weak or ineffective security controls are updated, augmented, or replaced in a timely manner upon detection and in accordance with Control Objective 3.3.
• Weak or ineffective security controls are updated, augmented, or replaced in a timely manner upon detection.
Modified
p. 23
Vendors should monitor and/or routinely test their software to confirm that implemented software security controls remain appropriate (i.e., fit for purpose) and effective for sufficiently mitigating evolving risks or design flaws. For example, a software-specific security requirement may call for cryptography to be used to protect software communications. While the use of SSL may have been sufficient upon the initial design and release of the software application, SSL is no longer sufficient to adequately protect communications as new threats and …
Vendors should monitor and/or routinely test their software to confirm that implemented software security controls remain appropriate (i.e., fit for purpose) and effective for sufficiently mitigating evolving risks or design flaws. For example, a software-specific security requirement may call for cryptography to be used to protect software communications. While the use of SSL may have been sufficient upon the initial design and release of the software, SSL is no longer sufficient to adequately protect communications as new threats and attack …
Modified
p. 23
• Security controls that have been deemed “weak” or “ineffective” have been updated, augmented or replaced
• Security controls that have been deemed “weak” or “ineffective” have been updated, augmented or replaced.
Removed
p. 24
Security testing should be performed by appropriately skilled vendor personnel or third parties (in accordance with Control Objective 1.3). In addition, security testing personnel should be able to conduct tests in an objective manner and be authorized to escalate any identified vulnerabilities to appropriate management or development personnel so they can be properly addressed.
Modified
p. 24
• Tools or methods used for security testing are appropriate for detecting applicable vulnerabilities and are suitable for the software architecture, development languages, and frameworks used in the development of the software.
• Tools or methods used for security testing are appropriate for detecting applicable vulnerabilities in the vendor’s software, and are suitable for the software architectures, and the software development languages and frameworks employed.
Modified
p. 24
• Security testing is performed by authorized and objective vendor personnel or third parties in accordance with Control Objective 1.3.
• Security testing is performed by authorized and objective vendor personnel or third parties.
Modified
p. 24
• Security-testing details, including the tools used, their configurations, and the specific tests performed, are recorded and retained.
• Security-testing details including the tools used, their configurations, and the specific tests performed are recorded and retained.
Modified
p. 24
Routine security testing should be performed prior to or as part of the code-commit process to detect coding errors or the use of insecure functions. It could also be performed during unit, integration, regression, or interoperability testing, or during separate security testing. Security testing should be performed consistently and throughout all stages of the software lifecycle, including during various pre-release phases of the software- development process and after code release, to ensure the software is free from vulnerabilities upon launch …
Routine security testing should be performed prior to or as part of the code-commit process to detect coding errors or the use of insecure functions. It could also be performed during unit, integration, regression, or interoperability testing, or during separate security testing. Security testing should be performed consistently and throughout all stages of the software lifecycle, including during various pre-release phases of the software development process and after code release, to ensure the software is free from vulnerabilities upon launch …
Modified
p. 26
In some cases, it may be impractical for a vendor to fix all identified vulnerabilities prior to the release of production code or updates. In such circumstances, the vendor should have a methodology with clear criteria defined for prioritizing vulnerability fixes. The default outcome should always be that vulnerabilities are fixed before the software is released. In cases where it is reasonably not possible to fix a vulnerability prior to release, an exception process involving management at a level commensurate …
In some cases, it may be impractical for a vendor to fix all identified vulnerabilities prior to the release of production code or updates. In such circumstances, the vendor should have a methodology with clear criteria defined for prioritizing vulnerability fixes. The default outcome should always be that vulnerabilities are fixed before the software is released. In cases where it is not possible to fix a vulnerability prior to release, an exception process involving management at a level commensurate with …
Modified
p. 26
Under no circumstances should a previously resolved vulnerability be reintroduced into production code, nor should similar vulnerabilities within the same class of vulnerabilities. Additional assurance processes and safeguards should be implemented to ensure that such incidents are avoided. The specific processes to prevent such occurrences will largely depend on how the vendor’s software is structured and how the vendor manages updates to the software’s code. It is up to the vendor to determine the most appropriate methods to prevent the …
Under no circumstances should a previously resolved vulnerability be reintroduced into production code, nor should similar vulnerabilities within the same class of vulnerabilities be reintroduced. Additional assurance processes and safeguards should be implemented to ensure that such incidents are avoided. The specific processes to prevent such occurrences will largely depend on how the vendor’s software is structured and how the vendor manages software updates. It is up to the software vendor to determine the most appropriate methods to prevent the …
Modified
p. 26
4.2.b For a sample of vendor software, the assessor shall examine software-specific security-testing results and details of application update to confirm that security fixes are made available and deployed (where applicable) in accordance with defined criteria.
4.2.b For a sample of vendor software, the assessor shall examine software-specific security-testing results and the details of software updates to confirm that security fixes are made available and deployed (where applicable) in accordance with defined criteria.
Modified
p. 26
4.2.c For the sample of vendor software, the assessor shall interview personnel to confirm that decisions not to provide security fixes in accordance with defined criteria are justified by appropriate personnel.
4.2.c For a sample of vendor software, the assessor shall interview personnel to confirm that decisions not to provide security fixes in accordance with defined criteria are justified by appropriate personnel.
Modified
p. 27
Control Objectives Test Requirements Guidance Control Objective 5: Change Management Identify and manage payment software changes throughout the software lifecycle.
Control Objectives Test Requirements Guidance Control Objective 5: Change Management The software vendor identifies and manages all software changes throughout the software lifecycle.
Modified
p. 27
• The process results in an inventory of all changes made to the software, including a record of the determined security impact.
• The process results in an inventory of all changes made to software, including a record of the determined security impact.
Modified
p. 27
It is imperative to understand the security risk of a change to the software to ensure that it is addressed accordingly. It often involves understanding the types of functionality the change impacts (e.g., functionality that deals with encryption or authentication processes), the type of information assets that the functionality can access or manipulate, the likelihood of successful exploitation of a vulnerability, and the impact a successful attack may have on stakeholders.
It is imperative to understand the security risk of a change to the software to ensure that it is addressed accordingly. It often involves understanding the types of software functionality the change impacts (e.g., functionality that deals with encryption or authentication processes), the type of information assets that the functionality can access or manipulate, the likelihood of successful vulnerability exploitation, and the impact a successful attack may have on stakeholders.
Modified
p. 27
5.1.b For a sample of changes, the assessor shall examine software- and change-specific documentation or evidence to confirm the following:
5.1.b For a sample of changes, the assessor shall examine software-specific and change-specific documentation or evidence to confirm the following:
Modified
p. 28
• A formal system or methodology for uniquely identifying each version of the software is defined.
• A formal system or methodology for uniquely identifying each version of software is defined.
Modified
p. 28
• All changes to software functionality are clearly associated with a unique version of the software.
• All changes to software functionality are clearly associated with a unique software version.
Modified
p. 28
• All changes to software functionality are clearly associated with a unique version of the software.
• All changes to software functionality are clearly associated with a unique software version.
Modified
p. 28
Without a thoroughly defined versioning methodology, changes to software may not be properly identified, and customers and integrators/resellers may not understand the impact of a version change to the software.
Without a thoroughly defined versioning methodology, changes to software may not be properly identified, and customers and integrators/resellers may not understand the impact of such changes.
Modified
p. 28
The system or methodology adopted by the vendor should allow different release versions of a software product to be easily distinguishable. To ensure a software’s version accurately represents the release version, the versioning system or methodology should be integrated with applicable lifecycle functions, such as code control and change management.
The system or methodology adopted by the vendor should allow different release versions of a software product to be easily distinguishable. To ensure a software version accurately represents the release version, the versioning system or methodology should be integrated with applicable lifecycle functions, such as code control and change management.
Modified
p. 28
The versioning system or methodology should encompass all changes to all software components. As several iterations of a software component may be produced for a single software release, the versioning system or methodology should easily identify the version of each component associated with a software release version.
The versioning system or methodology should encompass all changes to all relevant software components. As several iterations of a software component may be produced for a single software release, the versioning system or methodology should easily identify the version of each component associated with a specific software release version.
Modified
p. 28
5.2.b For a sample of software updates, the assessor shall examine vendor evidence including change- specific documentation to confirm the following:
5.2.b For a sample of software updates, the assessor shall examine vendor evidence, including change- specific documentation, to confirm the following:
Modified
p. 29
• Processes, mechanisms, and/or the use of tools results in the secure delivery of update code.
• Processes, mechanisms, and/or the use of tools results in the secure delivery of updated code.
Modified
p. 29
Security updates should include a mechanism within the update process to verify the update code has not been replaced or tampered with. Examples of integrity checks include checksums and properly implemented digitally signed certificates.
Security updates should include a mechanism within the update process to verify the updated code has not been replaced or tampered with. Examples of integrity checks include checksums and properly implemented digitally signed certificates.
Modified
p. 29
To ensure the implemented controls are adequate to address the evolving attack vectors, the vendor should perform a periodic review to confirm their efficiency.
To ensure the implemented controls are adequate to address the evolving attack vectors, software vendors should perform periodic reviews to confirm their continued effectiveness.
Removed
p. 30
To protect the confidentiality of any sensitive production data
•that is, sensitive data that is owned by the vendor’s customers
•it should never be collected or used for purposes other than those for which the data was originally collected. If the vendor provides services to its customers that could result in the collection of sensitive data⎯for example, for troubleshooting or debugging purposes⎯the vendor should record which specific data elements it collects and retains, and clearly communicate what data elements are collected and why they are collected to its customers and other stakeholders.
• for each data element during storage and transmission.
•that is, sensitive data that is owned by the vendor’s customers
•it should never be collected or used for purposes other than those for which the data was originally collected. If the vendor provides services to its customers that could result in the collection of sensitive data⎯for example, for troubleshooting or debugging purposes⎯the vendor should record which specific data elements it collects and retains, and clearly communicate what data elements are collected and why they are collected to its customers and other stakeholders.
• for each data element during storage and transmission.
Modified
p. 30
• An inventory of sensitive production data captured or stored by the vendor’s products and services is maintained.
• An inventory of sensitive production data captured or stored by the software vendor’s products and services is maintained.
Modified
p. 30
• Vendor decisions to use sensitive production data are approved by appropriate personnel.
• Decisions to use sensitive production data are approved by appropriate software vendor personnel.
Modified
p. 30
• Vendor decisions to use sensitive production data are recorded and reasonably justified.
• Decisions to use sensitive production data are recorded and reasonably justified.
Modified
p. 30
The inventory of sensitive production data should include identification of the specific data elements captured, whether storage of each element is permitted, and the security controls required
•for example, to protect confidentiality and/or integrity
•for example, to protect confidentiality and/or integrity
The inventory of sensitive production data retained by the software vendor should include identification of the specific data elements captured, whether storage of each element is permitted, and the security controls required
•for example, to protect confidentiality and/or integrity •for each data element during storage and transmission.
•for example, to protect confidentiality and/or integrity •for each data element during storage and transmission.
Modified
p. 31
7.2.a The assessor shall examine vendor evidence and interview personnel to confirm that a mature process exists to ensure sensitive production data is protected when retained on vendor systems and is securely deleted when no longer needed.
7.2.a The assessor shall examine vendor evidence and interview personnel to confirm that a mature process exists to ensure sensitive production data is protected when retained on software vendor systems and is securely deleted when no longer needed.
Modified
p. 31
When software vendors collect production data from their customers
•for example, for debugging or other customer support purposes
•the vendor should coordinate with itscustomers to identify which elements of the production data require protection. Vendor customers may have their own definition and associated security requirements for “sensitive production data,” and appropriate protection efforts should be agreed upon by both parties.
•for example, for debugging or other customer support purposes
•the vendor should coordinate with its
When software vendors collect sensitive production data from their stakeholders
•for example, for debugging or other customer support purposes
•the vendor should coordinate with its stakeholders to identify which data elements require protection. Vendor stakeholders may have their own definition and associated security requirements for sensitive data, and appropriate protection efforts should be agreed upon by both parties.
•for example, for debugging or other customer support purposes
•the vendor should coordinate with its stakeholders to identify which data elements require protection. Vendor stakeholders may have their own definition and associated security requirements for sensitive data, and appropriate protection efforts should be agreed upon by both parties.
Modified
p. 31
Where the vendor collects or retains sensitive production data, the vendor should ensure it is secured•for example, by using robust access control measures and/or strong cryptography with industry-accepted key-management processes. As soon as it is no longer needed for its collected purpose, the data should be securely deleted such that it is not possible to reconstruct or recover the data from any vendor system.
Where the software vendor collects or retains sensitive production data, the software vendor should ensure it is secured•for example, by using robust access control measures and/or strong cryptography with industry- accepted key-management processes. As soon as it is no longer needed for its collected purpose, sensitive production data should be securely deleted such that it is not possible to reconstruct or recover the data from any software vendor system.
Modified
p. 31
• Sensitive production data is not resident on vendor systems unless appropriate evidence of approval and justification exists.
• Sensitive production data is not resident on software vendor systems unless appropriate evidence of approval and justification exists.
Modified
p. 32
Control Objectives Test Requirements Guidance Control Objective 8: Vendor Security Guidance The vendor provides stakeholders with clear and thorough guidance on the secure implementation, configuration, and operation of its payment software applications.
Control Objectives Test Requirements Guidance Control Objective 8: Software Vendor Implementation Guidance The vendor provides stakeholders with clear and thorough guidance on the secure implementation, configuration, and operation of its software.
Modified
p. 32
8.1.a The assessor shall examine vendor evidence, including the security guidance provided to stakeholders, and interview personnel to confirm the following:
8.1.a The assessor shall examine vendor evidence and interview personnel to confirm the following:
Modified
p. 32
• A mature process exists to produce, maintain, and make available security guidance and instructions for stakeholders.
• A mature process exists to produce, maintain, and make available to stakeholders guidance on the secure implementation, configuration, and operation of its software.
Modified
p. 32
• The security guidance includes documentation of all configurable security-related options and parameters for the vendor’s software, and instructions for properly configuring and securing those options and parameters.
• The implementation guidance includes documentation of all configurable security-related options and parameters for the vendor’s software, and instructions for properly configuring and securing each of those options and parameters.
Modified
p. 32
When followed, the vendor's security guidance provides assurance that the software and patches are securely installed, configured, and maintained in the customer environment, and that all desired security functionality is active and working as intended. The guidance should cover all options and functionality available to software users that could affect the security of the software or the data it interacts with. The guidance should also include secure configuration options for any components provided with or supported by the software, such …
When followed, the software vendor's implementation guidance provides assurance that the software and patches are securely installed, configured, and maintained in the customer environment, and that all desired security functionality is active and working as intended. The guidance should cover all options and functionality available to software users that could affect the security of the software or the data it interacts with. The guidance should also include secure configuration options for any components provided with or supported by the software, …
Modified
p. 32
Following the security guidance should result in a secure configuration across all configurable options.
Following the secure implementation guidance should result in a secure configuration across all configurable options.
Modified
p. 32
(continued on next page) 8.1.b For a sample of vendor software, examine software-specific documentation and materials to confirm that the vendor provides and maintains security configuration guidance for each security-related option or parameter available.
(continued on next page) 8.1.b For a sample of vendor software, examine software-specific documentation and materials to confirm that the software vendor provides and maintains guidance on the secure configuration of each security-related option or parameter available in the vendor’s software.
Modified
p. 33
• The security guidance includes instructions on how to securely install or initialize, configure, and maintain the software.
• The secure implementation guidance includes instructions on how to securely install or initialize, configure, and maintain the software.
Modified
p. 33
• The security guidance is sufficiently detailed.
• The secure implementation guidance is sufficiently detailed.
Modified
p. 33
• Evidence exists or is obtained to illustrate that following the security guidance results in a secure software configuration.
• Evidence exists or is obtained to illustrate that following the secure implementation guidance results in a secure software configuration.
Modified
p. 33
As the vendor is expected to continuously identify, assess, and manage risks to its software, the vendor’s software-change processes should include determining the impact of the change to the security guidance. Software changes that impact a configurable feature or option should result in an update to the security guidance.
As the software vendor is expected to continuously identify, assess, and manage risks to its software, the vendor’s software-change processes should include determining the impact of the change to software vendor guidance. Software changes that impact a configurable feature or option should result in an update to the secure implementation guidance.
Modified
p. 33
• The process to produce and maintain security guidance includes generation of updated guidance when new software updates are released, or security-related options or parameters are introduced or modified.
• The process to produce and maintain secure implementation guidance includes generation of updated guidance when new software updates are released, or security-related options or parameters are introduced or modified.
Modified
p. 33
• Security guidance is reviewed at least annually for accuracy even if updates to security-related options and parameters are not issued.
• Secure implementation guidance is reviewed at least annually for accuracy even if updates to security-related options and parameters are not issued.
Modified
p. 33
8.3.b For a sample of software updates, examine security guidance as well as details of the software updates to confirm that as new security-related options and parameters are updated, the security guidance is updated.
8.3.b For a sample of software updates, examine secure implementation guidance as well as details of the software updates to confirm that as security-related options and parameters are updated or added, the secure implementation guidance is updated.
Modified
p. 34
• A mature process exists to support open, bi- directional communications with stakeholders for reporting and receiving security information regarding the vendor’s products and services.
• A mature process exists to support open, bi- directional communications with stakeholders for reporting and receiving security information regarding the software vendor’s products and services.
Modified
p. 34
• The vendor maintains resources to respond to reports or inquiries regarding the security of the vendor’s products and services.
• The software vendor maintains resources to respond to reports or inquiries regarding the security of the vendor’s products and services.
Modified
p. 34
Software vendors should monitor the threat landscape in order to identify new vulnerabilities and security issues that impact their software on the market. Software vendors should also provide open lines of communication to enable researchers or other stakeholders to report newly discovered vulnerabilities in the software vendor’s products and services. Communication channels could include a publicly disclosed e-mail address, website page, or other method to facilitate interactions with external researchers•for example, through a formal bug bounty program. The software vendor …
Modified
p. 34
In addition to supporting the receipt of information about vulnerabilities within its software products, the vendor should also issue communications to customers, installers, and integrators to provide information about known vulnerabilities and when fixes will be available. Fixes/patches should be developed and released in a timely manner, based on criticality and in accordance with Control Objective 4.2.
In addition to supporting the receipt of information about vulnerabilities within its software products, the software vendor should also issue communications to customers, installers, and integrators to provide information about known vulnerabilities and when fixes will be available. Fixes/patches should be developed and released in a timely manner, based on criticality and in accordance with Control Objective 4.2.
Modified
p. 34
Software vendor security notifications should include the criticality and potential impact of the vulnerability, as well as clear guidance for addressing the vulnerability⎯for example, how to install a patch or software update. Where a fix is not readily available, the software vendor should communicate the risk and provide guidance on mitigation options.
Modified
p. 34
Software vendor-initiated communications could include e-mail notifications, website alerts, written notices, social media posts, and any other channels the vendor maintains for stakeholder engagement. Communication channels should be publicized so that stakeholders know how to access them⎯for example, by signing up for e-mail notifications. Software vendor contact information should also be provided for stakeholders to submit further questions regarding security notifications.
Modified
p. 34
9.3.b For a sample of software security updates, examine stakeholder communications, product-specific documentation, security-testing results, and other materials to confirm that where known vulnerabilities are not addressed in the security updates, risk mitigation instructions are provided to stakeholders.
9.3.b For a sample of software security updates, examine stakeholder communications, product-specific documentation, security-testing results, or other materials to confirm that where known vulnerabilities are not addressed in the security updates, risk mitigation instructions are provided to stakeholders.
Modified
p. 35
• Change summary information accurately reflects the changes made to the software (see Control Objective 5.2).
• Change summary information accurately reflects the changes made to the software.