It's a good thing I put on my "Be Disruptive" shirt this morning, because I'm about to disrupt all up in this place. You're sitting down, right? Excellent.
According to recent documentation, Microsoft's current best-practices guidance for passwords is to…set them to never expire. It's ok if you need to take a moment to re-read that. Once you've made peace with that one, you can also disable complexity requirements.
We've been talking for some time about the limitations of passwords and the importance of enabling multi-factor authentication, but this is the first time we've seen the drumline change from "passwords aren't enough" to "seriously, just don't bother even changing them any more", and that's a HUGE posture shift.
So what's driving it? Again, we know passwords tend to be hard to remember and end up jotted on sticky notes under keyboards (or stuck to monitors). We know users recycle the heck out of them, too, with statistics saying a full 73% of credentials are recycled across systems. And we know users love cat names, their children, and the tried and true "password1".
Microsoft warned us some time ago that winning team names make up a huge percentage of passwords, and introduced some really cool password filtering capabilities to prohibit that. Windows 2016 AD will very soon be able to actually subscribe to those filters, and admins will be able to introduce their own banned words, so users don't just put famous employees or corporate initiatives as passwords. That's cool, and would somewhat imply that passwords still have a very high value. But what Microsoft has also discovered is that having users change passwords more frequently actually drives up the likelihood that they'll fall into these bad password habits. And it makes total sense, if you think about it: being forced to think up a new password every 60 to 90 days is an out-of-band exercise for most of us. It's usually interruptive to our process, so it doesn't get the attention it might deserve. Our brains tend to go to something that's on our minds, we turn it into 1337 sp34k, and move on.
But no more. Those great filtering tools now block simple 1337 sp34k conversions, which ultimately means users will get even more frustrated trying to come up with something quick.
All of which is just to say that passwords aren't getting the job done, and you can stop worrying about them. So sayeth Microsoft (so don't blame me). But we can't just wholesale dump the principal security mechanism that protects the object that we've declared "the new control plane" of IT security: the user identity.
Back to multi-factor…. If you haven't enabled it yet, what's holding you back? Office 365 and Azure admins can use it for free. In fact, let me quote Alex Simons, who in that same document updated the Azure AD best practices guidance this week with the following gem:
We strongly recommend enabling always-on multi-factor authentication for all admins in your organization, especially subscription owners and tenant admins. Seriously, go do this right now.
The best part about that guidance is that it can be done for free, right now. Admins get MFA for free in all subscriptions of Office 365 and Azure. There is literally no justification to not enable it.
But if you're swinging the password hammer, you can't just enable admins and call it good. Users need the same level of account protections, and multi-factor authentication is a much more powerful protection than passwords will ever be. So let's handle some objections…
Now there has traditionally been one challenge to getting MFA deployed, and it's one of reporting. Azure AD gives great insights into just about every element of a user account, but oddly does not do a great job reporting who is and isn't MFA-enabled. You can look them up one-at-a-time in the portal, but there's no export functionality. Even PowerShell doesn't provide direct visibility, and some of the scripted solutions I've seen on the Internet make bold assumptions about fields that will or won't be populated. So please steal the following code, run an Azure Active Directory PowerShell, and see who in your environment is licensed, enabled for login, and NOT MFA-enabled.
If you're not using Azure Active Directory at the P2 license level, just run that guy once per day and call every user that pops up on the list until you whittle it down to zero. If you are running AAD P2, though, you can turn on risk-based sign-in policies that will automatically configure your users for MFA.
Once you have your users configured, they can leverage that security against on-premises authentications via the Azure MFA server and/or ADFS, VPN authentications with Network Policy Server configurations, Office 365 & Azure services, and SSO-enabled SaaS applications that have been integrated with your Azure AD.
There are very few tools in the security toolbox that can have such a wide-reaching and profound impact to the overall security posture as MFA. What's stopping your deployment?
Posted: 3/19/2018 5:16 PM
I’ve worked in the disaster recovery (DR) space for a number of years and with various entities both private and public. All of those entities have used some sort of backup devices, storage …