Locking down access to webmail on your national or private cloud service

For many, if not most of our partners in the network operator & application hosting space the challenges of identifying the subscriber has become nothing short of a nightmare in recent times. Password based security by itself no longer is manageable, secure, and aggravates the user experience of the service by adding layers of frustration to the authentication sequence. Lets look at some techniques that will mitigate some of these challenges and provide some added assurances to the customer experience that the service security policies are effective, but also thoughtful of the impacts on the user.

We have in CommuniGate Pro a certificate authority built into the platform and for the purposes of our chat today we will focus on using TLS certificates in combination with multi-factor authentication to lock down access while providing a reasonably smooth user experience. We should point out that this type of model is typically in demand for business subscribers, especially governmentally regulated industries, i.e. banks, air transportation, government agencies and healthcare are especially pushed to conform to certificate based security topologies. One of the challenges of the topology is the management and setup of the devices which is normally mitigated when the system is operated by IT departments and “bring your own” devices are not permitted, unless they are put under such management.

So what the heck am I talking about in simple terms? Certificate based TLS sessions are where the client system, laptop, desktop or mobile have installed a signed digital certificate that is presented to the service during the SSL connection session. That means that the computer trying to “login” must also have this certificate to present to the service as a means of determining that the computer itself is authorized, not just the user credentials.

 

The illustration above shows  a typical deployment at a network operator with a Pronto! based web access method for the subscribers. In the private cloud all the users must conform to 3 added policies to “get into” the service:

  1. Password and user challenge / response is met with a biometric scan using our multi-factor API and mobile client
  2. TLS certificates must be present on the client machines and presented to the server
  3. The network that the machine is coming from must be on the list in the server policy

Furthermore the network operator has also placed several “good practice” policies on the public access network for reception and transmissions of messaging content. In many cases we are seeing that inner agency traffic, for example from the police to the justice department are required to also present TLS certificates. Adding TLS certificates on the SMTP sessions is highly recommended to “tamp down” the flames of SPAM and create policies that control what you want coming in versus the model of “cleaning up” the junk after it arrives with a open SMTP policy.

It should be stated as sometimes there is confusion about “email encryption” and if that means encrypting the mail itself or the transportation of the mail. For our purposes of this discussion we are talking about  TLS / SSL and that is all about the “transport” not the encryption of the email itself. Email encryption is performed in the CommuniGate Pro platform with a cousin technology called S/MIME that we will discuss in another blog posting.

In the hosting model we have two “doors” that we are talking about locking or having keys for the user to open. First is the “web access” or Pronto! webmail that combines all its communications over a HTTP/S session. That means we can send/receive mail, VoIP calls, and perform actions on the calendar or directory with a single socket connection; in this case HTTP/S using the TLS certificate to control whom and from what system can open the door. The other doorway we are talking about controlling is public or external to the “domain” in question. That means if in my example of the police and the justice department are on separate services, each can install the TLS certificates on their respective SMTP/S configuration profiles and lock the doors for any abuse or fraudulent attempted access.

While most of our talk is centered around the installation of TLS certificates on the access computers, we should not lightly skip over the way the user should authenticate. In the end of the day, if a computer is stolen, or accessed by an imposter, all they need is the fingers on the keyboard. Often times security breeches are performed by persons with mal-intention within the organization or on the periphery, like a partner or even staff with access for cleaning and maintenance of the facilities.

Password based authentication is only designed to determine that a password is “correct” not that the person is actually who they say they are. Biometric authentication in a multi-factor policy is the best method today for adding a layer that is far more precise, but also simple to use compared to lengthy passwords that are difficult to enter and remember for the user. CommuniGate Pro has build a simple to user and re-brand mobile client for TouchID on iOS devices and Android systems with biometrics sensor features. We can also “fall back” to secure session data code transmissions or least secure SMS code validation but strongly suggest that biometric scan policies are enforced for the most reliable and traceable security policy on your cloud service.

REFERENCES:

CommuniGate Pro PKI infrastructure

Tips for protecting the SMTP session on CommuniGate Pro 

 

You may also like