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.
* 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.
* 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
In what may be a first for the technology industry, RSA Conference 2015 next month apparently will be...
Website password strength meters, like a spouse asked to assess your haircut or outfit, often tell you...
With all the public cloud storage offerings on the market today, many vendors just want customers to...
Sponsored by AT&T
Sponsored by Brocade
Investors made a crowd around the cloud this week, investing $175 million in companies focused on...
The SDN project now has a security response team to quickly handle new vulnerability reports
Here's how many cybersecurity entry-level job seekers fail to make a great first impression.
As CIOs become overwhelmed by IT demands, chief data officers (CDOs) are stepping in to serve as a...