Cisco Email Security Solution Lab v2.0

Cisco dCloud
Cisco Email Security Solution Lab v2.0

Last Updated: 9-Dec-2020 dCloud: The Cisco Demo Cloud
IMPORTANT! This content is community developed and is not subject to standard dCloud verification or support. Please contact
dCloud Support for more information.
About This Demonstration

This guide for this preconfigured demonstration includes:
• Requirements
• About This Solution
• Topology
• Supporting Files
• Get Started
• Case Study
• Scenario - Protecting Against Malicious or Undesirable URLs
• Scenario - Outbreak Filtering
• Scenario - Forged Email Detection
• Scenario - Macro Detection
• Scenario - Graymail Detection
• Scenario - Advanced Malware Protection (AMP)
• Scenario - DomainKeys Identified Mail (DKIM)
• Scenario - Sender Profile Framework (SPF)
• Scenario - Domain-based Message Authentication, Reporting & Conformance (DMARC)
• Scenario - Sender Domain Reputation (SDR)
• Scenario - Consuming External Threat Feeds (STIX/TAXII)
• Scenario - DNS-Based Authentication of Named Entities
• Scenario - Mailbox Auto Remediation for On-Prem Microsoft Exchange
• Scenario - Search & Remediate Email Via Message Tracking
• Scenario - Single Sign On using SAML 2.0
• Scenario - Support for Unified Common Event Format (CEF) based Logging
• Scenario - Ability to Safe Print Message Attachments
• Scenario - Improved Phishing Detection Efficacy with Cisco Cloud URL Analysis (CUA)
Requirements
The table below outlines the requirements for this preconfigured demonstration.
Table 1. Requirements
Required Optional
● Laptop ● Cisco AnyConnect®
© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 143
Cisco dCloud
About This Solution

Cisco Email Security formerly Cisco IronPort Email Security, delivers industry-leading inbound and outbound email cleansing and
dCloud: The Cisco Demo Cloud
control, offering high availability email protection against the constant, dynamic, rapidly changing threats affecting email today in a
variety of form factors to fit customer needs.
Read the Email Security Overview for detailed information on Cisco Email Security features and benefits, available form factors,
Cisco differentiators, and more.
For additional information about Cisco Cloud Email Security, visit http://www.cisco.com/go/office365.
Topology
This content includes preconfigured users and components to illustrate the scripted scenarios and features of the solution. Most
components are fully configurable with predefined administrative user accounts. You can see the IP address and user account
credentials to use to access a component by clicking the component icon in the Topology menu of your active session and in the
scenario steps that require their use.
Figure 1. dCloud Topology
Item Description:
Workstation 1 A Windows based workstation that allow lab user to access other devices in the same topology
Attacker A Linux machine that act as the bad actor which send random email message to other devices.
Splunk A Linux machine that running Splunk Enterprise for CEF log storage and management
Cisco dCloud
Active Directory – In An Active Directory server which own and manage by the internal user (Alan)
mail-in An Exchange mail server which own and manage by the internal user (Alan)
Email Security Appliance 1 An email security gateway that own by the internal user (Alan) to protect against malicious emails
Email Security Appliance 2 An email security gateway that own by the external user (Ben) to send and received emails.
Ngsma A centralized management platform that own by Alan to manage ESA reporting, tracking & quarantine services.
Active Directory – Out An Active Directory server which own and manage by the external user (Ben)
mail-out An Exchange mail server which own and manage by the external user (Ben)
The logical topology for all lab scenarios is based on the following: -
Alan represents an internal user and uses Microsoft Outlook as his mail client. The corporate mail servers are Microsoft Exchange
which in turn forwards to the Cisco Email Security solution for policy control and email hygiene before routing messages.
Ben represents an external user located anywhere on the internet, Ben also uses the Microsoft Outlook client for managing his
mailbox, however the mail server platform used here is arbitrary.
Alan - alan@dcloud.cisco.com Ben - ben@dcloud-out.cisco.com
Cisco dCloud
Supporting Files
This lab uses supporting files within various scenarios; these are all located in the dCloud Files folder on the “Desktop” of the
Workstation.
NOTE: In some scenarios Security warnings may be presented warning the user to exercise caution when executing certain
supporting files, these are perfectly safe. All files that are classified as malicious are in fact benign and present no harm to any
environment.
Cisco dCloud
Get Started
BEFORE PRESENTING dCloud: The Cisco Demo Cloud
Cisco dCloud strongly recommends that you perform the tasks in this document with an active session before presenting in front
of a live audience. This will allow you to become familiar with the structure of the document and content.
It may be necessary to schedule a new session after following this guide in order to reset the environment to its original
configuration.
PREPARATION IS KEY TO A SUCCESSFUL PRESENTATION.
1. Follow the steps to schedule a session of the content and configure your presentation environment.
2. Initiate your dCloud session. [Show Me How]
NOTE: It may take up to 10 minutes for your session to become active.
3. For best performance, connect to the workstation with Cisco AnyConnect VPN [Show Me How] and the local RDP client on
your laptop [Show Me How]
Workstation 1: 198.18.133.36, Username: administrator, Passphrase: C1sco12345
NOTE: You can also connect to the workstation using the Cisco dCloud Remote Desktop client [Show Me How]. The dCloud
Remote Desktop client works best for accessing an active session with minimal interaction. However, many users experience
connection and performance issues with this method.
Cisco dCloud
Case Study
Aquae Flaviae dCloud: The Cisco Demo Cloud
Aquae Flaviae, mostly known as AQF, is a renowned company that creates innovative ways for people to move – on snow, on water,
on asphalt or dirt an even in the air. It’s headquartered is located in the sunny Mediterranean. AQF has been building on a tradition
of ingenuity and intense customer focus that goes all the way back to 1935, operating manufacturing facilities throughout the globe
with a total workforce of more than 72,500 employees. The company’s portfolio of industry-leading and distinctive products
comprises snowmobiles, several watercrafts, on- and off-road vehicles, recreational boats, pontoon boats, marine propulsion
systems, and extremely performant engines for karts and recreational aircraft. Support for all their product lines is assured with
dedicated parts, accessories and clothing business, to fully enhance customer’s experience.
Due to all the investment in vital areas of the business, most of its business model relies, nowadays, on electronic transactions with
key customers and suppliers with electronic mail pervasively being used for all communications between internal and external parties.
A large part of the employees’ operation has moved into their inboxes. On top of that, over 53 percent of the world’s email traffic
overall is spam or some sort of an attack, according to the most recent statistics. The company has, therefore, become very sensitive
about and protective of their email space and time.
The increasing number of ransomware, phishing/spoofing, and malware attacks coming into their mail systems and recent attempts
to spoof their most known domains as well as identity deception emails being sent to their C-level executives, all made brand
protection and protection against business email compromise (BEC) types of attacks a top priority. AQF is obviously keen on
investing in latest technologies that provide them with enhanced protections. Recently appointed Chief Information Security Officer
(CISO) – Luis Domingo, also the acting Data Protection Officer, ordered a review of all strategic communications systems starting
with what he labeled the most critical of them all, email, to better protect the organizations, its customers and partners, from privacy
and data breaches in today’s data-driven world.
Following a lengthy review of the leading players in the Secure Email Gateway (SEG) business as reported by the Radicati Secure
Email Gateway Market Quadrant 2020, as well as the 2019 Forrester Wavetm: Enterprise Email Security, both clearly showing
Cisco as a Leader in the Email Security Space, has led to the adoption of the Cisco Email Security (CES) solution as its email security
platform of choice for its ability to defend against today’s sophisticated attacks.
As a side note, AQF is currently using Microsoft Exchange to manage all email transactions and communications between internal
and external environments, however, have aggressively retiring on-premise infrastructure for Microsoft Exchange Online (EOL) aka
Office 365 since a year ago.
Security Solution
AQF opted for the Cisco Email Security Solution to run on their existing virtual platform. In order to remain as secure, AQF
invested in the following Cisco Email Security features: -
• Email Source and Content Inspections
• Advanced Malware Protection
• Anti-Phishing Protection
• Sender Authentication Mechanisms
Objective
This lab will run through a series of exercises to implement the necessary security controls to defend against todays sophisticated
attacks. Email remained a primary attack vector and given its importance to AQF, it is vital that all avenues are sufficiently
defended. Though not strictly required, it is, however, advisable that all scenarios are run in sequence.
Cisco dCloud
Scenario - Protecting Against Malicious or Undesirable URLs
Use Case dCloud: The Cisco Demo Cloud
The advertising department of AQF decided to work on a new campaign to make better use of how the company products are
advertised. Previously all advertising was limited to the popular computing journals. The director of advertising operations has
asked his team to make use of additional resources to drive the message home on AQFs products and services following a small
dip in services revenue.
Several advertising agencies were approached to understand better how AQF could advertise using on-line computing websites
and blogs. Sample adverts were placed on several sites and the results of the trial with weekly statistics were sent to the
advertising manager via email for review. One late afternoon, the advertising manager clicked on a link within an innocent looking
message, which resulted in his browser redirecting him to a website that downloaded, unknown to him at the time, some malicious
code that shut down critical services on his computer. Once this was reported to the in-house support team, the infected machine
as immediately removed from the network for cleansing and posture assessment; the whole process took a few days prompting the
introduction of URL Filtering technology.
Objective
This scenario will demonstrate how to protect against prohibited URLs within emails by leveraging the Cisco Security Proxy service
to ensure end users are not accessing websites that may be a source of malware or violation of company policy.
Steps
Task – Send an email with malicious URL
For this scenario, an external user Ben will send an email with a shortened URL to an internal user Alan, with and without the URL
filtering’s policy configured to see the effect on the end results.
1. Launch Microsoft Outlook from the taskbar of Workstation and prepare an email with the following parameters: -
From: ben@dcloud-out.cisco.com
To: alan@dcloud.cisco.com
Subject: URL Filtering Test
Body: https://bit.ly/2FPpLyp
2. Send the email - Force the synchronization process by clicking Send/Receive Folder or by pressing the F9 key.
3. Examine Alan’s inbox to verify receipt of the message. It should appear arrive correctly as sent with the potentially malicious
hyperlink present.
Cisco dCloud
4. Click the hyperlink within the message. It will then launch a browser with the site accessible, if this was a site that contained
malicious or phishing content the end user that clicked the link would be exposed and the damage could spread quickly
between across interconnected devices.
The next task configures the Cisco Email Security with the “Shorten URL filtering” feature to implement the necessary controls to
keep the end user away from expose to the undesirable content.
Task – Configure a Content Filter
This task will create a new content filter to identify potentially malicious URLs within email messages and take an appropriate
action on that message – replace URL with text message to stop the recipient from reaching to the unauthorized website.
1. From the workstation launch Google Chrome. Click the bookmark ESA1 and log in with the following credentials: -
Username: admin
Passphrase: C1sco12345
2. Upon successful authentication, the Cisco Email security landing page, My Dashboard will be presented.
3. Navigate to Mail Policies > Incoming Content Filters and click Add Filter.
4. Using the following settings configure the Conditions and Actions.
Cisco dCloud
Name: URL_Filter
Condition 1: - No condition is required in this lab scenario

Action 1: - URL Category > Gambling
- Check URLs within > All (Message Body, Subject and Attachments)
- Action on URL … body and subject > Replace URL with text message > [This is a prohibited URL]
- Action performed for URL in Attachment(s): Strip Attachment
- Custom Replacement Message: This document contains malicious URL
- Perform Action for: All messages
5. Click OK.
Cisco dCloud
6. Click Submit to apply the actions.
Task – Edit Incoming Mail Policy
Once the necessary content filter has been configured, it must be enabled to a Mail Policy to be effective.
1. On the ESA1’s GUI, navigate to Mail Policies > Incoming Mail Policies. Click within the Content Filters box of the Default
Policy.
2. Place a checkmark against the content filter URL_Filter created in the previous step to enable it.
3. Click Submit to create the content Filter and verify the policy.
Cisco dCloud
4. Once completed, commit your changes – click the yellow box at the top right corner . Give an optional comment and click
Commit Changes again.
Task – Enable URL Filtering
This task will request you to ensure the URL filtering option is enabled via CLI session.
1. From the workstation, launch PuTTy located on the taskbar and select ESA1 from the Saved Sessions and click Open,
acknowledge any security warning presented.
2. Log in using the credentials listed earlier in this document.

Username: admin
Cisco dCloud
3. Once logged in, issue the command websecurityconfig and press [Enter]. Please verify the URL Filtering is in Enabled
condition. If not change needed, press [Ctrl] + [C] buttons to exit this command.
4. Next, issue the command outbreakconfig and press [Enter]. Make sure the Outbreak Filters is already Enabled.
5. Type setup and remain all settings with its default value and type Y to the Do you wish to enable logging of URLs? This
setting will provide more details about URL Filtering rules activities in the mail log.
6. Once verified the settings, ensure the changes are applied by issue the command commit and adding optional comments if
desired. Type Y to save the current configuration for rollback.
Cisco dCloud
Task - Testing URL Filtering
With the pre-requisite configuration in place, the URL Filtering feature can be tested by re-sending an identical email to Alan from
external user Ben with an unauthorized URL within the body of the message.
1. Stay on the PuTTy session, issue the command tail mail_logs and press [Enter] on your keyboard. Leave this running in the
background and proceed to the next step.
2. From the workstation launch Microsoft Outlook and prepare a new message from Ben’s inbox with the following parameters.
Subject: URL Filtering Test
Body: https://bit.ly/2FPpLyp
4. Switch back to the CLI and notice how the content filter handled the message, the undesirable URL has been stripped and
replaced with a text message.
5. Navigate back to Alan’s inbox, notice the URL has now replaced with the text message [This is a prohibited URL].
Cisco dCloud
Task – Testing URL Filtering for Attachment
With the pre-requisite configuration in place, the URL Filtering for attachment feature can be tested by sending an email to Alan
from external user Ben with an unauthorized URL within the message attachments content.
1. Remain on the Microsoft Outlook. Prepare a new message from Ben’s inbox with the following parameters.
Subject: URL Filtering - Attachment
Body: URL Filtering - Attachment
Attachment: URL-Inside.doc - located on the desktop under the dCloud Files > URL Filtering sub-folder
3. Switch back to the CLI and notice how the URL_Filter content filter rule handled the emails attachment.
4. Navigate back to Alan’s inbox, open the message and confirm the attachment has been stripped and replaced with a text
message file (ATT00001.txt).
Cisco dCloud
Scenario - Outbreak Filtering
Recently the services arm of AQF launched a new catalogue of customised services for the retail sector to help them procure,
utilise and support the various IT products that they offer; this was launched on the back of a successful marketing campaign
where email was the primary method of communication for this launch.
A mailing list was used to send out the marketing emails, however all replies were sent to a marketing co-ordinator who was
responsible for gathering metrics of the campaign, unfortunately the marketing co-ordinator received an email containing
attachments and URL that at first glance appeared to be non-suspicious, however after clicking the link within the email an infected
payload was delivered to her personal computer that was not detected by the multiple anti-virus engines installed across the
company infrastructure.
Objective
This scenario will demonstrate how Outbreak Filters protects an organization from large-scale virus outbreaks and smaller, non-
viral attacks, such as phishing scams and malware distribution, as they occur. Unlike most anti-malware security software, which
cannot detect new outbreaks until data is collected and a software update is published.
Steps
Task – Create an Outbreak Filter Disclaimers
Text resources play an important role in policy configuration on the Cisco Email Security. For outbreak filters, they allow valuable
information and feedback to be displayed to users when the solution applies a policy that prevents an action from being completed.
Within disclaimers action variables can also be used to provide more specific information, for example with outbreak filters the
following action variables are available:
1. For this task, let’s create an Outbreak Filter Disclaimer.
2. On the ESA1’s GUI, navigate to Mail Policies > Text Resources and click Add Text Resource
3. Name the new disclaimer as OFDisclaimer
4. Choose Type as Disclaimer Template
Note: This type of disclaimer utilizes HTML text as well as action variables. When a text resource containing both HTML-based
and plain text messages is applied to an email message, the HTML-based text resource message is applied to the text/html part of
the email message, and the plain text message is applied to the text/plain part of the email message.
When an HTML-based text resource is edited, the GUI includes a rich text edit that allows the entering of rich text without having to
manually write HTML code.
Cisco dCloud
5. Add the following statement in HTML box as shown below:
6. Scroll down the page and click the Submit button to save the change.
Task - Configure Outbreak Filter setting
An Outbreak Filter rule is basically a Threat Level (e.g. 4) associated with a set of characteristics for an email message and
attachment — things such as file size, file type, file name, message content, and so on. For example, assume the Cisco Talos
notices an increase in the occurrences of a suspicious email message carrying a .exe attachment that is 143 kilobytes in size, and
whose file name includes a specific keyword (hello for example). An Outbreak Rule is published increasing the Threat Level for
messages matching this criterion.
The Cisco Email Security checks for and downloads newly published Outbreak and Adaptive Rules every 5 minutes by default. On
the solution, a threshold is set for quarantining suspicious messages. If the Threat Level for a message is equal to or exceeds the
quarantine threshold, the message is sent to the Outbreak quarantine area.
1. On the ESA1’s GUI, navigate to Mail Policies > Incoming Mail Policies and edit the Outbreak policy to modify messages.
Click the link under the Outbreak Filters column (Retention Time: Virus 1 day) to open the Outbreak Filters page.
2. Under the Message Modification section, place a check mark against the Enable message modification. This is required for
non-viral threat detection (excluding attachments).
3. Scroll down the page and look for URL Rewriting; select Enable for all messages.
4. Under Threat Disclaimer, choose OFDisclaimer
Cisco dCloud
5. Click Submit.
Task - Testing Outbreak filters
To demonstrate how the Outbreak Filter works, send an email from Ben to Alan, this simulates a message coming into the
organization from an external user as per our earlier topology.
1. From the workstation, launch PuTTy located on the taskbar and select ESA1 from the Saved Sessions and click Open.
2. Issue the command tail mail_logs and press [Enter] on your keyboard. Leave this running in the background and proceed to
the next step.
3. Launch Outlook from the desktop, create an email from Ben’s mailbox with the following parameters:
Subject: Photos
Body: Outbreak Filter Test
Attachment: photo.voftest - located on the desktop under the Outbreak Filtering sub-folder
Send the email - Force the synchronization process by clicking Send/Receive Folder or by pressing the F9 key.
Cisco dCloud
NOTE: The attachment contains enough information to trigger an action from as Outbreak Rule ID 190 is in fact a system test,
verify this in Security Services > Outbreak Filters
4. Navigate to the PuTTy shell which you have initiated previously and look for the message that implies the message has been
quarantined. Note, the Threat Level of 3, this indicates that either the message is part of a confirmed outbreak or there is a
medium to large risk of its content being a threat, also note how the anti-virus engines delivered a clean result.
5. Make note of the MID and note what final action was applied to the message – Quarantine.
6. Return to Outlook client and click the Inbox for Alan. The message will not be present since it has been quarantined by our
content filter created earlier.
7. Return to ESA1‘s GUI. Navigate to Monitor > Policy, Virus and Outbreak Quarantines (scroll to the end of the menu list)
and note there is a message now in the Outbreak quarantine.
8. Click the value in the Message Column to view the message, note the reason it was quarantined.
9. Note the subject header, place a checkmark against the message and click the Release button.
Cisco dCloud
10. Click Confirm to acknowledging the action when prompted.
11. Navigate back to the outlook client and force the mailboxes to synchronize, the message will now appear in Alan’s inbox and
the subject header has been prepended as per our policy and warning information applied to the body of the file advising the
recipient to exercise caution.
Cisco dCloud
Scenario - Forged Email Detection

Business leaders congregated for a conference to discuss the next generation of Internet of Things (IoT) challenges the customers
of AQF and its partners will potentially face over the coming years in order to address the rapid acceleration connected devices
and the security challenges that will unfold. AQF see this as great opportunity to gain further market share with their current
offerings and mandated that key members of the business development team attend. Several market researchers were present
and additional information that was needed on the back of key meetings was to be distributed after the event by email.
On return from the event, the director of operations reported receiving an email demanding immediate payment for an overdue
invoice. Upon closer examination of the request, additional confirmation of its authenticity was sought, and it then materialised that
this request was not legitimate.
Objective
This scenario demonstrates how Forged Email Detection (FED) protects a selected targeted user or group (typically executives
that have high levels of corporate access, fiduciary and financial control) from phishing attacks. Low volume, targeted threats can
be difficult to detect. Forging, or spoofing email is easy to do. It can be done from within a LAN or from an external environment
using Trojans. Forged email is often used in spam and phishing campaigns.
Steps
Task - Sending a Spoofed email
This task will demonstrate what a potentially forged email looks like and how easy it is to craft and send using basic skills. At first
glance as the message lands in the mailbox of the indented target it can look like the email has come from the spoofed sender.
1. From the workstation launch Microsoft Outlook and prepare a new message from Ben’s mailbox with the following parameters.
From: crobbins@cisco.com
Subject: FED Test
Body: FED Test
3. Examine Alan’s inbox to verify receipt of the message. It should appear as if it has indeed come from Chuck Robbins at first.
Cisco dCloud
Task - Creating a Content Dictionary of Terms
The first task in tackling this undesired behavior is to create a content dictionary containing the names of high-profile figures that
are most likely to be targeted by this type of attack.
Content dictionaries are groups of words or entries that work in conjunction with the “Body Scanning” feature on the solution and
are available to both content and message filters. Dictionaries can also be used to define to scan messages, message headers,
and message attachments for terms included in the dictionary in order to take appropriate action in accordance with your corporate
policies. This task will create a content dictionary to list the names of potential targets internal to your organization.
1. On the ESA1’s GUI, navigate to Mail Policies > Dictionaries from the resulting window, click Add Dictionary - this will
create the custom dictionary with the names of the identified users.
2. Populate the dictionary with the following information:

Name: Execs
Add Terms: crobbins

chuck robbins
CEO
CFO
CIO
CISCO
NOTE: Multiple terms can be added to the dictionary in one go by separating each term with a line break
Cisco dCloud
3. Click the Add Button to add the terms to the dictionary.
4. Click Submit to create the dictionary.
5. Once completed, commit your changes - click the yellow box at the top right corner . Give an optional comment and click
Task - Create a Disclaimer Template
This task will create a warning that is presented to the recipient of the email with custom text advising them of potential
inconsistencies within the email message.
1. Navigate to Mail Policies > Text Resources and click Add Text Resource
2. Name the new disclaimer as SpoofWarning
3. Choose Type as Disclaimer Template
4. Add the following statement in HTML box as shown below:
Cisco dCloud
5. Click the Submit button.
Task - Configuring a Content Filter
Similar to Outbreak Filters in the previous scenario, content filters allow for granularity in policies to identify content. This task will
create a new content filter and use the content dictionary created in the previous step.
1. Navigate to Mail Policies > Incoming Content Filters and click Add Filter using the following settings configure the
Conditions and Actions.
Name: FED_Spoof
Condition 1: Forged Email Detection > Content Dictionary: Execs > Similarity score: 70
Action 1: Add/Edit Header > Header Name: Subject > Prepend … Existing Header: [Possibly Forged]
Action 2: Add Disclaimer Text > Choose: Above message (Heading) > Select Disclaimer Text: SpoofWarning
Action 3: Forged Email Detection
Cisco dCloud
2. Click OK.
3. Click OK.
Cisco dCloud
4. Click OK.
5. Click Submit to create the content Filter.
Task - Edit Incoming Mail Policy
The final task is to modify the default incoming mail policy, so the content filter comes into effect.
1. Navigate to Mail Policies > Incoming Mail Policies and click within the Content Filters box of the Default Policy.
2. Place a checkmark against the content filter FED_Spoof created in the previous step to enable it.
5. Finally verify the Default Policy has the FED_Spoof has been added.
Cisco dCloud
Task - Testing Forged Email Detection
With the configuration in place, the Forged Email Detection feature can be tested by repeating the first task that was carried out for
this scenario, once again sending a message with exactly the same text.
the next step.
3. Return to the Microsoft Outlook and prepare a new message from Ben’s inbox with the following parameters.
From: crobbins@cisco.com
Subject: FED Test
Body: FED Test
5. Examine Alan’s inbox to verify receipt of the message. It should appear as if it has indeed come from crobbins at first glance,
however some modifications should now be evident from what was observed from the first task.
6. Firstly, the Friendly From: header from the forged message has been replaced with the Envelope Sender.
7. The Subject header has been modified – prepended with additional custom text to advise the mail recipient immediately that
there is something not right about this incoming message. Secondly, when opening the message, a disclaimer has been
added advising the mail recipient to exercise caution when responding to this message.
Cisco dCloud
8. Navigate back to the CLI window and note how this type of message is handled by the FED service.
Cisco dCloud
Scenario - Macro Detection

AQF recently starting taking new custom from a newly formed organization across the state, this was seen as a potentially key
account going forward and the sales team insisted that all orders were processed quickly in order to remove any risk this company
would seek to conduct its business elsewhere having experienced delays with their previous partner.
The average on boarding time for a new account is between 5-10 business days; this involved getting the account registered with
the credit system as well as completes the necessary due diligence by the in-house legal teams prior to the online portal
registering the customer for internet access.
To prevent any further delays and risk losing the business the regional account director asked for all orders in the interim to be
accepted by email, citing the strategic importance of the account as a reason to expedite the process. Orders were sent via email
for the first two days to a sales order analyst without any issue, one morning an email containing a Microsoft Excel file was
received and opened and immediately caused local host instability, upon closer examination the local support teams declared the
infected computer inoperable as the TrojanDownloader: W97M/Adnel infection had hidden itself inside a macro within that
document that once opened spread very quickly. Immediately a decision was made to no longer accept messages with macro
enabled attachments.
Objective
The Cisco Email Security Solution provides the ability to filter attachments, detect advanced malware and to scan for macro-based
threats in attachments. The macro detection feature is designed to detect such macros using Content or Message filters. This
scenario walks through the configuration of the macro detection feature within the Cisco Email Security to drop potentially
malicious macro embedded files.
Steps
Similar to other lab scenarios, content filters help us get granular in policies to identify content. This task will create a new content
filter to identify macros in documents and subsequently remove them from the email message.
1. Access the ESA1’s GUI and navigate to Mail Policies > Incoming Content Filters and click Add Filter.

Name: Macro_Detection
Condition 1: - Condition is not required for this lab scenario.
Action 1: - Strip Attachment with Macro > Available File Types > Microsoft Office Files, OLE File Types
- Custom Replacement Message (Optional) : MACRO DETECTED
3. Click Add Action.
Cisco dCloud
4. Click OK.
1. Access to the ESA1’s GUI. Navigate to Mail Policies > Incoming Mail Policies and click within the Content Filters box of the
Default Policy.
Cisco dCloud
2. Place a checkmark against the content filter Macro_Detection created in the previous step to enable it.
3. Click Submit to create the content filter and verify the policy.
Task - Testing Macro Detection
With the entire configuration in place, the Macro Detection feature can be tested by sending an email to Alan from external user
Ben which contains an attachment that has a Macro within it.
2. Login the CLI session with username: admin and passphrase: C1sco12345
the next step.
4. Launch Microsoft Outlook and prepare a new message from Ben’s inbox with the following parameters.
Subject: Macro Detection Test
Body: Macro Detection Test
Attachment: ExcelMacro.xls.safe - located on the desktop under the Macro Detection sub-folder
Cisco dCloud
6. Open the message and confirm the attachment has been stripped and replace with text message (ATT00001.txt).
7. Navigate back to the ESA1’s CLI to observe the underlying mail processing and why the file was removed. Make a note of the
MID.
Cisco dCloud
Scenario - Graymail Detection

Since the investment in the Cisco Email Security Solution by AQF, the volume of messages classified as SPAM have decreased
markedly with most users reporting a high level of satisfaction in a recent internal survey. The control of threat within email
messages has also improved significantly with a sharp drop in reported incidents following the implementation of multiple security
measurements.
A handful of users however have complained that they receive messages from company websites that they once signed up for, an
example being the manager of enterprise accounts who regular receives email from Netflix, this was initially a service that he had
subscribed to, however is now looking to remove himself from that particular mailing list or at least have the message classified
appropriately making it easy to identify within his busy mailbox.
Objective
Graymail messages are messages that do not fit the definition of spam, for example, newsletters, mailing list subscriptions, social
media notifications, and so on. These messages were of use at some point in time but have subsequently diminished in value to
the point where the end user no longer wants to receive them.
The difference between graymail and spam is that the end user intentionally provided an email address at some point (for example,
the end user subscribed to a newsletter on an e-commerce website or provided contact details to an organization during a
conference) as opposed to spam, messages that the end user did not sign up for.
This scenario will demonstrate, through simulation, how Graymail messages are classified and processed by the Cisco Email
Security Solution.
NOTE: The graymail management solution in the Email Security appliance comprises of two components: an integrated graymail
scanning engine and a cloud based Unsubscribe Service. The graymail scanning engine is part of the base operating system, and
additional license is required to use the unsubscribe service.
Steps
Task - Customise Graymail Classification
This task will review these and make a subtle change to one.
1. Access the ESA1’s GUI and navigate to Mail Policies > Incoming Mail Policies. Click within the Graymail box of the Default
Policy to launch the Graymail settings
Cisco dCloud
2. Click Yes to Enable Graymail Detection for This Policy.
3. Check against Action on marketing, social network and bulk email respectively.
4. Click Submit to apply the changes.
Cisco dCloud
Task - Simulate Graymail
In order to see the effect of the Graymail engine, this task will simulate the sending and processing of a Netflix message that would
be categorised by the engine as Bulk.
the next step.
4. From the workstation’s Desktop, navigate to the folder dCloud File > Graymail_Detection and verify the presence of
graymail-exec.bat file. Double-click on this batch file.
5. Navigate to the CLI and note how the graymail engine classifies this type of message.
6. From the desktop navigate back the outlook client and synchronize the mailboxes. The message from Flash Sale will now
appear in Alan’s inbox, note the subject header, this has now been modified as per the previous task.
NOTE: The second part of this feature is Safe Unsubscribe, which provides an easy mechanism for end users to unsubscribe from
unwanted messages using Unsubscribe Service.
Cisco dCloud
Scenario - Advanced Malware Protection (AMP)
A third-party finance company recently launched a campaign offering competitive rates of credit to business within the state that
wish to invest in next generation date centre equipment. The campaign was sent to all eco-partners that had a high gross spend in
the previous 12 months; AQF came under this classification. A marketing assistance received one of campaigns emails, however,
unbeknownst, it contained malicious payload that rendered her computer temporarily inactive. The installed Anti-Virus solution was
sufficiently configured, and signature updates were set as per the recommendation of the developers of the software, however the
threat manage to evade this traditional but hardy layer of defence.
Objective
This scenario will demonstrate the File Reputation and File Analysis features of AMP by checking the reputation of a file and then
sending it for File Analysis to the Cisco AMP cloud to deliver a verdict, whilst the file has been sent for a disposition the email
message to the recipient will be held in quarantine.
Steps
Task - Edit the AMP Policy
Firstly, edit default policy to modify the action that will be applied to messages which have files that have been sent for analysis to
the Cisco AMP cloud.
1. From the workstation, access the ESA1’s GUI and navigate to Mail Policies > Incoming Mail Policies and click within the
Advanced Malware Protection section of the Default Policy.
2. Verify that File Analysis is enabled; this allows any qualifying file that has an unknown disposition to be redirected to the
Cisco Cloud Analysis Service for expert analysis and produce threat score.
3. Scroll down towards the Message with Malware Attachments and choose the Action Applied to Message is Drop Message
Cisco dCloud
4. On the Message with File Analysis Pending section and make sure the Action Applied to Message is Quarantine
5. Click Submit
Task - Create a Malicious File
To simulate this type of analysis, a benign file is generated and used within an email coming into the organization. The file itself is
not capable of doing any harm, however the Cisco AMP file treats this malicious test file and performs the same actions on it as if it
was carrying payload that is malicious.
1. Navigate to the desktop of the workstation, locate and open the folder called dCloud Files, open the folder and then open the
sub-folder named AMP.
2. Open the file Make Malware.bat by double clicking it; Acknowledging the Run button when prompted. If run successfully a
second file will be present named malware.exe.
Task - Send a Message with a potentially malicious file
Now that a file that contains malicious payload has been generated a file, send a message from Ben to Alan with malware.exe as
an attachment, this is sufficient to trigger the AMP engines and provide the required disposition.
Cisco dCloud
the next step.
Subject: AMP Test
Body: AMP Test
Attach: Attach malware.exe; located on the Desktop under the dCloud Files > AMP sub folder.
5. Send the message – Microsoft Outlook will display a warning about unsafe files, click Yes to ignore this.
6. Force the synchronization process by clicking Send/Receive Folder or by pressing the F9 key.
Task - Monitoring AMP
1. Navigate to the ESA1’s CLI session and wait for the logs to scroll, it may take a few moments for the screen to refresh with
fresh activity. The first point of interest here is what happens once the Anti-Spam and Anti-Virus engines pass their verdict.
2. The highlighted line below and the one prior to that shows the file reputation verdict – UNKNOWN therefore the file will be sent
for further analysis, also note that a SHA256 has been assigned.
3. Make a note of the MID.
4. The next point of interest is what happens to the file whilst a finalised verdict is returned.
Cisco dCloud
NOTE: It can take about 15 ~ 20 minutes for the verdict to be returned, leave the CLI window running and proceed to the next step,
or take a bio break!
5. Navigate to Monitor > Policy, Virus and Outbreak Quarantines, the message is now quarantined as per the configured
AMP policy while a verdict of its disposition is returned from the AMP File Reputation service.
6. Navigate to Monitor > AMP File Analysis, note the file is not analysed yet as indicated by the Interim Disposition.
7. After waited for more than 15 minutes, navigate back to the CLI session to check the latest verdict. Note the time between
when the file was sent for analysis and when the verdict was returned and finally the final action.
8. Navigate back to ESA1’s GUI and select Monitor > AMP File analysis, the verdict will now be presented here too.
9. Click on the SHA to get more details of the perceived threat and the various threat levels assigned to the file.
Cisco dCloud
10. Finally, click the link to the Cisco AMP Threat Grid to get details of the full analysis.
11. This will redirect to the Cisco AMP Threat Grid portal to get a detailed analysis of what caused this file to be malicious.
Cisco dCloud
Task - Send a Message with a benign file
The improved pre-classification engine for AMP has significantly reduce number of files that need to be sent for analysis be making
an early decision within the Cisco Email Security solution if the files contain any dynamic content that may compromise and end
user.
the next step.
Subject: AMP Pre-classification Test
Body: AMP Pre-classification Test
Attach: Attach the following file Text_File.txt - located on the desktop under the dCloud Files > AMP sub-folder.
Cisco dCloud
5. Send the message. Force the synchronization process by clicking Send/Receive Folder or by pressing the F9 key.
Task – Monitor AMP Actions Against a Text File
This task will demonstrate how a plain text file are handled by the Cisco Email Security, especially the enhanced AMP pre-
classification engine.
fresh activity. The first point of interest here is what happens once the Anti-Spam and Anti-Virus engines pass their verdict.
2. The highlighted lines below and the one prior to that shows the file reputation verdict – LOWRISK therefore it will not be sent
for further analysis but immediately forward the remaining inspection layers in the same inbound mail policy.
3. Voyage Corp The AMP log reveals the query responded from AMP Cloud and determined no active or dynamic content exists
in this text file, hence will not be uploaded for analysis.
4. Navigate back to Alan’s inbox and synchronize the mail client by clicking the Send/Receive Folder button or pressing the F9
key 2-3 times.
5. As the disposition set to LOWRISK, the email with Text_File.txt as an attachment will be delivered to Alan’s mailbox, this is
expected behaviour.
Cisco dCloud
6. Return to ESA1’s GUI, navigate to Monitor > Advanced Malware Protection report and from the summary of files handled
by AMP, a LOWRISK disposition incident has been recorded.
Task – Edit the Threshold Score
This task will demonstrate how the Cisco Email Security allow you to set the upper threshold limit for the acceptable file analysis
score in the Advanced Malware Protection (AMP) feature. The files that match the custom score range will be blocked and treated
as Custom Threshold in the Incoming Malware Threat File section of the AMP report.
1. Remain on the ESA1’s GUI, navigate to Security Services and click File Reputation and Analysis. Click Edit Global
Settings.
2. Expand the Threshold Settings section. Select Enter Custom Value and insert 50
Cisco dCloud
3. Click Submit.
Task - Send a Message with an unknown attachment
Now send a message from Ben to Alan with a freshly constructed file as an attachment, which will suffice to trigger the AMP
reputation scanning and provide the required disposition.
the next step.
Subject: Custom Threshold Test
Body: Custom Threshold Test
Attach: Attach the file custom.pdf - located on the desktop under the dCloud Files > AMP sub-folder.
Cisco dCloud
5. Send the message. Force the synchronization process by clicking Send/Receive Folder or by pressing the F9 key.
Task – Monitor AMP Actions Against the attachment
This task will demonstrate how this attachment is handled by the Cisco Email Security Solution and specially by AMP reputation
cloud service.
1. Navigate to the ESA1’s CLI session and wait for the logs to scroll.
2. The highlighted lines below and the one prior to that shows the file reputation verdict – MALWARE therefore immediately drop
the message by AMP.
3. Press [Ctrl] + [C] button to exit the tail mail_logs command.
4. Remain in the same CLI session, issue the command tail amp and press [Enter].
5. The AMP log reveals the query responded from AMP Cloud that it able to returns a reputation score as the file verdict status is
already available with the File Analysis server, hence will not be uploaded for analysis.
6. Since the File Analysis score has exceeded the custom threshold score (50), the message attached with this file will be drop
immediately by AMP itself in the mail policy.
Cisco dCloud
7. From ESA1’s GUI session, navigate to Monitor > Advanced Malware Protection report and from the summary of Incoming
Malicious Files by Category, a Custom Threshold incident has been recorded.
8. On the same reporting page, scroll down and look for Incoming Malicious Threat Files section.
9. Click on the SHA to get more details of the perceived threat and behavioural indicators assigned to the file.
Cisco dCloud
Scenario - DomainKeys Identified Mail (DKIM)
Luis and his department conducted a thorough security assessment of their email communications infrastructure. One area of
concern was the number of phishing attempts over a 3-month period, targeting specific employees. End user awareness and
training has increased and employees are in a better position to spot potentially spoofed messages, however a decision was made
to further enhance security by deploying additional technologies namely, Sender Policy Framework (SPF), Domain Keys Identified
Mail (DKIM) and Domain-based Message Authentication, Reporting & Conformance (DMARC).
Despite SPF being the most straightforward technology to deploy, the messaging team have concerns that given how vast their
messaging infrastructure is that they may not be fully aware of all legitimate sources of email for the company’s domains.
The messaging infrastructure consists of multiple 3rd party affiliates sending email on behalf of AQF, these messages are typically
newsletters, special promotions and even confidential email that may be encrypted. Given this widespread use and to prevent mail
flows from breaking a decision is made to implement DKIM, which does not require any external dependencies. Unlike SPF which
is a path-based technology, DKIM allows for messages to be signed thus vouching for their authenticity.
Objective
In brief, DKIM uses a cryptographic stamp to authenticate message senders. With DKIM, a digital signature is inserted into the
message headers of an email message, this is in the form of a public and private key pair.
The public key from the pair is published in a DNS text record that is publicly accessible and the Cisco Email Security
authenticates the message by extracting the sending domain from the email, retrieving the public key from the DNS text record and
validating the signature against the message’s contents. Cisco Email Security allows administrator take actions based on the result
such as to drop, quarantine, notify administrator.
This scenario will demonstrate how DKIM signing can protect against spoofing of the email content (both body and headers) by
adding a cryptographic hash the entire email. If the outgoing email passes the DKIM verification, the email recipient can be
confident has not been modified for fraudulent purpose whilst in transit.
Steps
Task – Configuring DKIM Key Pair (Sender – ESA2)
The first task is to generate a public and private key pair to be used for signing outgoing messages. The public key is published in
the DNS TXT record and the private key is stored and made available in Cisco Email Security to sign the outgoing messages.
1. On the Chrome browser, click ESA2 bookmark to access to the GUI of ESA2 with the following credentials:
Username: admin
2. Navigate to Mail Policies > Signing Keys and click Add Key. Name the key as DKIM_Key. Choose Generate and select key
size – 1024 Bits.
Cisco dCloud
3. Click Submit
Task – Create DKIM Signing Profile (Sender – ESA2)
This task identifies which parts of the email are to be included in the signing process, this can be either the whole message body or
just specific field of the email headers. The key pair created on the previous task will be referenced by a selector so DKIM verifiers
can differentiate between keys. All outgoing messages that match the domain defined in the profile will be signed and have a DKIM
signature inserted into them.
1. Remain on the GUI of ESA2 from previous task. Navigate to Mail Policies > Signing Profiles and click Add Profile. Enter a
name for this profile as DKIM_Profile and choose Domain Key Type as DKIM. Additional options will appear on the page.
2. Enter the Domain Name as dcloud-out.cisco.com and enter the Selector as lab. Keep both headers and body’s
canonicalization options as Simple and select the custom signing key DKIM_Key in the drop-down list.
Cisco dCloud
3. Remain other options as default setting. Type dcloud-out.cisco.com in the Add Users box and click Add to join this domain
to this profile.
4. Click Submit and commit your changes – click the yellow box at the top right corner . Give an optional comment and click
5. In the DNS Text Record column of the new signing profile, click the Generate link to show the DNS text record.
6. Copy the DNS Text Record. You will need to use it to create a new TXT record on DNS server that belongs to the sending
domain which we will conduct in the following task.
7. After copied the record, click Done.
Cisco dCloud
Task – Create a DKIM Record (Sender – ESA2)
DKIM record contain the public part of the cryptographic key used to sign the email. The recipient will use this record to confirm
that an incoming message which came from the sending server is valid.
1. From the workstation launch RDC located on the taskbar. Type the Computer as ad-out.dcloud-out.cisco.com and click
Connect to remotely access the DNS server.
2. Log in using the credentials below, acknowledge any security warning presented. Once logged in, click the DNS icon (on the
Desktop) to launch the DNS manager interface.
Username: DCLOUD-OUT\Administrator
3. Double-click Forward Lookup Zones and select dcloud-out.cisco.com. Right-click and choose Other New Records from
the list.
Cisco dCloud
4. Scroll the drop-down list to the end, select Text (TXT) and click on Create Record …
5. Enter the Record Name as lab._domainkey and paste the string v=DKIM1; p=MIGf … AQAB; (without quotes) which you
have copied from the ESA2 into the Text box. (Please refer to the screenshot below).
6. Click OK.
7. Once complete, click Start menu and Log Off Administrator to exit the remote desktop session.
Cisco dCloud
8. On the workstation, launch Command Prompt location on the desktop, and type the following command line: nslookup –q=txt
lab._domainkey.dcloud-out.cisco.com to verify the DKIM record.
9. Return to GUI of ESA2. In the Test Profile column of the new signing profile, click the Test to make sure the DKIM record
was created appropriately.
10. You should notice a text message Success – Published public key matches domain profile prompted above the profile.
Task – Enable DKIM Signing (Sender – ESA2)
At this point, the sender should be ready to enable DKIM signing on an outgoing mail flow policy. This functionality allows for the
email to be signed by a DKIM private key and sent out as to email receivers.
1. On the GUI of ESA2, navigate to Mail Policies > Mail Flow Policies and choose the listener Private 198.18.133.147:2525.
Click on the RELAYED mail flow policy name.
2. Scroll the page down towards the Security Features section, enable DomainKeys/DKIM Signing by selecting On.
Cisco dCloud
3. Click on the Submit at the bottom of this page and commit your changes – click the yellow box at the top right corner . Give
an optional comment and click Commit Changes again.
Task – Enable DKIM Verification (Recipient – ESA1)
Now that we have DKIM signing working, it’s time to enable DKIM verification. The receiving Cisco Security Email (ESA1) will
retrieve the public key from the DNS record of the domain taken from the signature and use that key to match the messages DKIM
signature to determine its validity. If the DKIM signature passes the verification test, the message will continue on to the next step
in the regular delivery process. This feature helps to ensure not only that a message is coming from the purported sender, but that
it hasn’t been modified between the time it was signed and when it was delivered to recipient.
1. On the Chrome browser, access the GUI of ESA1. Navigate to Mail Policies > Mail Flow Policies and choose the listener
Public 198.18.133.146:25. Click on the Default Policy Parameters mail flow policy name.
2. Scroll the page down towards the Security Features section, enable DKIM Verification by selecting On. Please be note that
a pre-defined DKIM verification profile (DEFAULT) is already available on the Cisco Email Security.
Cisco dCloud
3. Click on the Submit at the bottom of this page and commit your changes – click the yellow box at the top right corner . Give
an optional comment and click Commit Changes again
Task - Configuring a Content Filter (Recipient – ESA1)
In this task, a new content filter will be created to apply an action based on the result of the DKIM signature test in the receiving
email server. For example, the DKIM signed message might be dropped or quarantined if the signature found not match during the
DKIM verification process.
1. Remain on the GUI of ESA1 from previous task. Navigate to Mail Policies > Incoming Content Filters and click Add Filter.

Name: DKIM_Verification
Conditions: - DKIM authentication > Is not > Pass
Action 1: - Add / Edit Header

- Header Name: Subject
- Prepend to the Value of Existing Header: [DKIM FAIL]
3. Click OK
Cisco dCloud
4. Click OK
Task - Edit Incoming Mail Policy (Recipient – ESA1)
1. Navigate to Mail Policies > Incoming Mail Policies. Click within the Content Filters box of the Default Policy.
Cisco dCloud
2. Place a checkmark against the content filter DKIM_Verification created in the previous task to enable it.
Task - Testing DKIM (Sender and Recipient)
With all the configuration in place, both DKIM signing and verification features can be tested by sending an email to Alan from an
external user with email address ending with @dcloud-out.cisco.com.
1. Prior to preparing the message, initiate a connection to both ESA1 and ESA2 from the CLI in order to view, using the tail
command (tail mail_logs), the mail logs to see the message being processed and the actions being applied as it works its
way through the pipeline.
Cisco dCloud
2. From the workstation, launch Microsoft Outlook and from Ben inbox, prepare a new message with the following parameters.
Subject: DKIM Testing
Body: DKIM Testing
3. Send the email - Force the synchronization process by clicking Send/Receive Folder or by pressing the F9 key
4. Switch to the CLI of ESA2. Notice how the DKIM profile found the sender matched the email domain and signs the message
before initiate the delivery to destination host.
5. Next, take a look at the CLI of ESA1, note the message has been received with DKIM verification as Pass as the result.
6. Return to the workstation, synchronize the messages once more and the message will now appear in Alan’s mailbox, note
there is no modification to the Subject header.
Cisco dCloud
Scenario - Sender Policy Framework (SPF)
Following on from the previous scenario, by the time DKIM was rolled out across all of AQF’s company gateways, the messaging
team have successfully completed collecting data on legitimate senders from all stakeholders. Since SPF adds an additional layer
of protection, listing all IP addresses allowed to send email on behalf of his company, Luis decides to proceed with implementing
SPF in conjunction with DKIM to further enhance their ant-spoofing defenses.
Send Policy Framework (SPF) is still considered an effective tool to detect and block forged or spoofed emails by verifying the
senders email server before delivering the email to the receiving mail server. When an incoming email is received by the receiving
email gateway with SPF checking enabled, the Cisco Email Security solution helps administrator to validate the sender’s domain
against the published SPF record in DNS. Cisco Email Security confirms that the sending server IP address is on the allowed list
for that domain, otherwise verification fails if there is no match.
Objective
This scenario will demonstrate how SPF protects the envelope sender address by comparing the sending mail servers IP address
to the SPF record published in the DNS for the sender’s email domain. If an email and the sender is not listed in the DNS record, it
fails the SPF check.
Steps
Task – Create a SPF Record (Sender – ESA2)
An SPF record is a list of servers that are allowed to send e-mail from the sending domain. The purpose of an SPF record is to
detect and prevent spammers from sending messages with forged From addresses on the sending domain.
2. Log in using the credentials below, acknowledge any security warning presented. Once logged in, click the DNS icon to launch
the DNS manager interface.
Cisco dCloud
the list.
4. Scroll the drop-down list to the end, select Text (TXT) and click on Create Record ….
5. Leave the Record Name blank and enter this string v=spf1 mx –all into the Text box. Click OK
Cisco dCloud
6. Click Done.
dcloud-out.cisco.com to verify the SPF record.
Task – Enable SPF Verification (Recipient – ESA1)
Once SPF verification is enabled, the receiving Cisco Security Email solution will assess the sending IP address in the public DNS
to confirm it is permitted to send the email from the sender. The SPF verifies the HELO identity (the sending mail server) and the
MAIL FROM identity (the email addresses the message is sent from).
1. On the workstation, access the GUI of ESA1. Navigate to Mail Policies > Mail Flow Policies and choose the listener Public
198.18.133.146:25. Click on the Default Policy Parameters mail flow policy name.
Cisco dCloud
2. Scroll the page down towards the Security Features section, enable SPF/SIDF Verification by selecting On. Choose
Downgrade PRA verification result if Resent-Sender: or Resent-From: where used: to Yes and choose HELO Test to
On.
3. Click Submit and commit your changes – click the yellow box at the top right corner . Give an optional comment and click
Task - Configuring a Content Filter (Recipient – ESA1)
In this task, a new content filter will be created to apply an action based on the result of the SPF verification test in the receiving
email server. For example, if the message delivered from an unknown IP address, it can be considered as an illegitimate message
based on the sender.
1. Remain on the GUI of ESA1 from previous task and navigate to Mail Policies > Incoming Content Filters and click Add
Filter.

Name: SPF_Verification
Conditions: - SPF Verification > Is > SoftFail, Fail
Action 1: - Add / Edit Header

- Header Name > Subject
- Prepend to the Value of Existing Header > [SPF FAIL]
Cisco dCloud
3. Click OK
4. Click OK
Cisco dCloud
Task - Edit Incoming Mail Policy (Recipient – ESA1)
1. From the workstation access the GUI of ESA1 and navigate to Mail Policies > Incoming Mail Policies and click within the
Content Filters box of the Default Policy.
2. Place a checkmark against the content filter SPF_Verification created in the previous task to enable it.
Cisco dCloud
3. Click Submit. Once completed, commit your changes – click the yellow box at the top right corner . Give an optional
comment and click Commit Changes again.
Task - Testing SPF Verification
With all the configuration in place, the SPF verification features can be tested by sending an email to Alan from an external user
with email address ending with dcloud-out.cisco.com.
1. Initiate a connection to the ESA1 from the CLI in order to view, using the tail command (tail mail_logs), the mail logs to see
the message being processed and the actions being applied as it works its way through the pipeline.
Subject: SPF Testing
Body: SPF Testing
4. Switch to the CLI of ESA1, note the SPF feature has identified the mail-from address is matching the SPF record from public
DNS. The SPF final result is Pass.
5. Return to the workstation, synchronize the messages once more and the message will now appear in Alan’s mailbox, note
there is no tampering to the Subject header.
Cisco dCloud
Scenario - Domain-based Message Authentication, Reporting & Conformance (DMARC)
As a final step in his anti-phishing protection strategy, Luis makes a plan for gradual rollout of DMARC.
DMARC ties in information authenticated with SPF or DKIM (sending domain source, or signature) with what is presented to the
end-recipient in the “From:” header and ascertains that SPF and/or DKIM identifiers are aligned with the FROM header identifier. It
also allows Luis to explicitly instruct other systems on the Internet what to do with messages purported to be from domains his
company controls that fail verification. DMARC has a powerful reporting component and this allows Luis to gain visibility into
potential phishing attempts or campaigns using his corporate identity.
Additionally, he can feed information from DMARC reports into a dedicated analytics system to provide deep insight into his brand
trustworthiness and exploitation attempts to gain a better insight into how their email domains are being used.
Objective
DMARC is built on top of two existing mechanisms. Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM). It
allows the administrative owner of a domain to publish a policy on which mechanism (DKIM, SPF or both) is employed when
sending email from that domain and how the receiver should deal with failures.
This scenario will demonstrate how DMARC verification is implemented and used. In the DMARC policy, instructions can be given
to the receiving email server to follow in the event the email fails the SPF or DKIM alignment check. The sending domain is then
able to request a report regarding the outgoing email that either passed or failed the DMARC verification.
Steps
Task – Create a DMARC Record (Sender – ESA2)
Once SPF and DKIM records are in place, the administrator can configure a DMARC record by adding policies to the sending
email domain. As DMARC policies are published as TXT records, it defines what an email recipient should do with non-aligned
mail it receives.
2. Llogin using the credentials below, acknowledge any security warning presented. Once logged in, click the DNS icon to
access the DNS manager interface.
Cisco dCloud
the list.
4. Scroll the drop-down list to the end, select Text (TXT) and click on Create Record …
Cisco dCloud
5. Enter the Record Name as _dmarc and paste the string v=DMARC1; p=none; pct=100; rua=mailto:dmarc@dcloud-
out.cisco.com into the Text box. Click OK.
6. Click Done.
_dmarc.dcloud-out.cisco.com to verify the DMARC record.
Cisco dCloud
Task – Enable DMARC Verification (Recipient – ESA1)
Once DMARC verification is enabled, the receiving Cisco Security Email solution will verify if the email address that appears in the
mail-from field or the DKIM signature d=domain header is identical to the one displayed in the From header.
1. On the workstation, access the GUI of ESA1. Navigate to Mail Policies > Mail Flow Policies and choose the listener Public
198.18.133.146:25. Click on the Default Policy Parameters mail flow policy name.
2. Scroll the page down towards the Security Features section, enable DMARC Verification by selecting On. Please be note
that a pre-defined DMARC verification profile (DEFAULT) is already available on the Cisco Email Security. Enable the option
send aggregate feedback reports.
Task - Configuring DMARC Verification Profile (Recipient – ESA1)
This task will modify the default DMARC verification profile on the receiving Cisco Email Security and depending on the DMARC
verification result and specified verification profile, it will either accept, quarantine or reject the message. If the sending of
aggregate reports is enabled, Cisco Email Security gathers DMARC verification data and includes it in the daily report sent to the
domain owners.
1. Remain on the GUI of ESA1 from previous task and navigate to Mail Policies > DMARC and click the profile name
DEFAULT. Using the following settings configure the Message Action based on DMARC policy’s request.
When Policy in DMARC record is Reject: Choose Reject
When Policy in DMARC record is Quarantine: Choose Quarantine to > Select Policy
For Temporary Failure: Remain Accept
For Permanent Failure: Choose Reject
Cisco dCloud
Task - Testing DMARC
With all the configuration in place, the DMARC verification features can be tested by sending an email to Alan from an external
user Ben with email address ending with dcloud-out.cisco.com.
the next step.
Subject: DMARC Testing
Body: DMARC testing
Cisco dCloud
6. Switch to the CLI of ESA1, note the DMARC feature has identified both SPF and DKIM records are align to the DMARC
policy. The DMARC final result is Pass.
7. Return to the workstation, synchronize the messages once more and the DMARC testing message will now appear in Alan’s
mailbox.
8. Return to the GUI of ESA1 and navigate to Monitor > DMARC Verification to view what is being reported.
Cisco dCloud
Scenario - Sender Domain Reputation (SDR)

As a loyal customer of Cisco Email Security solution, AQF is traditionally filter untrusted emails based on the sending domain’s IP
& hostname reputation by querying SenderBase Reputation Service (SBRS). However, Luis’s team begin to notice the efficacy of
IP based reputation has been gradually decrease due to several reasons particularly the same IP address that could be used to
host multiple sending domains, in which case nature of each domain may be different, hence make SBRS less effective to prevent
the malicious infested email messages from bypassing the IP based reputation checking.
In order to address such concerns, Luis’s team has enabled the Sender Domain Reputation Service (SDR) feature in Cisco Email
Security, powered by Cisco Talos. With the preservation of IP reputation filtering at the SMTP communication layer, the reputation
based on the sending domain information presented in the SMTP conversation and message headers will be take into account as
well to determine if the email message should be permitted or blocked by the incoming mail policy.
Objective
This scenario will demonstrate how to protect against sender domain with bad reputation verdict by leveraging the Cisco Security
Proxy service to ensure the inbound emails from the untrusted senders are not reaching out to the end user’s mailboxes.
Steps
Task – Send an email from a sending domain with bad reputation verdict
1. On the workstation, return to Microsoft Outlook and prepare a new message with the following parameters from Ben’s inbox.
From: mark@cashslip.info (Note: You will find this email from the dropdown list, see screenshots below)
Subject: SDR Test
Body: SDR Test
3. Examine Alan’s inbox to verify receipt of the message. It should appear arrive correctly as sent from an email domain
(@cashslip.info) with a bad reputation score.
Cisco dCloud
This task will create a new content filter to identify potentially malicious sending email domain and take an appropriate action on
that message – direct it through the Cisco Security Proxy, which in turn will determine if the email domain is in fact potentially
dangerous.
1. Launch Google Chrome. Click the bookmark ESA1 and log in with the following credentials: -
Username: admin

Name: SDR_CF
Condition 1: - Click: ‘Add Condition …’

- Choose: ‘Domain Reputation’
- Choose: Sender Domain Reputation Verdict
- Select verdict: Awful to Tainted
Action 1: - Click: ‘Add Action …’

- Choose: Add/Edit Header
- Enter ‘Header Name:’ as Subject
- Select ‘Prepend to the Value of Existing Header:’
- Enter [Bad SDR]
Cisco dCloud
4. Click OK.
1. On the ESA1’s GUI, navigate to Mail Policies > Incoming Mail Policies. Click within the Content Filters box of the Default
Policy.
Cisco dCloud
2. Place a checkmark against the content filter URL_Filter created in the previous step to enable it.
3. Click Submit to create the content Filter and verify the Default Policy.
Task - Testing SDR Filtering
With the pre-requisite configuration in place, the URL Filtering feature can be tested by sending an email to Alan from the sending
domain with bad reputation verdict.
1. From the workstation launch Putty located on the taskbar and select ESA1 from the Saved Sessions and click Open.
2. Log in using the credentials listed earlier in this document. Once logged in, issue the command tail mail_logs and press
[Enter] on your keyboard. Leave this running in the background and proceed to the next step.
3. From the workstation launch Microsoft Outlook, prepare a new message with the following parameters.
Cisco dCloud
From: mark@cashslip.info
Subject: SDR Test
Body: SDR Test
5. Switch back to the CLI and notice how the SDR filter handled the message, it detected the domain ‘cashslip.info’ with sender
reputation as Awful.
6. Navigate back to Alan’s inbox and make sure the email is downloaded. You will notice the Subject is now prepended with the
texts [Bad SDR].
7. Return to the ESA1’s GUI and navigate to Monitor > Sender Domain Reputation to view what is being reported.
Cisco dCloud
Scenario - Consume External Threat Feeds (STIX / TAXII)

STIX/TAXII, or Structured Threat Information Expression and Trusted Automated eXchange of Indicator Information, are
community-supported specifications designed to enable automated information sharing for cybersecurity situational awareness,
real-time network defence, and complex threat analysis. Luis is aware of the Cisco Email Security Solution support for STIX/TAXII,
asks his team members to configure the External Threat Feeds (ETF) to gather more cyber risk intelligence from one of the
available repositories of Open Source Cyber Threat Intelligence feeds in STIX format.
Objective
This scenario demonstrates how External Threat Feed (ETF) framework allows Cisco Email Security to consume external threat
information in STIX format communicated over a TAXII protocol and use the fed Indictors of Compromise (IoC) to defend against
the cyber adversary’s attempt using Host Access Table (HAT), Message Filtering and/or Content Filter features.
Steps
Task – Configure a External Threat Feed (ETF) Source
This task will create a new External Threat Feed (ETF) source on Cisco Email Security in order to consume external threat
information in STIX format communicated over a TAXII protocol.
1. Access to the ESA1’s GUI. Navigate to Mail Policies > External Threat Feeds Manager and click Add Source. Using the
following settings configure the Source Details.
Source Name: Hailataxii-PhishTank
Description: (Optional) Leave it blank
Hostname: hailataxii.com
Polling Path: /taxii-discovery-service
Collection Name: guest.phishtank_com
Polling Interval: Default value (1 Hour)
Age of Threat Feeds: 10 Days
Time Span of Poll Segment: 10 Days
Use HTTPS: No (Note: Polling Port should automatically change to 80)
Configure User Credentials: - Yes > Basic Authentication

- Username: guest
- Password: guest
Use Global Proxy No
Cisco dCloud
2. Click Submit.
This task will create a new content filter to identify potentially malicious URLs based on PhishTank ETF and take an appropriate
action on that message – defang the URL.
1. On the ESA1, navigate to Mail Policies > Incoming Content Filters and click Add Filter. Using the following settings
configure the Conditions and Actions.
Name: ETF_URL_CF
Condition 1: - Click: Add Condition …

- Select URL Reputation
- Select External Threat Feeds
- Choose Hailataxii-PhishTank and click Add
- Check URLs within > Message Body and Subject)
- Click OK
Action 1: - Click: Add Action …

- Select Drop (Final Action)
- Click OK
Cisco dCloud
Once the necessary content filter has been configured it must be enabled to a Mail Policy to be effective.
Cisco dCloud
2. Place a checkmark against the content filter ETF_URL_CF created in the previous step to enable it.
Task – Verify ETF Polling Status
Once configure the content filter and applied it to the default incoming mail policy, it is an appropriate time to go back and verify the
ETF polling status.
1. Navigate to Mail Policies > External Threat Feeds Manager
2. A timestamp should be available under Last Successful Poll which indicates that initial polling task is completed.
NOTE: It may take about 30 minutes to complete the polling task. It is compulsory for you to wait for the completion of first polling
task in order to proceed the next task.
Task - Testing ETF Based URL Filtering
With the pre-requisite configuration in place, the ETF based URL Filtering feature can be tested by sending an email to Alan from
external user Ben with a malicious URL as the subject header of the message.
1. From the workstation, launch Putty located on the taskbar and select ESA1 from the Saved Sessions and click Open.
[Enter]. Leave this running in the background and proceed to the next step.
Cisco dCloud
Subject: ETF Test
Body: - Download the latest URL sample from http://data.phishtank.com/data/online-valid.csv

- Open the downloaded CSV file with Microsoft Excel
- Scroll down the list and select few URLs that were submitted about a day ago.
- Copy the URLs listed under “url” column
- Paste them into the email body
5. Switch back to the CLI session and notice how the ETF_URL_CF rule handled the message, it reveals few phishing URLs
have been detected by ETF source ‘Hailataxii-PhishTank’, hence the message has been dropped by the ESA.
Cisco dCloud
6. Return to the ESA1’s GUI and navigate to Monitor > External Threat Feeds to view what is being reported.
Cisco dCloud
Scenario - DNS-based Authentication of Named Entities (DANE)

As expected by the business, the volume of outgoing email has increased significantly specifically to handful of partner’s domains
that involved with business-critical information. The InfoSec team has been demanded by the top management to offer the best
possible measurement to make sure the emails are delivered to the intended recipients other than the implementation of email
content encryption (CRES), data lost protection (DLP) and TLS communication encryption on the outgoing mail policy.
After few rounds of discussions and researches among the team, Luis determine the adoption of DANE on Cisco Email Security to
ensure the email communication with those important partners are mutually trustworthy. While DANE improve the security of TLS,
Luis fully understand that DANE by itself may not be sufficient to fully protect the email delivery flow. The best coverage is to use
DANE for protecting the communication along with TLS and CRES for protecting the message content by encryption and signing.
Objective
This scenario demonstrates how Cisco Email Security can offer a better and more secure way to securely send messages to a
valid recipient domain by enabling DANE for outgoing TLS connection via Destination Control setting. This feature will help an
organization to ensure that business critical and confidential information is delivered to the intended recipient, provided the
destination domain supports DANE.
Steps
Task – Verify DANE status of a receiving domain
Cisco Email Security offers a CLI command daneverify to perform a set of complex queries to verify whether a receiving domain is
capable of passing DANE verification. The same command can be used with a known good domain to confirm the Cisco Email
Security ability to resolve DNSSEC queries.
1. From the workstation, launch Putty located on the taskbar and select ESA1 from the Saved Sessions and click Open.
2. Log in using the credentials listed earlier in this document. Once logged in, issue the command daneverify and press [Enter].
3. Enter the domain unixadm.org to verify DANE support. It will take about 5 - 10 seconds to display the DANE support result on
the screen. Ensure the DANE SUCCESS is indicated for the domain prior to proceed the next task.
Cisco dCloud
4. Type N to end the command.
Task – Enable TLS for delivery with DANE supported
Once confirmed the receiving domain is DANE supported, this task will create a new Destination Control for a domain
(unixadm.org) with both TLS and DANE enabled in the configuration page.
1. Access to the ESA1’s GUI and navigate to Mail Policies > Destination Control and click Add Destination. Using the
following settings configure the Source Details.
Destination: unixadm.org
TLS Support: Preferred
DANE Support: Opportunistic
Others: Default
2. Click Submit.
Cisco dCloud
Task – Edit Log Subscription
Custom Mail Logs at Debug Level will display complete DANE and DNSSEC lookups, negotiation expected, portions of the check
which pass/fail and a success indicator.
1. On the ESA1’s GUI and navigate to System Administration > Log Subscription.
2. Click mail_logs under Log Settings.
3. Under Log Level section, choose Debug.
4. Click Submit.
Task – Verify DANE success
With the pre-requisite configuration in place, DANE encryption can be tested by sending an email from internal user Alan to the
email domain with DANE supported (unixadm.org).
Cisco dCloud
3. From the workstation launch Microsoft Outlook and from Alan’s inbox, prepare a new message with the following parameters.
From: alan@dcloud.cisco.com
To: admin@unixadm.org
Subject: DANE Test
Body: DANE Test
4. Send the email.
5. Switch back to the CLI session and notice how the email is now delivered with DANE encryption applied.
NOTE: Please ignore the “Unknown address” error display on the mail logs and the “Undeliverable” bounced email. These are
expected behaviours in this lab scenario.
6. Mail logs configured for Debug Level logging may consume excessive resources on an ESA1 depending on the system load
and configuration, hence it is very important to roll back the log level to Info.
7. Return to the ESA1’s GUI and return to System Administration > Log Subscriptions.
8. Edit the mail_logs log setting again and revert the Log Level to Information.
9. Click Submit
Cisco dCloud
11. Stay on the ESA1’s GUI and now navigate to Monitor > TLS Connections to view what is being reported.
12. Scroll down to Outgoing TLS Connection Details table to find out if the DANE based delivery is successful or failed by
checking the counter value for each receiving domain (unixadm.org).
Cisco dCloud
Scenario - Mailbox Auto-Remediation (MAR) for On-Prem Microsoft Exchange
A file can turn malicious anytime even after it has reached user’s mailbox. Advanced Malware Protection (AMP) can identify this as
new information emerges and push retrospective alerts to Cisco Email Security appliance. AMP offers more than just alerting, it can
perform auto-remedial actions on the messages in user mailbox when the threat verdict changes.
As a patron of Cisco Email Security, AQF always ensure they get the maximum benefit out of their investment and have already
implemented MAR for all Office 365 users since the release of this feature on AsyncOS version 10. While the CISO team foresee
another 5 years to complete the full transition of all employees into Office 365 productivity environment, the team has expressed the
need for the same remedial action for their existing Exchange 2016 server farm where most of the mailboxes are still operating here.
Objective
This scenario will configure AMP to fight against file based advanced threats and witness how these threats are blocked and able to
be removed from Exchange mailboxes by MAR.
Mission
Your goal is to setup a MAR setting between Cisco Email Security and the Exchange 2016 server. In addition, we will send an email
with malware to showcase how this would work in the production AQF environment. These are the high-level tasks you need to
perform to complete this exercise:
• Create an EWS service account and the assignment of application impersonation in the Exchange server.
• Configure Mailbox Auto Remediation feature for on-prem Exchange on ESA1 and test the connection.
• Send a test email with a new malware sample as the attachment.
• Check the ESA1 logs & GUI reports for AMP file analysis process; remediation should happen before the lab ends.
Steps
Task – Create an EWS service account
In this task we need to log into the AQF’s Exchange 2016 email server (dcloud.cisco.com) and create an appropriate service
account for the use of our Cisco Email Security’s MAR configuration.
1. From the Workstation, click the RDC icon on the taskbar to launch a remote access session to mail2.dcloud.cisco.com with
the username: DCLOUD\administrator. If necessary, type in the passphrase: C1sco12345. Then accept the certificate warned
and click Yes to proceed.
2. Once accessed to Exchange server, proceed to the desktop by clicking on the desktop box. Then find the Active Directory
Users and Computers, this is found in the Taskbar. Click to open it.
Cisco dCloud
3. Right click on the Users directory. Select New > User from the menu.
4. In the First name box type Cisco, Last name box type EWS and then type ciscoews as the User Logon name. Click on Next.
De-select the User must change password at next logon and then select the Password never expires box. Type
C1sco12345 in the password and confirm password box. Click the Next box and click Finish.
5. Close the Active Directory Users and Computers window by click on the X button on the upper right-hand corner of the box.
Task – Assign the Application Impersonation to EWS service account
We now need to create an application impersonation assignment. We need this role to read and write into another user’s mailbox.
This role will then need to be assigned our ciscoews service account.
1. Open the text file named impersonate that is saved on the Exchange server’s desktop. Copy the commands that are in the file.
Cisco dCloud
1. Double click this file
2. Copy the command dCloud: The Cisco Demo Cloud
TIPS: To avoid typo error, please double-click the file impersonate.txt on the Exchange servers Desktop; copy the command and
paste it into the prompted Exchange Management shell.
2. Open the Exchange Management Shell from the Exchange server’s taskbar.
3. Paste the command (which you have copied from the impersonate text file) into the Exchange Management Shell and press
[Enter]. Make sure you received the confirmation that application impersonation is applied successfully.
3. Paste the command
4. Close the remote desktop session to return to the Workstation’s desktop. Click on the X button on the top right corner of RDC
session and click OK.
Task – Create an account profile
This task is relatively straight forward to create an account profile to enable our Cisco Email Security environment to login and
communicate with the AQF Exchange email server environment.
1. From the workstation, launch Google Chrome. Click the bookmark ESA1 and log in with the following credentials:
Username: admin
2. Navigate to System Administration > Account Settings.
3. Click on Enable
4. Tick the Enable Account Settings option and click Submit.
Cisco dCloud
5. Click on Create Account Profile
6. Using the following settings configure the Account Profile.

Profile Name: dcloud
Description: Leave it blank
Profile Type: Exchange On Premise
Username: ciscoews
Password: C1sco12345
Host: mail2.dcloud.cisco.com
7. Click Submit
9. If necessary, return to System Administration > Account Settings in ESA1.
10. Click the dCloud account profile name and click the Test Connection, enter alan@dcloud.cisco.com in the email address
box. This should give a connection unsuccessful error due to Exchange server certificate verification failed.
Cisco dCloud
11. Click Done to close the Connection Checkbox.
NOTE: You need to install the custom certificate authority (CA) in Cisco Email Security if the self-signed certificate is used on the
Exchange server.
Task – Install custom certificate authority
The previous connection was unsuccessful as the AQF exchange environment was using a self-signed certificate. We need to add
the custom certificate authority (CA) to enable a secure connection from our ESA1 to the Exchange environment.
1. Go to Network > Certificates. Click Edit Settings under the Certificate Authorities section.
2. Click the radio button next to Enable under the Custom List section. Then select Choose File.
3. Navigate to the desktop of the workstation, locate the folder called dCloud Files, open the folder and then open the sub-folder
named MAR for Exchange. Select the custom CA.txt file. Click Open.
Cisco dCloud
6. Click Edit Setting again on Certificate Authorities section to make sure the custom CA is added successfully.
7. A short sentence View Custom Certificate Authorities will appear in the Custom List box.
8. Click the link to view the custom CA content, it should depict DCLOUD as the Root CA.
9. Close the pop-up box. Now you are ready to test the MAR connection.
Task – Test account setting’s connection
In this task we will retry the test connection that previously failed before we applied our own custom certificate authority.
Cisco dCloud
1. Return to System Administration > Account Settings.
2. Click on the dcloud profile we created previously.

3. Click Test Connection, enter alan@dcloud.cisco.com in the email address box. Click on Test Connection.
4. Your Connection Status should now read “Connected to Exchange. Connection Successful. The appliance is able to read the
user’s mailbox.”
5. Click Done to close the box.
Task – Domain mapping
A domain mapping is used when a recipient domain is to be mapped to a profile or a chained profile. When a recipient domain is
mapped to a profile, ESA1 shall use that profile when trying to perform MAR on the message that is sent to recipients of the
domain.
1. Navigate to System Administration > Account Settings, click on Create Domain Mapping.
2. Enter dcloud.cisco.com into the Domain Name box and choose dcloud as the Mapped Profile.
Cisco dCloud
Task – Enable MAR in Incoming Mail Policy
Edit default AMP policy to enable MAR that will be applied to messages which have files that have been identified as malicious and
already delivered to Exchange’s user mailbox.
1. Remain on ESA1, navigate to Mail Policies > Incoming Mail Policies and click within the Advanced Malware Protection
section of the Default Policy.
2. Scroll toward the Message with File Analysis Pending section, change the Action Applied to Message as Deliver As Is.
3. Scroll down towards the Enable Mailbox Auto Remediation (MAR) section. Tick the box to enable this feature and choose
Delete as the action to be taken on the messages in Exchange user’s mailbox.
Cisco dCloud
4. Click Submit.
Task – Create a malicious file
To simulate AMP retrospective outcome, a benign file is generated and used within an email coming into the organization. The file
itself is not capable of doing any harm, however the Cisco AMP file analysis treats this as a malicious test file and performs the
same actions on it as if it was carrying a malicious payload.
sub-folder named MAR for Exchange.
2. Open the file Make Malware.bat by double-clicking it and acknowledging the Run button when prompted. If run successfully,
a second file will be present named malware.exe.
Task – Send a Message with a malicious file
Now that a file that contains malicious payload has been generated, let’s send a message from Ben to Alan with this as an
attachment, this is sufficient to trigger the AMP engines and provide the required disposition.
1. From the workstation launch Putty located on the taskbar and select ESA1 from the Saved Sessions and click Open.
[Enter] on your keyboard. Leave this running in the background and proceed to the next step.
Cisco dCloud
≈
3. From the workstation launch Microsoft Outlook and from Ben’s mailbox, prepare a new message with the following
parameters.
Subject: MAR for Exchange Test
Body: MAR for Exchange Test
Attach: Attach malware.exe created in the previous step; located on the Desktop under the dCloud Files > MAR for
Exchange sub folder.
4. Send the message – If Microsoft Outlook display a warning about unsafe files, click Yes to ignore this.
Task - Monitoring email delivery status via mail logs
latest activities.
2. The highlighted line below and the one prior to that shows the file reputation verdict – UNKNOWN therefore the file will be sent
for further analysis, also note that a SHA256 has been assigned.
Cisco dCloud
3. Return to the Microsoft Outlook and make sure the malware test email is now delivered to Alan’s Inbox folder.
4. Return to ESA1’s CLI session, hold down the [Control] + [C] keys on your keyboard to stop the [tail mail_logs] operation.
Task – Monitor AMP action via AMP logs
1. In the same CLI session, issue another command tail amp and press [Enter]. The AMP log reveals the query responded from
AMP Cloud and the verdict has been returned after the file analysis process has been completed approximately 7 ~ 10
minutes later.
2. Hold down the [Control] + [C] keys on your keyboard to stop the [tail amp] operation.
Task – Monitor AMP retrospective verdict updates and MAR action
As the disposition set to MALICIOUS, AMP will consider this outcome as a retrospective verdict change. An instruction to call for
MAR action upon the test malicious email in Alan’s mailbox will be automatically scheduled by CES.
NOTE: AMP cloud service can take more than 6-8 hours to respond with a retrospective event in order to trigger the MAR action,
so please proceed to the next lab scenario and we strongly recommend you resume this task after completed other lab scenarios.
If the MAR action does not occur during your lab session, please refer to the steps below to understand how MAR action is
working.
1. Access to ESA1‘s GUI (Chrome), navigate to Monitor > AMP Verdict Updates. The report shows the file (malware.exe)’s
disposition has been changed from UNKNOWN to MALICIOUS.
Cisco dCloud
2. Navigate to Monitor > Mailbox Auto Remediation to view the MAR action taken upon the message with malware.exe as an
attachment. It shows the message has been remediated successfully from Alan’s mailbox.
Return to Microsoft Outlook, the message (with malware.exe as the attachment) is no longer exist in Alan’s Inbox folder.
Cisco dCloud
Scenario - Search and Remediate Email via Message Tracking
Dealing with a suspicious email message is remain one of the biggest headaches when it comes to email security. Malicious
attackers might be sending email to the internal employees in an attempt to phish their credentials and gain access to highly
confidential information or corporate secrets. To help prevent this, The SOC team is seeking for a new measurement for the email
security administrator to search and remediate any suspicious messages.
However, it occasionally happens that an attacker sends an email that contains a benign link that only later redirected to malicious
content (such as malware or ransomware). Or, might realize too late that someone in organization has been compromised. While
the employees were compromised, an attacker used their accounts to send email to other employees within the organization. As
part of dealing with either of these scenarios, The SOC team need to remove suspicious email messages from employee’s inboxes
by providing actions such as hard delete, forward e-mail and delete and forward mail option.
Objective
This scenario will demonstrate a new feature that Cisco Email Security is providing for an administrator to retract message from
any given message found through the Message Tracking service, for the employee’s mailbox that is linked through the remediation
account setting.
Mission
Your goal is to setup a remediation account setting between Cisco Email Security and the Exchange 2016 server. In addition, we
will send a suspicious email showcase how this feature would work in the lab environment. These are the high-level tasks you need
to perform to complete this exercise:
• Configure EWS setting on Exchange 2016 and Cisco Email Security

• Send a test email that will be treated as unsolicited message to the employee.
• Configure remediation account setting feature on ESA1 and test the connection.
• Search the test email using “Message Tracking” on ESA1 and extract the test email from Outlook’s mailbox.
Steps
Task – Configure EWS setting on Exchange 2016 and Cisco Email Security
You should already configure this task in “Scenario - Mailbox Auto-Remediation (MAR) for On-Prem Microsoft Exchange”. If not,
please visit the following pages:
• Task – Create an EWS service account (Page 86)
• Task – Assign the Application Impersonation to EWS service account (Page 87)
• Task – Create an account profile (Page 88)
• Task – Install custom certificate authority (Page 90)
• Task – Test account setting’s connection (Page 91)
• Task – Domain mapping (Page 92)
Cisco dCloud
Task – Send a Test Message
Prior to configure EWS setting on both Exchange 2016 and Cisco Email Security, let’s send a test message to Alan from Ben’s
mailbox.
1. From the Workstation 1 (known henceforth as Workstation), launch Microsoft Outlook and from Benny’s mailbox, prepare a
new message with the following parameters.
From: benny@dcloud-out.cisco.com
Subject: Remediate Test
Body: Remediate Test
2. Send the message – If Microsoft Outlook display a warning about unsafe files, click Yes to ignore this.
4. On Alan’s Outlook account, review his Inbox to ensure the messages arrived.
Task – Initiate a CLI Session to Observe the Process Flow
Initiate a connection to ESA1 from the CLI in order to view, using the tail command (tail mail_logs), the mail logs to see the
message being processed and the actions being applied as it works its way through the pipeline.
2. Login the CLI session with same admin’s credential (username: admin and passphrase: C1sco12345). Issue the command
tail mail_logs and press [Enter] on your keyboard.
Cisco dCloud
3. Leave this CLI session running in the background and proceed to the next task.
Task – Search and Remediate the Test Message
With the pre-requisite configuration in place, the Search and Remediation actions can be tested via Message Tracking feature in
Cisco Email Security (ESA). Please take note that this remediation only available in the next-generation GUI of ESA.
1. On Google Chrome, click the bookmark ESA1 and log in with the following credentials:
Username: admin
2. Remain on the ESA1’s GUI. Click the top banner to access ESA1’s next-generation GUI.
3. If necessary, re-login to ESA1 with the same admin credential (username: admin and passphrase: C1sco12345)
4. Click the Tracking tab to access the Message Tracking service.
5. Keep everything as default. Make sure the duration set to Today and click the Search button (at the bottom right corner).
Cisco dCloud
6. The test message that you sent earlier ago should be displayed on the search result. Place a check mark against this
message and click Remediate (at the top right corner).
7. Name the Remediation Batch as dCloud Test and retain Delete Email(s) as the Remediation Action. Click Apply.
Cisco dCloud
8. A Remediation Status box appears. Click Go Back to close the box.
9. Switch back to the CLI (PuTTy) and notice the remediation batch job – dCloud Test was initiated. After few seconds later, the
message status has been updated as Remediated.
10. Return to the Outlook client. The test message should be removed from Alan’s Inbox.
Cisco dCloud
Scenario - Single Sign-On (SSO) using SAML 2.0

Luis has mandated that the InfoSec department to centralize the identity control of all employees and contractors due to the
increasingly large and complex environment with several disperse geographical location expanded over the past 5 years.
SAML has been highly regarded as the best authentication framework for AQF’s network environment primarily due to its capability
that allows application from different vendors to be able to communicate with each other using a common authentication scheme
which eventually provides a seamless user authentication experience with a single login that provides access to other application’s
portals.
SAML also provides a strong layer of security by leveraging PKI to protect the asserted identity against attempted attacks which
makes it the most preferable option by the InfoSec team as well. Cisco Email Security offers the ability to support centralized
authentication and role management using SAML. InfoSec team is interested in utilizing this feature to ensure that all employees
have the correct permissions in a timely fashion.
Objective
This scenario will demonstrate how to integrate the AQF’s Cisco Email Security environment with the customer’s Microsoft Active
Directory using Active Directory Federation Service (ADFS) as the identity provider (IDP).
Mission
Your goal is to configure SAML SSO based external authentication on the AQF’s email security appliance (ESA) and login to the
ESA1 portal with custom AD user accounts. These are the high-level tasks you need to perform to complete this exercise.
• Learn how to configure both service provider (SP) and identity provider (IDP) settings.
• Establish a trust SAML relationship by sharing the metadata between both SP and IDP environments.
• Create the custom groups and users in the Active Directory and configure External Authentication in ESA.
• Showcase how AQF can use centralized role management for Cisco Email Security.
Steps
Task – Create a Service Provider (SP) profile on ESA1
In this task, we need to log into the AQF Cisco Email security environment and create a service profile to enable secure connection
to the Active Directory Federation Service (ADFS).
1. Open Chrome from the taskbar, and click the first bookmark for ESA1. Log in with the following credentials: -
Username: admin
2. Go to System Administration > SAML and click Add Service Provider.
3. Enter the following information in the Service Provider Settings
Cisco dCloud
Profile Name: esa1
Entity ID: https://esa1.dcloud.cisco.com

Assertion Consumer URL: https://esa1.dcloud.cisco.com
SP Certificate: - Select Upload Certificate and Key:

- For “Certificate”, click: Choose file
- Select the folder path: Desktop > dCloud Files > SAML > esa.pem
- For “Private Key”, click: Choose file:
- Select the folder path: Desktop > dCloud Files > SAML > esa.key
- Enter passphrase: 123
•
Organization Details: - Name: esa1.dcloud.cisco.com
- Display Name: esa1.dcloud.cisco.com
- URL: https://esa1.dcloud.cisco.com
Technical Contact: - Email: administrator@dcloud.cisco.com
Cisco dCloud
4. Click Submit
Task – Create an Identity Provider (IDP) profile
In this task, we will import the IDP (ADFS) metadata to enable secure communications for authentications and authorizations.
1. Open a new browser tab in Chrome and click the bookmark ADFS Metadata. This bookmark will immediate download the
XML based metadata from the Active Directory server that hosting the ADFS service.
NOTE: The default URL address for AD FS metadata is https://adfs-server/federationmetadata/2007-06/federationmetadata.xml
2. You will see the downloaded file in the left bottom corner of your Chrome browser:
3. The XML based metadata file should be downloaded and saved in the default Downloads folder.
4. Return to ESA1 browser tab. Stay or navigate to System Administration > SAML click on Add Identity Provider
5. Enter the following information for the Account Profile:

Profile Name: dcloud-ad1
Configuration Settings: - Choose: Import IDP Metadata

- Click: Choose File
- Select: C:\Users\Administrator\Download > FederationMetadata.xml
Cisco dCloud
6. Click Submit
8. Click Download Metadata under Service Provider Settings, this will download a file called esa1_metadata.xml
NOTE: A copy of metadata file – esa1_metadata.xml is already stored in the AD1 server. Please proceed to the next task.
Task – Upload service provider metadata into the identity provider
In this task, we shall upload the ESA1’s metadata which we created in the previous task into the ADFS service hosted in the AD1
server.
1. From the workstation launch RDC located on the taskbar. Type the Computer as ad1.dcloud.cisco.com and click Connect
to remotely access the AD1 server. If necessary, log in using the credentials below, acknowledge any security warning
presented. Once logged in.
Username: DCLOUD\Administrator
Cisco dCloud
2. Click on the icon in the taskbar labelled AD FS Management.
3. On the right Actions panel of AD FS console, click Add Relying Party Trust…
4. Click Start to begin the wizard. Choose Import data about the relying party from a file and click Browse
Cisco dCloud
5. As mentioned in previous task’s note, we already transferred the metadata file (esa1_metadata.xml) over for you. The file is
located at the AD1’s Desktop > SAML (ESA1) folder. Select this metadata file and click Open.
6. Click Next
7. You should receive the following error: Error – AD FS Management. Click OK to acknowledge the error and proceed to the
next task to fix the metadata.
Cisco dCloud
Task – Fix the ESA metadata’s defect (CSCvh30183)
This error is a known defect (CSCvh30183) and scheduled to be fixed. However, we need to fix our metadata in order to work in
the lab environment right now.
1. On the desktop of AD1, open the SAML (ESA1) folder, then right click on the esa1_metadata.xml file. Edit the file using
Notepad or Notepad++
2. Using the Notepad++, remove these texts -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- from
the following lines – 12, 31, 39 and 58.
NOTE: Do not remove <ds:X509Certificate> and </ds:X509Certificate>
Cisco dCloud
3. Save the file and proceed to the next task.
Task – Configuring the claim rules
In this task, we are configuring the claim rule to indicate what information we are sharing.
1. Return to AD FS console and click Next again. If the Federation metadata file location: is blank, please choose the ESA1
metadata file again from the Desktop > SAML (ESA1) folder.
2. Enter the Display Name as ESA1 and click Next.
3. Keep the remaining steps with default selection, click Next (3 times) and click Close. The Edit Claim Rule dialog should be
open when the wizard is closed.
4. Click Add Rule…
5. Select Send LDAP Attributes as Claims from the Claim rule template dropdown. Click Next.
6. Enter ESA1 in the Claim rule name field.
7. Select Active Directory for the Attribute store.
8. Select the following values from the drop-down menu to map the LDAP attributes:
LDAP Attribute (Select or type to add more) Outgoing Claim Type (Select or type to add more)
SAM-Account-Name Name ID
Cisco dCloud
Token-Groups-Unqualified Names Group
9. Click Finish and click Apply.
10. Click OK to close the Edit Claim Rule dialog box.
Task – Create custom users and groups on AD1
In this task, we are going to add two custom users and two custom groups in the AQF’s Active Directory Environment.
1. On the AD1 desktop click the icon on the taskbar labelled Active Directory Users and Computers.
2. Right-click on the Users directory. Select New > User from the menu.
Cisco dCloud
3. In the First name box type ESA, Last name box type Admin and then type esa-admin as the User Logon name. Click on Next.
De-select the User must change password at next logon and then select the Password never expires box. Type
C1sco12345 in the password and confirm password box. Click the Next box and click Finish. dCloud: The Cisco Demo Cloud
4. Repeat Step 2 & 3 to create another new user account – esa-guest.
5. We are going to create 2 custom groups and place those newly created user accounts into each group respectively. Right-click
on the Users directory. Select New > Group from the menu.
Cisco dCloud
6. Enter ESA Admin Group in the Group name field and click OK.
7. Repeat Step 5 and create another group – ESA Guest Group.
Cisco dCloud
8. Look for the username ESA Admin in the Users directory. Right-click the username and select Add to a group…
9. In the Enter the object names to select field, type ESA Admin Group and click OK.
10. Click OK to acknowledge the notification box.
11. Right-click the username esa-guest and select Add to a group…
12. In the Enter the object names to select field, type ESA Guest Group and click OK.
Cisco dCloud
13. Again, click OK to acknowledge the notification box.
14. Close the remote desktop session for AD1 to return to the Workstation’s desktop.
NOTE: Please ensure the user account is added to the appropriate group. Adding the user account to more than one group may
result in inconsistent outcome.
Task – Enable external authentication
Return to ESA1 (on Chrome browser), we will enable external authentication and use the Active Directory (SAML) to authenticate
the users who login to the ESA1.
1. On ESA1, navigate to System Administration > Users. Click Enable under External Authentication
2. Under Authentication Type, choose SAML
3. In Group name in Directory, enter ESA Admin Group and select the role as Administrator.
4. Click Add Row
5. In Group name in Directory, enter ESA Guest Group and select the role as Guest.
Cisco dCloud
NOTE: Group Names are case-sensitive. They must be identical to the AD group entries in order to succeed the SAML based
authentication on Cisco Email Security.
6. Click Submit.
Task - Confirm Single-Sign-On (SSO) functionality with external user credentials
We are almost done; we will now test our work to ensure that our new logins are working properly.
1. Remain on the ESA1 browser tab, highlight Options in the upper right-hand corner. Then click Log Out.
2. Click the Use Single Sign On button below the Username and Passphrase fields
3. Let’s try to sign on with the external user credentials dcloud\esa-admin and the password C1sco12345. Click Sign in.
Cisco dCloud
4. The login should be successful. Click Options again in the upper right-hand corner and click Active Sessions.
5. The external username esa-admin should be assigned with the role as Administrator.
6. We have successfully demonstrated the ESA1 single sign on via SAML authentication method.
7. Log out from the ESA1 again and type chrome://settings/clearBrowserData on the address bar.
8. Click Clear data to clear the SAML cookie session.
Cisco dCloud
9. Click ESA1 bookmark. A warning presented, click Advanced and Proceed to esa1.dcloud.cisco.com (unsafe).
10. Now you will try to login with another external username – esa-guest via Use Single Sign On option. Enter dcloud\esa-
guest and the password C1sco12345. Click Sign in.
11. The ESA1 login should be successful. Click Options again in the upper right-hand corner and click Active Sessions. The
external username esa-guest should be assigned with the role as Guest.
Cisco dCloud
NOTE: Close the Chrome browser or visit chrome://settings/clearBrowserData as you need to clear the SAML session cookie
before proceeding to the next lab scenario.
Task – Disable Single Sign-On (Clean-up)
Congratulations, you have now completed the “Sign Sign-On” portion of the lab. Before proceeding to the next lab scenario, please
disable the “External Authentication” setting in the ESA1 portal.
1. Remain on the ESA1 browser tab, highlight Options in the upper right-hand corner. Then click Log Out.
2. Do not click on the link “Use Single-Sign On”. Please login to the ESA1 with username: admin and passphrase: C1sco12345
3. Navigate to System Administration > Users. Click Edit Global Settings under External Authentication
4. Un-check Enable External Authentication.
5. Click Submit.
Cisco dCloud
Scenario - Support for Unified Common Event Format (CEF) based Logging
As a loyal customer of Cisco Email Security solution, AQF traditionally uses Message Tracking to track and look for specific events.
However, the SOC team began to notice a huge number of logs and email events and would like to consolidate all events for an
email transaction, into a single log line, so that they are able to consume those events in a 3rd party product for a better analysis.
In order to address such concerns, the SOC team has decided to create a new log subscription that consolidates all events in a
Single Log Line, containing chosen headers for the message details, such as sender, rcpt, message ID, etc., and also verdict
information (AS, AV, OF, etc.) and the final actions to apply.
Common Event Format (CEF), RFC3164, is a Logging and Auditing file format, by ArcSight - a standardized Syslog format. Since it
is relatively simple to generate and parse, it reduces disk consumption and allows for faster indexing, on top of being transport
independent and the preferred log format for many SIEMs to ingest those same logs.
On top of it, the Cisco Email Security solution also supports Amazon S3 (Simple Storage Service), offered by AWS, making it that
much easier to export and consume the logs, by placing them into a S3 bucket.
Objective
This scenario will demonstrate how to create a new CEF log subscription that consolidates all events for an email transaction, into a
single log line for easy export to a 3rd Party reporting tool – Splunk.
Mission
Your goal is to create a new CEF log subscription with the Single Log Line (SLL) feature on Cisco Email Security. These are the
high-level tasks you need to perform to complete this exercise.
• Create and configure a new Log Subscription profile in ESA1.

• Choose the appropriate Consolidated Events Logs.
• Create a new TCP Data Input in Splunk to ingest the Single Log Line events created.
• Send a batch of email events – the logs referring to these emails should be searchable in Splunk.
Steps
Task – Change a TCP data input in Splunk Enterprise
1. From the Workstation, launch Google Chrome. Click the bookmark for Splunk. A new tab with Splunk will be created.
2. Log in with the following credentials: -

Username: admin
Cisco dCloud
3. Click the Settings Menu and select Data Inputs.
4. Under TCP section, click + Add new.
5. Choose TCP on the right pane and configure the instance to listen on port 514, since that is the port our log subscription listens
to. Leave the rest at the default values. Click Next.
6. In Input Settings go to Select Source Type and hoover over Miscellaneous, choosing generic_single_line
Cisco dCloud
7. In App Context choose Search & Reporting (search)
8. Leave the rest of the options as the default parameters. Then click Review, on the top right corner
9. You can now review all the Options for the New TCP Collector created. Click Submit to save the change.
Cisco dCloud
Task – Create a new log subscription profile in ESA1
This task is to create a new log subscription for consolidated event logs and choose the appropriate log fields that you will going to
export over to Splunk Enterprise via Syslog (TCP/514).
1. Open a new browser tab in Chrome. Click the bookmark ESA1 and log in with the following credentials:
Username: admin
2. Navigate to System Administration > Log Subscriptions. Click Add Log Subscription.
3. In Log Type, choose Consolidated Event Logs
4. Using the following settings configure the new Log Subscription.

Log Name: ESA_CEF
Log Fields: - Highlight the following inside the Available Log Fields:
o AMP Verdict
o AS Verdict
o AV Verdict
o Message Filters Verdict
o Message Final Action
o Message Final Action Details
- Click: Add
Retrieval Method: - Choose: Syslog Push
Cisco dCloud
- Hostname: 198.18.133.110
- Protocol: Default (TCP)
3. Selected log fields displayed here

1. Select specific log fields
2. Click “Add”
5. Click Submit
Task - Generate random messages to ESA1
Once we have the CEF based log subscription configured in the ESA1, it is time for us to generate some messages into ESA1 and
receive the visibility of those message logs via Splunk Enterprise portal.
sub-folder named Single Log Line.
Cisco dCloud
2. Double-clicking at the send-email.bat and acknowledging the Run button when prompted.
NOTE: After message injection is completed, it will take about 6 - 10 minutes for those CEF logs to become searchable in the
Splunk Enterprise web portal. Please feel free to take a bio break!
Task – Search CEF logs in Splunk
It’s about time for you to do a log searching in the Splunk Enterprise and make sure the CEF log field are populated appropriated
in the search result.
1. On Chrome, return to the Splunk tab. Go to Apps and click Search & Reporting
2. Under What to Search box, you should see the event value is continuously increasing.
Cisco dCloud
3. It is not necessary for you to wait for all the CEF logs to be imported to Splunk. Click Data Summary button to see the events
that account for those search parameters. In the Data Summary, click the host – esa1.dcloud.cisco.com to view the CEF
logs. dCloud: The Cisco Demo Cloud
4. You should be able to see something similar as below shown:
5. Choose one of the events in the right column, and click the > icon to expand further on a specific event:
6. Click the > icon button (again) to revert the log event back to normal view.
Cisco dCloud
Task – Generate a report with imported CEF logs
One of the main differences with using Syslog to parse and build reporting based on multiple line events, is that you need to
leverage add-on applications or plug-in that allow for some sort of integration with SIEMs. Now, with CEF formatted log event, one
can natively produce reports by simply adding them into a Widget/Dashboard. Let’s try it out!
1. On the left panel of Splunk Enterprise portal, search for ESAASVerdict (ESA AntiSpam Verdict) in the Interesting Fields. Click
it to display its properties. Click Top values.
2. A bar chart will appear for the Top Values in terms of ESA AntiSpam Verdicts found.
3. Hoover over Bar Chart and change to a Pie Chart.
Cisco dCloud
4. You will see the data represented in a Pie Chart
5. You can save this search as Dashboard Panel. Click Save As button and select Dashboard Panel.
6. Select New Dashboard and enter ID as ESA1_Dashboard. Type AntiSpam Status in Panel Title and click Save.
Cisco dCloud
7. Click View Dashboard.
8. You should be redirect to ESA1_Dashboard page.
Cisco dCloud
Scenario - Ability to Safe Print Message Attachments

Use Case
As advanced threats constantly evolve to find new ways around traditional security signature-based and reputation-based
prevention measures, Cisco is constantly adapting and introduces more sophisticated features to all its customers. SafePrint is
able to look at emails with attachments and, depending on the file type we want to select for safe printing, effectively creating a flat
sanitized file and disabling any active content in those files in real-time. SafePrint strengthens companies file protection strategy,
by proactively removing any possibility of end-users clicking malicious content in files.
AQF decides to enable this out-of-the-box, included feature in their Cisco Email Security solution. The company’s purpose is not to
determine or detect what is the malware's functionality but effectively remove the possibility for end-users to click malicious content,
or be infected by malware, opening files that are not approved within the Companies Corporate Policies. On top of it, end-users will
be able to still view the Safe Print version of the files, with the possibility to request that the Original file is released to them.
Objective
This scenario will demonstrate how to enable and configure SafePrint feature and corresponding options. You will be able to stop a
potentially malicious macro-enabled file but still be able to view its content in a safe and protected manner.
Mission
Your goal is to learn how to enable and configure SafePrint on Cisco Email Security (esa1.dcloud.cisco.com) running on version
13.0. These are the high-level tasks you need to perform to complete this exercise.
• Enable and Configure the SafePrint Global Settings

• Create a new Incoming Mail Content Filter with SafePrint as the action.
• Send an email with a macro-enable attachment, guaranteeing that SafePrint is protecting the Inside users (Alan).
• Understand how SafePrint works and what the resulting SafePrinted version of the Original file looks-like
Steps
Task – Enable and configure SafePrint global settings
1. Launch Google Chrome. Click the bookmark ESA1 and log in with the following credentials:
Username: admin
2. Navigate to Security Services > Scan Behavior. Scroll the page down and click Edit Global Settings.
3. Scroll down and look for the Safe Print Settings section. Provide the following information for the Safe Print Settings:
File Type Selection: Click: Select All
Watermark: - Choose: Enabled

- Enter Custom Text: SafePrint
Cover Page: - Choose: Enabled

- Enter Custom Text: This is a SafePrint version.
Cisco dCloud
Task – Create a Content Filter
This task will create a new content filter to identify macros in documents and take an appropriate action on that message – safeprint
the document, which in turn will send a sanitized copy in PDF format to the intended recipient(s).

Name: safeprint
Condition: - Attachment File Info > File Type > Is > Documents
Action 1: - Choose: Quarantine

- Send message to quarantine: Policy
- Select: Duplicate message
-
Action 2: - Choose: Safe Print
- Action for attachment(s): Safeprint all attachments
- Strip unscannable attachment(s): Yes
-
Cisco dCloud
3. Click OK
4. Click Add Action.
5. Click OK.
6. Again, click Add Action.
Cisco dCloud
7. Click OK.
Cisco dCloud
2. Place a checkmark against the content filter safeprint created in the previous step to enable it.
3. Click Submit to create the content filter and verify the policy.
Task – Send an email with an attachment
With the pre-requisite configuration in place, the SafePrint feature can now be tested by sending an email from Ben to Alan and
checking how the ESA will protect Alan from this unauthorized attachment.
1. Launch Putty located on the taskbar and select ESA1 from the Saved Sessions and click Open.
Cisco dCloud
Subject: Safe Print Test
Body: Safe Print Test
Attachment: Test.docx - located on the desktop under the dCloud Files > SafePrint sub-folder
5. Navigate back to the ESA1’s CLI to observe the underlying mail processing. ESA1 detected the file “TestDoc.docm” and
successfully SafePrint it.
6. Hold down the [Control] + [C] keys on your keyboard to stop the [tail mail_logs] operation.
7. Navigate back to Alan’s inbox in the Outlook client and make sure the email is downloaded. You will notice the TestDoc.docm
file is now converted into a sanitized safe_print_TestDoc.pdf.
Cisco dCloud
8. Double-click the safe_print_TestDoc.pdf file. In the Dialog box, click Open
9. You will see the cover page that you created for SafePrint documents
10. Scrolling down the PDF file. It will show you the content of the file as well as the watermark texts SafePrint that you have
configured in the Safe Print global settings.
11. Return to the ESA’s GUI and navigate to Monitor > Safe Print to view what is being reported.
Cisco dCloud
Task – Release the original document from ESA1’s quarantine zone
Let’s assume the sanitized PDF copy has been reviewed by the Alan and he is requesting the ESA administrator to release the
original document as it has been verified as a valid and clean document.
1. On ESA1, navigate to Monitor > Policy, Virus and Outbreak Quarantines
2. Click on the value under Messages that belongs to Policy to display the list of quarantined messages.
3. Note the subject header, place a checkmark against the message and click the Release button, acknowledging the action by
clicking Confirm when prompted.
Cisco dCloud
4. Navigate back to the outlook client and force the mailboxes to synchronize, the message will now appear in Alan’s inbox with
original document attached.
Cisco dCloud
Scenario - Improved Phishing Detection Efficacy with Cisco Cloud URL Analysis (CUA)
An increasing number of URL based email attacks have been observed by the SOC team within these few quarters. Most of these
campaigns involve the use of emails that contain embedded links as the content and enticing the employees to a phishing or
malware infested website which designed to steal personal or confidential information. However, solely depending on the
conventional IP based reputation detection and URL Filtering (both reputation and categorization) services to combat against this
threat is not effective as many of suspicious URL detected by Cisco Email Security gateway (ESA) were resulted in "unknown" as
the final verdict. The SOC team is demanding more proactive measurement to intercept those threats and re-assess thoroughly
before they reach to the employee's mailboxes.
Objective
This scenario will demonstrate how to Cisco Email Security (ESA) address efficacy gaps against URL based email attack through
the improvement in URL reputation infrastructure. With the greater integration of ESA and Talos intelligence services, this new
feature - Cisco Cloud URL Analysis (CUA) is performed seamlessly along with others security features in ESA leading to increases
in efficacy for URL based phishing threats.
Mission
Your goal is to discover and understand how Cisco Cloud URL analysis (CUA) work with Talos, leverages URL reputation service
to deliver latest verdict and mitigate the URL phishing attack by blocking the malicious message on the ESA.
• Enable new service on ESA to support phishing detection.

• Enable Outbreak Filter to detect and quarantine message that embedded with suspicious URL.
• Send a test email that contains a phishing or malware-infested URL.
• Observe how CUA bringing email context into URL analysis to combat phishing attack
Steps
Task – Enable URL Threat Detection on Outbreak Filters
Cisco Cloud URL Analysis (CUA) relies on Outbreak Filters to provide better phishing efficacy against URL threats while reducing
the latency of URL and IP reputation delivery back to Cisco Email Security.
1. On the Chrome browser, click the ESA1 bookmark to access to the classic GUI and login in with the following credentials: -
Username: admin
2. Navigate to Mail Policies > Incoming Mail Policies and click the link under the Outbreak Filters column to open the setting
page.
Cisco dCloud
3. Under the Message Modification section, place a check mark against the Enable message modification. This is required
for non-viral threat detection (excluding attachments).
4. On the top section, look for Maximum Quarantine Retention. Change Other Threats: retention period to 20 Minutes.
5. Click Submit.
6. Once completed, it is mandatory to commit your changes – click the yellow box at the top right corner to take effect the new
changes. Give an optional comment and click Commit Changes again.
Task – Verify URL Filtering and Service Logs
URL Filtering and Service Logs are equally crucial for CUA to functions properly in Cisco Email Security. Let’s take a quick walk
through to ensure both services are enabled prior to test the CUA feature.
1. Navigate to Security Services > URL Filtering and make sure URL Category and Reputation Filters is Enabled.
2. Navigate to Security Services > Service Logs and make sure the Sharing Setting is set to Enabled.
Cisco dCloud
Note: Sender Domain Reputation (SDR) and all other security services such as Anti-Virus, AMP, Graymail Detection are highly
recommended to be enabled in Cisco Email Security to increase the coverage and accuracy of Outbreak Filter’s detection against
URL threats. dCloud: The Cisco Demo Cloud
Task – Configure Anti-Spam Setting
Outbreak Filter releases the suspicious message when the retention period is over. The released message will be re-scan by Anti-
Spam and action will be taken if the URL contained in the message is convicted as malicious or phishing URL. This task will review
the Anti-Spam setting and make a subtle change on it.
1. Navigate to Mail Policies > Incoming Mail Policies. Click within the Anti-Spam box of the Default Policy.
2. Under Apply This Action to Message: option of Positive-Identified Spam Settings, choose Drop from the drop-down.
3. Scroll down the page and click Submit.
4. Commit your changes – click the yellow box at the top right corner to take effect the new changes. Give an optional comment
and click Commit Changes again.
Task – Initiate a CLI Session to Observe the Process Flow
Initiate a connection to ESA1 from the CLI in order to view, using the tail command (tail mail_logs), the mail logs to see the
message being processed and the actions being applied as it works its way through the pipeline.
2. Login the CLI session with same admin’s credential (username: admin and passphrase: C1sco12345). Issue the command
tail mail_logs and press [Enter] on your keyboard.
Cisco dCloud
3. Leave this CLI session running in the background and proceed to the next task.
Task – Simulate a Phishing Attack via Email
This task will simulate the sending of an incoming email with a phishing URL in the email content. The phishing URL is benign and
will not cause any damage to the lab environment, however Cisco URL Analysis (CUA) will treat this URL as phishing and
subsequently re-scanned and quarantined by Cisco Anti-Spam service (CASE).
1. Launch the Microsoft Outlook. Simulate a phishing attack using Ben’s mailbox with the following parameters.
Subject: CUA Test
Body: http://phish.threat.example.com/test/<company>/<your email address>
Example: http://phish.threat.example.com/test/dcloud/ben@dcloud.cisco.com (Please do not re-use this URL)
2. Send the message – Microsoft Outlook will display a warning about unsafe files, click Yes to ignore this.
4. Switch back to the CLI (PuTTy) and notice how the CUA leverage Outbreak Filter feature during the scanning process and
quarantine the suspicious message.
5. Observe the initial verdict of Cisco Anti-Spam engine (CASE) upon this phishing email is Negative.
Cisco dCloud
6. Once the Anti-Virus, AMP and Graymail engine passed their verdicts, the Outbreak Filter perform a threat assessment of this
message and replied the threat level as 5 indicates that there is a high risk of its content being a phish threat, hence redirected
it to “Outbreak” quarantine zone for further analysis by Cisco CUA. dCloud: The Cisco Demo Cloud
7. Return to ESA1’s GUI. Navigate to Monitor > Policy, Virus and Outbreak Quarantines, notice that the message is now
quarantined as per the configured Outbreak Filter policy while a verdict is returned from Cisco Cloud URL Analysis service.
NOTE: It can take about 20 minutes for ESA to release the phishing message from PVO Quarantine zone, please leave the CLI
session running and come back after a short bio break!
8. After 20 minutes later, navigate back to the CLI (PuTTy) session to observe the quarantine exit scan. The message has been
released and re-scanned by Cisco Anti-Spam (CASE).
9. Cisco Anti-Spam (CASE) received the latest verdict from Cisco CUA (via URL reputation service) and convicted this message
as Positive Identified Spam with Drop action applied to it.

Cisco Email Security Solution Lab v2.0

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cisco Email Security Solution Lab v2.0

Uploaded by

Copyright:

Available Formats

Cisco dCloud

Cisco Email Security Solution Lab v2.0

About This Demonstration

● Laptop ● Cisco AnyConnect®

About This Solution

Figure 1. dCloud Topology

Alan - alan@dcloud.cisco.com Ben - ben@dcloud-out.cisco.com

PREPARATION IS KEY TO A SUCCESSFUL PRESENTATION.

2. Initiate your dCloud session. [Show Me How]

NOTE: It may take up to 10 minutes for your session to become active.

Workstation 1: 198.18.133.36, Username: administrator, Passphrase: C1sco12345

• Email Source and Content Inspections

• Advanced Malware Protection

• Sender Authentication Mechanisms

Scenario - Protecting Against Malicious or Undesirable URLs

Use Case dCloud: The Cisco Demo Cloud

Task – Send an email with malicious URL

Subject: URL Filtering Test

dCloud: The Cisco Demo Cloud

Task – Configure a Content Filter

4. Using the following settings configure the Conditions and Actions.

Condition 1: - No condition is required in this lab scenario

dCloud: The Cisco Demo Cloud

6. Click Submit to apply the actions.

Task – Edit Incoming Mail Policy

dCloud: The Cisco Demo Cloud

Task – Enable URL Filtering

2. Log in using the credentials listed earlier in this document.

Task - Testing URL Filtering

Subject: URL Filtering Test

Task – Testing URL Filtering for Attachment

Subject: URL Filtering - Attachment

Body: URL Filtering - Attachment

Scenario - Outbreak Filtering

Use Case dCloud: The Cisco Demo Cloud

Task – Create an Outbreak Filter Disclaimers

1. For this task, let’s create an Outbreak Filter Disclaimer.

3. Name the new disclaimer as OFDisclaimer

4. Choose Type as Disclaimer Template

5. Add the following statement in HTML box as shown below:

dCloud: The Cisco Demo Cloud

Task - Configure Outbreak Filter setting

4. Under Threat Disclaimer, choose OFDisclaimer

dCloud: The Cisco Demo Cloud

Task - Testing Outbreak filters

Body: Outbreak Filter Test

dCloud: The Cisco Demo Cloud

10. Click Confirm to acknowledging the action when prompted.

Scenario - Forged Email Detection

Task - Sending a Spoofed email

Subject: FED Test

Body: FED Test

dCloud: The Cisco Demo Cloud

Task - Creating a Content Dictionary of Terms

2. Populate the dictionary with the following information:

Add Terms: crobbins

3. Click the Add Button to add the terms to the dictionary.

dCloud: The Cisco Demo Cloud

4. Click Submit to create the dictionary.

Task - Create a Disclaimer Template

2. Name the new disclaimer as SpoofWarning

3. Choose Type as Disclaimer Template

4. Add the following statement in HTML box as shown below: