Cisco IronPort E-mail Security Appliance Best Practices : Part 1

I’ve cheekily phrased this blog article as a best practice guide to setting up/configuring your Cisco IronPort email security appliance. However I must make clear that the below is what I deem to be best practices/configuration. Every environment is unique so please make sure you understand what you are doing before attempting to implement any of my suggestions below. So, let’s get started! The suggestions below are in no particular order.

Quarantines

1. It is a good idea to create separate quarantines for different items you expect to be in the quarantine. For example, it is easier to manage your quarantines if there is a one for ‘bad’ attachments, one for URL filtering, etc.

Incoming Content Filters

1. Have a content filter to block actively exploited threats. For example, I have a content filter called quarantine_active_exploits that blocks .rtf attachments (because of the recent Microsoft RTF 0-day that can execute code just by viewing an attachment in Outlook) and bounces back a message to the sender to inform them that their message has not been delivered, the reasons why and what they can do to get their message to go through. Obviously once the exploit is patched, the content filter will be modified to reflect that.
2. A content filter to block executables or allow ONLY certain extensions is definitely a must for an email security appliance. Either have a content filter to block a list of ‘dangerous’ extensions (don’t bounce any of these messages) or one that will only allow a list of ‘safe’ extensions. The latter is obviously more secure but will probably cause you more of a management overhead/annoyance in the long run 😉
3. A content filter to quarantine failed SPF messages will help reduce the number of spam/phishing messages coming through your environment. SPF is basically a DNS record which states which hosts are allowed to send on behalf of a domain. So for example, only 100.100.100.100 is allowed to send from example.org. If your IronPort sees a message from example.org with the IP 200.200.200.200, it will be quarantined as the owners of example.org have said that nothing other than 100.100.100.100 is to be classed as legitimate. SPF is slowly becoming more and more popular; I recommend you set up SPF for your domain too if you can.
4. Add a content filter for URL filtering. Choose your categories as appropriate to your environment but the obvious ones are pornography, illegal downloads, proxy avoidance, etc

Outgoing Content Filters

1. A lot of people filter attachment types inbound but forget to do the same for outbound messages. If an internal machine is compromised and starts sending out malware to your customers, you’d probably want IT to be notified so they can identify and fix the issue asap.
2. Encrypt e-mails. Create a policy to encrypt e-mails that contain the word confidential in the subject line or messages with the header sensitivity=company-confidential (this header is set in Outlook when you mark a message as confidential in message composition options)

   

3. I’ll go in to this in more detail later on (in the encryption section) but it is a good idea to create content filters that encrypt messages that contain certain keywords in the message body or even in attachments.

E-mail Encryption

1. Edit your encryption profile so that the encryption algorithm is AES-256
2. Customise the encryption HTML template and make it a bit more personalised – company logo, policies, who to send an e-mail to if the recipient has troubles opening the encrypted attachment, etc
3. Personally I would recommend unchecking the box for Use Decryption Applet. The user experience is a lot better when the recipient doesn’t need to install Java or accept security warnings or other annoying pop-up messages just to open the secure message. I notice no performance or lack of functionality when I disable this checkbox – the secure attachment still opens in the browser – without the hassle
4. Select the radio box for Use the Cisco Registered Envelope Service URL with HTTPs.
5. This one is very important and I suggest you take some time doing this properly. Talk to all departments in your company and make a list of attachments or e-mail types that contain sensitive information that you/your company does not want to send out un-encrypted. Ideally you will have some example sensitive attachments so you can create unique regular expressions in content filters to encrypt messages that match the sensitive keywords. For example, let’s assume the finance team send out an attachment every month to an outsourced company with all employee salary and bonus details. I would ask the finance team for a copy of this attachment with all the actual numbers and figures blanked out. I would then look for keywords in the document or document name that would not normally be used in other documents. So let’s say this particular attachment has the keyword employee salary details in it. I would then create a regex in a content filter to match this particular keyword and encrypt all messages containing that keyword. Your mileage and environment may vary but it is usually a good idea to do something like this

Host Access Table (HAT)

1. Unless you absolutely have to and have no other choice, never put anything in the whitelist/trusted policies; especially if it’s a large subnet of IPs or domains as this could leave you wide open to attacks. If you do need to whitelist some IPs or domains, do NOT disable spam/virus checking otherwise you’re just asking for trouble.
2. Edit the default mail flow policy so that:
   Max. Concurrent Connections From a Single IP is not more than 2. Your environment may, for whatever reason, require external users more than that but it has never been an issue for me. Normal, well behaved e-mail clients should not open more than 1.
   Enable Directory Harvest Attack Prevention and set it to something low. I have mine set to 5. This will stop automated bots from attempting to guess and store a list of valid e-mail addresses
   Set TLS under Encryption and Authentication to preferred.
   Enable SPF/SIDF Verification
   Enable DMARC Verification
   Enable Envelope Sender DNS Verification – this hasn’t caused issues for me and it shouldn’t for you assuming sender domains and DNS are properly configured but that can be a dangerous assumption to make
3. Edit your sender group settings to enable the following: Connecting host PTR record does not exist in DNS. Connecting host reverse DNS lookup (PTR) does not match the forward DNS lookup (A)
4. I haven’t done this yet but I do think it is something I will implement soon – adding DNS lists; also known as DNS blacklists (DNSBL) and Real-time blackhole list (RBL). In your sender group settings, there is a field for DNS lists. Add well known, popular sources such as Spamhaus and SpamCop. These blacklists along with the Cisco senderbase network will make your ESA an almost unstoppable force against the evil of spam/malicious e-mail.

 Destination Controls

1. Change TLS Support to preferred

I hope this has been useful to you! If I have missed anything obvious from the list above, or if you have any comments, please share them below. I plan on creating a part 2 to cover some things I have missed such as DLP, bounce profiles, LDAP queries, and more so stay tuned!

Edit December 2014: Part two has been released!