With passwords here to stay, a ‘Zero Trust’ approach to authentication makes eminent sense

When I first started writing about technology for USA Today in 2000, reporters were required to use what at the time was a cutting-edge 2-factor authentication device to securely log into the newspaper’s editing and publishing network.

Related article: The case for rethinking security

It was an RSA SecurID token. I attached it to my key chain, and activated it to issue a one-time 6-digit code, each time I needed to log in to file a story.

Today that same functionality has been vastly improved. One-time security codes routinely get pushed to smartphones to affect a second factor of authentication in a wide array of scenarios. An approach referred to the “Zero Trust” model, takes it a few steps further.

Increasingly, behavior monitoring and machine learning are being brought to bear to assess details of each separate login to each service. This enables companies to make decisions as to whether any specific access request is routine – or suspicious.

Companies can tune such systems to automatically take a range of actions, from requiring a second-factor of authentication, to permitting only very limited access or even blocking access altogether. And they are able to do this at scale, in real time, while watching effectiveness improve as the machine learning algorithms crunch more and more data.

Last Watchdog asked Andy Smith, vice president of product marketing at Centrify, a leading supplier of identity and access management (IAM) technologies, to supply context for the Zero Trust model. One big takeaway was this: the Zero Trust model has come along in perfect timing to support stronger authentication requirements happening on the fly as part of digital transformation.

For a full drill down, please listen to the accompanying podcast. Here are excerpts of our conversation edited for clarity and length.

LW: Keeping track of identities and controlling access has always been a big challenge. Now the challenge is escalating, getting more complex.

Smith: The cool thing is there’s some new tech that’s in this space across the board that’s helping with this. One is multifactor authentication, which has been around for a long time. Today we all carry mobile phones, and so the state of the art is push notifications sent to your phone. You just click the ‘allow’ button and you’re let into the system.


The other thing that’s really cool is user behavior analytics. I can look at different access requests, see what that user is doing, the normal time of day they log in, the usual location and usual device. And if I have all that context, then I can say, ‘Yep, go ahead let, ‘em in.’  If I see anything that’s not normal, that’s when I can apply multifactor authentication. . . Machine learning allows you to identify these things and take action in real time. I can even look at commands that may be running and identify things that no human looking through logs would be able to identify.

LW: How does that apply to things like micro services, container-based architecture, dev ops, etc.?

Smith: These are all basically new attack services. These actually are driving this need for ‘Zero Trust.’ What I do in my AWS environment, or while implementing a dev ops pipeline, or doing continuous integration, these things all need the same types of control.

It’s the same basic identity controls that we’ve had for decades, applied to these new attack surfaces. In the client-server days, it used to be a small set of clients accessing a server. Now you’ve got micro services, with hundreds, or thousands of access requests. And then, as you move towards, containers now you’ve got potentially millions of these containers that just show up for a few seconds, and then go away. So the attack surface has gotten much larger.

LW: DevOps is where the software developers are innovating, creating and communicating, back and forth, to do this.

Smith: Exactly. So there’s much more of a machine-to-machine or workload-to-workload inter-communication. Building an application used to be one monolithic thing. Now I could have hundreds or even thousands of micro services that need to talk to each other, each in its own little container. And they all need to talk to each other.

LW: Lots of more opportunities for unauthorized access.

Smith: One of the bad practices is when you have two micro services that have to talk to each other. If I’m the developer, I could hard code a default password for these two things to communicate. Well, that default password gets out there, and then you can have denial of service attacks and things shutting down. And it’s the same problem with IoT. Basic identity management controls need to be in place.

LW: Threat actors are already taking advantage, witness the hacks at Uber and Tesla, which came through AWS.

Smith: They’re going after those accounts by just scanning and looking for default passwords. You ‘ve got an outsourced developer who may be putting some code up on GitHub that is accessible. They can find that by scanning for a field that says, ‘password equals.’

LW: And then navigate over to the database where all the customers’ data resides.

Smith: Exactly. Just get in, elevate privileges and get across. So the need is for the same controls we’ve had forever, but applied to these new use cases; dev ops pipelines and just general movement to cloud and security for AWS accounts.

We talk about achieving Zero Trust through NexGen access. It’s not just users accessing applications. It’s also privileged access to services, and machine-to-machine access and code-to- code access.  All of that is part of NexGen access. I have to make the same kinds of decisions. Who’s that user or system? Do I want to limit their access and privileges? And then continuously learn through behavioral-based learning, and apply policies consistently.

LW: Are passwords here to stay?

Smith: I would love to get rid of passwords but we’re not going to. More short-lived tokens and secrets, that’s better, and we should do as much of that as possible. In all cases, you want to validate that authentication request, as strongly as you can.

Machine learning can help establish the context. If it’s low-risk authentication request, let it happen. If the risk increases, require a little more authentication. If the risk increases a little more, require more. So I may be doing a fingerprint and an iris scan. It is now possible to apply the appropriate controls for the appropriate amount of risk.

(Editor’s note: Last Watchdog has supplied consulting services to Centrify.)

*** This is a Security Bloggers Network syndicated blog from The Last Watchdog authored by bacohido. Read the original post at: