Objective-Based Approach to Requirements
There are numerous mature, secure software lifecycle management methodologies and frameworks available that, when properly implemented and maintained, can produce secure software1 . In recognition of this, the PCI Software Security Framework has adopted an “objective-based” approach to defining the PCI Secure SLC Requirements. This approach acknowledges that there is no “one size fits all” method to software security, and that software vendors need flexibility to determine the secure software lifecycle management practices and methods most appropriate to address their specific business and software risks.
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 must be able to demonstrate how the implemented controls are supported by the results of its risk-management practices. Without a robust risk-management practice and evidence to support risk-based decision making, adherence to the PCI Secure SLC Requirements may be difficult to validate.
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 its implementation provides ongoing assurance that the activities are effective and meet the intent of all applicable security requirements.
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.
