Introduction
This blog entry looks at how to use the PCI PA DSS in your general application security program.
The PCI PA DSS (Payment Card Industry Payment Application Data Security Standard) version 3 has just been released. According to the standard:
"The PA-DSS applies to software vendors and others who develop payment applications that store, process, or transmit cardholder data and/or sensitive authentication data".
It applies to software vendors who develop applications which process payment cards (credit or debit cards). This is separate from the main PCI DSS (Payment Card Industry Data Security Standard) which applies to any organization which stores, processes or transmits payment card information. The PA DSS is targeted at developers.
While this is aimed at applications which are used to process payment card information, it can also be used as a general standard for application security. If you are involved in application security, you should have a look at the PA DSS standard because you may get some useful tips from it.
The standard contains 14 requirements. While some of these are specific to payment cards, most of the requirements can apply to general application security. In the requirement simply replace "payment application" by "application" and cardholder data or PAN by "sensitive data" and the contents can apply to any application. The application is the software application that you are developing and "sensitive data" is any sensitive data that your application may be processing e.g. personal information. The phrase "software vendor" can be replaced by software developer - essentially the team that is developing your application.
What is the best way to use the standard for general application security? When designing your application, go down through each of the requirements in the PA-DSS documents and ask the following types of questions.
While this is aimed at applications which are used to process payment card information, it can also be used as a general standard for application security. If you are involved in application security, you should have a look at the PA DSS standard because you may get some useful tips from it.
The standard contains 14 requirements. While some of these are specific to payment cards, most of the requirements can apply to general application security. In the requirement simply replace "payment application" by "application" and cardholder data or PAN by "sensitive data" and the contents can apply to any application. The application is the software application that you are developing and "sensitive data" is any sensitive data that your application may be processing e.g. personal information. The phrase "software vendor" can be replaced by software developer - essentially the team that is developing your application.
What is the best way to use the standard for general application security? When designing your application, go down through each of the requirements in the PA-DSS documents and ask the following types of questions.
- Does this requirement potentially apply to my application?
- What is the risk of not implementing this requirement in my application?
Alternatively, if you have a secure development program within your organization, go down through the PA-DSS, perform a gap analysis and see if there are tasks which you should incorporate into your security program.
For example, requirement 5 covers the elements of a secure development program. This should really be the first requirement. Are there sections in requirement 5 which you can incorporate into your program? Requirement 4 covers application audit trails. In particular, it includes the types of information that should be stored in the audit log itself. Audit requirements are often not included in general application security requirements. However this is one area which can be expensive to retrofit but relatively cheap to incorporate if it is included from the beginning of the development.
Download and read the PA-DSS standard itself. Each requirement consists of a number of different subsections. There are 3 columns. Column 1 gives the requirement itself. Column 2 describes the testing procedure that that an auditor or tester would follow to see if the requirement has been implemented correctly. Column 3 gives general guidance. In reviewing the standard, you should concentrate on columns 1 and 3.
The following sections give a very brief overview of each of the requirements. However you should download and read the actual standard.
Requirement 1:Do not retain full track data, card verification code or value (CAV2, CID, CVC2, CVV2), or PIN block data
This is fairly specific to payment card applications and is probably irrelevant to your application.Requirement 2: Protect stored cardholder data
Read through the requirement. Where it talks about cardholder data or PANs (Primary Account Number) replace it with "sensitive data" and see do any of the recommendations apply to your application. Does data need to be encrypted or masked in some way when it is being stored.Requirement 3: Provide secure authentication features
Secure authentication features apply to any application where authentication is required. It talks about username requirements and the types of password features that may be used.Requirement 4: Log payment application activity
This requirement covers audit trail considerations. Does your application need an audit trail? In particular, requirement 4.3 covers the data that an application should record. This requirement is often neglected.Requirement 5: Develop secure payment applications
This covers good development practices and should probably be the first requirement. Production type data should not be used in test systems. It talks about secure code reviews, secure training for developers. There should be a "formal process for secure development of applications". Requirement 5.2 covers the OWASP Top 10 type risks.Requirement 6: Protect wireless transmissions
This is fairly specific to payment type applications and probably does not apply to most general applications.Requirement 7: Test payment applications to address vulnerabilities and maintain payment application updates
Test the applications properly and keep them patched.
Requirement 8: Facilitate secure network implementation
Essentially this is saying that the application should not have a negative security impact on the environment in which it is to be deployed. For example it should not require that insecure services such as FTP are needed.Requirement 9: Cardholder data must never be stored on a server connected to the Internet
Your sensitive application data must be stored securely. It should not be on a server connected directly to the internet.Requirement 10: Facilitate secure remote access to payment application
If remote access is required to your web application then it should be implemented securely. Remote access should only be enabled when it is required and should only be allowed from specific ip addresses. Two factor authentication should be implemented. Default usernames and passwords should be changed.Requirement 11: Encrypt sensitive traffic over public networks
Any sensitive data that your application processes should be encrypted as it travels over the public network. In most cases this means using SSL/TLS over the internet. However note, the standard itself mentions a number of other technologies including bluetooth etc.Requirement 12: Encrypt all non-console administrative access
Your application should not use technologies such as telnet for administrative access. SSH, VPN, or SSL/TLS should be implemented.Requirement 13 and Requirement 14
These probably do not apply to general applications.Useful Links
Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot
