Security Experts:

Evaluating Risks to Identity and Access When Moving to the Cloud

Are Too Many Companies Putting Identity and Access at Unnecessary Risk in Their Move to the Cloud?

I was chatting with the CSO of a Fortune 500 company a couple of weeks ago and the topic came around to cloud services. Her company is famously cloud-averse.

“I know you guys don’t do cloud,” I began, “but are you moving to Office 365?”

“Probably. Eventually. I think we’re going to get dragged there whether we want to go or not,” she replied.

Identity Access Risks in CloudMicrosoft Office has long been the most popular business productivity software suite. Now the Redmond-based giant is aggressively promoting their cloud-based version, Office 365, to organizations of all sizes. The promise of Office 365 is better collaboration (do we really need to email 12Mb Word docs around all the time?), which should increase user productivity. In theory, creative employees can use it to collaborate anytime, anywhere, from any device.

For small businesses particularly, the lure of a few dollars each month for the cloud version instead of hundreds of dollars per employee for the desktop suite is a huge temptation and given the choice, they’ll just go with it. I would, skinflint that I am.

But larger organizations, such as the one run by the CSO I was chatting with, want to be more proactive about their cloud security. And she’s right to think that way; most Office 365 deployments result in user credentials (including C-level usernames and passwords) going to the cloud whether they mean to or not.

Don’t believe me? Let’s look at the three identity and access management models used by Office 365.

Cloud Identity Model – All your passwords belong to Microsoft.

The simplest Office365 identity model is the Cloud Identity Model, where user names and passwords are managed solely in the cloud with Office 365 creating a user identity. The user identity is stored in and verified by Azure Active Directory.

Synchronized Identity Model – Passwords hashed on-premises and in the cloud.

In the Synchronized Identity Model, an organization’s on-premises server manages user identity, while the user account and password hashes are synchronized to Azure AD. Users enter the same password on premises as they would in the cloud, with their password hashes verified by Azure Active Directory.

Federated Identity Model—The most secure, but still sees mobile user passwords.

The Federated Identity Model is the most secure method to access Office 365. It is similar to the Synchronized Identity Model but uses an on-premises identity provider to verify the user password hash. That means the password hash does not need to be synchronized to Azure Active Directory.

The Federated Identity model suffers from a mobile client password gap. Nearly all mobile email clients use the ActiveSync protocol. ActiveSync doesn’t support federation and transmits the user password to Azure AD. Azure AD sends the password back to the on-premises identity manager for verification over an encrypted tunnel, but is that good enough?

What’s the Threat Model Here, Anyway?

Here’s a short list of possible threat vectors you’d consider if you were doing a threat model assessment for any of cloud passwords management models (including the three above):

· Cloud breach

· Man-in-the-middle attack

· Rogue cloud employee

· Nation-state (subpoena)

· Accidental credential logging

· Phishing attack

Where possible, Microsoft has clearly done what it can to avoid seeing user passwords, but they still do. And there are plenty of examples of all of the above threats being realized. Whether or not these threat vectors fall into your assessment model is up to your organization.

Closing the Gap

Many organizations have decided that they are comfortable with this gap. No model is 100 percent secure, right? But a few CSOs want to close the gap before they make the switch. Right now, the way to do it is to intercept and proxy ActiveSync connections from the client to an on-premises proxy which then encrypts the passwords before they transit to Azure AD.

The final step is to implement adaptive multi-factor authentication (MFA). Adaptive MFA is risk-based authentication and can include certificate checks and context-aware, one-time passwords (OTP) via email.

Most organizations say they support MFA but when you drill down, they’re only providing it to select users (C-levels, hopefully, and IT, and a few others). MFA that covers only some users isn’t ideal, but it’s better than no MFA at all.

Cloud Should Be More Than Someone Else’s Computer

Getting back to the conversation with that CSO. Even though her organization is famously cloud-adverse, she knows they’re going to end up editing Word documents and PowerPoint files in the cloud. When they do, there will be no turning back. Her staff’s real challenge will be managing the risk before – and when - that happens.

view counter
David Holmes is an evangelist for F5 Networks' security solutions, with an emphasis on distributed denial of service attacks, cryptography and firewall technology. He has spoken at conferences such as RSA, InfoSec and Gartner Data Center. Holmes has authored white papers on security topics from the modern DDoS threat spectrum to new paradigms of firewall management. Since joining F5 in 2001, Holmes has helped design system and core security features of F5's Traffic Management Operating System (TMOS). Prior to joining F5, Holmes served as Vice President of Engineering at Dvorak Development. With more than 20 years of experience in security and product engineering, Holmes has contributed to security-related open source software projects such as OpenSSL. Follow David Holmes on twitter @Dholmesf5.