CLOUD PRIVILEGED ACCESS MANAGEMENT

Powered by intelligent identity

INTRODUCING SAVIYNT’S CLOUD PAM

Built in the Cloud for Cloud Workloads and Hybrid Critical Applications

Saviynt’s Cloud PAM is industry’s first PAM-aaS, delivered on commercial and FedRAMP ATO GovCloud, to harness the power of preventive risk and identity analytics with integrated governance.

CLOUD PAM FOR CLOUD WORKLOADS AND HYBRID APPLICATIONS

 

FRICTIONLESS

ACCESS

  • Real-time workload discovery and auto-registration. Bootstrap SSH keys and credentials, register / deregister workloads automatically for ready access, essential in an ephemeral environment
  • No jumpbox / bastion host required. Accelerate access to critical assets and lower operational hardware costs by leveraging auto-scaling containerized SSH and RDP
  • Temporal and granular priviledged access with seamless sign-on experience. Supports in-session role / access elevation and privileged ID-based assignment models.
  • Keyless and passwordless support. Seamless access to workloads without the complexity of SSH keys management and credentials.

BUILT IN RISK AWARENESS,

COMPLIANCE AND GOVERNANCE

  • Eliminate non-persistent local OS accounts and effectively reduce the attack surface
  • Integrated credential lifecycle management and vaulting
  • Granular audit logs for effective monitoring and better detection
  • Prevent misuse & fraud with preventative segregation of duties policies
  • Continuous controls monitoring
  • Integrated ID-based lifecycle management

BUILT FOR ELASTICITY AND

RESILIENCY

  • Utilizes native cloud technologies to provide a robust and scalable platform
  • Available as a Service on Saviynt’s global and resilient cloud platform
  • Rapid deployments and upgrades enabling faster rollouts and keeping up with the speed of business
  • Significant cost savings on infrastructure and operational costs
Saviynt Cloud PAM - Apps - Infra - Infographic

Saviynt’s integration with Hashicorp enables keys-as-a-service to deliver keyless browser-based terminal services to access *NIX workloads

Saviynt + Hashicorp

AWS re:Inforce 2019: Monitoring and Administrating Privileged Access in the Cloud

Featuring Vibhuti Sinha
Chief Cloud Officer

Transcript

AWS re:Inforce 2019: Monitoring and Administrating Privileged Access in the Cloud

Featuring Vibhuti Sinha, Chief Cloud Officer, Saviynt

 

Thank you, all. Good afternoon, everyone. My name is Vibhuti Sinha, Saviynt Chief Cloud Officer. I run Saviynt’s cloud platform, as well as all its cloud security products. Thank you once again for joining me in today’s session about monitoring and administrating privileged access in the cloud.

So, as part of today’s session, I’ll be talking briefly about what are the pros and cons in managing privileged access in the cloud, as well as share some of our best practices, learnings, as well as what we have garnered from our field implementations around what are the challenges you are going to face when it comes to managing and securing privileged access, especially in a cloud scale. Lastly, I’ll also be doing a deep dive into some of the different conduits and interfaces through which you gain privilege access onto your cloud ecosystem.

As per the Verizon 2019 data breach study, one thing which clearly came out was that the number one cause of incidents was privilege misuse. Now, what that constantly reminds us is that these are the users who actually had more access onto their systems. They did not have to hack into the systems. They had more than what they really needed, which caused the real problem of having all these data breaches you keep on hearing about.

It also serves as a constant reminder for us with the concept of applying least-privileged access on your workloads, whether it is cloud or your traditional Enterprise data systems.

So, let’s take a look at what organizations are trying to do when they’re trying to adopt traditional or legacy privileged access management products, and trying to solve the cloud problems in it.

So, a couple of gaps. What we saw is, number one, they’re trying to do a lot of lifting and shifting of traditional privileged access management (PAM) products onto the cloud, and it’s sad to see that those implementations are failing. They are not meeting the needs of what the cloud ecosystem demands from a privileged access management perspective because if you think about it, cloud is very ephemeral in nature. It’s very transient, it’s very dynamic, and the way a cloud privileged access management (cloud PAM) solution should be architected, it’s not the way these traditional legacy privileged access management solutions have been designed. So, that’s one of the fundamental reasons why these lifting-shifting methodologies are not working very well in a cloud ecosystem.

Second and very big important aspect is not identifying the different types of privileged identities on the cloud. If you take the example of any organization, the different conduits, the different interfaces through which you can gain privileged access on a cloud ecosystem is multiple. Very seldom you will see an organization just using AWS to consume or implement its services. You will be using devops tools, you’ll be using CI/CD processes, you will be using serverless functions, APIs. So, all in all, understanding what your privileged identities and interfaces are becomes a core component of strategizing your cloud PAM solution.

Third one, which we also observed, is that SaaS applications are being again solved in a very traditional manner. A very common example is that if someone needs privileged access onto your Salesforce workloads, or Office 365 workloads, a very simple and rudimentary way is that you will have to have a separate ID for a privileged user versus a regular ID. What it does in SaaS applications is it increases your licensing cost because you have to maintain multiple more IDs, and secondly, it increases the complexity of your overall identity life cycle management of those extra IDs. So, when you think about solving privileged access management for your SaaS applications, again, that strategy has to change. You’ll not have to solve in a traditional way with which your traditional applications privileged access management needs were being solved because SaaS application’s security model is extremely different as compared to any traditional application.

Another important aspect, which we observed, is that not reducing the attack surface. This is, again, predominant because a lot of your workloads, what they have is a proliferation of local OS accounts, local user accounts. It just exists on those workloads. Oftentimes, these accounts are not even being used, so the problem statement, which comes as part of your audit issues, is why do these accounts even exist? Because these accounts, if they exist, they are there for someone to hack into, someone to breach into, and later data breaches into your data centers.

The fundamental, most important part is that risk awareness and the concept of governance has become an afterthought. Organizations are trying to push the risk and governance as an afterthought. They are procrastinating it, they are delaying that. That is why your privileged access management processes are not at all risk-aware, and governance has just become an afterthought.

So, all in all, if you look at all these gaps, let’s try to understand what are the design principles with which you should be thinking about strategizing your privileged access management solutions or privileged access management architecture on cloud ecosystem.

Number one, when you think about cloud ecosystem, as I explained, the sheer volume and velocity with which drift happens in cloud is just staggering. If you or your solution has not been architected for cloud, if your solution or strategy is not meant to solve the needs of cloud, it is not going to be an effective and optimized privileged access management solution. So, the fundamental driver for you should be that your solution should be as close as possible, utilizing cloud-native technologies in your cloud PAM strategy as a privileged access management solution. Because that will help you to create a product or a platform, which is very resilient and which can scale through the demand and needs, which a cloud ecosystem requires.

The second, which we keep on repeating, is the convergence of Identity Governance and Administration (IGA) and Privileged Access Management (PAM) under one platform. As I was explaining earlier, risk and governance has become an afterthought for your organizations. Identity governance and administration brings that discipline, brings that governance into the fold. Often, what you would see is that when you start implementing privileged access management solutions, you would have an over-reliance on an identity and access management platform or an identity and access management product to solve your provisioning needs, your life cycle management of service accounts, your life cycle management of your local OS accounts. So, all in all, it increases the roll-out time for your cloud PAM implementation because you have to start thinking about that integration. You have to start thinking about how you can implement or integrate your existing identity and access management platform with your privileged access management platform.

The need of the hour is that it’s now the right time to think about converging identity and access management and privileged access management under one single unified platform, so that your privileged access management processes become risk-aware, they are governed from the get-go and you do not have an over-reliance between these two technologies, so that it reduces your overall time-to-market, as well as brings down your overall total cost of operation.

So, as I keep on explaining that the fundamental driver as part of converging these two technologies is that your overall privileged access management processes they become risk-aware and your governance happens from the very get-go when you start implementing it.

So, after the design principles, what exactly are the pillars in which Saviynt is headed towards? A couple of important aspects of our overall solution or architecture is there’s a big push happening across the industry about having everything password-less. It’s a push happening by all the industry leaders, AWS again leading the charge on it, by saying that you should be moving away from passwords as much as possible.

The same thing even falls through for your privileged access management implementations or PAM solutions. Why do you even need your credentials to be vaulted? Why do you even need your longterm keys or longterm credentials to be stored in vault? How can you effectively design or strategize your privileged access management solution, which becomes extremely seamless and completely password-less or credential-less for your end-users?

The second aspect is traditional privileged access management products, they scan your environments over the weekends to figure out how many new workloads have been added, how many new servers or how many new accounts have been created. It doesn’t work that way on cloud because due to your auto-scaling policies, your workloads would be spinning up and down in a very rapid fashion. So, obviously, you have to have a concept of having automated workload discovery, as well as continuous local accounts discovery happening in your entire ecosystem, which comes under the privileged access management portfolio in a regular and consistent manner.

Obviously, the audit ability and centralization of this entire interface becomes important. So, the way, what we have done is we are primarily integrated with HashiCorp Vault. HashiCorp Vault is the undisputed leader when it comes to vaulting technologies, and Saviynt has used HashiCorp’s stack to become its vaulting stack in its overall privileged access management offerings.

The second one is we primarily rely on Amazon’s ECS layer to provide a complete containerized SSH experience. Now, one of the other fundamental things, which you all would observe is, traditional privileged access management products rely on a proxy or a jumpbox-based model. The problem with that architecture is it often becomes a choking point in your overall architecture. Secondly, you have to predefine what your jumpbox specifications or size or capacity would be.

Now, it leads to two issues. Number one, it wastes your compute capacity if your traffic is not enough, or if there’s a surge, a sudden surge in your traffic, it just crashes. So, why not have something, which is not proxy-based, which is more cloud-native, and which is fast, agile and scale up and down, depending on what your volume and traffic looks like? That’s where containers fit in in the right manner. So, we use Amazon’s ECS service to do containerized SSH and RDP sessions.

Lastly, when it comes to auditing and vaulting, as I explained earlier, that the sheer volume and velocity with which audit logs will get generated in our AWS footprints, you can easily generate terabytes and petabytes of logs with the small footprint. So, how do you crunch, how do you sift, how do you mine all that data to figure out what your privileged users have been really doing in your ecosystem? That’s where again Elastic plays a very important role. They’re being an undisputed leader when it comes to handling large sets of data or large volume of data. So, that’s the third cornerstone in our overall architecture.

So, with these three cornerstones, let’s see what other issues or concerns you have to think about when you start delving deep into doing privileged access management for infrastructure and software-as-a-service.

Number one, when you start getting into audits for your infrastructure-as-a-service, one of the key things which you would see is if you are federating your identities, or if you have local IAM users in your AWS environment, your auditors are going to ask that if your users are a part of an active directory group, what access do they have on your cloud assets? Now, typically what happens is the visibility which an organization will have is all the way from IdP to the federated role in AWS to which they are tied to. But the visibility after that is often missing, and that’s what the auditors are going to look for.

So, again, getting this visibility becomes extremely important when you start strategizing for your privileged access management solution. The only way to do that is having a fine-grain integration with the native cloud provider’s IAM framework, in which case, it would be AWS identity and access management framework, which will allow you to go and scan all the identity and access management policies, the large adjacent objects, which really comprise of all the permissions, which essentially ties down to a policy and which ties down to the federated role. So, all in all, having this whole visibility from all the way to IdP to all the way up to cloud assets becomes a very important aspect, especially from an audit standpoint, and understanding the overall risk exposure you’re carrying in your ecosystem.

The second one is more around compliance. We keep on hearing about the importance of compliance. Compliance is the new imperative. There’s one tricky thing about compliance. Achieving compliance in a cloud environment is, I would say, relatively easy, but staying compliant is extremely, extremely difficult. The reason is, again, cloud being really dynamic, cloud being transient, how do you ensure that your baseline security policies constantly keep on getting applied in a cloud ecosystem?

So, again, the whole idea here is that having the identity view of who is having access to what, and mapping them to your industry standard frameworks, like CIS, ITAR, NERC/CIP is just one part of the equation. But extending that framework to ensure that your violations constantly remediate, constantly mitigate those issues, as well as help you to stay compliant, will make you a successful organization. Because not only you are achieving compliance, but you are staying compliant in an ever-changing environment.

The third one is, again, extremely, extremely important. What you would have seen is that there are cases where organizations or employees, they get fired or terminated in their HR system, but they still have access in the cloud ecosystem. The reason being is often the life cycle management of these identities are not tied to the joiner-mover-leaver events happening in your HR system. So, when you are effectively designing your HR systems, when you’re effectively designing the processes between your joiner-mover-leaver scenarios and to your cloud ecosystem and the life cycle management around it, integrating that with your HR systems becomes extremely important.

One of the key things which we also observed is that 63% of the organizations were not revoking their terminated employee’s access on cloud ecosystem. Now, you can imagine the catastrophic results which it can create in your data centers. So, the long story short, the idea here is that when you are effectively designing your life cycle management for your identities on a cloud ecosystem, integration or integrating that with an HR system has to happen without any reasons or without any questions about it.

So, if I sum it up, the whole idea which with we started was that you have to apply the concept of least-privileged access continuously at any given point of time. The way to do that is you look at your HR systems, you look at all your joiner-mover-leaver systems and you start applying risk on top of it.

Now, how do you apply risk is you can use an identity governance and administration platform, which can help you in doing outlier analysis. It can help you in doing separation of duties. Or, it can even evaluate your business policies if they are being enforced properly or not. That risk evaluation further it gets tied to your concept of joiner-mover-leaver events so that you can enforce the idea of having least-privileged access on your cloud asset by your identities in a continuous manner.

There are several things which you can do from an identity governance and administration and privileged access management conversion standpoint, as in, how do you make this entire request access done in an intelligent manner? How do you bring separation of duties in the fold here? So, for example, if your devops engineers are having access to your dev workloads, should they be getting access to production workloads? If not, what is the governance? What is the policy you have in place which creates those kinds of segregation of duties violations, as well as which creates those preventive segregation of duties violations? So, for example, making the system more intelligent in a way, saying that if someone is requesting access, I should be blocking their access on a production workload.

Another one is how often are you certifying or reviewing their access on a periodic manner? Are you reviewing what access do they have on your AWS assets continuously? Or, let’s say a data breach happens, or a person changes their job description, or a business reorg happens. How are you reviewing that the access, what they have on your cloud assets, is being refined, optimized and looked into in a continuous manner?

So, with that being said, let’s take a look at the fifth one, which is, identifying all the cloud conduits or interfaces through which you can gain privileged access.

Couple of important points here to consider is that these are the seven different interfaces, through which you can gain privileged access. Another most important part is unless you have identified all these interfaces, it becomes really difficult for you to have a rock-solid plan to have an effective privileged access management solution in place.

So, let’s take a look at, one by one, each of these. Management consoles. As I explained earlier, it’s very difficult to understand who has got access onto AWS management console until and unless you have not defined or scanned for those IAM policies or IAM permissions. Having that in place, as well as having the flexibility to either use separate IDs or to use the same enrolled session elevation for that user to have privileged access becomes important.

Instances and workloads. Now, the key things which happens is the proliferation of accounts, which often leads to a large attack surface. So, try to reduce the number of persistent accounts by the concept of having non-persistent accounts on your workloads, which I’ll talk about it in a minute.

Two other interfaces. Serverless. The advent of serverless has become enormously successful in the market. Everyone is using these. But a lot of these serverless functions execute in the context of privileged roles, which are static in nature. So, do these serverless functions need that privileged role all the time, or should they be getting access to only what they are really required for? Secondly, the threat vectors in this case are not only just your code, but also humans who can change those serverless functions to do things which they’re designed for.

APIs. You keep on hearing about a developer forgets to remove the keys from the code, it gets checked into GitHub and then automatically it becomes available to the entire world for them to make privileged calls to your cloud. So, how do you effectively design for that?

Cloud databases. They do not even provide you hooks on how do you manage the life cycle management of your identities on cloud databases. The default ones which comes with cloud is often having super-privileged access on your cloud databases.

One of the most important ones here is devops tools. Often, these devops tools get neglected, due to organizations that have not been bringing devops in the purview of privileged access management. This is a grave mistake which organizations do because very seldom it will happen that you will not be using devops tools to consume your infrastructure services. Chef, Puppet, Ansible, if you are using these tools, they have to come under the portfolio of privileged access management. Not only for visibility governance, but also on how you are managing, or rather effectively managing, the privileged access on these devops tools.

So, all in all, let’s take a look at some of the design patterns. Number one, which I mentioned, is look for doing temporal access elevation. So, rather than having separate privileged IDs onto your system, it becomes important that you start ensuring that the same ID you get, gets privileged access by switching roles. So, the concept here is that try to switch from an ID-based privileged access management to a role-based privileged access management, which will allow you to do this temporal access elevation.

Secondly, having the automated workload discovery and doing registration in real-time is absolutely important for cloud because your workloads are going to spin up and down in real time, and you cannot afford to have a scheduled scanning in your ecosystem. It will just… does not work that way.

Another important thing to understand here is that the key distribution aspect, whether it is SSH keys, whether it is password-less, it has to be completely seamless. Your users, if they are your privileged access management users, they should not even know that there is a password or there’s a key which is being used behind the scenes. It should be completely password-less. It should be completely key-less.

So, the idea, what we say here is, and sorry about the formatting issues here, the idea here is that try to… the model which we are going ahead with is no jumpboxes. It’s completely containerized, which is cloud-native, of course.

Second one is there is no use of having a thick SSH or RDP client. The reason being is the moment you look into thick clients, operationalizing the thick client becomes a huge issue because how do you roll out those thick clients onto your jumpboxes? Are you sure that the thick clients are on the right version? Have they been patched properly?

The industry is headed towards a browser-based mechanism. AWS, again, launched their AWS Session Manager last year. A lot of industries’ leaders are pushing towards a browser-based access management. That’s what we are also headed towards, wherein all your privileged access management access, what you need is a laptop or a desktop with internet connectivity. No jumpboxes needed, no thick client needed.

Third, you’ll not need to have a separate investment into an IGA product because it has to be one platform, which can help you to make your entire privileged access management processes risk-aware, governance-aware, so no separate over-reliance on an IGA product.

Of course, there doesn’t have to be the concept of persistent accounts. When you need access to any workload, your account will be created just in time, and when it is no longer needed, you do not have to keep that account persisting. That account can be purged, thereby, reducing your overall risk surface.

So, what are the different benefits of a converged platform? So, I’ll wrap it up with this slide, is when you think about doing cloud security, converging identity governance and administration, converging privileged access management and thinking about an effective DevSecOps, what you really need to think about the solution drivers is, it has to be a single platform because that will reduce your overall integration complexities, that will reduce your overall time-to-market and how effectively and quickly you can roll it out.

Obviously, it has to be modular, so if you just want to plug-and-play with privileged access management and not the identity governance and administration portion, that should effectively be working with you. As well as, it should be completely risk-driven. The beauty of converging identity governance and administration and privileged access management is that your privileged access management processes automatically becomes risk-driven if IGA is pre-baked, if IGA is embedded in the platform.

Easy to integrate, of course. Privileged Access Management solutions have been notorious enough, which have become difficult for organizations to roll it out. It becomes difficult for developers to customize. So, obviously, it has to be easy to integrate and business-friendly.

Lastly, this entire platform should be available as a service, which can happen only if we are utilizing or strategizing for a solution which utilizes native cloud technologies and it runs on cloud as a service for you.

So, with that, I’ll wrap it up. I hope you found this session useful. If you want to have any other conversations, I’ll be glad to answer them. We are located at Booth 807. Thank you once again for spending your time here and learning about AWS and Saviynt’s Cloud PAM solution. Thank you.

“Digital transformation and cloud first are the top initiatives in most enterprises today. With the proliferation of data and critical assets now residing outside the traditional perimeter, identity is now the new perimeter. In response to these market conditions, It is important for us to deliver a cloud-native PAM solution that not only is more effective than legacy PAM but can also be delivered faster to provide quicker business value.”

Amit Saha
CEO
Saviynt

“Working with Saviynt on this important next step in their technology maturity has been enlightening how we can extend the value of the Saviynt industry leading IGA platform to encompass a broader set of functionality that is essential to the protection, health, and growth of the enterprise.”

Dan Thormodsgaard
Co-founder & CTO
Fishtech

“As large enterprises look to both extend their digital reach and better orchestrate this expanding universe, we see an inevitable convergence of PAM and IGA. It is a matter of achieving stronger, more consistent governance while paying particular attention to those that can do the greatest damage to an enterprise; the privileged users. Saviynt’s approach of blending their cloud-native PAM solution with their existing IGA access governance addresses is a solid step in the right direction.”

Gary Rowe
CEO and Principal Consulting Analyst
TechVision Research

“The protection of critical applications such as ERP is not given the attention that it desperately needs; IDC finds that the cost of one hour of downtime often exceeds an organization’s total spend on ERP security.”

Jay Bretzmann
Program Director, Cybersecurity Products
IDC

Why Saviynt? Assured Compliance delivered with Cloud PAM

Intelligent Identity. Smarter Security.

Saviynt’s cloud-native PAM solution incorporates Identity Governance and Administration (IGA) capabilities for managing Privileged Access within your Cloud Infrastructure and Hybrid Applications, delivered in a single solution.

Saviynt’s Cloud PAM meets the velocity and elasticity of the cloud because it was built in the cloud, for the cloud.

Natively integrating with your hybrid business critical applications, the Saviynt platform enables organizations to incorporate a variety of hybrid applications and cloud infrastructures, creating a frictionless user experience and holistic approach to managing privileged access.

Saviynt’s Cloud PAM solution enables organizations to protect data while also providing the necessary documentation to prove compliance.

Assured Compliance delivered with Cloud PAM