Toronto based PCI Compliance upstart brings single solution to Voice-Web-POS

As published in ITWorldCanada.com
(http://www.itworldcanada.com/blog/toronto-upstart-brings-tokenization-protection-to-uc-web-pos/98109)



The standard Information Security mantra is to Protect Sensitive Data Where It Resides, but I posit that with the number of Security Breaches being publicized these days, we should quickly move to Remove Sensitive Data Where Not Required.

I know that I'm not new to this train-of-thought, but the cost of non-compliance is growing exponentially.  Financial Damage can be insured against... Reputational damage cannot.

In a previous article, I spoke about the need for complementing industry standard Encryption with a process called Tokenization. While encryption is intended to hide the actual data in a manner that is reversible, tokenization replaces the sensitive data with a tag or token, preserving only the format or schema of the data.

The Payment Card Industry has clearly stated that any piece of infrastructure that is accessible by network to those systems that either process or store PCI (Credit Card) Data are "in scope" for PCI compliance. This means that the scope an an annual compliance audit could essentially include every device on your network....

Many software companies have taken on portions of the tokenization challenge.  Originally, they provided API's and libraries for developers to embed tokenization into applications, or bootstrap tokenization onto existing applications.  These did little though to reduce the scope of your PCI compliance, and in many cases raised the complexity of the environment.

Next came the tokenization broker appliances, which were housed in your data center to communicate with your Point Of Sale and payment processing systems. Although this reduces scope and complexity of your PCI environment, it still leaves a large amount of your environment "in scope" for PCI, and the "crown jewels" were still onsite, albeit in a very robust data vault.

With a tokenization solution outsourced via a SaaS model, sensitive data such as credit card numbers are not stored in your system. There is nothing to obtain during a breach.  Full stop. Let someone else take on the burden of PCI compliance.

Toronto's own Blueline Data has taken on the challenge, by creating a novel tokenization gateway solution that not only covers your Web and Point Of Sale transaction systems, but your Telephony and Unified Communications Infrastructure as well. In fact, you can define any type of digital data sequence to be protected for SOX / HIPAA / OSFI  or any other regulatory requirement and tokenize it as well.  They call their strategy "Assurance through Deterrence". By removing the sensitive data from your environment, they deter would-be attackers from investing in Advanced Persistent Attacks to breach your environment.

The PCI-DSS covers 6 areas of protection with 12 Specific Requirements.  Blueline's unique offering covers 7 of these requirements, across 5 areas!

The Blueline environment itself, subject to PCI audit, complies with the DSS 3.0 requirements. It offers a unique and low-risk approach to protect your IT assets, such as financial records, intellectual property, employee details and data entrusted to you by customers or third parties. The combined benefit is the highest security and the lowest cost.


Their approach to format preserving and diskless tokenization at the perimeter, essentially creates a Zero Vector of Attack™ computing environment, which is easy to operate but not feasible to exploit.

I believe that their forward thinking initiative of providing tokenization services to non-traditional channels of data flow sets them aside from the competitors in this market.  I'm anxious to watch this company flourish amid the weekly disclosures of Sensitive Data Breaches.


From the Blueline Data Website:

Blueline Data Products and Services

• Strategic Assessment – a review with your team to determine what Blueline Solutions would be most impactful with your business requirements and technology investments
• Solution Services – compliance delivery guidance and market insight (call center, financial services, healthcare, retail, etc.) 
• Voice Gateway - encompasses security encryption around voice channels that send and receive sensitive data, to eliminate fraud by capturing, masking and encrypting confidential signaling information on the  path. The encrypted sensitive datagrams are securely rendered to allow fully protected  processing, eliminating the possibility of a call to get compromised.
• Retail Gateway - offers integration with any point-of-sale (POS) device in a secure and compliant manner, and allows point-to-point encryption of client's personal information from any payment media. This applies to any transaction or function where a client is required to use a payment terminal for credit or debit card processing expected to integrate with the backend data repository. There is no need for manual card data entry for proof of identity, payment guarantee or other purposes.
• Data Gateway - provides organizations with a single access point-of-presence to transaction services, such as secure banking and financial networks, mobile application payment delivery, or secure web bill presentment. It allows you centrally and uniformly govern all traffic of financial interest, whether it is exchanged between your partner organizations or with your clientele involved in the transaction flow.  Sensitive data transfer is fully protected to meet the highest security and privacy standards.
• Data Vault - presents a conversion engine that takes any sensitive data element – whether it is SSN or SIN number, driver's license, credit or debit card, or patient record – and encrypts such information in a format-preserving manner.  The data is tokenized and optionally stored in a secure "digital vault" that you can access as you need, provided that sufficient privileges are presented.  It fully removes sensitive payment and personal information from your computing systems and digital media.

References:
PCI Security Standards: Information Supplement: PCI DSS Tokenization Guidelines 
SANS: Six Ways to Reduce PCI DSS Audit Scope by Tokenizing Cardholder data 
http://bluelinex.com/resources/blp204_pci_compliance_sheet.pdf
Blueline Services: Data Tokenization 
Securosis: Understanding and Selecting a Tokenization Solution
Shift4: A detailed look at tokenization and it's Advantages over Encryption
TokenEX: Outsourcing Tokenization vs. On-Premise Data Security 
http://www.mashery.com/api-gateway/tokenization
http://www.bankinfosecurity.com/whitepapers/using-pci-dss-criteria-for-pii-protection-w-947
Payment Card Industry (PCI) Data Security Standard
Protegrity Tokenization Securing Sensitive Data for PCI, HIPAA and Other Data Security Initiatives
Protegrity: Vaultless Tokenization
Protegrity: Vaultless Tokenization Fact Sheet.
Cybersource: Reducing PCI Compliance Scope: Take the Data Out
Intel: PCI DSS Tokenization Buyer’s Guide 

PCI DSS Cloud Computing Guidelines - Overview

The PCI Security Standards Council  has just published (02'07'2013) an Information Supplement: 

 PCI DSS Cloud Computing Guidelines



According to their press release:

"One of cloud computing’s biggest strengths is its shared-responsibility model. However, this shared model can magnify the difficulties of architecting a secure computing environment," said Chris Brenton, a PCI Cloud SIG contributor and director of security for CloudPassage. "One of this supplement’s greatest achievements is that it clearly defines the security responsibilities of the cloud provider and the cloud customer. With PCI DSS as the foundation, this guidance provides an excellent roadmap to crafting a secure posture in both private and public cloud."

So, first things first: 

This is an information supplement, not intended to replace the PCI Data Security Standard (DSS), but rather to enhance the work done during the development of the Virtualization Guidelines in June of 2011. They have acknowledged the move toward Cloud Services, and have created a set of guidelines to allow businesses to remain PCI Compliant while moving their workloads to the Cloud.

To diferentiate roles and responsibilities between Cloud Customer and Cloud Service Provider, the PCI Security Standards Council leverages the definitions of Cloud Computing provided by NIST to outline the common deployment models:

• Private cloud. The cloud infrastructure is provisioned for exclusive use by a single organization comprising multiple consumers (e.g., business units). It may be owned, managed, and operated by the organization, a third party, or some combination of them, and it may exist on or off premises.
• Community cloud. The cloud infrastructure is provisioned for exclusive use by a specific community of consumers from organizations that have shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be owned, managed, and operated by one or more of the organizations in the community, a third party, or some combination of them, and it may exist on or off premises.
• Public cloud. The cloud infrastructure is provisioned for open use by the general public. It may be owned, managed, and operated by a business, academic, or government organization, or some combination of them. It exists on the premises of the cloud provider.
• Hybrid cloud. The cloud infrastructure is a composition of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load balancing between clouds).

Within each of these you would have service models  (Software As A Service SaaS, Platform As A Service PaaS, and Infrastructure As A Service IaaS).

They then clearly define the relationships between Customer and Service Provider.  Of particular note:

The level of security responsibility across the cloud service models generally migrates towards the client as the client moves from a SaaS model (least client responsibility) to an IaaS model (most client responsibility). The greatest level of responsibility for the CSP to maintain security and operational controls is present in the SaaS service model.

  

They then thoroughly discuss the PCI related responsibility each side may have from the physical data center of the provider, through the network, storage, virtualization layers, Operating System, Application Stack, presentation layer, and finally data. The following table is one of the examples they provide:

As expected, considerable care is placed around the discussion of segmentation.

It is the Customer's responsibility to ensure that the Cloud Service Provider has adequately provided "an equivalent level of isolation as that achievable through physical network separation."  Critical to this discussion is the isolation of each layer (network, virtualization, Operating System, and Data)  from other Customers of the Provider. 

Once any layer of the cloud architecture is shared by CDE (Cardholder Data Environment) and non-CDE environments, segmentation becomes increasingly complex. This complexity is not limited to shared hypervisors; all layers of the infrastructure that could provide an entry point to a CDE must be included when verifying segmentation.

Recommendations for minimizing and simplifying PCI DSS scope in a cloud environment include:

Don’t store, process or transmit payment card data in the cloud.

Failing that:

• Implement a dedicated physical infrastructure that is used only for the in-scope cloud environment.
• Ensure Segregation of CDE and non-CDE environments
• Ensure Segregation of Service Provier Customers
• Minimize reliance on third-party CSPs for protecting payment card data.
• Do not transmit data in clear text
• Do not store data in clear text
• Maintain control of your encryption keys (isolate encryption/decryption/key management from your cloud)
• Validate PCI DSS controls regularly

  There are several case studies described in the document to assist in understanding the accountabilities/responsibilities in various Cloud Provider models.

All in all, this is a clear and concise read which go to great lengths to help assess the requirements to meet when selecting a Cloud Service Provider to support your PCI environment.