Deploying SEE Management Server to be Internet Facing

SEE Management Server supports several “cloud” platforms, however, it has not been certified
to be public facing. Although this is not certified and tested at this time, it is possible to make
this happen and has been accomplished in enterprise environments. This document goes over
recommendations to consider that have been implemented in similar situations.

SEE Management Server has a few different components to consider:

IIS to handle all SEE Client communications, as well as the communications channel for the
Web Helpdesk recovery page. Making the IIS service internet facing is necessary in order for
the SEE Clients to communicate with the SEE Management server without VPN, however, we
recommend placing security solutions between the actual IIS server and the internet. This
document will go over some of these scenarios.

Important Note: Symantec highly discourages making the SEE Helpdesk recovery page
available to the internet and should be done only with internally-protected connections.

The other component to consider in this scenario to protect is the SEE database managed by
MS SQL. These components should be highly secured and accessible only to the internal
network as it relates to the logical placement of the Symantec Encryption Management Server.
In other words, only the communications URL should be accessible from the internet and
nothing else.

The IIS and Database components are the key components to secure when considering this
scenario. Both of these must be protected from a security standpoint and before anything
opens the communications channel back to the IIS service, penetration tests should be done to
ensure the server where these reside are hardened.

Some common practices to make IIS available externally is to place the internet-facing IIS
servers in a DMZ behind a firewall with a second firewall between the DMZ and the internal
network. Other security practices have been used in the past, but this is needed at a very
rudimentary perspective. For security, it is discouraged to make available any Internet-facing
IIS servers that would be part of an internal Active Directory domain that would have access to
or use accounts that are part of this internal AD domain.

As has been mentioned, server hardening should be done thoroughly to ensure no internal
resources are made available, including, but not limited to keeping the server updated with the
latest OS patches, all security software, such as SEP be installed, and other applications
appropriate to protect the system.

Considerations:

● SEE Client communications over the internet should only ever be done using secure
HTTPS, designating a specific port. Typically the port for HTTPS is 443. Only the
necessary ports should ever be opened.

● SEE Clients communicate via an IIS account, which has credentials built in. As this is
the case (and why we recommend only HTTPS for client comms), this authentication
must be possible from outside the internal network and should be taken into account.
There are two authentication methods that would need to be considered:
●
SEE Client comms: Windows User Auth - This comprises the IIS account credentials
mentioned in the above bullet. The SEE Client installer generation process builds in
these credentials and will use these credentials for all communications back to the SEE
Management Server. The exception to this is if SEE RME is being used and takes
advantage of the Workgroup Key.

In the case of SEE RME with the Workgroup key, we use Computer Identity
Authentication.

TIP: Use the communications URL generated with the SEE Client to validate if the URL can be
resolved externally.

In the registry of the endpoint where the SEE Client is installed, check the following location to
obtain the communications URL:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Encryption Anywhere\Framework\Client
Database\ServerLocation

● DNS needs to be fully resolved back to the SEE Management Server. When the SEE
Client is created, there is a communications URL that is configured. A typical URL looks
similar to the following (if the FQDN is see.domain.dom:
https://see.domain.dom:443/GECommunicationsWS.asmx

As you can see, DNS would need to resolve to “see.domain.dom” and this should then
be resolved back to the IIS server so that the SEE Client can reach the
 GECommunicationsWS.asmx website. If this is properly resolved, the SEE Client should
then be able to authenticate and check in to the SEE Management server to download
policy.

Although there may be various ways to make SEEMS communications available externally and
should be done with security in mind, this document focuses on a configuration with load
balancers in addition to internal security applications to help isolate external traffic from internal
traffic. The following diagram provides some ideas for how this can be done:

In the diagram above, you can see there are external clients that need to connect from the
internet to an internal SEE Management Server. IIS being the backbone of communications for
SEE, we need to get the authenticated traffic from SEE Clients externally to the internal SEE
Management Server. SEE Management Servers should not be placed in the DMZ for security
isolation.

The external SEE Clients will attempt to check in to the server, which will be done by resolving
the host via DNS. Depending on how this happens, the connection will resolve to a host that
should then be redirected to a security application such as the Threat Management Gateway in
the example above that is placed behind a firewall.

Ideally, traffic should be accepted by the TMG only when the correct certificate is presented.

The TMG will handle the authentication requests and pass these internally through another
firewall to the internal network and to the next hop inbound such as a VIP/LB, which will then
determine where the traffic needs to go internally and resolved to the internal IIS service, which
will communicate with SEE Management Server.
All of the above is meant for recommendations and is not a substitute for a thorough network
security analysis and always include periodic/regular penetration tests to ensure continued
security. Since all traffic from the SEE Client can be encrypted via TLS 1.2 protocols, no other
traffic should be allowed through this process.

Considerations Checklist Summary:

*IIS and Database components to secure.

*Only Secure protocols should be used.

*DMZs and internal networks to be considered

*Firewalls, Load Balancers/VIP and Threat Management Gateways placements

*External DNS configuration

*Security Software installed on endpoints, such as SEP.

*Active Directory Accessibility and security

*Server operating system updates to be applied before making SEEMS publicly accessible.

*Run through Penetration tests on all applicable endpoints to ensure components are secured.