Authenticating in the Cloud - Not your father's authentication methods (multi-part cloud security series)

This post is the first in a series on securing #cloud computing. Though it may not follow the chronology in which a company would consider or deploy cloud computing capability, I wanted to cover #authentication as I see many companies doing a very poor job of that today.

Authentication in the cloud should NOT be viewed as the same authentication a company would have on-premise. If you consider the layers of control and the compensating controls in play, an "internal" authentication to a trusted application running in the company's data center can be considered much more secure than the same authentication to a trusted application hosted in the cloud, such as ADP or Saleforce.com.

Let's begin by looking at an internal authentication on the trusted network. An internal authentication is relying on several key controls that can often be overlooked when considering cloud security.

1. Control: background check and continuous behavior checking by office staff - e.g a trusted individual. A user has been vetted through the HR process, and if security guards and building tenants haven't raised a concern, the person looks and behaves "normally."
2. Control: physical badge access to the facility - e.g. a trusted facility. A user is accessing the application from a trusted location inside a company facility (this can be problematic in hospitals for example, that are open to the public 24x7x365).
3. Control: company-issued computer - e.g. a trusted asset. A user is accessing the application from a company asset which if properly configured and locked down, is considered secure.
4. Control: use of company network - e.g. a trusted network. A user accessing an internal application from within a company facility is leveraging a company network that is trusted to be able to access that application.

Now let's change the scenario so the application is hosted in the cloud and is made available via the public internet (so any employee can access the application from anywhere - a key enabler for efficient work processes today). I'm going to take these in reverse order of above.

1. Trusted network? No. The whole idea is that the individual can be in the office, at home, sitting in Starbucks, etc. so we can't make any assumption about the trust level of the network they are using.
2. Trusted asset? Maybe. Hosting applications in the cloud is intended to make them easy to access and easy to use. So even if the user has a "trusted asset" issued from the company, they may be using their person PC or even a shared PC at a library or coffee shop. So you can't assume they are using a trusted asset.
3. Trusted facility? No. Again, the drive to the cloud is an enabler to allow people to work from multiple different locations and perform the same job. So we can't make any assumptions about the access coming from a trusted company facility.
4. That leaves us with Trusted Individual. Without physically coming into a company facility, or using a photo badge access card, the only way to be able to positively identify who is accessing the application is via authentication, and the application grants authorizations based upon the individual the authentication process identifies.

Given the lack of controls 1-3 above, why would any company rely on simple ID and password authentication for a web application? Answer: They shouldn't. With the number of accounts that have been breached to date, there is no lack of user credentials available on the black market (if you want to see if your email address is part of a breach, check out Troy Hunt's page: Have I Been Pwned). If a company doesn't rely on more than an ID/Password combination for access, they are simply inviting access by unauthorized parties, and regulators very well may find them negligent.

Authentication can be done a number of different ways, but at a bare minimum, multi-factor authentication (MFA) should be used for any access to company assets from outside a company location. This could be a text to a cell phone, a hard or soft token or biometric item demonstrating either who someone is or something they have. So whether they are staffers accessing Salesforce from a coffee shop, or an administrator accessing a server from home, MFA should be used. Ideally your MFA solution would be adaptive and vary the degree of authentication challenges based on device, location, proximity to a mobile phone, biometrics, etc. and would do it in such a way that it's transparent or at least simple for the user so the authentication process itself doesn't impede their business processes. There are vendors out there that do adaptive multi-factor authentication, so please look them up if you're not using MFA for access to your cloud applications today.

Stay tuned for the next article in the series on securing cloud computing.