Merging WAF and IAM Capabilities for Next-gen Security | Scott Tomilson (Sr.Director, Ping Identity)

I work at Ping Identity, and I’m the director of our product engineering team here. I’m responsible for several teams building our federated SSO and Access Management Solutions here. I’m based in Vancouver, Canada. My whole career, at this point, has been in identity security.

Before Ping, I was at Entrust for about 11 years, and I’ve been at Ping now for it’s my 12th year. I’m also the senior director and site manager here for Vancouver. So, I have a lot of different hats I wear.

Ping Identity has been around for about 20 years. Our CEO, Andre Durand, founded the company. His vision for the company is to create a visa for identity.

He didn’t know what that was, but he knew he wanted the identity portable so a user could securely log in over the Internet and prove themselves to many different applications and domains. And that identity would somehow securely traverse through untrusted networks.

He didn’t know what technology would enable that, so he didn’t realize it would be a product company.

Ping started more as a consulting company. We were the niche player around Federated SSO for a long time. Ping’s first product was Ping Federate, a federation server, one of the first Federated SSO products on the market.

I’m responsible for that. That was our flagship product for a long time. We have many customers and massive deployments that use that product. It’s had a lot of success with that. Ping was a small company around the Federated SSO space for a long time.

And, 10 to 15 years ago, the world needed a Single Sign On. Applications were moving to the cloud. People were using SaaS apps. They didn’t want new accounts or new passwords.

They wanted to log in securely to their existing directory server in their enterprise and then get single sign-on access to these applications. And SAML was the technology that enabled that.

There are also a lot of partner use cases and customer use cases where SSO was critical, so Ping had a lot of success with that.

It was a lightweight service you could deploy and enable that use case in the customer environment. Since that time, we have branched out into many different areas.

We got bigger, had a lot of success, and invested in many other products. We do access control and identity storage with the directory server. We’re in authentication solutions and risk management. We’re branching out into ID verification and personal identity solutions as well.

It’s like a framework in practice that describes how users will securely access resources, like applications or APIs.

It first needs to identify your users. If you are say using a website, you need to offer a registration process as users. If you are an employer bringing in new employees, HR or IT is onboarding them somehow.

At that point, they’re going to issue credentials. So simple case is a username and password that the user can then return to and prove who they are.

Then you have authorization controls:

• Were they authenticated?
• How do they access these applications?
• What are they allowed to do at that point?

And I have also defined the whole lifecycle around these things. So, you will have users that register, if they want to leave and revoke them at certain points. There’s a whole governance process that’s required around identities as well.

So, identities might not always be users. You might also have devices or service applications representing the client aspect and access to other things.

Yeah, at Ping, we do have a risk service as well. Machine learning based. We’re looking at large volumes of data – what the user typically does, where they usually come from, and what applications they typically access, which will drive policy decisions.

So, in the perfect case, at 9 a.m., you’re accessing your apps as an employee for the first time of the day, and nothing unusual. You’re just logged in. You don’t even have to enter your password.

But if you’re at a coffee shop, it’s evening. If something is unusual, a risk policy will detect that, forcing you to do a stronger form of authentication.

Nowadays, people are very fatigued with entering a password so many times and entering OTPs from text messages and stuff, and it’s just a mess. And ideally, we offer a password-less experience up to the point where we see any risk involved.

The term has been around for several years. It’s not that new. I believe it is a Forrester analyst that coined the term initially. It’s kind of an evolution of our industry.

Do you remember when we started working on security solutions 20 years ago?

It was a much simpler time when we were picturing that you have a nice DMZ and a security layer, and the apps are behind that.

You probably remember that the first product we worked on was a proxy-based solution, and it was an encrypted tunnel, and users went through the browsers connecting through that tunnel.

And then, on the other side, another proxy decrypts it and then goes to the application. All that traffic will be unencrypted at that point.

And then, we work in a zero-trust framework. You should assume that compromises could be anywhere in your network, and the applications can be anywhere. You don’t need to have this nice layer of protection where everything’s in the data center and is securely under your control.

Pretty much every enterprise is using SaaS apps. They have a mix of internal apps that might be deployed in a private or public cloud, AWS, and Google.

You don’t have this nice perimeter anymore. So you have to change your mindset and think about what is the security perimeter and what you should be monitoring around those things.

Since it’s changed, it’s more of a distributed architecture at this point, where it’s just the user going to these apps. You need to consider, what normal behavior is and how you authenticate these sessions securely.

CARTA is built around a zero trust framework but emphasizes more on continuous monitoring and adapting to different risks.

So focus on what is normal behavior for these users, for these identities, and constantly monitor that. You can’t just have a strict policy that will be successful forever.

So think back to when we were 20 years ago, we worked on our web access management product, and it was using our back-based controls, a role-based access control.

And you would go, and you would configure those rules, say these applications require these roles, and these users are getting these roles. And you think, I’ve got this all defined, and now I’m good and secure.

But that’s just the first step; you enabled access to the applications. But that’s not secure. You are just giving people the tools they need to do their job.

But with CARTA, you’re constantly monitoring for new threats, attacks, and things that look ordinary using machine learning or artificial intelligence.

So you’re constantly evolving your policies and practices around keeping your applications secure and accessible to the right users.

Unfortunately, humans are frequently the weakest link in an organization. You could have all the best security. But a phishing attack by clicking on the wrong thing on a site can quickly compromise somebody’s machine, and then an attacker is in the network; they have access and can impersonate that user.

So, I think that’s probably why they lead with that, to see the risk if this particular set of credentials was compromised. What can be done at that point?

At Ping, as many of our customers do, we educate our employees to ensure they understand how to identify and avoid phishing attacks. But it takes one person to let somebody in, and then you’re in trouble.

So, you have to assume that the threat is already inside your environment.

Yeah! If you know, there’s an authenticated session from Venky and an attack coming alongside that; you can quickly narrow it down.

All right, what happened here? How did these credentials get compromised? How did the session get taken over? That allows you to back-track quickly.

Maybe it doesn’t let you identify what this is in this case; this is an advanced user doing it as expected. So I think there could be strong reasons why you want to tie the two together and be able to tune the knobs around what’s allowed based on the type of user that this traffic pattern is coming from.

We have a dedicated security engineering team here at Ping. They sit alongside our teams like another QA testing team, that does a very deep review of any new features and functionality around our products to make sure they identify the risk associated with that. They do very detailed testing to make sure that it’s hardened as possible.

Also, we get external penetration testers quite regularly to look at our products and make sure that an outsider can’t find new vulnerabilities as part of that. And we’ll get reports around that.

We also participate in bug bounty programs. We get external submissions from bug bounties and review those closely. And if it’s a legitimate issue, we pay for those.

And of course, like any security vendor, we’re constantly getting requests from our customers asking, “You are using this 3rd party technology in your product. A vulnerability has been announced about that, and we have to review that and see if that impacts us.”

So we’re constantly reviewing those, keeping up to date with these, and making sure that we’re keeping our products as secure as possible.

Absolutely. Yeah. We have many businesses through SaaS, so you must keep testing things. You have to ensure that it’s not just the new stuff; even the new stuff can introduce vulnerabilities you weren’t aware of it, so we have to test everything out there regularly.

We have a lot of automation around our products to ensure we avoid regression. We’re getting ahead of the issues there before our customers notice anything.

As I said, it’s our business we need to be on top of that. So, we do our best.

I’d say identity needs to be a huge investment. I don’t think we thought that way 20 years ago.

I think front and center now because everyone realizes there will be risks associated with it. So it needs to be a large part of security spending. It needs to be a core part of the business.

There are two major areas of identity. The workforce identity access management and CIAM, customer identity access management. There is some overlap between them, but some very different things need to be considered.

For the workforce, you want to ensure we talked about. You want to give users the best tools to authenticate securely, give them strong multi-factor authentication solutions, get them into the applications, and you want to monitor the access to the applications and ensure that you’re checking for any anomalies.

The user experience is not that critical for the workforce. Nobody’s going to quit over a bad logging experience at their employer. Maybe they are frustrated with their job or something, but they won’t quit.

You’ll lose business if you’re making your customers create a new account, a password with X number of special characters in it, and stuff just to register for buying some products from your new website.

That must be smooth and easy to do, but it must be very secure. So, you have a very different approach, and these things are always changing, and you can’t think like, oh, I’m going just to carve it out, and then I’m going to code this, and then I’m done.

It evolves, and there are new forms of authentication, and there are new attacks.

You should be using best practice tools for this stuff and solutions that enable you to change how you’re configuring and providing the user experience to the user.

It’s not all cemented in code, but once that code is all written, what happens when those developers leave your organization, and you need to bring new people in?

They don’t know the code base. There may be bugs you’re unaware of and everything. You should use hardened tools for these things that will give your business much more agility.