Industry jargon around authentication is practically inescapable. In today’s threat landscape, there’s certainly justification for keeping these topics front-of-mind and sparking conversation. But, when authentication concepts start to get a little tangled, it can be hard to know if you’re speaking the same language as everyone else. Simplifying key terms is important to understand what they really mean, so you’ll see just how complex the world of authentication can be.
Strong authentication is one of those industry terms that’s been overused in so many contexts, that its significance has been blurred.
Many people consider strong authentication to be the same as multi-factor authentication (MFA) or two-factor authentication (2FA), but if you examine the European Central Bank’s standards for strong customer authentication, there are a few more hoops to jump through than just having more than one factor:
There have to be at least two methods used to authenticate. These two methods should come from these three categories: something only the user knows, something only the user has, or something only the user is.
The methods used have to be independent of one another, meaning if one is breached, the others aren’t automatically compromised. One also has to be non-replicable (unable to be duplicated), unable to be stolen through online means, and not reusable.
Here’s a caveat, though: this term, like any term based (however loosely) on codified standards, can be a double-edged sword. Just because you’ve complied with standards doesn’t mean you’ve chosen the most secure or appropriate mix of authentication factors for your organisation. Compliance matters, but strategy and thoughtful implementation matter too.
To understand the problem posed by authorization creep you first need to understand the difference between authentication and authorisation. Authentication is when a system determines that you are who you say you are. Authorisation is when the system determines what you have the right to do within the given network or application, given your authenticated identity. That’s where things can get tricky.
The problem with authorisation creep, also called privilege creep, is that the threat it poses to your organisation will typically have nothing to do with the strength of your authentication, but instead is all about your policies, oversight, and the ease of managing your system. The fanciest, most high-tech authentication protocols won’t mean a thing if legitimate users are over-authorised. Pretty creepy, right?
In the authentication framework, biometrics are a factor linked to something you are, and they can be incredibly difficult to steal, spoof, or lose. That’s what’s so strong about them. Typically, people think of biometrics as things linked to physical characteristics—like eyes and fingers. They’re something you’re born with, right? Not necessarily. Yes, physical characteristics that you’re born with still account for the largest portion of biometric use cases. But there’s another category: behavioral biometrics. Your voice, gait, your way of typing, and a whole host of other unique characteristics are all a part of this group. These “life measurements” are acquired over a lifetime and may change subtly, all while remaining as unique as a fingerprint.
Federation and single sign-on
To nail down the differences between these two terms, let’s start by explaining the comparatively simple structure of an SSO authentication environment. Single sign-on allows you to sign on once with a service provider for a range of services, allowing that one authentication event to give you access to a suite of services. There are plenty of services that enable SSO, and the beauty of SSO is how frictionless it is for users.
Federation works slightly differently, as it isn’t just requesting access from a single service provider. There’s still one sign-on involved on the user’s end, but not on the back end. Instead, federation relies on a trust relationship between multiple service providers, with a single source for that trust. So, the user signs on to the source of the trust relationship (a centralised identity provider, or IDP) with all of the necessary credentials once. Attempts to access federated services will involve re-authentication through that IDP. You won’t be using credentials to access those diverse services—the IDP will be sending them out. Same time savings as SSO, and similar risks if the IDP is breached.
A Zero Trust model says that anything coming onto your network (person, or device) has to have a positive identity that’s verified by the system. Put simply, “Trust never, always verify.” That way, access is restricted to licit users and devices: trusted entities. When hundreds or even thousands of internet-enabled devices are able to come on the network of a large organisation, it’s crucial to give them access rights commensurate with what they need from the network—which shouldn’t be much.
So how does a Zero Trust security posture contribute to a safer organisation? Basically, it makes sure that what’s on your network belongs there and heads off breaches by unauthorized devices that may not be properly configured. It also addresses vulnerabilities arising from use of your network’s resources by devices that may be communicating remotely over an insecure internet connection. Finally, it keeps users from bringing in their own less-secure devices and inadvertently causing a breach. No one wants to be that guy. With a Zero Trust security model, they wouldn’t get the opportunity.
Phishing, as you probably know, continues to be one of the most common security scams. Through email (the usual source), text, phone, or even messaging, social media, and productivity apps, crooks attempt to steal user data. Usually, they’ll pose as a legitimate organisation and steal a bit of formatting from licit communications from those organisations. The goal is to get people to click a malicious URL, log in to a fake site, or download a virus-ridden attachment.
Because it can be devastatingly successful, cybercriminals have continued to innovate. They all want to build the better phish-trap, which is why there are some new terms associated with this old-school brand of attack, such as: Spear Phishing, Whaling, Clone Phishing.
Internet of Things
If you think of a certain talking home speaker system or your smart oven when you think of the Internet of Things (IoT), you’re not alone. Consumer “smart” devices overwhelm the public imagination when it comes to IoT. The surface area of this ecosystem and its vulnerability to breach is enormous. A “headless” device, which has no clear user interface and may even communicate through archaic or unsecured protocols, is an attractive target for crooks. What’s crucial is to have an identity and access management solution that encompasses all of these headless devices (Zero Trust), ensuring that their access to the network is licit, and that no bad actors are hijacking the device to access your network.
The consequences of an IoT breach can be dire, but avoiding breach isn’t necessarily simple or straightforward. A great illustration of this concept is the recent discovery that one popular smart light bulb sold on Amazon was essentially cracking network security wide open for many consumers without their knowledge. This bulb stored wi-fi credentials in plaintext in its firmware and had no security settings whatsoever. Because these devices tend to utilize low-energy chipsets and low-complexity code (code that is sometimes downright archaic), they can be a welcome mat for hackers. Today’s IoT ecosystem is full of mismatched headless or limited UI devices that may be ticking time bombs.