What is PCI Compliance?
The Payment Card Industry Data Security Standard (PCI DSS) is a set of comprehensive requirements developed by the major card brands to facilitate the adoption of consistent data security measures. Each year Authorize.Net renew their PCI DSS compliance.
Authorize.Net maintains the core of the PCI DSS which is a group of principles and accompanying requirements, around which the specific elements of the DSS are organized:
1. Build and Maintain a Secure Network
2. Protect Cardholder Data
3. Maintain a Vulnerability Management Program
4. Implement Strong Access Control Measures
5. Regularly Monitor and Test Networks
6. Maintain an Information Security Policy
Software Developers Role for PCI Compliance
Most of PCI DSS requirements that affect software development fall within requirements 3, 4, and 6 of the standard. Requirements 3 and 4 concern the protection of cardholder data, in that any developed application that processes, stores, and transmits cardholder data, must meet PCI DSS functional security requirements. This protection includes elements like access control and encryption of cardholder data. Application functional PCI requirements are expected to be instructed by the organization to developers, as part of the application’s requirement definition. They can therefore be regarded as not a direct development PCI responsibility. Developers are directly responsible for compliance with PCI DSS requirement 6, since this section of PCI DSS concerns application development.
For the PCI DSS requirement 6 – Developer will maintain an Information Security Policy
– Developer responsibility lies as follows:
1. Establish a process to identify security vulnerabilities, by using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as ‘high,’ ‘medium,’ or ‘low’) to newly discovered security vulnerabilities.
2. Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.
3. Develop internal and external software applications (including web-based administrative access to applications) securely, as follows:
• In accordance with PCI DSS (for example, secure authentication and logging)
• Based on industry standards and best practices
• Incorporating information security throughout the software-development life cycle
Which helps ensure that applications are developed in a structured manner, by using development processes that adhere to known secure best practices.
PCI Myth Busting: Which applies to applications developed by external third parties on behalf of the organization.
4. Remove development, test and custom application accounts, user IDs, and passwords before applications become active or are released to customers.
5. Review custom code prior to release to production or customers to identify any potential coding vulnerability (using either manual or automated processes).
Developers should receive secure code training upon hire and at least annually. It is recommended to have developers sign an agreement or ideally pass an exam to demonstrate compliance with requirement 6 are directly based on the current OWASP Top Ten guidance. The OWASP Top Ten is regarded as industry best practice for secure application development. Requirements 6 norms are subject to change outside the PCI DSS three-year update cycle. When OWASP releases an updated top ten, be aware that PCI DSS requirements 6 instantly changes to reflect the latest best practice.
OWASP (Open Web Application Security Project) Top Ten:
OWASP (Open Web Application Security Project) is an organization that provides unbiased and practical, cost-effective information about computer and Internet applications. Project members include a variety of security experts from around the world who share their knowledge of vulnerabilities, threats, attacks and countermeasures.
1. Invalidated input: Information from web requests is not validated before being used by a web application. Attackers can use these flaws to attack backend components through a web application.
2. Broken access control: Restrictions on what authenticated users are allowed to do are not properly enforced. Attackers can exploit these flaws to access other users’ accounts, view sensitive files, or use unauthorized functions.
3. Broken authentication and session management: Account credentials and session tokens are not properly protected. Attackers that can compromise passwords, keys, session cookies, or other tokens can defeat authentication restrictions and assume other users’ identities.
4. Cross site scripting (XSS) flaws: The web application can be used as a mechanism to transport an attack to an end user’s browser. A successful attack can disclose the end user’s session token, attack the local machine, or spoof content to fool the user.
5. Buffer overflows: Web application components in some languages that do not properly validate input can be crashed and, in some cases, used to take control of a process. These components can include CGI, libraries, drivers, and web application server components.
6. Injection flaws: Web applications pass parameters when they access external systems or the local operating system. If an attacker can embed malicious commands in these parameters, the external system may execute those commands on behalf of the web application.
7. Improper handling: Error conditions that occur during normal operation are not handled properly. If an attacker can cause errors to occur that the web application does not handle, they can gain detailed system information, deny service, cause security mechanisms to fail, or crash the server.
8. Insecure storage: Web applications frequently use cryptographic functions to protect information and credentials. These functions and the code to integrate them have proven difficult to code properly, frequently resulting in weak protection.
9. Denial of service (DoS): Attackers can consume Web application resources to a point where other legitimate users can no longer access or use the application. Attackers can also lock users out of their accounts or even cause the entire application to fail.
10. Insecure configuration management: Having a strong server configuration standard is critical to a secure web application. These servers have many configuration options that affect security and are not secure out of the box.
Observation on PCI Compliance in perspective of Authorize.Net
1. Authorize.net absolutely says AIM is recommended and most secure. Check it out here: http://developer.authorize.net/api/aim/
2. That any method can be bad if the developer doesn’t use proper methods.
3. But, even if a developer uses https for the check out form, purchases an SSL, and scans their site daily, that is NOT enough to be PCI compliant (according to the PCI self-assessment questionnaire)
4. And, those are the only things that Authorize.Net seems to be saying are necessary
5. If you read the questionnaire (or do a search for PCI compliant servers), you will see that it takes a lot of work to have a PCI compliant server
6. http://www.rackspace.com can offer a PCI compliance hosting server
7. A properly coded site never records the CC in the site’s database.
8. The CC is passed along from page to page as a form POST parameter over a SSL encrypted connection.
9. It will be in the server’s memory for a time,
10. But not in any place that an attacker could get at without a great deal of difficulty, and if they could do that, you’re toast anyway
Asoke Mukherjee's Blog 