Posts Tagged ‘PCI Compliance’

Decoding PCI DSS Requirement 6: Develop and Maintain Secure Systems and Applications

by FireHost Evangelist on June 24th, 2010

The main directive of the Payment Card Industry Data Security Standard (PCI DSS) Requirement 6 is to “develop and maintain secure systems and applications.” At a high level, the requirement seems reasonable and the language in the title is simple and straightforward. Closer investigation, however, reveals a much more complex compliance scenario.

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.

(more…)

Decoding PCI DSS Requirement 4: Encrypting and Storing Credit Card Data

by FireHost Evangelist on May 19th, 2010

PCI DSSData encryption seems complicated, and in most cases it lives up to that complexity. This is especially true when encryption requirements go beyond the basics, such as names and passwords, to include highly confidential information like social security numbers, credit card numbers, and protected health information.

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.

(more…)

Understanding the Whole PCI Compliance Pie – Which slice do you own?

by FireHost Evangelist on March 30th, 2010

When you develop Web sites that collect payment via credit card for goods and services sold online, part of your responsibility is to establish and maintain PCI compliance. If followed properly, the Payment Card Industry Data Security Standard (current version 1.2) does a very effective job of providing a safe shopping experience for customers. However, achieving compliance is easier said than done, especially for startups and developers for small online retailers.

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

(more…)

Credit Card Processing: Between a Rock (Hackers) and a Hard Place (Compliance)

by FireHost Evangelist on December 8th, 2009

CSA_06For many ecommerce developers, the thought of designing a system to store the credit card data of their clients’ customers is chilling.

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.

(more…)

Cyber Crime Targeting Financial Services Organizations Continues to Rise, Gain Success

by FireHost Evangelist on October 6th, 2009

financialTargetOf the 285 million successful data breaches investigated by Verizon Business last year, 99% of the data was stolen from servers and applications, not desktops, mobile devices, or portable media. Additionally, over 90% of the 285 million successful data breaches involved organizations that provide financial services.

Experts attribute the proliferation of cybercrime in the Financial Services sector to the recent and lucrative trend toward personal identification number (PIN) fraud.

Hackers who successfully associate a stolen PIN with the appropriate credit card or debit account information can steal cash directly from the consumer’s account. This type of attack, where money is taken “legitimately” from checking, savings, and/or brokerage accounts is more difficult to trace and almost impossible for consumers to defend.

Cyber criminals have been quick to react to the vulnerability, re-engineering processing and developing new memory-scraping malware making it easy to obtain and store PIN details.

While Financial Services Organizations accounted for most of the data compromises, they were not the most targeted sector:

  • Retail Industry #1 at approximately 33% of all attacks
  • Financial Services #2 at approximately 30% of all attacks (highest growth, +16% from previous years)
  • Food and Beverage Services #3 at approximately 14%

These statistics (30% of attacks, 90% of successful breaches) indicate that security measures presently in place with financial institutions are severely underdeveloped.

(more…)