Jeremy Dallman here to introduce our second paper aligning SDL practices with compliance activities. Last year we released the SDL and HIPAA whitepaper. This time, we chose the Payment Card Industry Data Security Standards (PCI DSS) and Payment Application Data Security Standards (PA-DSS) commonly used by merchants, payment card processors, and application developers equipping those industries. These two sets of requirements create industry standards to protect how cardholder data and payment applications store, process or transmit data as part of authorization or settlement. Today, I would like to announce the release of a new whitepaper:
Every day, consumers use electronic payment systems to complete purchases in physical stores and on the internet. These transactions must reference and store personal data. Because this data is being stored, it is crucial that it is handled securely at every point in a transaction. This involves not only the merchants and payment card processors, but the entire IT system used to support the merchants, authorize the purchases, and store the information. The risks to consumers are profound, and have resulted in new regulations – designed to ensure technology is being used correctly to protect personal information. Although the PCI DSS goes to great lengths to protect the physical and network infrastructure surrounding the payment card industry, our increasingly digitized world requires software protections as well. It is no longer enough to only rely on perimeter defenses. The process of creating more secure applications is what the Microsoft SDL is designed to address.
Recent studies have shown that organizations are spending on compliance tasks in lieu of security – however compliance and security don’t have to be at odds. As merchants and software developers are being asked to meet PCI DSS requirements, it is important to find ways to align proactive, risk-based security practices with compliance activities. We saw this need and realized that we should evaluate the application of the Microsoft SDL alongside some of these regulatory activities.
This paper shows how the Microsoft SDL can help meet some of the requirements of PCI DSS and PA-DSS. It addresses two primary scenarios—1) building new PCI DSS compliant software and 2) custom software integration (e.g. a Point of Sale system in a retail store). Each of these scenarios illustrates a common intersection between software security and PCI DSS or PA-DSS requirements. Our goal is to show where software security can both assist in attaining regulatory compliance with PCI DSS and ensure that the software created for these industries are written and deployed with security as a priority to mitigate risk, using the Microsoft SDL as a guide.
Similar to our first paper, the expected audiences for this paper are business decision-makers, compliance managers, software developers, IT consultants, and systems integrators who are working within or on behalf of organizations that must meet PCI DSS requirements. This paper is not intended to advise organizations of their legal requirements and responsibilities. It is assumed that the reader understands the laws and regulations mentioned in this paper and how those laws and regulations apply to their organization.
The paper is broken into easy-to-digest sections that we hope are both readable and practical in application:
· Overviews of the Microsoft SDL and both PCI DSS and PA-DSS
· A scenario-based review of SDL applicability to parts of the PCI DSS and PA-DSS
Appendix (three “rip out” tables for reference)
· One table mapping SDL Practices to the PCI DSS Requirements
· A second table mapping SDL Practices to PA-DSS Requirements
· The Simplified SDL spreadsheet for reference.
We realize that aligning security practices with compliance activities will vary across organizations; we hope this paper will ease the task of integrating secure software development activities with PCI DSS regulatory requirements.
As always, we welcome your questions and feedback.