Become PCI DSS v4 Compliant with Conosco EDS

The Payment Card Industry Data Security Standard (PCI DSS) is an internationally recognised information security standard designed specifically to apply to organisations that handle credit card data, to ensure that businesses can process credit and debit card payments securely, protecting businesses and consumers and reducing the likelihood of card fraud. Any organisation that processes card data must comply with PCI DSS.  

PCI DSS v4.0 introduces an outbound email security control, “Domain-based Message Authentication, Reporting & Conformance” (DMARC), an open standard which authenticates your email ensuring it is from a trusted sender of your email domain. 

Key milestones for your organisation:

June 2024: PCI DSS auditing will begin. You should have a valid published DMARC policy, it is acceptable to configure with just monitoring mode (no enforcement) 

March 2025: mandatory compliance. The DMARC policy must be configured with at least quarantine enforcement. 

It is unclear at present what penalties will be imposed for non-compliance, but we anticipate those services you use may refuse to process transitions, significantly impacting your business and customers. 

Why you need DMARC

When you register a domain, by default, it is vulnerable to direct email impersonation (spoofing), meaning anyone can send an email as your domain. They don’t even need to steal your email account credentials and login. 

Spoofing is a common type of cyber attack and is often incorporated into larger phishing and social engineering campaigns.

DMARC is the industry standard used to mitigate this inherent vulnerability. It is built upon two existing email protocols (SPF and DKIM) which fail to fully address outbound email security. 

Sender Policy Framework (SPF):  

A policy published in your domain’s DNS (Domain Name System) which contains a list of IP addresses authorised to send email on your behalf (as your domain).

Example SPF Policy

v=spf1 ip4:199.60.103.228 include:_spf.mx.cloudflare.net include:servers.mcsv.net ~all 

The receiving server checks if the sender’s IP address can be found in the domain’s SPF policy, and if found the message passes authentication. 

It uses the domain in the hidden “Envelope From” email address header to locate the SPF policy, which may be different from the domain in the email address the user sees in the inbox, the “Message From” header. 

Issues: 

• Although SPF can be configured to instruct the receiver to reject messages failing authentication (-all), it does not fully address unauthorised domain impersonation and is easily bypassed.
• There is no reporting mechanism. The domain owner is unaware who is sending emails on their behalf and if the message passed or failed authentication.

Domain Keys Identified Mail (DKIM)

Uses public key cryptography to ensure the message wasn’t changed in transit. The sending service hosts the private key, and the corresponding public key is published in your domain’s DNS. 

Example DKIM public key:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCeM4FzvVjLOlVw2CA4itdsepFj2dxpaiof3NNEJx4l
pliyyn7r2QMdaF/B8NPp8gINGAoFKpNTdPibjH1OTD1A9j9njhgjdBIFUlQxHt6EL+5yxn/oXQ+ZJODodWuIi39vpteHMDM2Arb
5ADF+j67ZtMITrEXieH3xOA8T25KIeQIDAQAB

The sending server computes a hash of the email and encrypts this with its private key, then creates a digital signature containing the hash and adds this header to the outbound email. The receiving server computes a hash of the email; then looks up the domain in the digital signature to retrieve the corresponding public key and decrypts the hash within the digital signature. Finally, the receiver compares both hashes and if they match, the message hasn’t changed in transit and passes authentication.

Issues:

• There is no mechanism to instruct the receiver what to do if the message fails authentication. It is also easily bypassed - the threat actor signs the unauthorised outbound email impersonating your domain with their own DKIM signature.
• There is no reporting mechanism. The domain owner is unaware who is sending emails on their behalf and if the message passed or failed authentication.
  

How DMARC Resolves These Issues

DMARC works by allowing domain owners to publish a policy in their DNS. The policy instructs the recipient how to handle unauthorised domain impersonation (messages failing authentication) and where to send reports (giving you visibility).

Example DMARC policy:

v=DMARC1; p=reject; rua=mailto:dmarc@example.com 

DMARC Authentication

A pass (authenticated email) requires two conditions to be met:

1. Either SPF or DKIM pass authentication (can be both)
2. The domain found in SPF or DKIM (whichever passed authentication) must match the domain for the email address the user will see in their inbox, the “Message From” header. This is known as domain alignment.

A receiving server uses the domain in the “Message From” header to locate the published DMARC policy and actions failed authentication according to its enforcement setting. DMARC is a journey, you should start with no enforcement (monitoring), then move to quarantine and finally reject.

None (p=none)

Action: Accept the email; we are only monitoring it. 

This gives you the opportunity to identify your authorised sending services and configure them to pass SPF or DKIM, or both. This depends on what the sending service allows you to configure. DKIM is considered best practice. 

The domain is still vulnerable to impersonation. 

Sprucedata are an automotive company and have no DMARC policy. A threat actor, let's call them the Phish Me Group,  can send an email impersonating their domain.

This can be done by simply typing SMTP commands in a terminal window and communicating with recipient's email server. Conosco has created a script to automate the process. The impersonation is successful.

Security awareness training always teaches you to check the sender's address. As we can see this is correct from Phil at Sprucedata

Quarantine (p=quarantine)

Action: Accept the email but send to the recipient’s spam/junk folder (suspicious). 

Move to this first enforcement once you have identified your authorised sending services and have configured, and confirmed they pass DMARC authentication. If any fail, correct the issue. 

Domain impersonation is partially mitigated. 

Sprucedata are an automotive company and are on the DMARC journey. They have configured their authorised sending services for DMARC compliance while in monitor mode and have now moved to quarantine enforcement. A threat actor, let's call them the Phish Me Group attempt to impersonate Phil in finance.

Conosco use Mimecast as their Secure Email Gateway and have configured this to honour the senders DMARC policy. As we can see, the recipient receives a notification from Mimecast informing this message failed DMARC authentication and has been held. An administrator must release this suspicious message. Other email gateways are likely to send this to the recipient's spam folder.

Reject (p=reject)

Action: Do not accept the email, this isn’t from us! 

Only move to this enforcement once you are certain your authorised sending services are passing DMARC authentication. 

Domain impersonation is mitigated. 

Sprucedata are an automotive company and are on the DMARC journey. They have configured their authorised sending services for DMARC compliance, tested quarantine enforcement without issues and and now move to reject enforcement.

A threat actor, let's call them the Phish Me Group attempt to impersonate Phil in finance. Conosco use Mimecast as their Secure Email Gateway and have configured this to honour the senders DMARC policy. As we can see, this fails authentication and the email is immediately rejected.

DMARC Reporting

The following is an example of a minimum valid DMARC policy which Conosco has seen implemented by several organisations starting a DMARC journey.

v=DMARC1; p=none;

The problem here, no reporting mechanism defined to gain visibility into sending. You may as well have no DMARC policy at all.

A receiving server should at least send daily reports for messages from your domain which pass or fail authentication. These are known as aggregate reports and do not contain any Personally Identified Information (PII). Information includes the sending IP Address, the SPF, DKIM and DMARC results.

Example DMARC policy instructing the receiver where to send aggregate reports.  

v=DMARC1; p=reject; rua=mailto:dmarc@sprucedata.co.uk

Example of a raw aggregate report, which as you can see, are not human friendly readable:

Use an Email Domain Security (EDS) service capable of automating aggregate reports to gain valuable insights with meaningful actions.

Conosco Email Domain Security (EDS) Services

Due to the impact of COVID-19, numerous DMARC projects were temporarily side-lined in favour of more immediate business continuity initiatives. Regrettably, many organisations have since struggled to resume these vital projects amid a rise in domain impersonation attacks.

Many organisations are simply unaware this direct domain vulnerability exists or believe SPF with a reject mechanism (-all) mitigates the vulnerability. Perhaps you are aware but don’t know where to start.

Conosco’s managed Email Domain Security (EDS) services safeguard your business, employees, and customers against the financial ramifications and reputational harm stemming from email fraud and brand impersonation. Our experts do the work, so you don’t have to! 

What is included in Conosco EDS?

Domain-based Message Authentication, Reporting & Conformance (DMARC)

Outbound email security protecting your email communications from direct domain impersonation (spoofing), enabling receivers to determine whether a given message is from your authorised sending services, and what to do if it isn’t.

Brand Indicators for Message Identification (BIMI)

An emerging email specification for outbound email security which builds upon DMARC bringing your branded logo to the recipient’s inbox. Requires either DMARC quarantine or reject enforcement.

Mail Transfer Agent Strict Transport Security (MTA-STS)

Strengthens your inbound email security posture by enforcing encrypted connections between email servers, reducing the risk of interception, and tampering by malicious actors.

Mimecast (Secure Email Gateway)

As a trusted expert partner, Conosco conducts thorough policy health checks and delivers actionable recommendations to enhance your organisation's security posture.

We provide a shield for your organisation's email communications, ensuring that your messages are delivered reliably and protected against unauthorised access, impersonation, and cyber threats. Our team takes care of the intricate technical aspects, such as verifying the legitimacy of senders, protecting against email fraud, and encrypting your inbound emails for your peace of mind.

For a demonstration where we actively spoof your domain live on-call; complete the form below and someone from our team will reach out and schedule the call with you.  

FAQ 

Q: How does DMARC address the vulnerability of direct domain impersonation and enhance outbound email security? 

A: DMARC, which stands for Domain-based Message Authentication, Reporting & Conformance, is an industry-standard protocol designed to mitigate the inherent vulnerability of direct domain impersonation, also known as spoofing. It achieves this by allowing domain owners to publish a policy in their DNS that instructs recipients on how to handle unauthorized domain impersonation, such as messages failing authentication. DMARC builds upon existing email protocols, SPF (Sender Policy Framework) and DKIM (Domain Keys Identified Mail), by requiring that either SPF or DKIM passes authentication for an email to be considered authenticated. Additionally, DMARC ensures domain alignment, meaning the domain found in SPF or DKIM must match the domain in the "Message From" header that the user sees in their inbox. This multi-layered authentication process helps organizations enhance outbound email security. 

Q: What are the potential consequences for organizations that do not comply with PCI DSS v4.0, specifically regarding the new DMARC requirements? 

A: Non-compliance with PCI DSS v4.0, especially in relation to the new DMARC requirements, can have significant repercussions for organizations. The key milestones outlined in the article highlight the importance of adhering to these standards. Starting from June 2024, organizations must have a valid published DMARC policy, even if it is configured only for monitoring mode initially. By March 2025, mandatory compliance requires the DMARC policy to be configured with at least quarantine enforcement. While it is yet unknown the specific penalties for non-compliance, it is anticipated that services may refuse to process transactions, potentially impacting the organization's business and customer relations. 

Q: What are the specific challenges and risks associated with domain impersonation attacks? 

A: Domain impersonation attacks pose several challenges and risks for organizations. When a domain is registered, it is, by default, vulnerable to direct email impersonation, meaning anyone can send an email as that domain. This vulnerability exists even without stealing email account credentials through two existing email protocols, SPF and DKIM, which partially address outbound email security but have limitations. SPF, for instance, does not fully prevent unauthorized domain impersonation, and both SPF and DKIM lack reporting mechanisms. Without visibility into who is sending emails on their behalf and whether they pass authentication, organizations are left exposed to potential fraud. DMARC resolves these issues by providing a comprehensive policy in DNS, instructing recipients on how to handle unauthorized impersonation and offering reporting mechanisms for enhanced visibility into outbound email security.