Zero Trust Privilege redefines legacy Privileged Access Management (PAM) for the modern enterprise IT threatscape. Organizations must discard the old model of “trust but verify”, which relied on well-defined boundaries. Zero Trust mandates a “never trust, always verify, enforce least privilege” approach to privileged access, from inside or outside the network.
Zero Trust Privilege requires granting least privilege access based on verifying who is requesting access, the context of the request, and the risk of the access environment. By implementing least privilege access, organizations minimize the attack surface, improve audit and compliance visibility, and reduce risk, complexity and costs for the modern, hybrid enterprise.
Legacy PAM Is Not Enough for the Expanded Threatscape
Legacy PAM has been around for decades and was designed back in the day when ALL your privileged access was constrained to systems and resources INSIDE your network. The environment was systems admins with a shared “root” account that they would check out of a password vault, typically to access a server, a database or network device. Legacy PAM served its purpose.
However, today’s environment is different, privileged access not only covers infrastructure, databases and network devices, but is extended to cloud environments. It also includes big data projects, it must be automated for DevOps, and it now needs to cover hundreds of containers or microservices to represent what used to be a single server.
On top of this, we now all live in a world of Advanced Persistent Threats (APTs) that create a growing and changing risk to organizations’ financial assets, intellectual property and reputations. Expanding access and obtaining credentials is an essential part of most APTs, with privileged access being the crown jewels. Forrester (see Forrester Wave: Privileged Identity Management: Q3 2016) stated that “80% of security breaches involve privilege credentials.”
Cloud-ready Zero Trust Privilege is designed to handle requesters that are not only human but also machines, services and APIs. There will still be shared accounts, but for increased assurance, best practices now recommend individual identities, not shared accounts, where least privilege can be applied. All controls must be dynamic and risk-aware, which requires modern machine learning and user behavior analytics. Now PAM must integrate and interoperate with a much broader ecosystem including IaaS providers like AWS and Azure, with DevOps CI/CD Pipeline tools such as HashiCorp and Ansible, and with Container solutions such as Docker, Kubernetes and CoreOS.
The Six Tenets of Zero Trust Privilege
A Zero Trust Privilege approach helps enterprises grant least privilege access based on verifying who is requesting access, the context of the request and the risk of the access environment. By implementing least privilege access, Zero Trust Privilege minimizes the attack surface, improves audit and compliance visibility, and reduces risk, complexity and costs for the modern, hybrid enterprise. Zero Trust Privilege is built on six tenets, which are covered in detail below:
Verify Who
Today, identities include not just people but workloads, services and machines. Properly verifying WHO means leveraging enterprise directory identities, eliminating local accounts and decreasing the overall number of accounts and passwords, reducing the attack surface. Many large organizations have standardized on Microsoft’s Active Directory, but with Zero Trust Privilege you don’t have to standardize on any particular directory. In fact, you can keep different populations of identities in different directories. The important part is to establish identity for users via HR-vetted enterprise directory identities, meaning these identities are automatically disabled when the person’s employment is terminated. The last thing you want is a database administrator (DBA) to leave, but still, retain their privileged access rights.
A best practice for privileged access is to establish unique accounts for each administrator to use for admin purposes. Microsoft suggests that these be “Alternate Admin Accounts” (commonly referred to as “dash a” due to the typical “-A” appended to the user’s account) that are associated with the admin user but are separate from the admin’s end user identity, which is typically a publicly-known account with an email address. This way, if the public email account gets compromised, it does not expose their Alternate Admin Account.
To verify who, we must also apply Multi-Factor Authentication (MFA) everywhere. During login, upon password checkout, at privilege elevation — anytime there is a new request. With privileged access we must know with certainty who is on the other end before granting access. MFA is a must-have, passwords are not good enough. Let’s face it, 10% of you probably have the word “admin” as your password – that’s not going to cut it. The good news is MFA is way easier than before, when you used to have to wait for 120 seconds for a new 6-digit code to come up and type it in. Now users just get a push notification to their phone and/or just touch their FIDO key.
When implementing MFA, it is critical to enforce National Institute for Standards and Technology (NIST) Assurance Level-2 at a minimum for admin functions. This means a dual challenge: something you know, and something you have. A good example is a password combined with a push notification to your phone, or an OTP generated by your phone. For most critical assets it is recommended to increase even further to NIST Assurance Level-3, where possible. This includes two-factor authentication with a password in addition to a hardware-based cryptographic token, such as a smart card or FIDO key. Google claims they have not had a single successful phishing attack since they implemented FIDO keys for all users.
Contextualize Request
First, we need to start with why it is important to have a “request and approve” access process. It makes sense that a database administrator (DBA) should not have default rights to access all databases, only to the ones they need to work on that day. That way, if that DBA’s credentials are compromised, we have limited the attack surface. For each request, it is important to know WHY somebody, or something is performing privileged activity. To do this, we must understand the context behind the request for access, and review and approve the request based on the context provided.
The concept of least privilege is to only provide the needed level of privilege to perform a certain task and only for the amount of time necessary to perform that task. To execute least privilege, the granter of access must understand the context to be able to make the appropriate access decision.
Recording the request context typically includes associating the request with a certain trouble ticket and providing a reason, as well as what is being requested and for how long. Once the request is contextualized, then it must be routed for approval and this workflow can be as simple or complex as you would like to make it. For larger companies to best achieve this step, it’s likely going to involve the integration of a PAM solution with an enterprise grade ITSM (IT Service Management) solution like ServiceNow or IGA (Identity Governance Administration) platform like SailPoint Technologies.
Secure Admin Environment
When accessing privileged resources, it is critical that we do not either enable malware access to servers or introduce infections during our connection to servers. To achieve this, we need to make sure access is only achieved through a clean source. Zero Trust Privilege means preventing direct access from user workstations that also have access to the Internet and email, which are too easily infected with malware. Access should only be granted through approved Privileged Admin Consoles, which can be achieved in many ways, including web-based access to sensitive systems via an administrative jump box, such as the Centrify Zero Trust Privilege Services with its Connectors.
Modern cloud jump boxes with distributed connectors are a great way to achieve a secure admin environment for distributed organizations. In the past you only had to secure access from inside your network. But the beauty of a properly designed Zero Trust Privilege Admin Environment is it not only allows remote staff to access resources 24x7, but it is well-suited for outsourced IT or outsourced development users because it alleviates the need for a Virtual Private Network (VPN) and handles all the transport security between the secure client and distributed connectors.
Distributed jump hosts or “connectors” serve the dual purpose for load balancing in the same network and for supporting multiple, different private networks. These connectors go where the resources are located, such as DMZ, IaaS, or Virtual Private Network with private, mutually authenticated connections. These secure connections allow Web-based SSH or RDP that works from any location. For outsourced, third-party users it includes federated in-bound authentication, meaning authentication can depend on a partner’s directory of authorized employees, providing much higher identity assurance.
Grant Least Privilege
Least privilege as a concept is more common than you realize. Think of physical access control at your office: different levels of users have different access rights, and to get access to certain areas you must request and be approved. This is all very well recognized in the physical security space, and the same logic applies for logical security. It applies when granting granular role-based access to privileged resources.
Another objective to granting least privilege is to limit lateral movement across the network. This is the primary way attackers get access to sensitive data: they start in one location and move laterally until they find what they are looking for. If we zone off what they have access to then we can stop lateral movement. Just like nobody should have a single key/badge that accesses everything, you really don’t want to use the root account on a server, as it gives too much access and has no attribution to the actual user, who we’ll call “Bob.” Instead Bob should login directly to the target system with his alternate admin entitlements that give him access to restart only a particular set of servers. If he needs to change the configuration or access a different target system, then he must request access for a specified period of time through something like ServiceNow and may be asked for Multi-Factor Authentication (MFA). Once complete, Bob’s entitlements will reduce back to just what is needed.
Audit Everything
For privileged sessions, it is of course best practice to audit everything. With a documented record of all actions performed, audit logs not only can be used in forensic analysis to find exactly the issue, but also to attribute actions taken to a specific user. Because these sessions are so critical it is also best practice to keep a video recording of the session that can be reviewed or used as evidence for your most critical assets or in highly regulated industries. There are multiple regulations including PCI-DSS for payment card data that specifically requires this level of auditing.
Monitoring and session recording can be achieved through either a gateway- and/or host-based technique. Host-based ensures that sessions cannot be bypassed, as well as to also provide process launch and file system change auditing, which is a highly desired technique for your most critical resources.
If you have a security department, a good practice is to integrate this audit data with your existing Security Information and Event Management (SIEM) system or Cloud Access Security Broker (CASB) service for automated mining where risky activities can be identified and alerts raised.
Adaptive Control
Zero Trust Privilege controls need to be adaptive to the risk-context. Gartner promotes CARTA – Continuous, Adaptive, Risk and Trust Assessment – and it’s absolutely required for Privileged Access too. Zero Trust Privilege means knowing that even if the right credentials have been entered by a user, but the request comes in from a potentially risky location, then a stronger verification is needed to permit access. Modern machine learning algorithms are now used to carefully analyze a privileged user’s behavior and identify “anomalous” or “non-normal” (and therefore risky) activities and alert or notify security.
Adaptive control means not only notifying of risky activity in real time, but also being able to actively respond to incidents by cutting off sessions, adding additional monitoring or flagging for forensic follow up.
Machine learning allows companies to pore through millions of events and scan for that needle in the haystack on an ongoing and continuous basis, which would never be achievable by manual forensics. Even more valuable is performing machine learning-based analytics inline and in real time and thus being able to enforce truly adaptive preventive controls and not just after-the-fact detective controls.
Conclusion
To deliver Zero Trust, today’s Privileged Access Management (PAM) solutions cannot rely on simply vaulting away shared accounts. They must cover, in detail, both Privileged Account and Session Management as well as Privilege Elevation and Delegation Management. But clearly that is not enough. To sufficiently verify who (or what) a requester is, today’s cloud-ready Privileged Access Management (PAM) must include Privileged Identity and Access Management, Multi-Factor Authentication as well as Privilege Threat Analytics.
Legacy Privileged Access Management (PAM) did a great job of serving yesterday’s threatscape, but in a modern enterprise IT world, to protect yourself, your company, your customers, and your investors, a Zero Trust Privilege approach should be applied.
Debunked: 5 Myths About Zero Trust Security
Debunked: 5 Myths About Zero Trust Privilege
In 2018, Zero Trust Security gained popularity due to its simplicity and effectiveness. Yet despite a rise in awareness, many organizations still don’t know where to start or are slow to adopt a Zero Trust approach.
-
Natasha: Hello everybody. On behalf of Centrify, I'd like to welcome you to today's webinar titled Debunked: 5 Myths About Zero Trust Security. Before we go into our session, I wanted to go over a few housekeeping items. Today's webinar is an interactive session. We've put together a few poll questions to get your input, and we'll share those as we go through the hour. Please submit your questions, if you have any, via the chat box throughout the webinar. We'll try to answer questions as they come. Then we'll also save some time at the end of the webinar.
Natasha: Also, as some of you know, the first 20 registrants who are in attendance today will receive a free Echo Dot. Congratulations. I will be reaching out to each one of you to get your shipping address throughout the webinar. Now let's get started.
Natasha: In 2018, zero trust security gained a lot of popularity as more organizations recognize that zero trust is the only approach to security networks. That's the good news. The bad news is that when it comes to implementing a zero trust security model in their own organizations, many still don't know where to start. There are several misconceptions surrounding zero trust that further impede adoption.
Natasha: This might explain, while despite the rising awareness about zero trust security, an incredible 66% of companies were still breached last year, with some averaging five or more separate breaches in just 12 months. Given the reality of today's dynamic threat landscape, zero trust security is the antidote to becoming statistics. As we kick off 2019, there's never been a better time to rethink the outdated enterprise security strategies and move towards zero trust security.
Natasha: My colleagues Tony Goulding and Torsten George will review with you the five myths about zero trust security and illustrate best practices on how to execute the security in organizations independent of size and industry. Welcome to both of you. Torsten, why don't you give us a quick rundown of zero trust security and create the foundation for today's discussion.
Torsten George: Sure. Thanks, Natasha. According to Gartner, organizations have stepped up their efforts to prevent cyber attacks, investing an estimated $114 billion in IT security this past year. This is up $10 billion compared to 2017. That's a huge investment. However, every morning I'm getting up at 4:30 to check on the news and every morning I read about the next data breach. As a matter of fact, there's about, as Natasha mentioned, two-thirds of companies that are still getting breached. Worse, of those that are getting breached, they're getting breached not once but an average of five or more times in 12 months' period.
Torsten George: That makes me really start scratching my head. We're spending $114 billion in security, but that doesn't seem to deter the hackers at all. Something is wrong with this picture here. Before we move on to the next slide, we wanted to really get your views on this with our first poll question. Please take a few seconds to tell us what you think the leading cause of data breaches today is. Okay, let's take a look. Privilege abuse and bad actors inside a company are tied for the number one spot. Congratulations. That's a great result.
Torsten George: We conducted studies, and there are a lot of other studies out there just last year, and that showed a completely different picture. At that point in time, a lot of people still believed it's malware, it's anything else than really the human. But, fortunately, things have changed. Thanks for submitting your opinion. Let's move on.
Torsten George: You would hope that with $114 billion in your pocket that our industry's catching up with the cyber adversaries. Unfortunately, though, things are not getting easier for security practitioners like you. In fact, the enterprise landscape have gotten much more complicated in the last decade. Systems and data were inside the network perimeter. Now 90% of organizations are moving workflows through the cloud. They're automating processes with that, storing data in huge data stores, terabytes of them, and what used to be a seamless server is now spread across hundreds of containers or microservices.
Torsten George: With this extended to attack surface, we all know that the risk or breaches have increased. You can read about it every day. What can be done? What do all of these breaches have in common that could assist us in defining a more effective defense strategy?
Torsten George: When you do a fact check and look at postmortem analysis of data breaches, you will find out that 80% of today's hacking-related data breaches involve compromised privileged credentials. 80%. That's an absolute stunning number.
Torsten George: If we apply these facts, one thing really becomes obvious. Organizations need to recognize that permit of their security, which focuses on securing endpoints, firewall, to networks provides no protection against identity and credential-based threats. Until we start implementing an identity-centric security measure, it can compromise and techs will continue to provide a perfect camouflage for data breaches. That's why it's important to rethink your enterprise security strategy and move towards zero trust security.
Torsten George: Based on the realities of today's dynamic threat landscape, we have nowadays to assume that untrusted actors already exist both inside and outside the network. If we can't necessarily trust any longer that the system administrator is really who he claims to be, we have to remove trust entirely from the equation.
Torsten George: In the old days, we're following the mantra "always trust and verify". However, today this is no longer sufficient. That brings us to zero trust. We have to apply this concept to any of our access decisions.
Torsten George: Now zero trust security is not something that Centrify came up with, or a security model that just recently emerged. But it was conceived by Forrester in collaboration with the US-based National Institute for Standards and Technologies in 2010. So quite a few years back. Meanwhile, companies like Google have adopted the security strategy as part of their security admission.
Torsten George: The zero trust core principles are very simple. First, you have to assure that all resources are accessed securely, regardless of their location. In other words, there's no longer a trusted zone. Secondly, you have to apply a least privilege approach and strictly enforce access control. Of course, in a zero trust world, all users are initially untrusted.
Torsten George: Then the third step is really inspecting and logging all traffic and access requests. Even if traffic originates in your LAN, you have to assume that you can't trust it. You have to analyze it. The implication of zero trust is never trust, always verify. It does not matter if you're in the networking or outside the network. All access, regardless of user type, be it a privileged user, be it your contractors, be it your outsourced IT, all of them, and regardless of the infrastructure that you access, must be verified as far as your trust.
Torsten George: Natasha mentioned at the beginning that we have seen quite a bit of momentum for zero trust. Since its detection, the early benefits have evolved dramatically. Nowadays, zero trust has become a mindset that drives businesses' strategic security initiatives to allow decision-makers and security leaders to move toward pragmatic implementations.
Torsten George: The entire security industry is talking about zero trust. Numerous thought leaders, Centrify is an example, Cisco, Symantec, Palo Alto, you name them, have embraced it and now use it to market and position their capabilities as well as guide their future outcomes. Even some recent M&A activities are tied back to the desire to incorporate zero trust capabilities into the acquirer's technology portfolio. Example is Cisco acquiring Duo Security or Okta acquiring ScaleFT.
Torsten George: While not all analysts agree on zero trust as a common nomenclature, analyst firms like Gartner, which uses the term CARTA, or 451 Research, and Cooper-General Corp embraced the zero trust model as a needed concept to tackle today's threatscape. When zero trust was initially introduced to market, it was just a concept. However, today it has grown into a security framework that is being used by a growing a number of businesses and government agencies.
Torsten George: What you see in this slide is really the result of an IDG 2018 security priorities survey, whereby 71% of security-focused IT decision-makers are aware of the zero trust model, with already 8% actively using this in their organization and 10% at least piloting it. Following in the footsteps or your peers will definitely yield tremendous benefits as zero trust security is proven to minimize the attack surface, improve audit and compliance visibility, introduce risk complexity and cost for the modern hybrid enterprise.
Torsten George: We talked about it, and we want to make this interactive. It's time for another quick poll. Where are you in implementing zero trust security in your organization? Oh, wow! All of you researching. That's why you're on this call. That's great. Tony, let's start really talking about the myths that often hold us back also.
Tony Goulding: All right. Let's do that. Thanks a lot, Torsten. Hi, folks. This is Tony. I'm going to talk about these five myths. It's the title of this webinar. Torsten gave you a pretty good introduction, actually a great introduction, to zero trust security and really why this model is shaking up to be the definitive approach to security, especially today in the digital age.
Tony Goulding: Now both Torsten and I, we do a lot of traveling. We're on the road a lot. We evangelize the concept of zero trust security wherever we go. We end up speaking with a lot of folks about this paradigm shift, and we're frequently getting their insight, which helps us shape our message even further.
Tony Goulding: But, unfortunately, there are a number of misconceptions surrounding the topic of zero trust security and zero trust privilege in particular. That tended to slow down at auction, questions about its total functionality, its applicability across different-sized organizations, and to what kind of steps or how you would go about implementing this, let's say a phase one through a phase three. For our audience's benefit, what we're going to do now is we're going to look at the top five myths and we're going to, hopefully, debunk them. Torsten?
Torsten George: Okay. Sure. Let's talk about myth number one, which deals with the fact that many believe that really zero trust security is really something that should start with data integrity. Of course, ultimately hackers are after data, correct? So is this really the case? Tony, why don't you address this myth a little bit in more detail?
Tony Goulding: All right. Thanks, Torsten. In the earlier slides that Torsten presented, he mentioned that 80% of today's breaches are caused by the abuse of privileged credentials. It only really takes one compromised privileged credential to impact potentially millions. Now millions can be in the form of users, it could be dollars, it can be lost opportunity due to intellectual property theft. But until organizations start implementing identity-centric security measures, account-compromised attacks will continue to provide a perfect camouflage for data breaches. The path to zero trust should always start with identity.
Tony Goulding: Now for its part, Gartner recommends putting privileged access management on top of an organization's list of security projects. That should come first and foremost. Let's stop here and let's take another poll. We'll see how many of you with privileged access management are only using a password vault. If you're only using a vault, click on the 'Yes' button. Otherwise, click on the 'No'. We'll just give it a few seconds to populate.
Tony Goulding: All right, let's see what we have. We have about 40% only using a password vault and the remaining 60% of the audience are using something in addition to that. Hopefully, especially for those that answered yes, as we continue down this path, you'll get a sense of why vaults alone is not enough and how zero trust securities or trust privilege can really help us better protect ourselves and mitigate the risks for just using a vault alone. All right. Let's move on then. Let's take a look at privileged access management and let's determine how it can contribute to achieving zero trust security.
Tony Goulding: Now this diagram basically starts with legacy PAM. Legacy PAM solutions have been around for decades. Legacy PAM was designed way back in the day when all of your assets, all of your privileged access was pretty much controllable. IT was in control and everything was within a fixed boundary.
Tony Goulding: This is not a new message. We're all familiar with the analogy of the fort and the moat surrounding the fort, but all of your systems and resources reside pretty much inside a network that you could control.
Tony Goulding: Now the environment was basically consisting of administrators, system admins accessing predominantly servers. They typically use the shared local account available on the systems that they manage, which would be a shared root account on LINUX and UNIX or a shared administrator account on Windows.
Tony Goulding: Typically, they would check out one of those privileged accounts so that they could use it on those systems, and they'd use a vault in order to do that. They would access servers, databases, network, devices, et cetera. For that purpose alone and in that type of dynamic, legacy PAM definitely served its purpose.
Tony Goulding: However, in today's environment, we see quite a different look. We see that privileged access not only is involved with helping us administer access to infrastructure, database, and network devices, but now we're extending to the cloud. Now we have to consider other environments as well, cloud environments. That might include big data, Hadoop type of projects where we need to protect access to the various clusters and the hundreds of thousands of nodes that those clusters consist of.
Tony Goulding: It's also got to consider automation. DevOps is not coming to play where we're doing lots of automation for scale and for speed and rapid development. Also, we've got a lot of our customers now who are taking their old monolithic applications and they're spreading them across containers. It could be hundreds of containers that now represent the application that used to be a single app on a single server, as well as microservices as well.
Tony Goulding: With this expanded threatscape, a legacy PAM solution simply won't suffice. We need a cloud-ready zero trust privilege solution, and that has to emerge has being our direction. Now that doesn't mean we no longer use the legacy tab as we see in this diagram. It's really a combination of both because the majority of organizations are hybrid in nature.
Tony Goulding: Cloud-ready zero trust privilege is designed to handle requesters that are not only human. We've also got a lot more machine-to-machine, application-to-application, service-to-service using APIs, et cetera. The requesters are very, very much different.
Tony Goulding: Now we still have shared accounts. We'll always strive to get rid of shared accounts, especially local accounts, but that's not always possible. But for increased assurance, our best practices recommend using individual identities where we can apply a least privilege model. An example of that would be logging in instead of as a fully loaded administrative account that's shared. We login as ourselves with minimum privilege. Then we can apply privilege elevation.
Tony Goulding: Now all controls that we have, they need to be dynamic and they need to be risk-aware, so we're not just basically saying yes or no based on a static rule. That requires more modern technologies, machine learning, behavioral analytics. PAM needs to integrate and interoperate with a much broader ecosystem, including infrastructure as a service providers, like AWS and Azure, and with DevOps tools like HashiCorp, Ansible, Jenkins, other tools like that in the CICD pipeline, as well as container-based solutions such as Docker and CoreOS. This modern threatscape, it can't be served with an appliance-based vault alone.
Tony Goulding: Moving on to this next slide, we'll take a look at our model here for zero trust and really our approach towards it. To achieve this zero trust, organizations, they need to discard the old model, as Torsten mentioned, a "trust and verify", and that relied on very, very well-defined boundaries.
Tony Goulding: Zero trust mandates a "never trust, always verify" and enforced least privilege approach to privileged access. It's from the inside or outside the network. Basically, our attackers are already inside the network. But without a well-defined boundary, then our network is just massive.
Tony Goulding: Now zero trust privilege requires granting least privilege access. We have to base that on verifying who is requesting that access. As we see on the slide here on the left, verify who. We need to know who that individual or who that application or service is.
Tony Goulding: The context of the request is also equally important. We need to make sure that we understand the context in which that request is being requested. Also, the risk of the access environment itself. If we implement least privilege access, then organizations or customers are able to minimize the attack surface. We can improve our auditing and compliance visibility. We can reduce risk, we can reduce complexity, and costs for the modern hybrid enterprise that has a mix of on-premises as well as cloud-based infrastructure.
Tony Goulding: Starting with verify who, it's really about today's identity as we saw in the previous slide, including not just people but also services and applications and workflows in the cloud. We really need to verify who by means of leveraging enterprise directories. A lot of our customers have multiple directories. We may have users in LDAP and AD, and cloud directories.
Tony Goulding: We want to eliminate local accounts. By doing so, we can decrease the overall number of accounts and passwords and reduce the attack surface. In terms of contextualizing the request, again, we want to include context within that decision-making process. That might be in the form of a valid trouble ticket that is causing an administrator to actually perform a privileged task.
Tony Goulding: We want to provide a reason as well as to what's being requested and for why, so when we make an access request that goes through an approver, they have all the context they need to say yes or no. Now once this request is contextualized, then it has to be routed for that kind of approval. Again, we can include other contextual factors such as IP address, location, date and time, et cetera.
Tony Goulding: Now securing the administrative environment. When we're accessing privileged resources, it's very critical that we don't enable or spread malware to the endpoint, to the service that we're trying to access. We don't want to introduce infections during our connections to servers. To achieve this, we need to make sure that access is only achievable through a clean source.
Tony Goulding: Now zero trust privilege means preventing direct access. If I'm on a user workstation, I need to have remote access to a server. I'm not going to be granted direct access to that server. If my access is approved, if I have the right roles in order to achieve that, then I will be going through some kind of intermediary that ensures any malware on my system does not spread to the target systems. That is securing the administrative environment.
Tony Goulding: Now granting this privilege, that's a big court of what we're talking about here, which is granting just enough privilege just in time both on that server as well as just for accessing resource and assets on that server, as well as preventing lateral movement. If I'm an attacker and I compromise an account, if that account has the least amounts of privilege, then I will be, hopefully, prevented from moving laterally to try and get access to a more privileged account or additional resources.
Tony Goulding: Now just-enough privilege is what we're talking about to get the job done. Just-in-time privilege is based on temporary access. We want a simple request process that we can use to request legitimate access, giving that approver the context they need to make an informed decision, and then basically I get back only the rights I need to do the task at hand. Once that task is completed, those rights are taken away.
Tony Goulding: If you look at a graph of a risk profile, instead of it being constantly high, as would be the case if I'm given a shared privilege account like root or administrator, it only gets high for those times when I need that elevation to do a legitimate task, no more.
Tony Goulding: Now auditing everything, obviously from a compliance perspective, we need to audit everything. We need a documented record of all privileged access that have been performed. Now audit logs that can not only be used in forensic analysis to find an issue and resolve an issue, but also to attribute those actions taken back to an individual user. With shared privilege accounts that are vaulted, root, administrator, article, SSA, these are all anonymous accounts. We need to be able to tie activities back to an individual.
Tony Goulding: Now because these sessions are so critical, it's also best practice to keep a video recording of the session that can be reviewed or used as evidence when things are compromised, especially in highly regulated industries. Now there's multiple regulations, including PCI DSS, the payment kind of data, that specifically requires this level of auditing.
Tony Goulding: Finally, we come to adoptive control. Adoptive control is leveraging modern technologies that, quite frankly, legacy PAM doesn't have. That is using things like machine learning and adopted MFA to add that additional security layer and to detect abuse, privileged access abuse, before it turns into a data breach. We're talking real time alerting at the point of access.
Tony Goulding: That doesn't just mean logging into a vault. There's multiple points of access that an administrator will touch. It could be vault logging, it could be password checkout, it could be requesting a remote session, or it could be on the server itself when you're requesting privilege elevation. All of those are access control decision points, and they require this rigor to be applied at those levels as well. After this discussion, I guess, let's see how the audience feels about whether vaulting alone is sufficient.
Torsten George: Before we go there, I wanted to inject the question that came in as it relates to secure admin environment. Wade was asking if the securing admin environment dependent on the request and therefore integrated into the controlled workflow.
Tony Goulding: Yes, it is. Securing the admin environment is really all about trusting the user as well as trusting the device that they're coming from. As we've mentioned, if you're remote, we can't always trust that device.
Tony Goulding: But the infrastructure, the design of our solution, has what we call a scalable connected model. Basically, what we want to do is ensure that these, especially remote users where we have no control over their device and we don't know whether they're infected or not, it's really that intermediary that is the trusted clean source. That is the lockdown source of establishing connections to the endpoint.
Tony Goulding: As an example, as a remote user, I may access, let's say, the Centrify vault through a browser-based session. That alone doesn't attach me to a target network if I'm coming in through a browser. I'm not coming in through a VPN, so kind of secure VPN-less remote access. But it's the actual connected layer that we introduce that has the SSH or the IDP session to the downstream server.
Tony Goulding: By doing that, we have total control over how the endpoint is accessed, and we isolate that user's desktop from the equation. If they do have malware, it's not going to spread to the target server.
Torsten George: Another question is in the context of contextualizing request. Scotty is asking, "How much support to help desk that zero trust have?"
Tony Goulding: How much support to help desk does zero trust give us? As far as a help desk user is concerned, I mean very often we find that in a help desk scenario, let's say I'm on a system and we want to actually implement or install additional software, then a help desk person may need to work on that server or on that desktop with elevated privileges in order to perform an administrative task. Often that involves having to logout the original user that's there and then login as an administrator in order to do that.
Tony Goulding: But with our host-based privileged access solution, we have the ability to run as another user. As a help desk individual, I could access the application, I could run as a privileged user. The credentials I'm using to login are not exposed to the original user, and so then I'm able to perform that administrative task and get the job done.
Tony Goulding: But very often help desk is more associated with end use, a desktop type of scenario. What we're really focusing more on here is administrative use of service and infrastructure, which doesn't usually involve a help desk type of scenario. Hopefully that answered the question.
Torsten George: Okay. Any other outstanding questions, we will address at the end. Let's move on then. As Tony mentioned, we were interested, after what he laid out here, if you have change of mind when it comes to if vaulting alone is sufficient or not. Click 'Yes' if you still believe so. If you get reservations, again, click on 'No'.
Tony Goulding: All right, we'll give that a few seconds to populate before we move on.
Torsten George: Oh, you did a great job, Tony.
Tony Goulding: Well, I can't say I'm surprised, but it's nice to have 100%. We do have a lot of people attending the webinar, so it's not like two people. That's pretty good. All right, let's move on to myth number two.
Tony Goulding: Torsten, you've mentioned earlier that Google was one of the first organizations that adopted the zero trust security model as part of their BeyondCorp initiative. Now obviously by using this tech giant as an example, many of our listeners, especially when we're out on the road, they fell for the same myth as many others and believed that zero trust security, zero trust privilege is only applicable to large organizations. What's the reality here, Torsten?
Torsten George: Okay. Quite frankly, the reality is that nobody is safe from falling victim to credential-based cyber attacks. I mean we all read or heard about major breaches at Equifax, Uber, Under Armour that really impact millions of consumers and has really large financial consequences. The latest research by Ponemon Institute estimate that the average cost of data breach nowadays is at $3.86 million. That's a huge number. Always there's focus on the media on these big consumer data breaches, but, in reality, government agencies are also under severe attacks. Senate phishing attacks and the OPM breach are just a couple of examples.
Torsten George: What many may not know is that it's not just large, well-known brands. It affects us all. 61% of small businesses were breached in 2017. SMBs don't have access to the same resources as their counterparts. It's unfortunate that 90% of small businesses go even out of business within six months of an attack. As a small business owner, you're funding situation is obviously not comparable with the likes of Google. However, driving towards zero trust security doesn't need to break the bank.
Torsten George: I had recently a get-together with some friends, and one of my friends runs a small business. He knows what I'm doing, and he was asking, "Hey, is there a beer budget that I can apply?" Yes, there are. We will talk about the steps that you can take. You don't have to implement everything at once. Nobody expects you to mimic what Google has done. But it really can be achieved, it's affordable. Thus, company size or budget should not be a deterrent to give up on pursuing the zero trust security strategies. Let's look at another myth that was born by looking at the BeyondCorp example.
Torsten George: When Google established their zero trust security architecture, they decided to rebuild their entire network from ground up. That's why many observers believe zero trust security always requires a rip and replace of the existing network. Let's find out if this is really true. Tony?
Tony Goulding: All right. Thanks, Torsten. Yes, Google, BeyondCorp, I guess, unfortunately, it is a bad example. It tends to represent more of the exception than the rule. The reality is that implementing a zero trust architecture is really an authentication of the current security controls that you have. It's not necessarily a rip and replace.
Tony Goulding: Now it does help if the vendor that you're choosing has control over all of those products and services and applications, and they're built organically so that they fully integrate. But you can describe this process as a journey towards zero trust security, which is reflected by the maturity model that you see or the journey that you see on the screen here, and it really can be step-by-step.
Tony Goulding: The idea here is that a lot of our customers find themselves in the danger zone that you see there. Too many passwords, too many accounts, and too much privilege. What we're trying to do is move away from that danger zone. Best practices recommend to start by establishing identity assurance.
Tony Goulding: Now this could be done, for example, by deploying MFA everywhere, which is a common first step. It gives you tremendous value. MFA is not as complex as it's been in the past. If it can be applied everywhere, I mentioned earlier about the multiple access control decision points. If you can apply MFA optionally at each one of those decision points for additional identity assurance, you can really pull down that attack surface dramatically.
Tony Goulding: Now in the next step, it's recommended to take action to limit lateral movement, and we mentioned that earlier. It's easier to limit lateral movement if an account that gets compromised, let's say, by an attacker has the least privilege. If that account that's being used consistently by IT for routine login and maintenance is a fully privileged account, if that get compromised, it can be easily used to move laterally.
Tony Goulding: We can do that also. I mentioned earlier about remote access, if we can use VPN-less remote access, where the remote user, let's say, an outsourced IT, a third party, or even internal IT that's working remotely, if they're not using a VPN to gain access to your internal resources, then we can protect them from network access in a broader sense and we can also surgically place them on that target server instead of perhaps giving them exposure to other service within the network.
Tony Goulding: Ideally, the next step on the journey then is to enforce that least privilege by, for example, enforcing just-in-time privilege. We mentioned access request and control. If I have a least amount of privilege as an administrator on a box, but I need to restart the web server or install some software, then having the ability to get those additional entitlement to achieve that particular task by requesting just in time but just enough privilege no more, then that helps controls that attack surface as well.
Tony Goulding: Now ultimately you want to be in a position of auditing everything, as we mentioned, but the reality is that every organization is different, not just related to the ecosystem but also from a risk appetite and a risk tolerance perspective. This maturity model can be adjusted to meet individual need, but it does represent, broadly speaking, all of the different touch points that should be a consideration for you in trying to increase your maturity and reduce your overall risk. Okay, next slide then.
Tony Goulding: When we look at the steps that are specific to zero trust privilege, it doesn't have to be complicated, but there are some proven best practices. The last diagram was like a maturity model of things you can do. This diagram is really a little bit more prescriptive in terms of a phase one, two, and three, what a lot of our customers have actually done in terms of adopting the best practices necessary to achieve zero trust privilege. You'll find that Gartner recommends a very similar three-step approach as well.
Tony Goulding: But the first phase gives you some quick and effective wins. I mean let's face it, privileged access management can be a complicated beast. Getting simple, quick wins early on is always a boon to such a project. But the first phase gives you some of those. It puts some basic controls in place.
Tony Goulding: Those basic wins could be discovery. You can't manage what you don't understand or you don't know. Discovery is a great way of getting all of your privileged accounts, resources in place, vaulting away those privilege credentials, especially when you can't get rid of local accounts, vaulting them away so that they're properly managed. But again we've already ad nauseam spoken about the vault is not enough. You can't simply stop there, with just vaulting what you discovered.
Tony Goulding: Phase two involves reducing that attack surface. The principal way we do that is consolidating identities. Like many of our customers in the danger zone, they've got identities everywhere. An administrator may have 10, 20, 50 different accounts spread throughout multiple systems.
Tony Goulding: Identity consolidation is all about eliminating local accounts as far as humanly possible. Then giving those users or administrators a single identity. Then we're managing a single identity, we can better control what they're allowed to do on those various endpoints by doing that. We're also implementing both privileged elevation controls as well as workflow for that just-in-time privileged access, the request approval mechanism we mentioned earlier.
Tony Goulding: Now one of the lowest hanging fruit in this particular phase is MFA for all privileged users. Nobody should be allowing an administrator to login to a business-critical server without prompting for a second-factor authentication. Now, of course, if you have more advanced tools like privilege analytics, you can put context into play there so that you're not binary or on a rolloff, you're actually only prompting for that second factor if the context suggests that the risk is too high to just let them in.
Tony Goulding: That final phase involves hardening the environment by air gapping administrative accounts, following things like Microsoft best practices, so Microsoft's enhanced security administration environment, the ESAE, is one such set of best practices. Shutting down dangerous workarounds by putting host-based monitoring, using advanced behavioral analytics, as I just mentioned, and finally adding assurance level three.
Tony Goulding: NIST is very, very popular. It's tracked and adhered to by a lot of our customers, not only in the federal government but also non-governmental customers. They're looking for those extra assurance levels. NIST assurance level three, for example, is not just about a second factor, but it's about the use of a physical second factor. Working up to that assurance level three gives you that more mature stance. It gives you additional risk mitigation, especially for those ultra-sensitive servers where, for example, PII lives, credit card information, or healthcare information.
Tony Goulding: None of these has to be complicated. It sounds complicated, but it doesn't have to be. Centrify and the partners that we work with, we've got many years of experience putting together these types of solutions in some of the world's largest and most complex environments.
Tony Goulding: I guess that brings us to our next poll question. Please take a moment to share where you are in terms of implementing zero trust privilege, zero trust security within your organization. Give that a few seconds to populate before we move on to our fourth myth.
Tony Goulding: Okay. We have some results in here. It looks as though we've got about a quarter of the audience is doing discovery in vaulting, which is no real surprise there based on the earlier answers to people using a vault. Identity consolidation is interesting with least access privilege. Maybe we could have separated those two out. But identity consolidation is great, least access privilege is awesome.
Tony Goulding: The high assurance hardening is zero. We don't have anybody taking that extra step of doing a lot more host-based auditing and session recording, perhaps with behavior analytics and contextual-based access controls. We have about a quarter of the audience who have really not started on any of this, which is scary, but, hey, that's why we're all here, is to learn and discover what's possible and what's achievable. All right. Thank you for that. Let's move on to the fourth myth.
Tony Goulding: Most organizations that we've spoken to, they look at zero trust as something that is exclusive to on-premises, something that can't be applied to the public cloud, especially in hybrid environments. The infrastructure in the public cloud is basically not under their control. Let's get some insights from Torsten on myth number four.
Torsten George: Sure. We all know that it's really impossible to stop the cloud migration movement. All the stats you can find from leading research firms confirm that businesses of all sizes have started and continue to outsource their IT environment into the cloud. By doing so, all their sensitive data now resides outside their traditional network perimeter.
Torsten George: Hackers have missed that trend and are nowadays including hosted environments in the tech cloud. I don't know if you've heard about last year there was a big attack on Tesla, whereby compromised credentials were used to gain access to their AWS DevOps environment, and it served the hackers as their own cryptomining operations center. They didn't have to pay for it, Tesla did. Just one example.
Torsten George: It's really important to adopt zero trust security not only in your own infrastructure, but extend the security model to your cloud environments. At the end of the day, you're applying the same zero trust security best practices and tools to the cloud. The rules haven't changed, only the location of your data. Zero trust can easily be extended into the cloud as you're treating this outsourced infrastructure like you would with any of your internal data centers.
Torsten George: To round things off, myth number five. We hear about this a lot in the field. As Zero trust security was conceived as a response to the new threat landscape, many believe that its benefits are primarily focused on minimizing an organization's risk exposure. Is this really the only benefit that zero trust security delivers? Tony, please enlighten us.
Tony Goulding: Yeah. Thanks, Torsten. Yeah, clearly, that is ... We're leading the witness here. That's clearly not the case. We've worked with a number of analysts. We've done our own research, but certainly we've worked with Forrester, and they conducted multiple studies to look at the advantages and the benefits of zero trust security.
Tony Goulding: As expected, the results prove that organizations can reduce their risk exposure. Certainly during the initial rollout, that risk exposure reduction can be dramatic. It can be 50% or more, to be more precise. But in addition, organizations that they've interviewed experienced an average of $5 million in cost-savings related to breaches, which is not insignificant.
Tony Goulding: Now interestingly, the most mature organizations preferred an integrated platform approach instead of points or custom one-off solutions. By taking that strategic approach, that led to an estimated 40% reduction in IAM, identity and access management, and privileged access management technology costs as a percentage of their IT budget. Those are massive savings.
Tony Goulding: But as Torsten was alluding to, it's not all hard benefits that you gain. Zero trust privilege, it also contributes to a business confidence that's required in the form of enhancing customer and partner experiences. If they feel as though they're then secure, that they're applying modern security to protect their best interests, then you get better partner experiences and customer experiences. Also, more and more about daily life is mobile. Empowering your mobile workforce is another benefit that you can get from implementing this type of solution.
Tony Goulding: Also, Dev and DevOps, I mean let's not forget Dev and DevOps. A lot of our customers are aggressively moving to the cloud and using containers and microservices. Their developers are frantically working to create very scalable applications and services in the cloud, and so they become the focus of many attacks. Securing what they do, being able to vault away passwords and secrets that they use routinely within their pipeline, as well as securing their access to assets, what they're allowed to login to and what they're allowed to do. Should the Devs be able to access the production systems or the QA systems, et cetera? These are all important benefits that we get as well from using privileged security in this manner.
Torsten George: That's real great information, Tony. Thank you. Let me quickly summarize our discussion for our audience. It was a lot of information to digest. We're able to debunk the top five myths about zero trust security and learned that, number one, the path towards zero trust security starts with privileged access management as far as zero trust privilege, and not like many believe with data integrity.
Torsten George: The second thing is that, in addition, zero trust is universal, meaning it applies to organizations of all sizes and industries. Furthermore, it's affordable. Think about the beer budget next time you sit at the bar.
Torsten George: We also learned that zero trust security doesn't require a rip and replace, but rather augments existing security controls and can be implemented step-by-step over time. Importantly, it was also discussed that zero trust concept expands beyond traditional network perimeter and covers the ever-expanding attack surface, including public cloud environments.
Torsten George: Last but not least, zero trust security offers a broad range of benefits, from risk and cost reduction to increased confidence levels and empowering your modern enterprise projects. As we wrap things up, before we start with further questions, let's take a look at our last poll. We really would love to hear from you on what other topics you're interested in for future webinars. Please take a few seconds to review and respond.
Torsten George: Oh, it looks like people really want to drill more into the zero trust security concepts and how zero trust privilege can help their organizations. We will definitely take that into account. Let's see what other questions came in here. While we're looking through the questions, you can also ... If you need to contact, you already have our contact information. Please join us for future webinars, events. You can find all the links there. Then also if you're really interested to get your fingers onto the solution, we offer a 30-day free trial. With that said, let's see.
Torsten George: There is a question here from Steve, asking, "We're currently using a password vault. But based on your presentation, it appears that approach doesn't meet the full zero trust requirements. Can you elaborate on this a little bit?"
Tony Goulding: Yeah. I think you figured out that part of our message here is that password vaults are not enough. We find a lot of customers are using just a vault, and that might be just because they got an audit finding that said, "Hey, you've got too many shared privileged accounts in the hands of the admins, and it's insecure." They get a ding and it's like, "Well, password vault is an easy way of basically reconciling that."
Tony Goulding: But from an overall enterprise security perspective, just having that vault and continuing to perpetuate the use of shared privilege accounts and local accounts especially is simply not enough. Going back to some of the slides that we had on the maturity model, if all you're doing is the vault, then you really are leaving yourself exposed.
Tony Goulding: We have a lot of customers actually who've implemented the vault. If I'm an attacker, I'm going to bypass that vault. I'm not going to necessarily say, "Oh, look, they've got a vault." I'm going to try and compromise infrastructure by going through the vault, which is if all you have is a vault, that's the single point of failure as well, because it's typically where your policies are applied. A lot of vault vendors do their command filtering there, they do their session recording there. If an attacker gets onto your network and goes laterally to different servers, then you're bypassing that vault completely and you don't have any session recording on what's going on.
Tony Goulding: Augmenting a vault, a vault has its place, but augmenting it with a host-enforced privileged access management solution is ... Oh, have we gone to mute? Sorry. We might have muted there. Augmenting the vault with a privileged access management solution that's at the host level can mitigate those risks. It also provides the more fine-grained authorization necessary on the host. You can only see so much of what's going on if you're a proxy at the vault and you're trying to filter commands.
Tony Goulding: On the host level, we get fine-grained session recording and auditing, including process-level auditing, which can go quite deep. We can figure out if attackers are trying to hide privileged activity inside a script file or behind an alias. We can do constant monitoring at that level and alerting, which you can't very easily do up at the vault level.
Tony Goulding: Also, we get the ability to basically consolidate those identities in a much more efficient fashion. What we want to do is get rid of those local accounts, give everybody, for example, a single active directory identity that they can then use to login to their resources wherever they happen to be.
Tony Goulding: Certainly, as it comes to more modern approaches like in the cloud, if I stand up an instance, let's say, of Linux in the cloud, I want to be able to login to that instance with my own AD account without having to replicate AD infrastructure into the cloud. These are some of the benefits that we get, certainly with the Centrify solution that's fairly unique, is the ability to support authentication and login to those instances without replicating that infrastructure into the cloud. I might have wobbled a little bit there, but hopefully that addressed part of that question.
Torsten George: Okay. A question from Kevin from our audience, "What tools and approaches are available for database access? It seems that a lot of the conversation has focused on server access. What about database administrators? We know we need to mature and not let engineers connect directly to databases."
Tony Goulding: Yeah. There's a couple of things there. I mean, for example, our vault is not unlike many vaults, isn't it? It's not just a password vault. It stores generic secrets as well. But it can also store database accounts. Let me give you a use case.
Tony Goulding: Maybe I'm a database administrator. I login to the Centrify vault, the privileged access service, and, based on my role, maybe I have the ability to login to a database or to checkout a database password. Maybe I have to request that. But ultimately we do have the ability of managing those database accounts within the password vault infrastructure.
Tony Goulding: Then, further, you may use intermediary applications like Toad. What you want to do is access a database through that intermediary service. We have the ability of enabling that from within the vault infrastructure as a secure remote session, but governing whether or not that user really should have the ability to do that. Hopefully that answered the question.
Torsten George: Okay. Then we've got a question that is focused on MFA. Vernat is asking, "We're using Google authenticator in a limited scope. Are there any other such alternatives you would suggest?" It's more about the MFA methodologies that you should apply for lock-in, for privilege elevation, and talking about the assurance levels, basically.
Tony Goulding: Yeah. I mean we're big proponents of MFA. Obviously, it's a means of mitigating risk through additional identity assurance. Certainly if you're a bot or a piece of malware that's running there, then they don't have the fingers necessary to open up and authenticate on a phone and respond to that. It's great in that respect.
Tony Goulding: But to answer your question, yeah, we have built-in MFA support. We like to give our customers a bit of a leg up. Most of our customers do already use third-party tokens for multifactor authentication, and we support the bulk of the common ones out of the box, whether it's RSA SecurID, Radius-based, host-based OTP, OAuth, SAML, all of these different types of mechanisms. We support those. I guess we're unlike a lot of the vaults out there that focus more exclusively on storing stuff.
Tony Goulding: We also have a built-in authentication framework. We can generate these tokens within our own service without relying on third parties. That becomes really useful for when a lot of our competitors, let's say, the service-to-service or application-to-application password management, when an application needs to authenticate to another one, it's all about having programmatically the ability to check a password out of the vault in order to login.
Tony Goulding: But passwords are inherently insecure. By talking to our service, they could actually use a stronger token that's not long-lived like a password. They could use a SAML token or an OAuth token in order to do that authentication, which is much, much stronger, and they are ephemeral tokens that will only last for the duration of that session.
Tony Goulding: From an MFA perspective, yeah. We've got that down in spades. We do it at vault login, checkout, remote connections to the servers and on the server itself, not just on server login but also on privilege elevation. Nobody else does that using a single unified framework. That's part of our benefit is organic ... We've built all this stuff ourselves. We haven't OEM'ed it, we haven't acquired it, we haven't tried to Frankenstein it together. It all works in a unified way.
Torsten George: Okay. Thanks so much, Tony. I think these were all the questions we can take in today's webinar. Natasha, why don't you take us off?
Natasha: Great. Thank you all for joining us. I will be sending the slides and the recording in the next 24 hours, so keep an eye out for that. We hope to see you at our next webinar. Thank you all. Thank you, Torsten and Tony.
Torsten George: Thanks, everybody.
Tony Goulding: Thank you.
Trusted by over 2,000 Organizations, Worldwide
