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.

This vision has haunted us ever since. The responsibility of keeping your company’s data safe is one that’s shared by the whole team, and should make them feel empowered. Hacker prevention for companies that store data and/or transact business online isn’t as simple as hiring a secure web host, it’s a 24/7 job that requires good physical and virtual housekeeping from everyone. Luckily, it’s not as tedious, time consuming, or boring as cleaning your actual home, and it doesn’t require you to pat down your employees each time they walk out the door.

Here are five best practices that every one on your team should put into action to keep the company safe from cyber criminals.

#1 Mobile Security
Whether you’re a swanky, MacBook Pro toting executive or a lowly intern who has company email syncing to your phone, you’re responsible for data security when working remotely. Password protecting your mobile devices, and your software, is a ridiculously easy and yet commonly overlooked step that can prevent a world of loss. Password protect everything that your employees work on and access remotely. And we mean everything – mobile phones and laptops, email accounts, VPN connections, and SaaS programs used for business. In addition, don’t store or “remember” passwords for critical services. Require that every employee manually type his or her credentials every time. It’s really not as daunting as it sounds. It takes just a moment to enter a password.

In addition, it’s never a good idea to use a shared wireless connection (coffee shop, airport, etc. As an alternative, bring your OWN Internet (a mobile wireless card) or use a secure VPN service when connecting to proprietary information through an un-trusted network.

Bonus tip: There are numerous Lojack-type software packages that can help locate, recover, or delete misplaced and stolen laptops and mobile phones, and here’s a short article on how to wipe your iPhone’s email account using Exchange.

#2 Destroy More Than You Retain
You have so many documents sitting on your hard drive, in your email, and in your trash bin that it’s almost as daunting to clean up as your actual desk. “I save everything! I need a paper trail!” Not really. In fact, you probably only need a fraction of the data that’s cluttering up your system. Make it a point to routinely determine what should be kept, and what should be deleted. This can mean email, e-files, and customer information. Here’s the plan:

• Retain only what you need, and keep it for the shortest period of time that makes sense.
• Don’t store documents on your local machine, save them to the designated place within your company network.
• Don’t save old emails containing any confidential information, and don’t reply to or forward emails that contain confidential information without removing or encrypting the offensive data. This includes credit card numbers, social security numbers, and sometimes names and addresses, depending on the nature of the correspondence.
• Empty your trash! Shred any sensitive or confidential physical waste, but don’t forget to regularly empty your virtual trash bin (or recycle bin) too.

#3 Patch, Upgrade, and Heed the Warnings
Most software patches and browser updates are free, so there is no excuse to let one slip by. We’ve all been guilty of uttering “ugh, I’ll do it later”, and then never get around to it. Stop doing that. You should have to wear a big dunce cap for putting your company’s integrity at risk by not performing an update that is free and takes a few minutes to install. Performing upgrades within a week of release should be the standard. Here are some of the commonly overlooked upgrades that can, seriously, save your company from a cyber attack:

• Firewall updates
• Browser updates
• Web application updates (WordPress, Drupal, Joomla, et al)
• Operating System updates
• Virus signatures

Life lessons prove that the squeaky wheel gets the oil, so don’t dismiss software update notifications. Keep those nagging, little reminders in plain site so you make sure to do it.

#4 Report Potential Security Breaches
Give your employees permission to be a tattletale. Reporting, (or let’s give it a positive spin — “having an open discussion with a supervisor”) about insecure work conditions or habits should not carry a negative undertone. Let your employees know this, and remind them frequently. Being proactive and responsive about potential security threats is part of a company culture and it should be fostered from the top down. If you think your employees will brush this off, remind them that as an employer, you have quite a lot of THEIR personal information – social security numbers, bank information for direct deposit, healthcare information… the list goes on. Understanding that their information is just as secure (or not) as your customers and every other piece of company data is crucial to getting their buy in.

#5 Passwords
It sounds so simple, and it’s even been brushed off as ineffective (gasp). Setting, storing, and a commitment to changing passwords should be number one on this list. We’ve listed this critical step last on the list because “everybody knows about passwords” and you would have probably stopped reading this if it were the first point in this article. Here are some of the top suggestions for devising a hacker-resistant password scheme:

• Revise any credentials that were supplied as default settings from your vendor
• Use a different password for each service you access online
• Personal passwords should not be related to naming conventions you use for work
• Make your passwords complex. Use a multitude of characters, and if you need help devising a creative password, try something like PC Tools Secure PW Generator < http://www.pctools.com/guides/password/ > for ideas
• Change passwords frequently. Every quarter at minimum
• Don’t share passwords or any part of your login credentials with anyone – friends, coworkers, or even your boss

Instilling these best practices with every member of your team should be part of the company culture from the get go. But it’s also never too late to start being more preventative and proactive in securing your business. Print this list and give it to every employee. Implementing these tips and having reminder discussions on a regular basis will help keep your business safe, from just about every cyber angle.

A version of this article appeared in VentureBeat on May 25, 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.

For many ecommerce developers

For good reason. Determined hackers can compromise the most sophisticated network by combining simple, free tools with a little effort. In fact, the cyber-criminals behind the famed TJ Max and Heartland Payment Systems breaches used novice techniques like War Driving and SQL Injections to access the retailers’ networks.

If hackers can penetrate the network of a global enterprise, imagine what they can do to your clients’ small businesses. It’s a scary proposition, no doubt, but it shouldn’t keep you from going down that path when a project requires it.

Managing Credit Card Data

The first (and perhaps most important challenge) you’ll face with such an ecommerce development project is credit card collection, storage, and handling. One of the easiest and least risky options is to offload, via an API, the storage and handling of credit card numbers to a payment gateway that “hides” credit card data – Authorize.net, PayPal, BluePay or the like. If the credit card data is passed directly from the client (browser) to the gateway, without passing through your client’s web server, you’ll reduce your liability as the developer and help keep your client’s ecommerce site protected.

However, this solution many not work in all situations or for all clients for, at least, a few reasons.

1. Complicated recurring billing. If your client has a complicated recurring billing structure wherein payments vary in time, frequency, amount, or purpose; or if your client’s customers use purchase orders, your client may need to keep the raw credit card numbers available for the flexibility. Your client can still use tokens and offload the recurring billing to some credit-card-obscuring payment gateways as mentioned above, but again the need to process or manage customer data can be project specific.
2. Save on Interchange fees. All credit-card merchant-account providers charge an Interchange fee, and these fees can and do vary from provider to provider. So for some potential clients managing customer credit card data can be well worth the risk if doing so allows them to get a significantly better fee structure.
3. Offloading credit-card-storage is not enough. If credit card data passes through your client’s web server, whether the business stores that data or not, the system you develop needs to be PCI compliant. In short, whenever possible, choose a solution that never exposes your web server and your client’s ecommerce business to customer data. But when a project does call for credit data transfer or storage, you’ll need to build a Payment Card Industry compliant system that hackers cannot easily overcome.

Understanding the Requirement for PCI compliance

The Payment Card Industry (PCI) Security Standards Council has established twelve mandatory practices and precautions that must be taken when handling, processing, storing, and transmitting credit card data. The effort necessary to achieve PCI compliance will vary depending on the state of your development and hosting environment in which the ecommerce application will reside. While the specific details of becoming PCI compliant would merit a separate article, it is important to remember that when a project calls for “touching” credit card information, PCI compliance is a must. Your ecommerce client cannot do business without being compliant.

Cutting the Cost of PCI Compliance

PCI compliance can be expensive. For example, building a PCI compliant system from the ground up may require enlisting the help of a Qualified Security Assessor (QSA) to shape the scope of your PCI compliance undertaking; a number of audits; and monthly scans. All of this may cost a Level 3 merchant—those that process between 20,000–and–1,000,000 transactions each year—up to $155,000, according to the PCI DSS Compliance Blog .

The cost for smaller, Level 4 merchants, processing less than 20,000 transactions each year, varies greatly, but could cost $2,500 or more according to a payment gateway provider.

As a savvy developer, you may be able to help your client defray some of these costs.

1. Find a compliant host. Choose a web hosting environment that is already PCI compliant. If your client doesn’t need to own servers, consider a qualified, PCI compliant host.
2. Encourage processing in the client. The points above notwithstanding, choosing a solution that captures credit card data in the client, passing a token to your client’s web server, may be the best option.
3. Small merchants can do it themselves. Consider taking the “self assessment.” Level 2 and smaller merchants can self-assess rather than hiring a third-party to do the assessment, which can be a money saver.

PCI Compliance: You Need to Do It

Achieving PCI compliance is not only mandatory for all ecommerce merchants, it also assures that you and your client have taken all the steps necessary to provide a safe shopping experience for your client’s website users. Taking the steps to secure your client’s environment before a security breach may go a long way with Visa, Mastercard, the PCI Council, and forensic auditors who will be performing due diligence should disaster strike.

In fact, mitigating a security breach may be more challenging and expensive for non-compliant companies. Forrester Research estimates that mitigation will cost an average of $200 for each person/credit card account that is compromised.

This article was featured in eCommerce Developer on December 8, 2009.