Bringing Shield's Innovation Forward to CloudFilter
This summer, we are bringing a series of modern enhancements to CloudFilter, backed by Shield technology. These updates are part of our continued commitment to providing you with the latest innovations for threat mitigation so you can stay ahead of the curve.
New Impersonation Attack Detection
Impersonation attacks occur when a malicious actor pretends to be a trusted individual or entity to deceive someone into taking harmful actions, such as sharing sensitive information, transferring money, or granting access to secure systems. These attacks exploit social engineering techniques, leveraging trust and familiarity to bypass traditional security measures and trick recipients into believing they are engaging with a legitimate source.
​
With this release, we’ve added a powerful new security layer to CloudFilter to combat the increasing sophistication of impersonation attacks. This layer, built using Shield’s advanced technology, combines organizational insights and behavioral analysis to accurately detect and automatically stop these dangerous threats in their tracks.
​
We’ve heard your feedback that the process of building message rules and populating them with organizational information to block or quarantine messages is more manual than anyone wants it to be, including us. With this release, this process will now be real-time. For the best results, we encourage you to use the user sync feature to automatically populate your cross-platform directories into the new security layer.
​
Once a message is scanned and identified as having impersonation characteristics, a confidence level and risk score are assigned. In line with the behavior of other CloudFilter features, each result will have a default score that influences the decision on how the message is handled. We’ve also included controls for administrators to dial in the security all the way down to the individual user or across the board for all organizations.
There are two new results for impersonation:
This result indicates that the message contained characteristics frequently used to impersonate senders in the organization or the recipients themselves. By default, this result scores 200, triggering a quarantine decision. You can increase or decrease the scoring sensitivity of this result.
This result indicates that the message contained characteristics sometimes used to impersonate senders. These characteristics are lower confidence since some legitimate emails use them as well. By default, this result scores 0, but can be increased if desired.
​
This release enhances protection against the growing volume and sophistication of impersonation attacks. By leveraging Shield’s technology, CloudFilter now provides a more automated and precise approach to detecting and stopping threats, ensuring stronger security for all users without added effort.
New Customizable DMARC Enforcement
Domain-based Message Authentication, Reporting & Conformance (DMARC) plays a pivotal role in helping to prevent email spoofing and phishing by verifying the authenticity of the sender’s domain. DMARC also fosters trust among email recipients, ensuring that messages originate from verified sources.
​
A DMARC policy allows a sender to indicate that their messages are protected by SPF and/or DKIM, and tells a receiver what to do if neither of those authentication methods passes – such as quarantine or reject the message.
​
With this update, you now have complete DMARC enforcement capabilities to customize the behavior of CloudFilter to meet your customer’s security needs. By default, you will have a secure DMARC posture with sensible defaults.
​
There are six new DMARC results, and you can customize the sensitivity of five. The sixth result, a failure and reject policy, follows the DMARC policy set by the sender domain owner as intended by DMARC.
DMARC Authenticated
Messages that were successfully authenticated and allowed by DMARC policy.
​
This result means the message followed the DMARC policy originating from an authorized source (SPF) and/or contained a valid signature (DKIM). By default, this result scores 0 so it won’t affect decisions either way. You can customize this result and assign a negative (good) score from 0 to -200. This allows you to trust messages that pass DMARC authentication that may otherwise get filtered for other attributes.
Bad DMARC Policy
Messages where the DMARC policy was invalid or multiple policies were found in DNS.
​
This result doesn’t directly indicate a security risk, but it indicates a misconfiguration. By default, this result scores 0 so it won’t affect decisions either way. You can increase the scoring sensitivity of this result.
DMARC Not Available
Messages where the domain in the From header has no DMARC policy or the From header is missing.
This result doesn’t directly indicate a security risk. By default, this result scores 0, so it won’t affect decisions either way. You can increase the scoring sensitivity of this result.
DMARC Failed with Quarantine Policy
Messages where DMARC authentication failed and quarantine was the action suggested by the DMARC policy.
​
This is a significant authentication failure that indicates the message is not originating from an authorized source (SPF) and/or is not digitally signed (DKIM) as defined by the sender domain owner. By default, this result scores 200, which will trigger a quarantine decision. You can increase or decrease the scoring sensitivity of this result.
DMARC Failed with No Policy
Messages where DMARC authentication failed and no specific action was suggested by the DMARC policy.
​
This is a significant authentication failure and indicates this message the message is not originating from an authorized source (SPF) and/or not digitially signed (DKIM) as defined by the sender domain owner. By default, this result scores 100, which will not on its own trigger a quarantine decision but may contribute to the score enough to quarantine. You can increase or decrease the scoring sensitivity of this result.
DMARC Failed with Reject Policy
Messages where DMARC authentication failed and reject was the action suggested by the DMARC policy.
​
This is a significant authentication failure that indicates the message is not originating from an authorized source (SPF) and/or is not digitally signed (DKIM) as defined by the sender domain owner. CloudFilter enforces the policy set by the sender domain owner. The message will be bounced with an SMTP response explaining that it couldn’t be relayed due to a DMARC failure and reject policy.
​
With these enhancements, we are taking a significant step forward in improving security and reducing phishing and spoofing attempts.
New Threat Detection Engine and Spam Scoring Levels
The first innovation brought to CloudFilter from Shield is a new threat detection engine. This advanced engine significantly expands our ability to identify and neutralize email-based threats using high-performance message evaluation algorithms. These algorithms analyze the message characteristics and content to generate a probabilistic threat score. This intelligent engine is also continually trained on new data and can adapt quickly, protecting users from the latest attacks.
Inside the product, you will now see three new spam classification categories: obvious spam, spam, and possible spam. The sensitivity of each of these categories can be tuned within CloudFilter to give you complete control. The first two categories are designed to stop higher probability threats. By default, obvious spam will be held in the quarantine and not included in message reviews. Spam will be held in the quarantine and included in message reviews. And finally, the possible spam category allows you to quiet the noise caused by graymail. It will contribute to the message quality score by default but not trigger a quarantine alone.
