3 min read

Vendor attestations prove nothing about your systems

Vendor attestations prove nothing about your systems

Over the years I've been tasked to implement controls as a developer or self-assess and design controls that meet the requirements of contractual, compliance, regulatory, and legislative obligations.

One of the continuing misconceptions I've seen is most business believe (and often publicly claim) a vendors security and compliance attestations will automatically give them the same level of security and meet the same obligations as outlined in the vendor provided attestation - this is wrong for many reasons and couldn't be further from reality.

Vendor Security and Compliance Attestations never cover your obligations

Amazon AWS Lambda example

AWS added Lambda to PCI DSS their compliance attestations known as AWS Artefact.

Ref: AWS Services in Scope

AWS approach compliance in a very minimal way, and services audited are scoped strictly to the shared responsibility model and in practice as part of the compliance exercise Amazon offer customers guidance so that they may achieve PCI DSS on their usage on top of AWS - this is known as applying the carve-out method where Amazon will be audited for a small portion of the whole PCI DSS requirements with the understanding the end-customer applied the remainder. In practice you as the end-customer are ultimately obligated to meet all of the requirements not just the remainder left over by AWS, thought it is the discretion of the auditor to consider the AWS attestation when auditing your organisation for PCI compliance.

To go deeper on this point, the QSA (Qualified Security Auditor) applied PCI DSS testing procedures on what AWS have implemented under-the-hood.
All requirements that are able to have the end-customer implement the control AWS are not tested by the QSA at all.

In terms of Lambda, a service where you do not have control of any infrastructure, access to the operating system, or any ability to configure anything at all beyond what the AWS abstraction provides - you don't even have access to the programming language execution environment configuration, how your code is initialised, or in some cases what the inputs are. You only have your source code in the form of a function which is executed on your behalf with limited or no ability to control more than the function output.

That is to say, for PCI DSS requirements around encryption at-rest, Lambda's disk-level storage is not encrypted, i.e. The encryption at-rest option presented will only encrypt the Lambda package AWS receives from you, but it does not provide encryption at-rest of the execution environment of Lambda itself.

The mentioned exception is if you pursue the PCI DSS Compensating Controls Worksheet, which must not only meet but exceed the original intent of the requirement you could not meet. More then that, compliance is at the full discretion of the QSA whether or not you've implemented sufficient controls that exceed the requirements original intent.
For encryption at-rest requirements you will need compensating controls that apply sufficient controls for confidentiality, data integrity, data being rendered useless upon breach or disclosure to name a few intents of encryption at-rest.

Remember, to achieve PCI DSS using the Compensating COntrols Worksheet you must exceed the original intent in the eyes of the QSA, so don't expect the audit will go smoothly when using this technique.

Important side note: Lambda disk storage is both multi-tenanted and eventually ephemeral, it is reused/shared across multiple Lambda invocations that are perceived to be distinct/sandbox execution environments but are not.

This means a end-customer can not achieve PCI DSS if AWS Lambda is PCI in-scope, with 1 exception I'll describe in a moment. You cannot apply the requirements for encryption at-rest and AWS have not provided this as an option for you to configure yourself, and AWS has not provided you with any attestation that they use any hardware-encrypted storage.

Generally, if you are an MSSP, providing hosting as part of your service offering to your customers on top of AWS (or any other MSSP) you are fully responsible for protecting your customers CHD (card holder data) and secure the CDE (card data environment), none of vendor supplied attestations can be provided to your customers as attestation of your security posture, you must obtain attestations of your own for each compliance or standard you supply-chain provides to you.

Putting it bluntly, if you do not achieve PCI DSS then none of your own customers can.

In summary, a vendors attestation is proof of their security not yours, attestations are not transferable to their customers in any way.