Home > A6, Cloud Computing, Cloud Security, Cloud Security Alliance, CloudAudit, PCI > Dear Verizon Business: I Have Some Questions About Your PCI-Compliant Cloud…

Dear Verizon Business: I Have Some Questions About Your PCI-Compliant Cloud…

You’ll forgive my impertinence, but the last time I saw a similar claim of a PCI compliant Cloud offering, it turned out rather anti-climatically for RackSpace/Mosso, so I just want to make sure I understand what is really being said.  I may be mixing things up in asking my questions, so hopefully someone can shed some light.

This press release announces that:

“…Verizon’s On-Demand Cloud Computing Solution First to Achieve PCI Compliance” and the company’s cloud computing solution called Computing as a Service (CaaS) which is “…delivered from Verizon cloud centers in the U.S. and Europe, is the first cloud-based solution to successfully complete the Payment Card Industry Data Security Standard (PCI DSS) audit for storing, processing and transmitting credit card information.”

It’s unclear to me (at least) what’s considered in scope and what level/type of PCI certification we’re talking about here since it doesn’t appear that the underlying offering itself is merchant or transactional in nature, but rather Verizon is operating as a service provider that stores, processes, and transmits cardholder data on behalf of another entity.

Here’s what the article says about what Verizon undertook for DSS validation:

To become PCI DSS-validated, Verizon CaaS underwent a comprehensive third-party examination of its policies, procedures and technical systems, as well as an on-site assessment and systemwide vulnerability scan.

I’m interested in the underlying mechanicals of the CaaS offering.  Specifically, it would appear that the platform – compute, network, and storage — are virtualized.  What is unclear is if the [physical] resources allocated to a customer are dedicated or shared (multi-tenant,) regardless of virtualization.

According to this article in The Register (dated 2009,) the infrastructure is composed like this:

The CaaS offering from Verizon takes x64 server from Hewlett-Packard and slaps VMware’s ESX Server hypervisor and Red Hat Enterprise Linux instances atop it, allowing customers to set up and manage virtualized RHEL partitions and their applications. Based on the customer portal screen shots, the CaaS service also supports Microsoft’s Windows Server 2003 operating system.

Some details emerge from the Verizon website that describes the environment more:

Every virtual farm comes securely bundled with a virtual load balancer, a virtual firewall, and defined network space. Once the farm is designed, built, and named – all in a matter of minutes through the CaaS Customer Management Portal – you can then choose whether you want to manage the servers in-house or have us manage them for you.

If the customer chooses to manage the “servers…in-house (sic)” is the customer’s network, staff and practices now in-scope as part of Verizon’s CaaS validation? Where does the line start/stop?

I’m very interested in the virtual load balancer (Zeus ZXTM perhaps?) and the virtual firewall (vShield? Altor? Reflex? VMsafe-API enabled Virtual Appliance?)  What about other controls (preventitive or detective such as IDS, IPS, AV, etc.)

The reason for my interest is how, if these resources are indeed shared, they are partitioned/configured and kept isolated especially in light of the fact that:

Customers have the flexibility to connect to their CaaS environment through our global IP backbone or by leveraging the Verizon Private IP network (our Layer 3 MPLS VPN) for secure communication with mission critical and back office systems.

It’s clear that Verizon has no dominion over what’s contained in the VM’s atop the hypervisor, but what about the network to which these virtualized compute resources are connected?

So for me, all this all comes down to scope. I’m trying to figure out what is actually included in this certification, what components in the stack were audited and how.  It’s not clear I’m going to get answers, but I thought I’d ask any way.

Oh, by the way, transparency and auditability would be swell for an environment such as this. How about CloudAudit? We even have a PCI DSS CompliancePack ;)

Question for my QSA peeps: Are service providers required to also adhere to sections like 6.6 (WAF/Binary analysis) of their offerings even if they are not acting as a merchant?

/Hoff

Related articles by Zemanta

Enhanced by Zemanta
  1. David Ochel
    August 25th, 2010 at 08:49 | #1

    "Are service providers required to also adhere to sections like 6.6 (WAF/Binary analysis) of their offerings even if they are not acting as a merchant?"

    Service providers are required to adhere to whatever they claim their scope is. It works the other way around: A merchant (or service provider) goes and buys a set of services from a(nother) service provider. The merchant is responsible for being 100 % compliant, and as part of that they have to manage their service providers' compliance for whatever services they have contracted to be provided in a PCI-compliant manner.

    So, it's completely feasible that a service provider excludes the provision of a PCI-compliant operation of a WAF (or application review) from its scope. The merchant could either implement this himself, or let the service provider implement it and then include the relevant infrastructure/operations of the service provider in the merchant's compliance assessment (if it's not in scope of the service provider's own assessment). Provided appropriate agreements are in place, of course. It's also an option that a service provider will offer the PCI-compliant operation of a WAF, and nothing else, to merchants. Or just the provision of physical security (think data center co-location). Or other pieces of the puzzle.

    (On a side note, it's of course possible as well that a service provider maintains a separate corner of its data center in a PCI-compliant fashion and gets it assessed, but then puts the services it sells to low-end customers into a different corner that doesn't meet the requirements. Is the service provider compliant? Sure. For a defined scope. Does this apply to all services provided to all customers? In this case obviously not.)

    So, from a service provider's point of view, it's OK to say "I don't offer this or that in a PCI compliant fashion", and to exclude it from their scope. Within the boundaries of logic and common sense, obviously – if you implement whatever pieces of the puzzle as a service, then you probably will never get around the DSS requirements for security management and such. It all gets tied together to a complete picture when a merchant's compliance is reviewed – at that point in time, all requirements applicable to the merchant's operation – and who implements them, and who is responsible for maintaining and demonstrating compliance – need to be accounted for.

    Determining overall compliance for merchants, and choosing a service provider that meets your needs, gets tremendously easier if the service providers actually advertise the scope of their PCI compliant operations and services correctly and fully. Which is what your point was in the first place, I believe. :-)

  2. August 25th, 2010 at 09:11 | #2

    <blockquote cite="#commentbody-48376">

    David Ochel :

    Determining overall compliance for merchants, and choosing a service provider that meets your needs, gets tremendously easier if the service providers actually advertise the scope of their PCI compliant operations and services correctly and fully. Which is what your point was in the first place, I believe.

    Like or Dislike: 2  0

    …indeed that was my point. The fact that Verizon claims they are "compliant" is interesting only within the context of what that means in terms of scope — just like a SAS70. Furthermore, if a "merchant" places an OS/Appstack in a VM above their offering, then they too must be audited for compliance, no?

    The "we're compliant so you will be too" is clearly targeted at people who don't understand that game. I'm not saying that's what VzB is doing, but I am truly intrigued as to what/how they declared as in-scope.

    I think DSS should make those elements mandatorily disclosed if a provider/merchant claims such.

    /Hoff

  3. Kettle
    August 26th, 2010 at 05:42 | #3
  4. August 26th, 2010 at 06:06 | #4

    @Kettle

    So I'm rather confused by your comment. If you read the information on that page, it describes a set of PCI compliance solutions for retail as such:

    "Cisco has developed a set of architectures in a lab environment with PCI requirements in mind. Cisco invited PCI auditors to evaluate these architectures, and the auditors found that the technology, if properly deployed and maintained, could help retailers achieve PCI compliance."

    So an architecture of products for POS and retail environments mapped to specific products to "…help retailers achieve compliance" is the same as claiming your entire cloud offering is PCI compliant how?

    What'd I miss?

    Not really interested in being defensive, I just don't get your point beyond the fact that nobody can magically make anyone PCI compliant…

  5. August 26th, 2010 at 06:11 | #5

    @Kettle

    Again, this post was not written to take pot shots at VzB, it was written to ask for clarification on a rather bold set of claims and highlight a problem we have in press release security in this industry. No vendor is holier-than-thou in this regard, even my employer…but since this is my personal blog…

    BTW, you do know you're IP address flows through when you comment, right? Do you have anything to actually add in reference to the post since you seem to work for Verizon Business?

    OrgName: MCI Data Services Ops, Packet Network

    OrgID: MDSOPN

    Address: 2560 North First Street

    City: San Jose

    StateProv: CA

    PostalCode: 95131

    Country: US

    NetRange: 131.146.0.0 – 131.146.255.255

    CIDR: 131.146.0.0/16

    NetName: TYM-SJ-NET

    NetHandle: NET-131-146-0-0-1

    Parent: NET-131-0-0-0-0

    NetType: Direct Assignment

    NameServer: AUTH-NS1.VERIZONBUSINESS.COM

    NameServer: AUTH-NS2.VERIZONBUSINESS.COM

    Comment:

    RegDate: 1988-11-22

    Updated: 2009-03-17

    RTechHandle: MCIHO-ARIN

    RTechName: MCI Hostmaster

    RTechPhone: +1-972-729-5738

    RTechEmail: hostmaster@verizonbusiness.com

    OrgAbuseHandle: ABUSE3-ARIN

    OrgAbuseName: abuse

    OrgAbusePhone: +1-800-900-0241

    OrgAbuseEmail: abuse-mail@verizonbusiness.com

    OrgNOCHandle: OA12-ARIN

    OrgNOCName: UUnet Technologies, Inc., Technologies

    OrgNOCPhone: +1-800-900-0241

    OrgNOCEmail: help4u@verizonbusiness.com

    OrgTechHandle: MCIHO-ARIN

    OrgTechName: MCI Hostmaster

    OrgTechPhone: +1-972-729-5738

    OrgTechEmail: hostmaster@verizonbusiness.com

    OrgTechHandle: SWIPP-ARIN

    OrgTechName: swipper

    OrgTechPhone: +1-800-900-0241

    OrgTechEmail: swipper@verizonbusiness.com

  1. August 25th, 2010 at 00:12 | #1