Dichotomy: Stemming from the 17th Century Greek word Dicho- (Duality) -Tomia (incision, cutting) means: A division into two parts or classifications, esp. when they are sharply distinguishable or opposed. (wordreference.com)
An Introduction of Cloud Service Provider Actors, Approach, and Gray Areas
This is the first of a series of posts about the mutual relationship between a Cloud Service Provider (SP) and its customers, within the realm of PCI-DSS.
As a QSA and a former PCI DSS compliance manager at one of the biggest PCI DSS certified level 1 SPs in Sweden, I have often experienced the challenges that the mutual responsibilities of a SP and a customer present, from both perspectives.
As a PCI DSS compliance manager, I had to deal with:
- My company System engineers
- My company management
- My company QSA
For my company audit:
- Customer System engineers
- Customer management
- Customer QSA
There are at least six different actors working toward one goal for a normal customer’s audit: the compliance of the customer.
In the next posts I will dig into the technical and governance nuances involved, detailing who is who and who does what. For now, let’s just assume that a common approach is to establish a mutual responsibilities Matrix between a customer and service provider similar to the one depicted in the PCI SSC council supplement for cloud guidelines, based on the kind of service(s) that the SP provides to the customer. Such a matrix is a crucial part of the audit since it depicts which requirements are applicable.
The Matrix is often very technical and detailed. The more detailed it is, the clearer the role of the actors involved becomes and the easier the audit. Yes, it is a large task that requires periodic tweaking and tuning according to the agreement between the SP and the customer.
Depending on the agreement, there might be five different scenarios for each sub requirement of PCI DSS compliance:
- N/A to SP
- N/A to Customer
- Applicable only to Customer
- Applicable only to SP
- Mutual Responsibility
For each PCI DSS standard requirement, a detailed description of the reason and type of applicability, alongside compliance description (when present), must be provided in the Report on Compliance (RoC). If the SP is not PCI DSS certified, the customer is fully responsible for all the 12 requirements (and all the sub requirements) of the standard.
If the SP is PCI DSS certified, the customer is only responsible for those Requirements that are applicable to the customer, since the SP is being audited by an independent third party QSA on the services that the SP sells, e.g., if the SP sells colocation on its data centers which are PCI-DSS certified, part of the physical security of Req. 9 is not applicable to the customer. Well, such distinctions seem to be difficult to digest for some QSAs. Every year, for every customer audit they are supposed to see and audit an SP’s process, data centers, hardening standards, etc…
Every time, even with the same QSA through different years, I’ve had to say that this isn’t possible since it is a waste of time, money, and effort for both the SP and the customer. An independent third party QSA already certified our services and our AoC was there to guarantee our compliance. Try to imagine what would happen if all the PCI DSS entities hosted at AWS (Amazon Web Services) wanted to have Amazon data centers (which are PCI-DSS certified) audited every time such entities had an audit:
It would be impossible.
Nowadays, as a QSA, I have to audit if the assessed entity monitors the compliance of its SPs and I often see that it is still a gray area. Personally, I trust the competence and the judgement of all the QSA who are out there. If one of them deemed an SP PCI DSS compliant and worth the AoC, I would never challenge his/her compliance manager against the customer.
Each QSA has undergone the same process as I have to become a QSA, and therefore his/her opinion should be respected if they deemed an SP PCI DSS compliant.
This ends the first post; next time we will cover the Theorem of the four Ws: Who is Who, Who does What. A consolidated approach to define boundaries between a SP and a customer within PCI DSS.
