Why Cisco’s ESA Could Be Right For Your Company

31069

A lot of organizations, from small companies to large enterprises, consider email one of their most important communication systems. Many people (including myself) are more apt to send an email than make a phone call or send a text. There are a few different reasons why using emails may simplify things:

Outreach & ease of use. You can quickly send an email to anyone if you have the right address. Including additional information in a form of attachment is trivial.
Convenience. Email messages don’t have to be “picked up” immediately. You give the other party time to think about the content and allow them to take actions to solve a problem/answer a question.
Tracking & visibility. You want to “log” what was sent to whom. As you already know, sending emails to intended recipients and “copying” other people is a common practice.

Unfortunately, email also serves as a potential gateway into an organization’s network, hackers know this and will try to use it to their advantage. Email threats and attack vectors can generally be broken down into three main categories:

Spam. This stands for unwanted/junk messages that you don’t really want to receive. At the very least they are irritating and time-wasting , at worst they can be very dangerous
Malware. Viruses, trojans & other malicious software can be easily attached to a message (typically legitimate-looking). According to Cisco’s Annual Cybersecurity Report, attackers turn to email as the primary vector for spreading malware.
Social Engineering. It is easy to spoof a message that appears to be legitimate (coming from a valid source such as your bank or CEO). This is often used by attackers to trick employees into revealing sensitive/confidential information in various phishing attacks. Those attacks are sometimes combined with more sophisticated techniques, such as homoglyphs (using fake domains containing text characters that are very similar or even identical to legitimate text characters).

Like everywhere in network security, it is nearly impossible to protect our environment from all attacks completely (spam, malware & social engineering are not going away any time soon ). However, we can certainly take some preventive measures to reduce the chance of a successful attack. Cisco’s Email Security Appliance (ESA) is a great example of an all-in-one solution that can be deployed to protect our email system. Continue reading to learn why the ESA is such a great tool to use in your network.

Design & Deployment

The Cisco Email Security Appliance is generally meant to act as a so-called Mail Transfer Agent (MTU), becoming the SMTP gateway to an organization. Its main role is to handle the transfer of all email connections – incoming (messages sent to your domain) and outgoing (messages sent from your domain, from the internal network). This way the appliance can see and inspect all messages, which is needed to scan their content, enforce connection limits, guard against spam and viruses, or enforce your custom policies built for different users in your organization.

In a typical design, the appliance is situated in the internet edge and it is connected to the firewall’s DMZ with as low as just one interface. This interface serves the data and management plane functions, allowing you to manage the device remotely and allowing the ESA to process all SMTP connections, including those coming from the internet (public IP address and correct MX DNS records are also required). An important thing to realize is that the appliance is supposed to act as the first email hop on the way in, and the last hop on the way out. This is needed to properly determine the sender’s IP address and match the correct policy. This concept, along with a typical email flow pattern, is illustrated below:

For incoming emails, ESA acts as a *first* hop for connections originated by SMTP servers belonging to external users. There is no other internal SMTP server that serves those connections before the ESA, thus allowing it to see IP addresses of SMTP servers relaying the original message. The messages are then inspected, and if allowed, relayed by the ESA through a separate SMTP connection established with the Internal SMTP Server. This is also where messages are stored so they can be further retrieved by the internal users via POP3 or IMAP (remember, SMTP is only used to “push” emails, not to download them).

The situation is slightly different in the second case when dealing with outgoing traffic. This time ESA acts as a *last* hop in the email chain, receiving the client-originated message relayed by the internal SMTP server last. Note that the message will still be scanned with the configured engines before it is eventually relayed by the ESA to the appropriate external SMTP server for processing.

The design illustrated above uses a single on-premise appliance (physical or virtual). All the ESA models have the same software features and differ only in the hardware platform, with some exceptions. The chief difference between the models is CPU count and speed, RAID disk count and mode, and the number of physical interfaces. However, there is no difference in the availability of software features. It is also possible to deploy ESA in the cloud or in a hybrid model. More information about currently available platforms, along with their specification, can be found in Cisco’s Email Security Advanced Email Protection Data Sheet on the Cisco website.

What can you do with it?

ESA uses multiple inspection engines capable of inspecting every single piece of an email message. It also offers a variety of smaller features, allowing you to control the connections at the TCP or SMTP level, modify certain portions of a message, and much more.

ESA functionality can be summarized in the so-called Email Pipeline, which illustrates how a new SMTP connection (and then the message) is processed by the appliance. The pipeline also shows us the order in which features and inspections are applied:

$C:\Users\IPexpert\Desktop\EmailPipelineBlog.png$

As you can see, the processing starts on a reception of a new connection (ESA is acting as a SMTP server). The two most important features applied at this stage are Host Access Table (HAT) and Recipient Access Table (RAT):

RAT allows you to control domains for which emails will be accepted (you normally configure it with your internal domain/domains only). This part is very important since that’s how ESA protects your organization from becoming an Open Relay (a SMTP server that could be used by anyone to send emails anywhere – quickly becoming a source of spam and malware).
HAT correlates email Senders (SMTP hosts connecting to the ESA) with Mail Flow Policies. Mail Flow Policies allow you, among other things, to set the connection thresholds and tell the appliance how to further handle the conversation (e.g. drop or allow and process as incoming or outgoing).

Workqueue makes the second phase of connection processing. At this point, ESA focuses on the actual message(es), where evaluation starts by checking the appropriate Mail Policy (incoming or outgoing, depending on the HAT results) looking for a match. A matching policy, typically tailored to the security needs of different user groups in the organization, triggers the inspection according to the configured policy engines (highlighted in gray). This is probably the most important stage in the Pipeline since that is what eventually controls what messages will be allowed to proceed to the transmission phase (the “Tx” column) to finally leave the ESA.

All right, so what exactly can be done with messages being inspected by the policy engines? A lot. Each engine was designed to combat a specific threat or to provide a certain functionality:

Anti-SPAM - examines the full context of a message - its content, methods of message construction, the reputation of the sender, the reputation of websites advertised in the message (URLs), and more. This information is then used to classify a message as Clean, Suspected, or Positive- spam.
Anti-Virus – includes integrated malware scanning engines from companies: Sophos and McAfee. These engines are used for the identification of different types of viruses, trojans, worms, and bots. They allow to repair infected attachments or to drop or even quarantine the entire message.
Advanced Malware Protection (AMP) – offers advanced file inspection capabilities, such as improved reputation scanning, file analysis, and cloud-based malware detection.
Graymail - detects and classifies graymail and then automatically presents recipients with a safe way to unsubscribe.
Content Filters – offer sophisticated filtering capabilities. Messages can be classified based on virtually any portion of the header or body, allowing the administrator to process them in custom ways (e.g. drop, save a copy or alter).
Outbreak Filters - block newly released viruses (0-day threats) and rewrite URLs known to point to phishing and malware websites.
Data Loss Prevention (DLP) – responsible for the inspection of outgoing emails (messages sent by local users to internal and/or external recipients). This communication path represents a serious risk because it allows employees to easily “leak” sensitive/confidential information to the public. This feature also allows organizations to comply with different state or federal regulations by classifying inspected messages based on their sensitive content (PII). Such messages can be then encrypted or simply not allowed to leave the network.

There are also several other features offered by the ESA giving you even more reasons to use it to protect your network, like Reputation Filters, Bounce Verification, Authentication/Integrity, DMARC or Encryption. More information about the policy engines and other ESA features can be found in the ESA End-User Guide on Cisco’s website.

If you now feel that ESA is something that could make your company a more secure and user-friendly environment, don’t hesitate to check out my latest CCIE Security v5 video series dedicated to this product. This course is meant to teach you ESA from the ground-up - you will learn how to deploy ESA in the field and how to configure, verify and troubleshoot some of its basic and advanced features.