You can check out the full article to learn more about why mobile payments are still vulnerable, how the PCI Security Standards Council is tackling the issue, and what the next year will bring for this popular consumer trend.

“There is vagueness around the safety of consumers’ credit card numbers when they are transmitted through mobile applications. A website that’s been modified for a mobile platform is presumably safer than an actual mobile application, making the latter considered not compliant according to the PCI DSS Council. If your business is working on a payment app to make transactions easier or more convenient for customers, you must consider this before deploying the app into the iPhone, Android, Blackberry or other marketplace.”

Check out the entire article on SecurityWeek. 

With that, we’re pleased to announce our expansion into a new data center facility in April 2011. The new facility is located in Richardson, Texas and represents FireHost’s third data center footprint in the US. The new facility brings a serious set of top-notch security, connectivity and redundancy features that will not only benefit our new customers, but also our existing customers who will migrate from our current Dallas facility.

Here are some of the major benefits you’ll experience with our data center expansion:

Redundant Connectivity Infrastructure

• Diverse fiber entry and intra-building fiber paths
• Fully redundant internal network distribution
• Multiple 10 Gbps connections from multiple premium carriers

Redundant Power Infrastructure

• Complete 2N Electrical Infrastructure
• Redundant Utility Feeds
• Redundant Transformers in Ring Configuration
• Redundant Power Distribution Units (PDU)
• Redundant 2,000 kw Diesel Generators
• 72+ hours fuel supply onsite with priority re-fueling status

Safe Environmental Infrastructure

• N+1 Centrifugal Chiller Cooling
• VESDA (Very Early Smoke Detection Apparatus) throughout
• FM-200 Fire Suppression System
• Dry-pipe pre-action sprinkler system
• Full electrical monitoring
• Under the floor water detection system
• Control and Monitor 32,000 points in the facility

Secure Premises

• On-site personnel 24/7
• Biometric and card security system
• CCTV video surveillance system with DVR recording
• Man-trap entry and badge-only access
• SAS70 Type II Certified
• PCI Certified
• ISO 900:2001 Certified

These features also lay the foundation for providing our HIPAA compliant, PCI DSS compliant, and high-availability customers an even more robust infrastructure upon which to build their critical disaster recovery plans.

We’re nothing short of thrilled with the new facility, and are looking forward to expanding the security, connectivity and redundancy we provide to every customer.

All existing FireHost customers will be receiving more details over the weeks, days, and hours leading up to the scheduled expansion. As the scheduled expansion nears, you can follow the progress by visiting our public status page or by logging into MyFireHost where you can communicate with our engineers directly.

While most of the contents of Requirement 6 are not technically difficult to achieve, maintaining the balance between an eCommerce organization’s business requirements, brand integrity, usability requirements, and security is challenging. It is the responsibility of the development team to weigh the best interests of the organization against its wish list, all while adhering to the best practices and requirements set forth in the PCI DSS standard to protect the organization and its customers.

Requirement 6 affects almost every aspect of the development process, from the planning stage to post-launch maintenance. Some of the provisions of Requirement 6 are very specific in nature and will vary depending on your deployment and development environment, and thus, this article will cover all of the general compliance guidelines.

System Configuration, Maintenance and Security

As with all of the PCI DSS requirements, it is important to consider all of the required accommodations early on and throughout the planning phase. The scope of Requirement 6 reaches beyond code to the configuration of the development and production environments as well as the administration of both.

This includes simple things, such as the requirement in Provision 6.1 that all systems (both production and development servers, as well as all developer workstations) have the latest security patches installed within 30 days of their release (or 90 days if your company’s policy requires roll-out testing); and that all security patches are tested against the vulnerability they fix prior to deployment in a production environment. Provisions 6.3.2-6.3.3 require that production and development environments be completely separate, and that a policy exists to provide a separation of duties, responsibilities and privileges between users with access to either system.

Additionally, specific system vulnerabilities may be addressed in code or as system configuration adjustments. The solution to each will be different for each configuration. Most PCI-certified vulnerability monitoring solutions will provide additional, detailed guidance for each specific instance discovered.

Considerations During Development

Requirement 6.3 and 6.5 are quite vague, but generally encompasses what are already considered best practices amongst developers. The PCI Security Standards Council recommends the Open Web Application Security Project Guide as a reference for community-accepted best practices in the architecture of your solution.

Requirement 6.3.1.1 and 6.5.1-6.5.10 specifically deal with the most common methods by which malicious attempts to compromise an application are made – namely SQL injection, cross-site scripting (XSS), cross-site request forgeries (CSRFs), and malicious file execution. It is simple enough to completely sanitize an HTTP request header, but often times the intended functionality is to post markup or script to a server (such as in a WYSIWYG editor). Writing custom exceptions for these specific instances without exposing yourself to potential risk is extremely labor intensive if done manually. In this scenario, the use of a web application firewall allows the developer to catch specific attempts, but generally be open and allow the web application firewall to catch suspicious HTTP traffic and create exceptions based on your applications’ functionality.

Once you’re ready to push your application to a production environment, you’ll need to follow requirements 6.3.1.2-6.3.1.5 which describe validation requirements of encrypted data storage and transmission, proper error handling, and role-based access controls (RBACs).

The requirements for data transmission and storage are discussed in depth in PCI DSS Requirement 4, which was covered in an earlier article. Once those encryption methods have been implemented, they must be reviewed and validated. In addition to encryption, Payment Account Number (PAN) data from a production system must never be present in a development environment, and all testing data must also be removed prior to deployment to production.

Error handling is generally simple, but is often overlooked. Disabling error output (PHP/Java/Python) or disabling .NET’s debug mode will prevent the disclosure of potentially sensitive information in your code. This should also include validation that tracing is disabled in compiled applications (Flash/.NET), and as a best practice, it is recommended that you use custom error pages wherever possible.

In addition to validating all of these items within the scope of your application, you must also ensure that all external endpoints (including third-party APIs) meet your application’s own requirements. For the purposes of PCI compliance, any third-party API or provider with which you integrate is included in the scope of your audit. Partnering with a vendor who is already PCI compliant can help reduce the number of questions an auditor may have.

Development Review and Procedural Guidelines

Code reviews are an important part of development for many reasons, but PCI DSS requires them to ensure that all code is properly implemented when separate teams or programmers collaborate on implementation of a security objective, but also as a measure to ensure that no developer has intentionally integrated security flaws or “back doors” into the code base.

It is also required that developers review all newly discovered vulnerabilities and assess their impact, applying security patches or code modification as appropriate. Using a PCI-certified vulnerability monitoring partner to perform scans on your network and applications not only simplifies the process of identifying known vulnerabilities, but it also ensures that you’re scanning for all of the latest known attacks, including 0-day vulnerabilities. Scanning, whether automated or manual, is required by provision 6.6.

Throughout the entire process, Requirement 6.4 outlines the need for change management procedures. These procedures must be part of your development and production-launch policies, and should include:

• Documentation—documenting the changes made both in functionality and in code, possible implications of these changes and their effect on other components of the application/network.
• Management Approval—a hierarchy must be established as part of this policy and changes then must be approved, once proper documentation is supplied, prior to launching the changes from the development environment to staging, and then from staging to the production environment.
• Testing—all code must be thoroughly tested, not only for its resilience against hacking attempts, but for the overall health of the application. Buffer runs, memory leaks, overflows, and other performance related issues can also cause severe security vulnerabilities. Items that may have previously been regarded as acceptable risk to usability or performance may not pass a PCI audit because of the risk they pose to security.
• Back Out Procedures—sometimes significant changes to the application and/or database schema, while not completely irreversible, may be difficult to revert. For every change that is documented, a reversal procedure must also be documented.

Conclusion

The provisions of PCI DSS Requirement 6 vary from being very specific to being very vague, or very cumbersome to relatively simple to implement. The requirement outlines the use of best practices throughout the planning, development, and maintenance phases of your application. You can use many options and methods to meet the provisions of this requirement, and each specific deployment will have its own set of quirks. In this article, I’ve outlined the several portions of Requirement 6 in the hope that it will point you in the right direction when you’re developing for eCommerce.

Resources

• PCI DSS
• Navigating PCI DSS: Understanding the Intent of the Requirements, v1.2
• Glossary of Terms used in the PCI Standard
• Automated, Continuous Vulnerability Monitoring
• Web Application Firewall and Other Application Protections

A version of this article was published in eCommerce Developer on June 24, 2010.

The Payment Card Industry Data Security Standard (PCI DSS) is a set of rules that help govern the way credit card information should be handled and protected. Its nomenclature can oftentimes be a bit confusing. So in a short series articles (starting with this one), we’ll break down the most important elements of the PCI DSS as it relates to data encryption.

PCI DSS Requirement 4

Requirement 4.1 of PCI DSS addresses the encryption protocols and instructs any entity that accepts, handles, transmits, or stores credit card data to “use strong cryptography and security protocols such as SSL/TLS or IPSEC to safeguard sensitive cardholder data during transmission over open, public networks.”
 
Let’s start with understanding what information is encrypted per Requirement 4. PCI DSS requires that all cardholder data (specifically the cardholder’s name, the card number, expiration date, and billing address) be encrypted when stored or transmitted.

Here are some common questions and answers about Requirement 4 to help developers navigate through it.

1. What encryption ciphers should be used for various classifications of data?

Different scenarios require different encryption methods and algorithm implementations. The types of data exchanged at various endpoints in your solution will determine the best method(s) for encrypting and storing/transmitting data. For most instances, symmetric key encryption is best suited for storing data. And 256-bit AES encryption is recommended for transmitting it. 
 
Symmetric key encryption is not always possible, and in these instances you must rely on the public key infrastructure (PKI) to establish SSL/TLS encryption between the customer-facing endpoints (such as a web server or application) and the customers’ systems. Most certification authorities accept key lengths up to 2,048 bits, which provides encryption up to 256-bit. However, this is not a guarantee that all traffic will be encrypted at that level. I highly recommended that you disable weaker SSL ciphers such as SSL1 and SSL2, and only allow SSL3 and TLS to operate with clients that support 256-bit encryption.

2. Will our encryption standard compromise the user’s experience or inhibit adoption of secure practices?

An example of this would be a system that is too slow to load, so users can write down confidential info, take it over the phone, or take shortcuts. Encryption oftentimes adds considerable overhead to a system that would otherwise operate smoothly. There are many hardware appliances available to accelerate the processing of encrypted data. Depending on different load scenarios, it may be necessary to consider additional hardware to maintain application scalability.
 
 
In addition to the impact on infrastructure, customers with older systems may not have the software necessary to support 256-bit encryption. These are extremely sensitive issues because this directly impacts the number of users who are able to conduct a transaction at an endpoint (whether it’s a hardware kiosk, such as an ATM machine or vending machine that accepts card data, or online via a website or application).

3. Will the hosting provider support the encryption requirements?

If “yes,” are there cost implications, and could it be found cheaper somewhere else?
 
 
Hosting resources are always important because, for all intents and purposes, most hosting environments meet the PCI DSS classification of a public environment. Even with dedicated server, data transactions commonly occur over common network equipment, which could constitute a breach of both the data and the keys themselves.
 
 
 
When working with your hosting provider it is extremely important to map out the various data sources and their destinations and ensure that traffic only traverses hardware dedicated to your company. In what is widely considered a deprecated architecture, most secure dedicated solutions include dedicated servers, switches, firewalls and physically isolated network design. This is oftentimes very expensive and not a requirement that hosting providers are willing to accommodate.
 
 
Virtualized environments are often best suited as they allow on-demand scalability, while also providing network isolation through the use of technologies such as VMWare’s vShield virtual switching. Breakthroughs in homomorphic encryption are also expanding possibilities in both virtualized and cloud-type systems, but these innovations are several years from being applicably useful.

4. How long should data be stored, and how to track the age of encrypted data?

Data can be stored for as long as it is required. It is a best practice to dispose of data when it is no longer useful. However, keeping data for extended periods of time often means that the data must be altered when the keys used to encrypt the data are retired and replaced. This often happens on a schedule resultant of a key policy, but can also result from the exposure of a compromised key.
 
 
These types of transformations must occur across all data, including data that has already been archived. This process is often cumbersome, and obviously becomes more so proportionate to the amount of data being stored.

Other Considerations

It is often not the responsibility of the developer to maintain an encryption key infrastructure. However, the developer must uphold the standards the IT department has established for developing strong keys and pairs, the secure storage of those keys, and the protected distribution of keys in transit to other endpoints.
 
 
In addition to making more resources available to the application, it is also a requirement that all encrypted sessions are automatically disposed after a specific period of inactivity. The ability to establish or re-establish a secure connection should also be tightly controlled.

Conclusions

The ultimate goal of PCI DSS Requirement 4 is simple: fraud prevention. Studies and real-life results prove end-to-end encryption (E2EE) to be one of the best ways to achieve this. The E2EE process starts with proper infrastructure and planning, and continues with developers who are responsible for implementing the actual encryption policies. Those developers also make sure it meets the highest protocols and security standards set forth in PCI DSS. 
 
 
Coding on top of (or around) encryption requirements is an art that often involves compromises or adjustments to business logic code. So it is critically important to establish up front business logic, encryption and data management standards when developing web applications that will handle credit card data.
 
Achieving compliance with Requirement 4 doesn’t have to be cumbersome or overwhelming. But it does have to happen. Understanding how to make this process simpler by breaking apart the various pieces can help developers reach PCI DSS security standards with less questioning and more clarity, which will help produce a secure environment.

A version of this article was published in eCommerce Developer on May 19, 2010.

After reviewing the 200-plus sub-policies, procedures, activities, and technical nuances that make up the PCI Data Security Standard, most small and startup E-commerce companies will choose to outsource portions of their website operation to third party service providers. In this scenario, each party is independently responsible for maintaining control over compliance for their respective organization. You shouldn’t fall into the trap of assuming that someone else is handling your compliance needs. Everyone involved in your online store is responsible for a piece of the security compliance pie.

Anyone that touches or has access to credit card data in any capacity is responsible for PCI compliance, regardless of their role.  This includes the online retailer, the Web application developer, and the hosting provider.

The most important steps every E-Commerce developer should complete as they establish a PCI compliant business:

• Step 1 – Become educated about the payment card industry mandates. Taking the time to become knowledgeable here can go a very long way.
• Step 2 – Identify which portions of the PCI DSS you directly control and which items will be outsourced to third parties (A QSA – Qualified Security Assessor – can help with this step)
• Step 3 – Select service partners that have expertise in protecting personally identifiable information (PII).
• Step 4 – Thoroughly review each service partner’s ROC (report on compliance) to make sure there are no unfulfilled requirements or pending remediations for critical items

Achieving and maintaining PCI compliance for your entire online operation starts with the online retailer, since it’s the retailer’s name on the “front door,” not the hosting provider or developer’s company. The E-commerce retailer is the first and most pivotal piece of the pie because they are legally liable for breaches.

In fact, PCI DSS requirement 12.8 states that if cardholder data is shared with service providers, the retailer must maintain and implement policies and procedures to manage service providers. For example, the PCI DSS requires you to:

• 12.8.1 Maintain a list of service providers.
• 12.8.2 Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess.
• 12.8.3 Ensure there is an established process for engaging service providers including proper due diligence prior to engagement.
• 12.8.4 Maintain a program to monitor service providers’ PCI DSS compliance status.

Being PCI compliant requires that your service providers to be PCI compliant. Your organization’s security foundation is only as strong as the weakest link in your PCI compliance checklist, regardless of whether the link resides within your control or in the hands of a service provider you’ve chosen.

Let’s review another PCI DSS requirement to show an example of how each party (retailer, developer, and hosting provider) plays a role in providing secure, PCI compliant E-commerce experience:

Requirement 7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access. Access limitations must include the following:

• 7.1.1 Restriction of access rights to privileged user IDs to least privileges necessary to perform job responsibilities
• 7.1.2 Assignment of privileges is based on individual personnel’s job classification and function
• 7.1.3 Requirement for an authorization form signed by management that specifies required privileges
• 7.1.4 Implementation of an automated access control system

This requirement has several implications:

1) Certain business activities performed by the retailer could fall into requirement 7.1. The retailer should oversee:

• Granting privileges for acceptance (and procedures for disposal) of credit card information received via phone, fax, or email.
• Granting permission for service reps to retrieve and input payment card information into the point of sale system if/when a “glitch” with the web application occurs.

2) E-commerce application developers are responsible for developing and maintaining the Web–to–database “tunnel” through which credit card information flows. Therefore, the Web developer’s piece of the pie includes:

• Granting privileges for developers to create, test, and troubleshoot data provider connections that feed CC information from the web application to the DB (and potentially API connections that feed CC information into a payment processing gateway)
• Granting privileges for managing encryption keys, and encryption key creation and retirement.
• Assigning emergency response chain of command and establishing who should and can access the systems if/when a malfunction occurs
• Assigning encryption key holder responsibilities

3) The hosting provider definitely has physical access to the cardholder data, and in some instances virtual access as well. Therefore, requirement 7.1 applies to hosting providers as well. In this case, the hosting provider owns:

• Granting privileges for physical access to data storage devices containing cardholder data, but also restricting specific access points to be only accessible to the tenant.
• Assigning an emergency response chain of command that is an extension of both other parties’ emergency response chains to authenticate and respond to requests originating from other parties’ policies and procedures.
• Restricting all access to key containers, repositories or other encryption key storage devices to the tenant to whom the keys belong.

Fortunately, you are not alone in deciphering the PCI compliance code. Understanding which party owns what piece of this big PCI compliance pie is a something that takes time and know-how to get your arms around. Once you become familiar with the standard, it will be easier to define which of the PCI compliance standards fall within your area of responsibility and which should be is shared among the various parties responsible for providing the safest online shopping experience.

A version of this article appeared in eCommerce Developer on March 30, 2010.