Microsoft Ignites a new Focus on Security (Part 6)

If you would like to read the other parts in this article series please go to:

Introduction

In Part 1 of this article series, I discussed the announcement at Ignite 2015 regarding more flexible patching cycles and the introduction of Windows 10 Device Guard. In Part 2, we started to look at more of the new security features, products and services, beginning with Microsoft Advanced Threat Analytics. In Part 3, we looked more closely at the Ignite presentations regarding what Microsoft is doing about security in the cloud and specifically in Office 365. In Part 4, we began talking about identity management in the cloud and particularly how identity management works in Office 365. In Part 5, we showed you how to implement each of the identity models and provided some tips for best practices with whichever identity model you ultimately choose.

The Problem with Passwords

For most of the history of computing, the standard means for accessing computer systems, applications, web sites and data has been through access controls imposed on individual user accounts that are identified by a unique user name and protected by a “secret” – a password or a PIN (personal identification number) that the user enters to log on.

It works, after a fashion, but the problems with passwords are myriad. Given the option to select a password, most users naturally go for something that will be easy to remember (and in today’s mobile-first world in which they are likely to be entering it using tiny on-screen keyboards, something that’s easy to type). In the early days of computing that led to countless users creating easily-guessed passwords such as 12345 or “god” or the painfully obvious “password” (or for a little variety, “password12345”).

Such common passwords are only a little better than no password at all. Only slightly more secure are passwords that consist of the birthdate of the user or one of his/her loved ones, a child’s or spouse’s name, the user’s social security number or some other piece of information that can be fairly easily ferreted out with a little research by a password cracker who targets that user.

As software became more sophisticated, technological controls were imposed that enforce rules regarding password length and complexity. Organizational policies now generally require that all user passwords be a minimum length (such as 8 characters) and often that they include both alpha and numeric characters, both upper- and lowercase letters, symbols, etc. Others go farther and require that users change their passwords on a regular basis, such as every four weeks.

The problem is that the more complex passwords become, the more difficult it becomes for users to remember them – especially when many have a dozen or more different passwords for accessing different systems, sites and services. And when passwords become too difficult for users to remember, they violate the rules and write them down, creating an even bigger security risk.

While passwords have been the standard authentication method for logging onto enterprise networks, some have seen the need for better security than passwords can offer and have sought

Introducing Multifactor Authentication (MFA)

Passwords will probably have a place in verifying user identity for a long time to come, but password authentication can be greatly enhanced by supplementing it with a second authentication factor. Authentication is all about making a user prove that he/she is really the person to whom the user account belongs. There are several different ways that a person can prove identity:

  • By providing some piece of information that only he/she knows. This is the basis of the password, passphrase or PIN. This information should be known only to the user to whom it belongs and no one else.
  • By providing a unique physical object that has been pre-associated with the user account (something you have). The most common examples of this would be a smart card or a USB token that can be inserted into a reader on the system. This object should be in the possession of the user to whom it belongs and no one else.
  • By providing an exemplar of a unique pattern of behavior that has been pre-associated with the user account (something you do). Examples of this would be voice pattern or typing pattern or handwriting. This pattern should be one that is unique to the user with whom it is associated and no one else.
  • By providing a scan of a unique biological or physical characteristic that has been pre-associated with the user account (something you are). Examples of this would be a fingerprint scan, a retinal scan, an iris scan, a facial recognition scan or even a DNA sample. This should be a biological characteristic that is unique to the user with whom it is associated and no one else.

The problem with smart cards and tokens is that they place an additional burden on the user to carry an extra object with him/her. If it’s left at home, the user will be unable to log in and access needed resources. It can also be stolen, thus presenting a security risk.

The behavioral and biological types of MFA don’t have those drawbacks. They’re always with you, and would be exceeding difficult for a thief to appropriate (Grisly scenes in movies such as Demolition Man aside). Of course, in order to authenticate a user based on a behavioral pattern or biological characteristic, those patterns must first have been collected beforehand and stored in a database for comparison when the user presents it for authentication. This has been the source of some resistance to these forms of MFA, since some see such storage of personal identifying information as intrusive.

A relatively new form of MFA attempts to balance these concerns by making the second authentication factor something you have – but that most of us almost always carry with us anyway. The almost ubiquitous presence of the smart phone makes it the logical choice as an authentication device.

Industry wide adoption of smart phone based MFA in the cloud

MFA in the form of two-factor authentication is becoming a standard option with all of the major cloud services. Even consumer-oriented cloud-based services have gotten into the act. Social networking services such as Facebook and Twitter offer it. Google offers it for logging onto their email and other cloud services. On the business side, the currently reigning King of Cloud (at least in the IaaS realm), Amazon, provides for MFA to authenticate to its Amazon Web Services (AWS).

AWS is Microsoft’s biggest competitor in the cloud, with the two companies having been named the only ones that qualify for the “leader” quadrant in Gartner’s 2015 Magic Quadrant for IaaS providers.

Image
Figure 1:
Gartner MQ 2015 Cloud IaaS

As part of its Identity and Access Management (IAM) feature for controlling access to AWS resources, Amazon supports MFA using hardware tokens – both in a credit card sized format and a key fob – as well as a virtual MFA device in the form of an app that runs on your smart phone or tablet. There are virtual MFA applications available for Android, iOS, Windows Phone and Blackberry. IAM and MFA are available to all AWS customers. There is no extra cost for the service, although there is a cost for the hardware MFA devices ($13 to $20 depending on the type of device).

So how does Microsoft stack up against Amazon in this area? It’s a legitimate concern for anyone who’s faced with the decision of which of these leading IaaS providers to go with. Microsoft supports MFA for Office 365 and Azure IaaS services. Microsoft’s MFA is focused on the phone (calls, text messages, mobile app) as the secondary authentication factor, but also supports third party OATH tokens.

In early February 2014, Microsoft announced via the Office Blogs that MFA support for regular user accounts was being added to the Midsize Business, Enterprise, Academic, Nonprofit and standalone Office 365 plans, including Exchange Online and SharePoint Online (it was already available for administrative accounts). MFA support is also built into the Azure Active Directory Premium version and is available for Azure administrative accounts at no extra cost with any Azure subscription (without having to upgrade to the AD Premium version).

The three different versions of MFA (Office 365, Azure Administrative and Azure AD Premium) have different feature sets, with the latter being the most full featured and including several features that the other two don’t have such as administrative control over authentication methods, PIN mode, fraud alert, MFA reports, one-time bypass, custom greetings for phone calls, customization of caller ID, event confirmation, trusted IPs, the MFA SDK and MFA for on-premises applications using MFA Server. We’ll talk more about those later in this discussion.

Summary

Now that we’ve laid the groundwork for understanding the importance of MFA in cloud services and its use across the industry, next time in Part 7 we will get into the nitty gritty of enabling and configuring Microsoft’s MFA options.

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top