Managing Incoming Mail Via Policies

Use Policies to specify what happens when messages meeting certain criteria are received by your organization. For example, you could write a Policy that finds all messages from a specific sending domain and notifies the recipient and an administrator. Or you could create a policy that moves suspicious messages to a quarantine folder (Enforcement customers only). The basic idea is to react to certain conditions (which you specify) in your incoming email traffic.

Possible actions include logging incoming messages for searching and reporting in the web UI (the default action), sending notifications (to the original recipients and/or designated admin users), moving the messages to a specific mail folder (Enforcement customers only), or even deleting a message entirely (Enforcement customers only).

The Policies page lists the existing Policies. From this page, you can create Policies, subscribe to System Notifications, and view the Event Log entries for Policies.

Creating a Policy

Creating a Policy is straightforward: specify criteria to match certain kinds of messages, and then set the action to be taken for messages which match those criteria.

A few important things you should know before creating a Policy:

• Every policy is evaluated for every message, and a single message can match multiple policies.
• Enforcement actions on a message that matches multiple enforcement policies will occur in the following priority order:
  1.  Inbox
  2.  Delete
  3.  Default folder move
  4.  Additional folder moves in the order set in organization enforcement settings
• You can create a policy with no notification or enforcement actions; all messages which match policies are logged in the Event Log and Reports.

Conditions

Enter criteria to match messages based on email header information, specifically: the From:, To:, and Reply-to: headers, the message Subject, and/or the sending domain. 

You can also specify Domain Tags to match here. Domain Tags are assigned on the Analyze > Domains page and discussed in Analyzing Incoming Email Traffic.

Additional criteria are available in the Advanced dialog (below).

Using Address Groups in Policies

You may want to specify a group of email addresses on which to match Policies. For example, you may want to create a policy that looks for email sent to any one of a group of executives. Rather than entering the names individually into multiple Policies, you can create an Address Group containing the list of names and then reference that Address Group in a single Policy.

One or more address groups can be referenced by a policy. Address groups can be used in the From, To, and Reply-To conditions of the policy.

You can create and manage Address Groups via the Manage > Address Groups page.

In the From: field:

Use an address group in the From: field of a policy condition when you want to detect imposters of the users in the address group. The condition will look for the address group members' names in the Display Name (i.e. Friendly From) of the From header. If a given From header does not use a Display Name, the condition evaluates the local part of the email address in the address group to see if it matches the email address in the From header.

For example, consider an address group containing the following address:

"John Doe" <jdoe@example.com>

• If a message is received From: "John Doe" <jdoe@not-example.com>, then the condition would match as an imposter of John Doe in the Friendly From and the action defined for the policy would be taken (alert, enforcement, etc.).

• If an inauthentic message is received From: "John Doe" <jdoe@example.com>, then the condition would match as an imposter of John Doe, because even though the real email address is used, it is not authentic. An action would be taken.

• If no Friendly From portion exists, the local part of the address is evaluated, so an address of <jdoe@example3.com> would match based on the local part of the email address in the From header matching.

In the To field:

Address groups will simply look for messages where the To field exactly matches an entry in the address group, ignoring the Display portion. A policy matching an address group in the To field might commonly be used along with other criteria like a Subject string match and Message Trust Score. For example, your policy conditions might be: To a member of the Finance address group, and Subject contains “Invoice,” and Message Trust Score is 0 - 4.9.  

Populating an Address Group

Populate your address group by entering a first name, last name, and email address for each user in the group. You can enter a user multiple times if, for example, the user has multiple internal email addresses.

Address group matching uses the first name and last name fields you enter when evaluating the "Friendly-From" portion of the email address. (In the example above "John Doe" is the "Friendly-From" portion; it is often this portion of the "To:" header which is visible on some Mail User Agents (MUAs) like Office365, Gmail, or the Mail app on iOS.)

Address Group Exceptions

Addresses in the exception list are for specifying "known good" or personal email addresses of the people in the address group to avoid false positives. For example, suppose that legitimate messages using your company's executives' names are sent from the address <yourco_announce@example.com>. You can add that to the exceptions list for the Executives address group. Now when an authentic message from <yourco_announce@example.com> is detected it will not fire an alert based on this address group. Addresses in the exceptions list are never tagged as imposters unless the message is inauthentic, and they are only considered when the address group is referenced by the From: and Reply-To: conditions.

• You can add addresses like messenger@webex.com or reply@chatter.salesforce.com so that when a user in your Address Group is spoofed legitimately, like "John Doe <messenger@webex.com>” or "John Doe <reply@chatter.salesforce.com>” the condition will not match.
• You can also add personal addresses like "johndoe@gmail.com" which may share the Friendly From of addresses above.
• Some email services make use of '+' addressing, per the sieve filtering standard.  In these cases, the local part of an email address will vary with a random text string after the '+' in the address which can cause problems for setting an exception in an address group.  For example "John Doe <notifications+2hef98h2uibf8h@yammer.com>".  In these cases, the address group matching will automatically ignore the '+' and all characters between the '+' and the '@'.  So you could simply add "notifications@yammer.com" to the exceptions list to ignore this so that it will not match on the John Doe display name.
• Some messages are automatically excepted from the address group display name matching by Agari.  For example, messages that pass authentication and come from a domain tagged as 'internal', 'partner', or 'service' will not be called an address group match.

Scoring

You can set a score threshold and whether to match Domains that are either Zero-Day or Imposter (or neither).

Advanced

Advanced criteria provide more granular scoring matches (authenticity, domain reputation, or SBRS ranges) as well as the option to match a specific IP Address.

Actions

Specify what Agari Phishing Defense should do when messages match this Policy.

Notify

You can specify who to notify and how to notify them (digest/etc.).

Notify original recipients will send an individual notification to all recipients of a message which matches the criteria. (Note that this could cause bounce messages, for example, if the Sensor parses a message and attempts to send a notification to a non-existent mailbox.)

Notify administrators will send either a single notification message for every matching message, or a single digest notification when the number of message matching a given policy exceeds a threshold you define. 

You can customize the global notification users receive via the Configure Policy Text for Original Recipients link on the Manage > Policies page.

Enforce

If you use O365 or G Suite as your mail store and have enabled Enforcement, you can choose to have matching messages deleted or moved out of the inbox and into a designated folder. You can also create a "whitelist" policy by choosing to move messages to the inbox when matching a set of policy conditions.  Note that enforcement action can be used in combination with a notification to the original recipients – so that end-users could receive a notification every time an Agari Phishing Defense policy moved a message based on a policy condition match. 

• Enforcement actions on a message that matches multiple enforcement policies will occur in the following priority order:
  1.  Inbox
  2.  Delete
  3.  Default folder move
  4.  Additional folder moves in the order set in organization enforcement settings (see Agari Phishing Defense Administrator and User Guide)

Getting Started with Policies

Out of the Box Policies

You will start out with nine default policies to match the most common conditions that Agari customers will catch with Agari Phishing Defense These policies need to be enabled to start matching messages and notify and/or enforce actions that need to be set up for the policies. It is recommended that you enable the policies with no actions first and after logging policy matches and monitoring results, then choose your notify and enforce actions. 

APD default policies:

Name	Conditions	Notes
Untrusted Messages	Message Trust Score is between 0 and 1.1	Catch all messages that Agari Phishing Defense has scored below the untrusted threshold.
C-Level Impostors	From: matches a Display Name in the address group C-Level Executives	Catch BEC attacks/ impostors of your CEO, CFO, and other top executives. Note that this policy requires you to populate the C-Level Executives address group, which is also created for you as a default address group.
Executive Imposters	From: matches a Display Name in the address group Executives	Catch BEC attacks/ impostors of other executives in your organization. Note that this policy requires you to populate the Executives address group, which is also created for you as a default address group.
Suspicious Messages to C-Level	To address: matches an email address in C-Level Executives Message Trust Score is between 0 and 3.0	Catch messages that are either untrusted or very suspicious and sent to one of your C-Level executives.
Rapid DMARC	Domain tag is "internal" Attack types include Domain Spoof	Catch spoofs of your own domains being sent to your employees.  This policy mimics a DMARC reject policy without the need to go through a long process of authenticating all sources.  Agari's trust models learn the authenticity of inbound sources.
Spoof of Partner Domains	Domain tag is 'partner' Attack types include Domain Spoof	Catch spoofs of your partners' domains
Brand Display Name Impostors	Attack types include Brand DNI	Catch brand impostors where common brands are spoofed in the display name.
Look-alike Domains	Attack types include Look-alike Domain	Catch imposter domains with intentionally similar names, things like agarii.com or paypa1.com.
Low Message Trust and Low Sender Reputation	Message Trust Score is < 2.5 SBRS score is < -2.0	Catch general spam and greymail that slips past your SEG.

The conditions in these default policies can be edited based on your experience and characteristics of your organization's mail flow. The out of the box conditions are based on what has been effective across the Agari customer base. 

Enable or Disable a Policy

To enable a policy, click the Policy Name on the index page (Manage > Policies) to get to the Edit Policy page.  At the top of this page, you will see the slider to enable the policy directly below the Policy Name.

Click Save to save your enabled policy.

 

Creating your own Test Policy

Let's get started creating that test policy. It's simple: you only need to enter three pieces of information.

1. On the Manage > Policies page, click Create Policy. Name the Policy and then enter your personal email address in the From: field and your company email address of your own inbox in the To: field.
   
   
   At this point, your Policy is finished. Note that we did not specify an action. The default action for all matched policies is to log the message in the Policy Log.
2. Click Create.
3. Send a message from your personal account to your company address.
4. On the Manage > Policies page, click the Policy Log tab. An entry in the log for your Policy and the message you just sent should appear. 
   
   
    

And that's it. You have successfully created a Policy to match incoming mail. 

Matching incoming messages based on conditions is a basic building block for creating a Policy. From here you can add more detail and complexity, matching subjects or specific domains or IP addresses. You can create Address Groups for matching groups of senders or recipients. You can specify a range of scoring options.

Next, you will want to specify actions to take on matched messages.

Specifying Actions

Now that you are comfortable creating Policies to match messages, it's time to specify what will happen when those matches occur. In addition to the default logging, you can also specify two other actions: Notify and Enforce (Enforcement customers only). Think of the actions as part of a spectrum: logging is the action with the lowest impact and followed by a notify action, and then enforcement at the highest end. So while you are coming up to speed on Policies, first try logging only, then notify just the Admin, then notify the message recipients, and then consider enforcing.

Enforcement customers: test your Policies before enabling Enforcement to ensure they are not too broad (overly broad Policies can lead to false positives).

How Are My Policies Working?

Once you have created some Policies you probably want some insight into the results. Are the Policies working as you expected? How many messages are matching? Is the number of matching trending upwards? etc. There are three places you can check for this kind of information. Policy Log is a running log of Policy matches, the Manage > Reports page is a view of aggregate Policy matches over time, and on the Search Messages page, you can search for Matched Policies.  

Event Log

Click the Policy Log tab on the Manage > Policies page to view the log of all Policy match and System Notification events. 

The Policy Log shows each Policy match as it happens. This is a list of Policy matches by message (one message per match). From the Policy Log, you can view the matched Policy by clicking the name of the Policy and you can view the message details for the message(s) matching the Policy by clicking the line in the Event column. You can also filter the Policy Log to show the matched messages for a specific policy. You can also choose whether to show System Notifications in this view. 

To see matches by Policy (all messages matching a Policy over a specific time period) use the Policy report via Manage > Reports.

Policy Report

The Manage > Reports page shows the summaries of Policy Events over time: how many matches for each Policy. 

• Click the Policy Name to review the policy conditions and actions from within the Policy editor.
• Click the number of messages (or the horizontal bar) to view a detailed Policy Report for that Policy.

The Policy Report shows the number of matches for the current day. You can expand the timeline by selecting a longer time period on the right. This view can show trends in matching for that Policy. Are more messages matching that Policy now? Fewer? Click on the number of messages in the Policy Report to view the messages in the Search Messages results.

Reporting on Enforcement

Select "with Enforce action" from the Show policies list to view a summary of the moved and not moved messages for all policies with the Enforce action.