The Cisco Ironport is an appliance that is deployed into an existing mail infrastructure. All emails are sent to the IronPort and the IronPort is either the last point out (most common configuration) or it can process email and then send it back to the mail server where it is sent out.
Although Microsoft Exchange is the supported mail server, we were able to use Ironport successfully with our test hMailServer by setting up simple SMTP rules to route email to Ironport. We set up several DLP scenarios using both built-in and custom policies. All of the tests we ran blocked or quarantined restricted content or attachments without incident until we attempted to use a custom rule to block XML files from being sent as an email attachment. The following screenshot from the Ironport console shows the setup. We ran tests using different various clients and the result was the same; we were able to send XML files. Cisco engineers were helpful in trying to resolve the issue, but in the end admitted there was a bug in the XML rule that is scheduled to be resolved in the next security release. In the meantime they provided us with a work-around that allowed us to successfully block XML files. The workaround involved creating a custom expression that evaluates the file content to look for a string match: \<\?xml\sversion="[0-9].[0-9]"\sencoding="
By installing the Cisco AnyConnect VPN client on our iPhone we were able to test a mobile endpoint by attempting to send a list of credit cards embedded in the body of an email message. IronPort applied the rule to quarantine the message and blocked it from being sent out.
The IronPort comes with on-screen DLP reporting that can be used to drill down by various categories such as users and violations, with date/time parameters. The on-screen reporting is nicely formatted and can be printed to PDF; there is also the option of exporting report data in CSV format. We did not find any capability to create custom reports.
Pros:* Compact 1U appliance, no need for additional hardware, easy to plug into existing network* Email channel protection worked across the board without regard for which email client we used* Efficient trouble resolution - When Cisco engineers became aware of the XML file rule not working as designed they immediately recorded this in their internal issues database, fondly named 'bugzilla,' and provided us with an issue ID. More importantly they quickly supplied a workaround that allowed us to block XML files using a different type of rule.
Cons:* Several steps are needed to apply rules and these are not necessarily intuitive* Reporting lags events - although we were able to get real-time event information from the email logs, it would be nice if the higher level reporting tools could synchronize more quickly
Read more about wide area network in Network World's Wide Area Network section.