Zero Trust & PAM – Privileged Access Management – Expert Discussion

Sath Inc

IDHub Team Member

Our very own Arun Binaykia leads a panel of cybersecurity experts to try and translate Privileged Access Management and Zero Trust to the rest of us.

Along the way, they will discuss the critical need for corporate adoption of this new security standard.

They will address common PAM misconceptions, and hesitations about implementing Access Management.

We confront two common concerns; the prospect of a single point of failure, and the case of security vs. lost productivity. 

The Zero Trust Pam Panel Of Experts.

Arun Binaykia - Moderator - Founder and SEO of Sath Inc.

  • 20 Years experience in Security Industry
  • Presented at Gartner, Kuppinger Cole, European Cloud conference
  • Featured in CIO Review  Magazine
  • Developed transformational solution, IDHub


Joe Burke - Chief Product Architect - Brodcom Inc.

  • Chief Architect for symantec PAM: from early origins and acquisition of Xeedium by CA Technologies, to modernizing it
  • Significant experience leading cybersecurity implementations
  • Financial verticals, PaaS/SaaS, others


Robbert Van Beveren - Solutions Architect, SecOps Enterprise Studio EMEA

  • In-depth, hands-on, full-life-cycle Practicing Solutions Architect
  • Leading solution visioning and design through implementations
  • Wide range of customers across EMEA for 25+ years


Sesh Ramasharma - Global Head of Identity Security Enterprise Studio

  • Decades delivering program management, advisory services
  • Organizations of all sizes, complexities verticals
  • Focuses on all aspects of identitty security
  • Multiple vendor soutions in all areas of identity security

Zero Trust PAM Transcript

Lisa Sass:

Hello everyone. And thank you for joining us. I'm Lisa Sass from Enterprise Studio by HCL Technologies Today, we have a panel of cybersecurity experts who will be discussing Privileged Access Management in the context of Zero Trust.

This topic is particularly relevant as PAM becomes much more visible with the Rampant exploits in Ransomware today.

Each of our panelists brings very deep expertise with a wide range of experiences across multiple regions, and multiple industries.

Please plan to stay for the Q and A at the end of the session, our panelists will welcome your questions. And you can submit your questions in the ask a question window, and we will answer them at the end of the discussion, or you can always email your questions to [email protected] and we will respond after the session.

After the session, you will also find some additional information about today's panelists and about today's topics in the attachment section.

So, joining us today on the panel, we have Arun Binaykia who is our guest moderator and facilitator for the panel.

He is the founder and CEO of Sath incorporated, and has more than 20 years of experience in the security industry.

He has presented in such forums as Gartner IAM. Kuppinger Cole, European identity, and cloud conference.

He's also developed a transformational solution IDHub. He's also built his organization from the ground up, and been featured in CIO review magazine.

We also have Joe Burke. He is the chief architect for Symantec, PAM, and he is with Broadcom, Inc.

His expertise is particularly welcome today because he has been the chief architect for the solution since its early origins, the acquisition of Xeedium them by CA technologies, to modernize it.

He brings significant experience leading cybersecurity solution implementations, including financial verticals and PaaS and SaaS.

We also have Robbert Van Beveren he is a practicing solutions architect for SecOps Enterprise Studio EMEA.

He has worked with a wide range of customers across Europe for more than 25 years and has extensive experience leading solution visioning and design all the way through implementations.

And finally, we're joined by Sesh Ramasharma, he is the global head of identity security for enterprise studio by HCL technologies.

He also brings decades of experience to the conversation, delivering program management and advisory services to organizations of all kinds, all industries, all complexities, and he has also worked across multiple vendor solutions in all areas of identity security.

So with that, I am going to turn it over to Arun and let's start this discussion knowing that it's going to be a very lively one. So Arun it's all yours.

Defining Zero Trust


Ultimately somebody is going to get in there and
try to do something they're not supposed to do.


Thank you, Lisa. Thank you very much for getting us started.

I am super excited to be here talking about Zero Trust and Privileged Access Management, two pretty interesting things in the security space these days, and explore all of these things with our panelists and pick their brains and see how things go.

So before we get started about talking about Zero Trust and PAM, let's talk about what are they?

So I'm going to just ask each of you to explain what Zero Trust is. What do you think Zero Trust is, and how do you explain it to our audience? So what is Zero Trust architecture, Joe?


Sure. So Zero Trust. Isn't a single thing. It's really a lens that's applied to all layers of technologies, whether it's your network, your servers, your desktops, databases, applications, and even your coat.

Zero Trust is pervasive across all of those, right? And it's really a system of beliefs of the way to approach identity and authorization. At its core.

You know, Zero Trust is nothing is trusted, which sounds kind of obvious, but whether it's a firewall configuration, API call access to a server, these are all controlled and audited centrally.

That is one of the key things that Zero Trust applies, not only can you prevent it, but you can also understand what's what, what has happened across it.

The fundamental assumption here is that some kind of actor, whether it's an employee, a contractor, a hacker, a process, what have you, will end up inside your environment.

And Zero Trust helps set that foundation so that no authorizations or access can be assumed, right? I mean, we often see that keys are misplaced and then used and abused and whatnot and Zero Trust helps take that part of it away.

Or if it is found it's, it's invalid and can't be used going forward. A lot of our customers take a multi-pronged approach. You know, PAM, along with the advanced and adaptive identity techniques, API coverage and governance are core to a successful Zero Trust architecture. A mature PAM product.

In my opinion should cover both what we call the coarse and fine grain types of authorizations. A course grain would be things like a proxy in a vault where access is often facilitated, either over credentials or secrets or what have you, but then fine-grain operates even at the kernel level.

And even on that as an agent on a server that can control processes and users from getting any kind of elevated privilege.


Quite a lot of things to understand and digest. So how about a you Sesh? What do you think, how do you explain Zero Trust?


Well Zero Trust simply put in a summary is never trust, always verify that pretty much is the essence of Zero Trust.

The idea of having everybody verified before they perform any actions on any asset, essentially is the key to Zero Trust, right?

So I think PAM is a really relevant topic in that sense.

And, the key tenants we would we look at would be NIST SP 800-207 publication, or Forester, or even Gartner models and ZTX model for Forester, all of them have certain tenants in it.

A key tenant of Zero Trust you can boil down apart from is, never trust, always verify.

A few things like; visibility and analytics are key.

They recommend automation and orchestration capabilities that essentially, we'll, you know, we'll see how it evolves into any solution for that matter.

And also segmentation, that's a key, it might be a network concept, but it goes beyond that.

And, then compliance those are aspects that all these models essentially cover.

So that's a quick, in a nutshell view of Zero Trust from my perspective.


Robbert, how do you explain it?


Yeah. I mean, to be fair with Joe's and Sesh's, explanation, there is not much more to add.

I mean for me, it is a thing you do in your company it's goes across the estate. So not just technology, it needs to be supported by processes and procedures.

As Joe said, ultimately it hits your, your information. That's what you're trying to protect, but it's also part of, your physical security.

How do you secure your buildings? How do you secure assets, even down to the point of, you know, even in your real racks, for instance. You know, who has access to them and how do you make sure that the right people have the right level of access all the time, whatever they need to do.

And yeah, as it's being repeated, a number of times, never trust, always verify, start with a point of “Who are you, why are you here? What are you trying to do? And what do you claim to be able to do? And verify that against your single source of truth, be that a vault, or be that something else.


So thank you for all that. I like to use metaphors and I think I like to use an airport, like a metaphor of a Zero Trust.

You're challenged pretty much almost at every step of the way, going into the airport, to the check-in, x-rays. If you are an airport mechanic, you have various checkpoints to access the plane's control, as a passenger, as a pilot, as a groundskeeper.

So you have different levels of access and you're challenged, pretty much at every source, every checkpoint. And so Zero Trust in a more of a digital world would be a metaphor.

An airport would, could be a, would you agree is something similar?

For people who don't understand the level of Zero Trust and the technicality that we understand, it's pretty much enforcing controls almost at every different space.

Even though you enter the airport, secure perimeter, as a baggage handler everything, every step of the way, you have to present your credentials and get in, and tell who you are. Okay.

Privileged Access Management


So let's talk about Privilege Access Management.

We talk about not trusting anybody, but somebody you've got to trust. There's gotta be a circle of trust.

How does Privilege Access Management help enable Zero Trust, Zero Trust with checking everyone, just trying to connect our audience to where they are coming from.

We're checking everything, everywhere in the context, with the credential, single source, all of those things.

That's great.

PAM Privileged Access Management helps us do a lot of implementing those controls.

So Joe, can you elaborate on how Privileged Access Management helps you implement zero trust and what it is and how does it implement it?


Sure. And you hit the nail on the head, right? So privileged, any PAM solution will enhance a company's control plane and also governance plane at the end of the day, providing consistency, one-stop shopping for how you meet against your auditors, your regulators, or your internal law compliance teams and procedures.

But ultimately the information that's inside of there is highly encrypted and inside of a vault and access to that information is authorized by policies to enable employees on a need to know basis, right?

So let's say you and I are on the same team. I am the baggage handler, as you said, as you would call it, you're the pilot, right? So we have different levels of access. We can control that through our policies inside of PAM. That works across whether you're in an enterprise or whether you're in a hybrid environment, right you know, across the clouds and what have you.

Most products, most PAM products, especially ours, starts with, it leads with the Zero Trust. And we do the least privileged approach. Right?

So anything that you put into the vault it's hidden and users are only gonna be able to see that when they are authorized to do it right. So it's by explicit grant as opposed to, you know, implicit grant.

In addition to that, we also hide things. And while that sounds bad, at the end of the day, if you're logging into a server, as let's say a root user, we will auto log in on your behalf and never release the credential back to you or the secret back to you. So it's never known by you, but yet you're using it.


Sorry to interrupt, but you mentioned a couple of things.

I think we can elaborate a little bit more. Control plane and governance plane. Yeah. I think I understand what you're saying, but if you can elaborate, why use that model?

For people who don't understand the control plane, governance plane, and especially in a Zero Trust and PAM, how does it?

It's probably where the rubber meets the road. It's like, so can you explain what you meant by control plane and governance plane?


Absolutely. So probably the simplest example I can give is how do you log into a server, right? Where I can use a password, or it can be set up as a password. I can set up as a key, right? And put something in the authorized key file. I might have even a cert that allows me to have a short time token to be able to get in.

All of those are essentially the same way to the same result to be able to get into a server. And so when you talk about a control plane, we're giving companies the ability to, to set those standards, right?

We don't want any credentials. We don't want any passwords. We only want keys. We don't want any keys. We only want certs, and they can adjust in tune the level of security that they're comfortable with, both from a compliance and as well as an operational perspective.

So that's the control side of it. In addition to that, I can make sure that only key people in the organization have access to those, to use those vaulted items.

And that's a key thing that, you know, I'm not going to be able to have a key, be passed around or put on a shared drive somewhere or a thumb drive. I'm going to have it controlled inside of my vault. And I'm only going to give access when it's being requested and only if authorized.

So that's the control side, on the governance side, typically a lot of customers, a lot of our customers have to go through very rigorous regulatory and compliance policies where the manager is signing off on all the employee activity at the end of the day.

So ensuring that there's proper change control, proper authorizations, making sure that folks that are authorized are supposed to be authorized or should remain authorized. So you don't have, longstanding privileges or, if you transfer departments, you don't end up with the access from your old department anymore.

Those are the things that allow for the governance side of it, where, people can look at it, monitor it, attest to it and, and ultimately sign off on understanding the risks that they're working with.


Just going to dig a little bit deeper. I've worked on compliance a lot, and here's interesting part.

Compliance plane and Governance plane, this is probably the first time I'm hearing, I'm looking at those terms and these words and these words in place. Governance I understand, when a whole bunch of regulators, lawyers, people who don't, who sit down and say, here's what ought to be.

Simple governance would be something as simple as, if you are terminated. If an employee is terminated, that access needs to be removed in 24 hours, that's a governance statement.

It's easy to understand for people, in lawyer speak, probably more complicated, but if this happens, in English, that should, that governance should be applied and control plan would be a Privilege Access Management or any management system goes in and yanks out the credentials from that.

So that's connecting what the governance is that happens, and what the technical controls are that happen and marrying them together.

I'm just going to pick on our other panelists here with Sesh. Do you want to add onto how the PAM helps us connect our governance and our controls? Because what we want, and what we have, sometimes there's a lot of drift between them.

How does PAM help us with getting the Zero Trust? Zero trust is again, more of a governance.

And for them to get the context, how does PAM help you put the governance of Zero Trust and the control together?


There's no perimeter anymore.
Everything has gone outside the perimeter.

Joe hit on key points there. As I said earlier, now the key tenants of Zero Trust being; visibility, analytics, automation, orchestration, compliance, and segmentation.

If you take a look at each of those elements, I can quickly kind of go over like; visibility and analytics, employee access management is pretty straightforward.

If you look at what PAM does essentially like that hooks into your dev ops CICB pipeline, right?

From that to access, to administrative access, to systems, logging into the operating system level, or a new database level, or you're an application and administrative role.

At any level, or you're looking into it, the fact that there's some level of control that you can govern to. Governance and control are kind of slightly different like Joe pointed out.

Control essentially is around creating a policy use and essentially implementing a policy.

Governance is around verifying the policies, around making sure that there's appropriate policies, and also separation of duty to a degree because the people who are governing these policies should not have access and vice versa.

People who want access, If they control the policies, and dictate how things are done, the governance aspect of it, you know, you don't want. You want some level separation aspects of it and that as well.

So, essentially the point is that, visibility, analytics, aspects of politics manager, a solution like that, and any orchestration or automation, the key is manual controls that are going to be very error prone.

Any level of Automation is going to make that a lot more, you know, you get a control of the situation and you can appropriately put better governance over it, right?

So you see the difference in the two terms that are being used here and segmentation, obviously.

There is no meaning for organizational perimeters anymore, right? In the cloud world, there's no perimeter anymore. Everything has gone out and you need micro perimeters around assets.

And that's where the segmentation comes in. Essentially when you gain control of credentials in politics and management, and essentially, lock them up, essentially release it only on a need basis.

In this case, Joe, illustrated a point where you're saying, we are going to proxy you. We're not going to give you the control. You want to do this. I'll proxy you into the end point.

So as long as segmentation and then, aspects of reporting, logging in any compliance oriented, things come as a side effect as a benefit, right? Because that's all required. Visibility is key.

So that's a quick summary of how a privileged management really fits in this particular realm.


So would you say Privilege Access Manager more lies on the controls Plane, helps you trace the governance policies in the controls plane?

Adds visibility, adds different controls, like not sharing passwords, not in each session brokering, proxying?

I'm going to slightly twist this for Robbert. So going from a governance plane, I'm thinking a board of a large organization, a fortune 500 fortune thousand comes in that says, tells the CIO, “Make us secure.” Guarantee me, assure me that you are secure.

The CIO says, well, we've got to have our Sox, a NERC CIP or HIPAA, whatever the regulation says, these are the best practice, ISO 27 K. And let's go ahead and implement this.

It goes on down the command and says, well, we can do all of these things, and part of it is Zero Trust.

Help me, help our audience understand, going back all the way to, how do you assure, I mean, there's no proof levels or proving security protocols.

How do you assure a high level of trust or a higher level of assurance of security with PAM when the governance and where the control the meet with PAM?


Hmm. I have to admit, I'm not quite sure where you're going with the question. However, I'll give it a whirl.

For me, PAM obviously, you've got your… for starters, when you've got this scenario, you, as CIO, you need to set up the governance framework.

What do you want to achieve in your, whatever your security model is that you want to do? And then if you haven't got one, you have to go out and make one or create it, or otherwise establish it.

That in its own right is a complete exercise to actually go through your entire business and set up?

What are the assets we want to secure? What is the value? Do we rate them one to five, one to six, whatever it is, you know, there's all sorts of things out there where, where people


This is the Governance plane


Yes. That's the governance plane. So you set that up. You can, then once you've got that, you can then look at your PAM and say, okay, that's my governance. How do I want to control that?

And then you can go into PAM and develop all your policies and set it all up. And then PAM then allows you to apply that consistently across whatever you've come across.

So to automates things. You can have a very complicated governance piece, but if you then implement your policies, then you can hand over your administration to people who may not necessarily be fully aware of your governance framework, but because they know the policies, they will follow that, and they will implement that. So it allows you all that automation and that consistency,


Any examples any of you can give us?


Yep, absolutely. So a governance policy might say something to the effect of, for anybody to access our production environments, a VP has to sign off on it before they can log in.

So that's the governance, and that's the control objective that they want to get to. The control implementation is in PAM.

So let's say Sasha has access to route at some server. He goes to click on it to auto log in, next thing you know, he has to wait for his manager to approve an email, or, come into the system and approve it himself.

Once that happens, he has it for a defined period of time for, let's say a two hour window, right?

So, you know, PAM is providing the consistency of controls, the consistency of workflow in a lot of cases, whereas it's meeting the control objectives and, or exceeding the control objectives that are being pushed by the company.


So the manager can go back. the VP can go back to the CIO and say we are more secure because every production is authorized by me, which CIO can go to the board and say, “We are getting more secure.”

An excellent example, any of the examples that we can all relate. I mean, that can be easily relatable.

Sesh you talked about visualization or reporting.


Yeah, those are more sophisticated aspects. Like as time progresses you can use intelligence to drive policies. Governance now begins a lot easier for organizations.

For example, they go look for patterns of behavior, user behaviors.

A very good example of this, let's say you caught the fact that a particular administrator has got certain types of behavior, and you realize that there are some loopholes that in control aspects of it have not been blocked.

That becomes relevant when you start analyzing the logs, understanding what your policies are. Working in the context of it, maybe there's something to be locked down further.

And that you realize in some Low level artificial intelligence, I would say, or machine learning kind of algorithms, as things are evolving and emerging. It's called analytics orientation. Right?

I think there's some products have things like threat analytics.

Hash creates a dynamic aspect to the whole thing.

Like, intelligently, you go fix the, there's some level of governance aspects that can be automated as well.

I think there's some, you know, in the reporting realm, starting from analyzing the report manually, you may start low, but as sophistication increases and you're able to layer and, and products are able to do these things, policies can be locked down. Used to lock down and gain control.

So it's a beautiful ecosystem. I would say. It's just evolving.


So going back to the airport example. I see the baggage handler is using the parts warehouse to access a shortcut to the outside. And okay, I see an anomaly, and they're allowed to do it.

It's policy, it's governance, but hey, this is something that isn't right because they get access to parts, which can, we don't want them to be accessing and tampering with.


So along those lines and Robbert, my apologies. I think you wanted to jump in too.

In our world, we have a behavioral analytics unit in our product set. We can detect things like; a user has always logged in from, let's say the Northeast of the United States.

But then, all of a sudden, he's logging in from a country that doesn't have a presence. The company doesn't have a presence in.

And so, you start to ask the question, are they at a customer site and their VPNing in? What's going on here?

If we can raise alerts, raise flags, we can ask for a minute, you know, dual approval. We can always record sessions when they do access something so we can monitor what's going on.

So that behavioral aspect of it, they logged in from somewhere else, or they logged in concurrently from more than 50 miles away from each other, in a short period. We can detect those things and, and certainly take action against them.


So help me understand. I want to explore that just a little further.

Cause that's, I mean, I've been hearing that particular use case for, I don't know, 12, 15 years now about how you're logged in from say China, Russia, and Santa Clara at the same time, there's something going on.

But the amount of policies, we just, it's more reactive.

It's like, okay, I'm building a policy for country A. I'm building a policy for region B.

And lately, we've heard a lot about AI being used, machine learning, pattern definition.

So let's talk about what you have seen, what do you see in PAM that helps you do this better?

Because if I start, I get policy fatigue. I mean, how many policies? The tons and tons of mountains of logs that get turned out.

Where do I find my weaknesses? How do you, how does PAM or the newer PAM technologies help you do better?


I certainly have an answer to that but I will defer to Robbert or Sesh. I don't want to hog up all the time.


By all means, go for it. But I, for me, it it's, it would be looking at automation to, inspect those reports, to look at, you know, where do people, what behavior do people have and track that?

So, yeah, but I mean, the one comment I wanted to make was, what Sesh and Joe have referred to; Know, Zero Trust it is a journey. You can't expect to take an organization from a level one trust to five or six within a short period of time. I mean, obviously a very small organization, you can, but Arun, as you said, a fortune 500 or a 1000 company that's unrealistic.

It is something that you need to embed in your company. And,

The firewall peremiter is obviously just gone. ~Arun Binaykia


My CIO says, now, the board says, well, we need to have it now.

But my people are logging in from everywhere, from Bangalore to Estonia, to Florida.

And I've got people everywhere. There's no boundaries. So Zero Trust, that's where I see Zero Trust principles, the mature levels of maturity increasing and the policies.

Because I think in my own company, we've got people I think by now we are at about 15 different cities. I can count where all our people that are working out of? And it's all remote. I mean, there's no, there's literally no boundaries.

I haven't seen some of them for a long time or never. But the point I'm trying to make is how do you put together policies?

What, how do these tools? They can do that, but to do something easily?

Just a few more things before I get into the next segue, which is the software defined perimeter.

And if you want to use, that's what I hear, the software defined perimeter is how you, your perimeter. The firewall perimeter is obviously gone, so how do you set software defined perimeters? You wanna chime in? Anybody, Sesh?


Yeah, sure. I mean, software defined perimeter is pretty much like saying, in Zero Trust is, paramount.

Because you know, as we all saw, like you said, in your example, and that's the case, most organizations, you're not near people.

Your assets are sprawling, right? They're not in one data center anymore. Right?

You got, you know, organizational assets, information assets stored in the cloud, all over the place.

You have databases running on Azure probably, or some servers running in AWS. You've got laptops in your organization that need locked down. Administrative access is all over the place.

As you can see, it's like everybody has got access to everything. And at some point, you need to start locking things down

The idea of a software defined perimeter is to have essentially a perimeter that can operate at various levels, in all the seven layers of the model, you can have a software defined perimeter essentially. The perimeter is virtual, as you can see.

The perimeter is essentially what you can and cannot do. Right?

Essentially, that's what it is. So instead of having a network perimeter saying, okay, I have a DMZ, anything inside DMZ, it's free for all, anything outside of the DMZ, I know there's attackers that are coming in, I'm going to be careful, but those days are gone.

And that concept goes into the micro perimeters scenario. That's where software comes into play.

Every one of these accesses need to have some level of salt. I mean, to put hardware on every piece of these things, there is no solution like that.

Now the software has basically come up with excellent creative ways, privileged access management being one of them, particularly that closes down, some of the perimeters down, particularly the administrative and elevated privileges down.

Access, that's going to be the key.. So that's become a paramount concept and overall governance of these controls. I yield the floor to my colleagues further to,


Yeah, I mean, just a, just a couple on that, right?

If you look at the dev ops revolution, what's happened in the auto rise of automation, hardware couldn't keep up.

Deploying new servers and new racks into a data center was a month long endeavor, or months, long endeavor oftentimes.

And so now the software has enabled the speed and the rate of change to be a lot faster.

That has certainly helped both destroy the outer perimeter to get to those micro perimeters, as Seth said, but then also to provide the greatest amount of flexibility to customize on a per, I'll call it, element basis on how you want to control it. Right?

And that's where, whether it's people coming in, whether it's processes coming in, whether it's access, whether it's applications accessing databases, all of that gets governed and pushed through. And PAM is at the core of all of that.


So let me ask Robbert, you being an architect, let's talk about something very interesting that this is leading on to.

So an example, we've got Google workspace, we've got Atlassian, I've got Bitbucket, I've got a Google cloud, and let's start with just this and Pipedrive and then Google analytics, all of these, they have some touch point.

And you go into marketing with Segment and with a CRM trusting segments, which is trusting our SMTP service from Sendmail too…

There's a whole web of interconnected trusts that have been established. And I worry about where the permission leakages might happen.

So in a SaaS infrastructure, so people who are talking about dev ops, we have automation that you can change.

You do a commit which goes ahead and pushes things out to all the way to stage, not in production, but all the way into stage

And stage which is trusting their services for notification that has credentials.

It's an insane web of trust that have become in a Zero Trust where, all of these are tokenized and the part I'm trying to get is how do you put PAM in there where these tokens are not available to, not necessarily, how do you put the PAM control plane on a web of trust like this, but with credentials all over the place?


If you don't gain control of what your assets are, you can't protect them.


Right, I have to admit, that's not something I've been involved in. So far, most of my organizations have been far smaller than that.

They've been starting at a much smaller maturity model in terms of just restricting access to their local resources or some of their suppliers.

So the whole cloud piece has, as an architect, I haven't really touched that.


It's Complicated, Absolutely

You know, I agree it's a challenging one. And that's exactly where we are in a position to kind of take one step at a time. The point is that you cannot boil the ocean idea, right?

When you have a web of trust, you've got to start at understanding what the entry points are, what the touch points are.

There's some whole analysis required. I mean, you know what your assets are obviously, right?

And as an organization, if you don't gain control of what your assets are, you can't protect them.

The fact that I don't know, there's a server running somewhere in the cloud and that got instantiated at some point in time because my capacity, or probably some web traffic, what had to be, we had to spin up more.

There's some level of control involved in it right?

When you setting up capacity increase for example, in AWS as an example, you said, or in Google, for example in dynamic set up.

You have Kubernetes just spin something up. There's some credentials involved that lets those things happen and make sure of that.

The point is to understand the assets. You understand what is ephemeral, what are constant assets, where are permanent assets

There's always constant change too, right?

And you're always, you know, your DevOps increasing your assets, you're retiring stuff kind of pushing you.

So, the idea is that you cannot boil the ocean, but you're going to have to start one step at a time like LABA was talking about maturity.

And that's the key is that you can start it, you know, you will be in a catalyst situation when you begin.

Get to step one. Gain control of a few end points. Then you get through learning. As you graduate through your maturity process, you can gain control and lock things down further and further.

As they say, a gradual approach is key to getting control like that.


typically see customers starting to ways that way, right in, they're absolutely correct where it's a maturity model, but it isn't just one path. Right.

You know, today in this conversation, we talked about user access. How do we get users the ability to see privileged information or gain privileged access to something?

However, there is the automated software side of things as well. The programmatic side of it, if you will, where I am an application and I need a credential to get into a database.

And that database has extremely protected information, maybe even company secrets or, customer PII, or what have you, things that you really want to slow down and make sure that those credentials are rotating very often, those credentials are your applications are able to adapt to that change in credential.

When it does happen, you don't want to be tying a dev ops activity to a security ops activity.

And so, as you see, as you described it, it was, how do you get to this whole mesh of things of, of, of being able to, get them all, to work together?

Well A, you identify the touch points that are using the information. Those key assets you bring into PAM. You get the targets they're going after, which is also key assets, where you have the credentials, passwords, token, secrets, what have you.

And then from there you give access to only the things in runtime environments and do so in a runtime kind of manner, right?

You don't, you know,I work a lot with the Kubernetes and containers and everything else, and a lot of people put secrets into two environment variables.

It's really not a secret. It's a decodable string that anybody can get access to provided they have access to the container, not to mention you change the secret.

And now you have to do a whole dev ops activity to be able to recycle everything.

Like that's, that's not a ideal place to be, but with runtime access and being able to query out to get the secret right now, that can be done in a very efficient manner, very low overhead, 30, 40 minutes seconds at most.

And then you can always be in touch and that way your security team can operate in any schedule they want to, and your application teams aren't right.

So all that comes into play through a secrets broker or a credential broker, or one of the components we have is called an applications application kind of Nonhuman consumers of accounts and credentials.


I think that could be a whole session by itself and sorting out the trusts.

And as you said, much in discovery, because I just discovered, I went into my DNS request, like, okay, what is this service? Where is it registered? Oh yeah, this is something I did six months ago for a proof of concept and it's still sticking out there.

Talk about discovery in assets, like any best practices? Anything that you can impart about?

How do you start? About, you started very good; discovery. We got to know what we have the two and from so, any?


How do we get started?

Sure. So, I would look at it from a coarse grain and then to a fine-grain perspective. Right?

So the coarse grain would, and again, I know it's a little bit of over use of terms, but the coarse grain would be; I have a PPC environment, I have a data center and all of a sudden new IP to show up, new VM show up.

If you go into it with the assumption that, even though I have all the controls in place to deploy it through whatever channels and pipelines and workflows that I have, ultimately somebody is going to get in there and try to do something they're not supposed to do.

And, you can try to stop them. Then there's certainly ways to do that. But when you don't stop them, how do you discover it?s

And that's sort of where I would look at it. It's like the catch all at the end of it all at the end of the day.

And when you have that catch all, you can look at things like, oh, I have VMs that have showed up on my network, raise an alert.

I have accounts that have shown up on this server that I'm managing, or I have authorized keys that somebody put in there somehow.

And I don't really know how, I don't really care how right now. I just want to get in there and either get rid of them or to change them, rotate them so that they could lose their access. So now I'm controlling it. Right?

So it always has to be a continuous process. That has to almost be monitoring and scanning daily, monthly, hourly, sometimes depending upon the nature of your environment.


It would be nice, if at the end of the thing, we could probably just collect some of those best practices and how do you go about starting and going through the journey?

Because I think a lot of people are in the same position with a web of trust and just not knowing how to manage it all. It could be larger or a smaller organization.

PAM Misconceptions And Misunderstanding


I think the primary thing is thinking that PAM is going to be a pain in the bum.


A couple of things I wanted to touch before I want to go just PAM, how do people misunderstand it?

What, what kind of things that you heard like, oh, this is not PAM or this is not right about PAM. What's something that you can say, okay, this is not correct about PAM?


Well, I think that the primary thing is PAM's going to be a pain in the bum. It’s going to stop us from doing whatever we are now used to doing. It's going to make our job impossible.

It's more difficult. I wouldn't say impossible.


I’m exaggerating, but I mean, they're the sorts of things you get push-back from, certainly from sysadmins who say, “look, I know, if I need to take a breath, I need to ask permission first from change management or something.”

They’re really ridiculous examples, but that's what I've come across.

Look, to be fair, I've been into that position myself, where in a big corporate, somebody came in from outside of the office and said, we're now going to do it this way. And you're going to basically lose root access yourself. My first reaction was do my job then.

And, but, you know, we went through the process and after a couple of months, I thought, Ooh, Hmm. I was wrong, okay, it works. And it works quite streamlined. It worked very, very well.


It is mostly changes control then. It's mostly letting people get accustomed to the newer way of doing things


So organizations managing change, managing people through change. They've got the longest standing practices and yeah, PAM's going to have to change those. You are taking control.


Yeah. Certainly the culture and a company will dictate a lot of things. Right? You have the compliance security culture in one side of the house.

And the other side of the house is the operation folks, the SAs that have to jump on and deal with problems very quickly.

And whenever you slow the SAs down, they're going to complain. I get it. And totally understand. And PAM is an access point that they have to deal with. It's the necessary evil at the end of the day.

But what it provides, aside from the consistency and the control though, is it does prevent people from accidentally doing things they're not supposed to.

And we're all human. We all make mistakes. I'm not saying anybody is trying to be nefarious. And certainly some people are, but you know, mistakes happen. And it's designed to help to try to control that.

I would say what's interesting is we have one customer whose SAs are actually compensated on how fast they can resolve issues.

And when they introduced PAM, it was a revolt, I mean, flat out.

But, at the end of the day, you know, we pushed through and the security compliance side of the world, the benefits outweighed, the operational slow down that has happened.

So, there's always going to be that tug of war. I would say the longest pole in any kind of implementation is that working out, which side of the house wins, or how do they compromise?

And that has nothing to do with PAM because PAM is the execution arm at the end of the day.

Getting the policy and governance and the objectives set, getting the agreements with the operations team is, you're bringing your helmet and your mouthpiece because it is going to be  fun conversations to have.


Just sit down as a project manager, as a therapist between the system administrators and the corporate, the compliance.  Everybody take a breath.


And sometimes here in particular countries here in Europe, that may not be so much the case in the US but worked councils can exert considerable influence over what you can and can't do with PAM.

You've got to get them on board in some ways first, before you even can proceed, they can lock the whole thing down. 


Talking about locked down. Does it become a single point of failure at some point in time?


It's always, when you put controls in place, you know, when the control fails, there's a whole idea of fail safe versus fail miserably, fail unsafely, right?

Fail safe essentially is like, you know, you need in a scenario in a Zero Trust goal.

Implementation managers, when you fail, you have all your walls essentially holding all your credentials and essentially if it is not accessible, therefore it, then this is a very classic example that everybody uses in saying, a case against PAM.

Because what happens when the administrative access is completely locked down and it takes a headache to get back.

The idea is that, when you put controls like this, you need to plan for, and essentially create compensating mechanisms for a break glass and other important things that are very key, you know, for a solution like this.

 So long as you, if you consider it carefully and put, break last policies and procedures in place, there's both technical and procedural aspects to break glass.

So, I didn't want to get into the detail specifics on the implementation here. The idea is that, you know, yes, it is. It is, and it is important to recognize that it could become a problem if you didn't plan properly for it.

So it's, it's a key, it's an important planning consideration. And it's important because corporate assets, how to be like now on any, as you can see, like, no, you look at any of these breaches or latest ransomware tags or anything like, you know, you can take like solar winds, for example, you know, under there, their signature off in all exploits of projections, it is very evident in many of these.

So I think like the 80% of the statistical perspectives they say, and Alice had been saying, you know, that the data bears out that it is there.

So, the fact is that it's simple thing, like, okay, we're going to be crippled, and therefore we're not going to implement is going to be a very dangerous position to take.

So there are compensating measures that one should take with regard to break last plan ahead. That will happen eventually, you know, will help you get over this fear of the single point of failure. I mean, that's the case with most of them. And then there's obviously this need to be built everywhere, right?


Yes. You can say that your database goes down, that's the single point of failure.


Exactly. It is a very good point. It's like saying that.


But for me, it's also, yes, PAM is effectively a single point of failure, but how many instances of the system do you have most importantly, you know, that the volt that you've built have you replicated that across a number of your sites?

And at that point, losing the database from a single site doesn't necessarily mean that you're, you're completely locked out of PAM. So say if you're using break clause, but for me, that is the final, last ditch effort to design your PAM system. Okay, fine. But you know, it's a very, very rare recurrence.


Yeah, it's definitely steps in, and layers of protection in session.

Sesh described a lot of the like operational layers that accompanied we put in place, but PAM products themselves should be highly resilient, should have copies, should have durability across, you know, network outages or, or site outages, or what have you.

Mature PAM products can handle that in the sense that when you, when you implement it the right way or in an HA kind of way, it gives you that resiliency against any kind of failure. Now, if all of your sites go out, I think you have a bigger problem than that.


Talking about a single point of failure. What all things do you put in there? I mean, every single corporate account, what becomes vaulted?

I mean, where do you draw the line on what goes in that becomes vaulted and controlled, and it goes into your control pain and what does not, how do you?


So, I would look at it from a risk perspective, right? What is the risk of a piece of information being let out, right. So a root account on a box that has a database with PII information or financial transactions, that's pretty high risk.

A content server that has, you know, a read only account that, not a read only account, but like a, you know, a basic account that can just publish content to it, into a set couple of directories, probably a lower risk, right?

So you have to look at it from the risk plane and, and do an assessment of what your critical assets are, build your program that way. Yeah.


It goes into the governance plane, let the security analyst figure out, okay, here's my different risk profiles for all these accounts and vault them, and put the PAM to control, right?


The Linux account. It could be a database account. It could be a SAS provider account, a third party vendor account. Like it's, it really goes the, you know, a very wide gamut.


Sesh, Robbert, do you want to add?


When you do that, when you, if you've done that analysis, you you've also got, you know, as we said, you start small, you start with your highest level assets, your most, the things that are of most value to you, you start with those and you then slowly build it out to get to the lower levels. So it, yeah. It gives you a way of tackling, implementing your Zero Trust across your organization.


Yeah. I would say, add to the two gentlemen, they were very good points made. That fact, the Zero Trust is not an objective, right? Zero trust is a concept.

You know, it needs to be applied with a level of relevance, and I think that it is possible to take it to the extreme. And again, it has to be considered against the value and the risk as, as my, my two esteemed colleagues mentioned.


So it's art versus science, and not everything gets vaulted, but you, you have to put in, bring in some experience, bring it some risk assessment understanding, okay. Before this last question, and I think we've got eight more minutes, but a few things. You can't end the conversation without talking about the impact of the pandemic. And in the last two years, we've seen, we've been through all of it. And how is there, is there, and how the pandemic has affected how we look at PAM, zero trust, it may or may not. It may be just business as usual as the pandemic is accelerated, but how do you see what has changed in the world of Zero Trust and PAM and in, in, adoption, or how the impact of it?


So, I mean, I think it's been an accelerate to be perfectly honest. I mean, it's gasoline on the fire, right? I mean, we're moving in this direction and the ones that were resisting it, you know, now that they have room for it.


Help me understand, help me understand what was, what was the inflection point? How did pandemic become the inflection point for adoption?


So the perimeter Sesh has talked about, that has gone away now at this point, we still have VPN and we still have security at the network layer, but that has allowed for more and more, more and more outside access to get into your, into your world. Right?

And, you know, if you move that perimeter from a big outside shell and much smaller shells, and even into applications and APIs, it's the lowest layer, you have, you know, companies that were resisting PAM because of the cost of the project or whatnot, are now being forced to, to go down that path simply because it's a way to survive.

And that's what I'm seeing.

Sesh and Robbert I’m not sure if you agree


I think the inflection point was basically the lock-down, certainly here in Europe, when you know, people got sent home from the office and everybody suddenly had to work remote, and that meant the system administrators as well. And at that point, you know, what do you do? And that brings PAM into very sharp focus.

Productivity Vs. Security?


I’m going to jump in with a couple of questions that are coming in from the audience. Is the Zero Trust the end goal? Will it be audited every step of the way? Isn't that productivity loss? So is Zero Trust implementing it, is it productive loss quick? I mean, it's what?


Is it productivity loss? Let's take that from two angles, right? There's the productivity loss of the security team, and what they're watching the monitoring, but then also there's the productivity of the user community that's accessing, you know, stuff through PAM. Zero Trust is really the fact that there's no standing privileges and nobody's going to be trusted even if you were trusted at one point in time. Right? So yes, there might be a couple of extra steps that the user might have to take to log into somewhere or to, to gain access to something. But what it gives to the company is the assurance and control of both credential rotation, you know, expiry times and certificates, if that's the preferred method, and those things help reduce the risk significantly. And so every customer, every company has to weigh the, you know, the additional productivity loss on a per person per transaction basis, versus the risks that they don't have to buy an insurance policy for that much anymore. Right? So like, there's a, there's a business decision there. Definitely


Following air traffic controls, is that a productivity loss? because we were taking an extra loop around? We could avoid a disaster. And so, yes, it is a productivity loss, but it's a cost benefit analysis in terms of what's the risk as well as correction. So the PAM, there's a significant gap in today's PAM solutions, addressing cloud environments, like we're talking about the web of trust and DevOps. As an organization, as organizations are adopting more of the cloud and DevOps, what steps can an organization take them in the interim to address their needs? It's an excellent question. That's the same thing, how PAM is, or is not falling short, in the cloud and DevOps environment. Robbert sesh and whoever?


I think products are catching up, there's a lot of, as time progresses right now here, we're seeing a lot of capabilities now with the integration capabilities with cloud, in being able to watch cloud accounts, being able to have like no ephemeral account, non non-local account, CIC pipeline integration, these are all, every vendor in the space is looking into these, and there are emerging solutions. I believe that there are solutions that are very reliable today, and if not, there are a lot of hooks that are provided by many of these products that we've been able to, for example, use an application kind of integration, kind of concepts, to build those out where there are no gaps. The point is, the good point about it is that there are good management solutions. You know, that we use today are not closed systems. They are germane to expansion and plus the vendors are keeping up and I see that coming up quite a lot. And this is a use case. The cloud use case I think is paramount in all the vendors' minds that they have now working towards it. I'll let Joe, being a product manager, has definitely better insights into that than I do.


Yeah. Architect, not product manager. Just wanna be clear on that. The interim steps that folks could take would be to, you know, obviously have a strong review process. Don't do things like put credentials in source code troll and put it out on GitHub, right? That would be a really bad idea. Make sure you're reviewing the data that goes out to S3 buckets, right? That would be insurance steps, that's manual. But as PAM continues to mature and we get different flavors of, of different types of tokens, authorizations, and policies and whatnot, really gaining that programmatic access to be able to grab those things when necessary, not tie them down to a point in time or point in time value and being able to leverage them through the tools that is, that is building out. I mean, even like, even if you take a look at like the CSI and Kubernetes, right? That's now an interface to be able to plug secrets in from third party vendors, right? So it's maturing in the space, but the space itself, as well as the tool sets the DevOps tools, as well as the PAM tools.


So my opinion on this one is I think, as you said, the governance plane and the control plane. Often we'll look at the control plane to build governance policies in which is an upside down way of looking at things. I don't think that governance model are mature enough to say, you know, this is how, this is how we should govern our cloud things, and once you have the governance implementation it’s simple, but looking at a PAM solution to, or any solution, any technology to solve your governance issues is a big problem, and that that's where the failures happen.


Yeah. So I agree that it's an upside down model, but if you look at it, right, you have a risk that you're trying to mitigate, which leads to a governance, which leads to a control. Right? And if you look at it from that standpoint and start to ask yourself in my DevOps pipeline, in my cloud environments, where are my risks? And with them, you can then say, okay, I got to cover this risk, that’s your governance, here's how I think I want to cover it. I want to have a manager approval, I only want to be able to access from our internal domain, right, or our internal network, what have you. And then that leads into how you. So it certainly a risk, I would say it goes even before governance.


Sometimes when I see these questions, I see like, okay, tell me how PAM would help me to reduce risk and not like here's my risk, and here's my governance, and here's my control. Like, show me what controls PAM has, and we'll put our risk policies accordingly. And that's what I was talking about is like upside down model,


Start with the risks because PAM can do, mature PAM solutions can, that are truly multifunctional, while it may go from risk to control, which is perfectly fine, governance can be sussed out of that along the way. Right? So as long as it starts with risk or governance, I think you're in good shape.


Yeah. That's a very good point. I agree with you Joe.


Yeah. Sorry for occupying the answer.


Privileged access management seems to be a single point of failure. If it is down, all needed privileged access is locked down. What are some strategies to mitigate this?, we talked about this, about maintaining high availability?


Insights can be disconnected, but yet still provide access and recording and all that other, all the other functions that it needs.


And on top of that, adding governance policies with break glass and all


Right. Yeah. The break glass scenario is, you know, in my mind, sixth, seventh in, you know, in the line of defenses.


Right. Nonetheless needed. But you know, many organizations fail and fail to do that. And then that's just, may not be a good idea.


Yeah, we just had one customer that has seven sites of our solution put in there. And you know, the question came up, well, what if at all seven sites are down? And the answer from their executive was “We don't have a business if all seven sites go down. We have other problems to worry about”. So that was a good answer. It was funny.


We are overtime. So just one minute to each of us, if you could just put out a closing remark and what you want the audience to take away, I hear an echo. So yeah. So if you could just give us a one minute a quick, what, what would you want to take away from patents that are trust from on this conversation?


I can start, I can certainly start with, you know, when it comes to Zero Trust, it's a journey. It's something that you have to plan for. You. It's like an elephant and you know, how do you eat an elephant one bite at a time, then you have to work your way through it. But at the same time too, you know, PAM products and PAM vendors are, are, are really also consultant arms at the end of the day, right? HCL is certainly definitely a part of that. And you know, when you have new use cases or new concepts that come up, you reach out to reach out to the folks that are the experts in, and maybe there's a piece of it that can, can allow for you to, you know, that the PAM can solve for or what you're trying to achieve.


Yeah. I mean, for me Joe, same thing, PAM is a journey. Zero trust is a journey. You start where you are, you do a baseline, you find out, you know, what are my highest priority assets that I want to, or highest value assets that I want to protect. And that's where you start it for organizations. It can take two years. I've heard rumors, there's been one organization that's been at it for the past seven. I don't think that's quite where you want to be, but you know, don't plan to do it in a week that that's not going to use then setting yourself an impossible target.


Yeah. I would say that privileged access management is a critical step because privileged access is going after some really high risk, exposure scenarios, right? When you lock those high value accesses down, it's going to be a closer step towards Zero Trust. And so I believe PAM is a very important step towards the Zero Trust. As a vision, as an organization, I'm going to leave it at that. Thanks.


Well, our time is up. I would, I could obviously go for another couple of hours with this. This is an interesting topic. So I'm kind of saddened to have this conversation end, but thank you everyone for joining. Thank you for having me as a moderator and Lisa, you can take from here.