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. 

Cloud security is a hot topic throughout the industry and the discussion is not complete without mentioning how the Cloud Security Alliance (CSA) has been influential in ensuring major security issues are addressed and averted. Cloud Security Alliance (CSA), a non-profit organization formed to promote security in cloud computing and education on the uses of Cloud Computing to help secure all environments.

“FireHost’s deep experience in virtualized and secure hosting is a welcome expertise for The Cloud Security Alliance,” said Jim Reavis, executive director of the Cloud Security Alliance. “We’re confident FireHost will be an asset in helping the CSA continue to innovate in developing best practices for securing providers in the cloud.”

Joining the CSA is further confirmation of our devotion to security and compliance for our customers. This is another step towards building on a foundation of security, governance and compliance, including PCI DSS, HIPAA compliance, SAS 70 Type II & other compliance mandates.

For more information and details, view the following press release announcing our partnership with CSA – http://www.firehost.com/company/newsroom/firehost-joins-cloud-security-alliance.

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.