Installing Symantec Encryption Server & Exchange 2010 Configuration Part2–Understand key Management

In part 1 https://autodiscover.wordpress.com/2013/05/21/installing-symantec-encryption-management-server-and-exchange-2010-configuration-part1/ we explored the basic steps to install the Symantec Encryption Server.

In This post, we will explore a very important aspect in any encryption solution, which is key management.

Introduction:

to understand what is public/private keys, check these link:

http://www.comodo.com/resources/small-business/digital-certificates2.php

http://blogs.msdn.com/b/plankytronixx/archive/2010/10/23/crypto-primer-understanding-encryption-public-private-key-signatures-and-certificates.aspx

If you read the above articles you will now realize that we will use public and private keys; While Microsoft uses x.509 certificate based on Microsoft CA which utilizes s/MIME to encrypt the messages, Symantec Encryption server uses PGP keys which uses different structure, keys are stored in PGP LDAP server (we will see how to import x.509 certificate to Symantec encryption server later).

Keys Provisioning:

In order for a user to obtain PGP keys, the user must register for PGP keys with the server, let use see the steps to do that.

To Configure email enrolment, first you need to define email route, this tells the encryption server where to send the registration emails and any emails send to your domain, from the control panel, go to mail > mail route and add email route to your server

When you download the Desktop encryption install package and install it on the machine, the client will detect automatically the encryption server and try to contact the server, since I don’t have a valid certificate on my server it will warn me; Click on always trust this site.

enter the email address:

the user will receive an encrypted email

once the user opens the encrypted email he/she can continue the registration:

verify the username and email address:

create a passphrase to protect your key (remember this step as we will talk about it later in details when speaking about the key storage types):

the key will be generated for the user:

now when you open the Encryption Desktop, you will see the keys and policies created by the encryption server assigned to the user:

in the console, you can see the list of managed keys as well:

If you click on the key mode button (from the Desktop Encryption window), you will see that the key is operating ins SKM mode; so what is that?!

Keys in Symantec Encryption Server operates in different modes, the modes are:

• Server Key mode: In this mode, the private keys are stored on the server and users can’t manager their keys
• Client Key Mode: In this mode, the private keys are not stored on the servers and users must manage their own private key and protect it.
• Guarded Key Mode: In this mode, a pass phrased protected private key is stored on the server and clients manage their key
• Server Client Key Mode: a sub key of the private key is stored on the server, the private key still stored on the client.

you must be very careful when selecting the key mode in your environment; depending on the key mode, you will have or lose some features as per the below table:

for the first instance, SKM might be the ultimate answer, but you have to be aware that administrators have control over private keys, so this might be a security concern.

To change the mode of the key being used, click on the reset key button and you will be taken through a page that will help you selecting the appropriate key mode.

you can also restrict the modes available in your organization, to do so, edit the consumer policy and change the available modes:

Installing Symantec Encryption Management Server and Exchange 2010 Configuration Part1

In this blog series, we will install together Symantec Encryption Server (previously known as PGP universal server) and configure it to work with Exchange 2010. Additionally we will explore some cool features around virtual disks, disk encryption and secure email delivery.

The Symantec Encryption Server binaries are certified to be installed as virtual and this is the recommended use from Symantec, and this is the method we will use in our environment.

Symantec Encryption Server can manage several different encryption products and solutions including:

• Symantec encryption email gateway.
• Symantec Encryption Desktop.
• Symantec File share encryption.
• Symantec Encryption portable.
• Symantec Drive encryption.

In this blog, we will install the Symantec Encryption Server v3.3, the latest version (at this time) of the product. There are several design and architectural decision elements that must be taken into consideration for several features to work; we will explore them later.

To install Symantec Encryption Server, download the ISO image and create a virtual machine, the documentation and install guide mandate that the VM must be created with Kernel 2.6 x86, 4 GB memory for single instance and 8 GB for HA instances.

Once you start the VM with the ISO attached, follow the simple install wizard that will take you through the installation steps:

In the IP address field, specify the IP address for the appliance:

Specify the Gateway and DNS servers:

Specify the host name; one important point is to note that your appliance MUST be named (keys.domain.com), this is mandatory if you want to cooperate with other PGP key servers. PGP keys servers contacts the recipients keys servers “if available” (if the server can’t locate a public key for the recipients) on keys.domain.com, thus if you want to facilitate exchange secure emails with external parties you must name the server’s FQDN keys.domain.com and this name must be reachable from outside.

Once you finish the wizard, the setup will start automatically, once finished the appliance will reboot and the post complete setup will be launched:

accept the license agreement

from the installation type, choose the installation mode. since this is the first server we will choose new installation.

set the time/date:

Confirm the IP settings:

Confirm the setup summary:

Reboot:

Enter the license information:

Enter the administrator information and password:

enter the primary domain that you use to send/receive emails:

To protect the server in case it is physcially attacked you must configure the ignition keys, I will use a passphrase as my ignition keys; enter them and continue:

review the setup summary:

Once setup completes you can login to the admin console on https://keys.domain.com:9000

This completes the Symantec Encryption Server installation, in Part 2 we will continue with the initial setup and keys management, part 2 and 3 will be fun, so stay tuned .

Thoughts on DLP in modern business…

What does it mean to implement DLP?? So far as I have seen; each vendor has his own view on how to enforce DLP within the organization and how to manage it.

The reason of what brought DLP to the surface is that I had a discussion with one of my customers on DLP enforcement and how to manage it within his infrastructure. While reviewing Email encryption solutions by Sophos and Symantec last week; I found that each vendor has his own concept “if we may call it like that” on DLP and how to manage and enforce it.

First, let me state my own view of DLP; DLP is a technology that helps the organization to own the information/data and prevent leaking those information/data out.

Modern information/data is stored in different locations now, some examples:

– ERP/CRM data.

– Email, Office files, PDF documents.

– SharePoint and similar portals.

– Laptops, USB memory sticks, and portable hard disks.

Helping any organization to control data on the above sources is not easy and could be done in several manners and ways, based on my findings; I will share some thoughts with people thinking about rolling out DLP in their infrastructure:

– DLP is not controlling physical ports (USB, serial, firewire ports..Etc).

– DLP is not DRM nor Encryption.

– Permissions help in controlling the data access, but when the data is accessed; a malicious consumer of the data could share them with 3^rd parties or leak them out either intentionally or unintentionally.

– Internal users do most of the hacks/leaks.

– Encrypting the data might help in DLP, but will not help in controlling what happens if a malicious user decrypted them or encryption algorithm is broken, Also encrypting the data might not help when the organization need to share All/some data with authorized 3^rd party.

– If the IT department secured physical ports/access, what about leaking the data out using corporate emails or worst, personal emails.

– How you will classify data as corporate and how you will classify data as none-corporate.

– Data classification is suitable for data stored in shared folders, but what about data in SQL/Oracle databases or data copied from documents and sent as emails.

– How data will be shared with 3^rd party and secured outside the organization’s control circle.

– Monitoring, logging and alerting, and feeding other 3^rd party security applications that are used by the security team.

– What about endusers experience, do we need any input from users?

– What about data in the cloud?!

As you can read from the above, DLP will never be a single solution/technology, DLP is a mix of solutions, technologies and processes that govern the data inside the corporate.

Hope that the above thoughts will shed some light and ring some bells in your head when thinking about DLP.