×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

Ironport c160 email encryption

Unanswered Question
Apr 24th, 2014
User Badges:

I understand and support the automatic encryption of our outbound emails.  In an attempt to possibly make it better, is there any method using our existing C160 email security appliance that can warn the sender that a message will be automatically encrypted prior to it going out?  Doing so could allow the user to choose to have it encrypted or not.  We have a subject tag "!m" that the user can type to force unsecured... but many times they have to do this after the fact they get an email from the C160 saying that the email was encrypted.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Robert Sherwin Thu, 04/24/2014 - 15:40
User Badges:
  • Cisco Employee,

When using the subject line flag and encrypt --- no... something like this probably wouldn't be feasible.

But - if your end-users are using Outlook - then the Outlook Encryption Plug-in is what you are after --->


 

Full details in the Encryption 7.3 Admin Guide:

http://www.cisco.com/c/dam/en/us/td/docs/security/iea/plugin7-3/Cisco_Email_Plug-in_7-3_AdminGuide.pdf

 

-Robert

keithsauer507 Fri, 04/25/2014 - 06:53
User Badges:

Ok.  Well a few years ago we tried the Outlook plugin but we would occasionally get crashes.  It would be very cryptic error messages like "Offset at (random hex address)  (OK)".

Now again that was a few years ago so maybe things have changed.

 

Would this work on Outlook 2013?  While the majority of users are 2010, there have been a few 2013 installs going out as we cannot get PC's with 2010 anymore.

 

I guess next thing is, I'll search the site to try to find this plugin and test it.  The biggest complaint our employees have is when the IronPort just encrypts a message without warning.  We do have it programmed to reply to the sender with which policy it hit on.  Many times its Policy Name: abanumbers even if there are no ABA numbers (could just be a string of numbers in a file attachment for example).  I guess if we use the plugin instead we would turn off all auto encryption options and then let the Outlook plugin / user decide?

Look, I don't even know why aba numbers should be encrypted.  They are public information.  Go to just about any financial institutions website and at some place they publicly state their ABA number.

Robert Sherwin Fri, 04/25/2014 - 07:15
User Badges:
  • Cisco Employee,

Yes - 7.3 version of the plug-in supports Outlook 2013:


(c/o: http://www.cisco.com/c/dam/en/us/td/docs/security/iea/Compatibility_Matrix/IEA_Compatibility_Matrix.pdf)

Click here for the Plug-in downloads.  You will need a CCO login to access the downloads.

As for the complaint against "encrypts a message without warning" --- that just really starts to get into end-user education of what is active in the environment.  If you have DLP in play on the appliance, and one of the set defined policy is Privacy Protection -> ABA Routing Numbers, then the appliance is only doing it's job, as you have configured.  If the end-users should be sending through a relay/outbound mail flow policy, and you don't want that group/end-users to be susceptible to the DLP  scanning, you'll need to configure them into an outgoing mail policy that doesn't have DLP enabled... or, has DLP enabled but not ABA Routing Numbers.

Using the plug-in and allowing the end-users to decide if they want to encrypt/not encrypt is only going to be the initial reaction of that end-user.  With the plug-in, you may be removing the need to use the subject line encryption flag in order to provoke encryption, but any/all mail from that end-user through the ESA will still be susceptible to the configuration and encryption actions set.  

You should leave the subject line trigger in place (either via message filter or content filter) - but, be sure to re-educate the end-users that may be using the plug-in to fully understand the right/wrong as you intend encryption to be handled.

-Robert

keithsauer507 Fri, 04/25/2014 - 07:26
User Badges:

Ok great, thank you.

 

Today the thing is that a user could send a harmless email.  Then they get a message back from the Ironport saying "your message was encrypted due to this policy: (policy name)."  Under that it explains each policy name and what they do.  So now frustrated beyond belief, the user has to go back in their Sent Items folder and forward the message back to the recipient and put a subject tag !m: in the front (eliminating the Outlook created FW:).  Each encryption policy has an "out"... basically if !m: is in the front of the subject, it stops processing that encryption policy.  Henceforth the second email with the proper subject tag overrides the encryption and the end user is happy again.

I see that the plugin has an encrypt message button (it's grayed out on me, but I didn't go through all the complex configuration steps yet).  It would also be nice if there was an Override Encryption toggle below Encrypt Message, so the end user could be 100% certain the message going out will not be encrypted.

 

Were not sure why but most recipients have a hard time with opening encrypted emails.  ESPECIALLY vendors.  They usually come back with "I can't open that attachment"  or "I don't have a password".  So just to get work done we resend it with the override tag.  Sometimes I'm not sure why technical vendors can't read the simple instructions how to create a CRES account.  Or I don't know if some people think a CRES account is different for each organization using it.  It's just a clunky solution for many end users, especially those with generic mailboxes like [email protected].

 

So an override is nice - OR out of the box we encrypt nothing unless the end user clicks that button.  That itself would be a discussion for the higher ups of the company.

 

keithsauer507 Fri, 04/25/2014 - 08:08
User Badges:

Thanks, I went through that got the file signed, renamed it to config_1.xml added the accountfilenames filepath=config_1.xml in the CommonEncryptionConfig.xml and reinstalled it using this command line:

C:\Users\sauerk\Downloads\ironport>CiscoIronPortEmailSecurity_7-3-1-005.exe /exe
noui /qn UseCustomConfigs=C:\Users\sauerk\Downloads\ironport

but encrypt is still greyed out.

 

I even uninstalled the plugin first.  I don't know, we may not use this if its not going to be easily mass deploy-able.

Robert Sherwin Fri, 04/25/2014 - 11:35
User Badges:
  • Cisco Employee,

*I ping'd and worked with Keith directly to address install and loading of the BCE XML.  

Let me know if you have any other issues/questions!

-Robert

Actions

This Discussion