For folks in the security space, time moves slowly. Many of us who have been in the industry for years learned the old-fashioned way that no system is perfect, and that at best, any security measure merely delays the amount of time an attacker can gain access. Techniques honed over years that used to deal with physical defenses (walls, doors, locks) were ported into the digital world of keys, hashes and certificates. Even then, it was broadly understood that having physical access to a device ultimately meant it could be compromised. And that security through obscurity was to be avoided.
In the past few years, however, many “traditional” pieces of security guidance have grown obsolete, or worse, counter-productive to their original intent. Most of these pieces of guidance grew out of early digital technologies (passwords, anti-virus signatures, monitoring systems) that transformed the way security was performed, and thus are tough to dislodge from a customer’s mindset. Many of them share a common thread: greater complexity.
Let’s use the oldest example: account lockouts. As soon as folks created digital identity systems, other folks realized they could attempt to guess usernames and passwords to break into them. The solution from three decades ago was two-fold: a limit on the number of bad passwords that could be attempted before the account was “locked”, and a period of time before the account itself unlocked. Even better, folks added an expiration policy to passwords to ensure that a compromised password didn’t exist forever. Over time, customers who wanted “greater security” would tend to lower the number of bad passwords attempts, or lengthen the time until accounts were unlocked and always to shrink the password expiration policy. These systems began to break down around twenty years ago, as many of the identity systems began to connect to the internet. In an isolated environment, a malicious actor had to have access to the network, and was therefore attempting to steal a specific individual’s password. Once connected to the internet, the threat migrated from folks trying to steal information, to simply locking out *every* account in an environment and shutting all access down. These denial of service attacks forced the large identity providers to change their position: instead of lockout policies, Microsoft (and others) moved to a “monitor and mitigate” framework. If a malicious actor was attempting to brute-force attack usernames and passwords, and a certain number of failures occurred, an email could alert an administrator to look into the matter, and block the offending IP address from reaching the network. This then, was the state of security guidance in place fifteen years ago.
Today, I continue to run into customers (and more ominously, auditors), that insist a “lockout policy” is a best practice for security. Yet implementing one would actually increase the risk of a DOS or DDOS attack on one’s organization. Education is the key here: by spreading information to all the stakeholders over time (and yes, it’s been 15 years so it’s a slow process!) we will hopefully get to a point where lockout policies, and even passwords themselves, are viewed as ancient history.
Yet some of the examples today aren’t a matter of education, but of changing the very worldview security practitioners espouse. A classic example of this are highly privileged accounts. In the past, the recommendation for accounts that had powerful rights and permissions assigned to them, was to create a completely independent account on your identity system (e.g. in Active Directory, if one’s account was john.doe@contoso.com, the privileged account might me adm-john.doe@contoso.com) to ensure that regular day-to-day activities weren’t being performed by an account that could accidentally bring the entire network down. As identity systems matured, it was possible that these privileged accounts could be further restricted so that instead of always having every permission needed, that one had to go through an approval process (in the Microsoft cloud this function is called Privileged Identity Management (PIM)) to gain rights. This further lowered the chance that a malicious actor, or sheer accidents, could cripple a company. So far, so good…but wait.
At the same time as identity services were increasing in power, advances in identification on the device level began to remove the need for folks to use passwords – with Windows Hello, for instance, one could log into a laptop with your face, or a short PIN that was tied to the device itself. Once logged into the machine, every action taken referenced the identity used earlier, eliminating password prompts and additional friction from the experience. Over time, it’s clear, folks will begin to move to a passwordless experience on their devices, which will eliminate the weakest link in the security chain: passwords. Even better: advanced identity systems could begin to look at patterns of behavior and suggest when folks weren’t acting normal. Logging in from Russia? Travelling between NYC and Washington DC in ten minutes? Accessing data from a known bad network? All of these scenarios can now be identified by modern identity systems and secured, whether passwords are in the mix or not. And yet! Once folks move to a single device model, with passwordless (whether using biometrics, or a phone device, or a physical USB key, or a PIN) options abounding, the separation of accounts becomes…challenging. Without passwords, how would one “credential up” to a highly privileged account? If identity systems are looking for aberrant behavior – what does having two (or more!) accounts look like?
The answer, as you may have guessed, is to ultimately eliminate using multiple accounts and to go back to a single account per person. I can envision folks reading this and saying “well, that’s silly, we will never do that…it is obviously insecure!” But just as some folks needed to realize that a four digit pin, tied to a device, is more secure than a 12 digit password, used everywhere; having two accounts to perform tasks, rather than a single account per person, with lots of layered protections, ultimately makes less security sense. The good news is that through technologies such as PIM, we can prevent a “regular” user account from ever accidentally making an irreversible change. And beyond identity protection, we can also be much more granular with role based access control to shrink the total number of privileged accounts needed in the first place. In general, a decrease in complexity tends to lead to both a more secure system overall and one that breaks in a way that can be understood (and fixed) more quickly.
This is only one example, but it drives home the point that there are many traditional security practices that in the modern world need to be updated. NIST has acknowledged that no one should use password expiration policies. Microsoft has lobbied against account lockouts. It’s only a matter of time before dual account use is seen as an unneccesary complexity that doesn’t move the security needle forward. Even standards used to protect desktops that lived in a single area, often insecure, are woefully different from the computers we stick in our pockets each day that every year accumulate more computing power. If a device is never truly off my person – perhaps that’s the greatest security benefit of all!
