Good afternoon ladies, and welcome to our copy cold webinar, making the cloud secure and easy to use environment, increase security and mitigate risks. When extending your on premises environment to the cloud. This webinar is supported by century file speakers. Today are various cut, who is CTO at Centrify and me Martin Ko, I'm CEO, founder, and principal Analyst at co a Cole. Before we start some background information, co a Cole and some housekeeping information Ko, a Cole is an Analyst company. We have been founded back in 2004.
We are focused on information security, have a long history in the area of identity and access management, but also look at more and more areas outside of the sort of core field of information security around digital transformational, blockchain, and a lot of other topics. We have three business areas. These business areas, our research, where we provide various types of research, including our leadership documents, where we compare vendors in certain market segments.
Our events I'll talk about this in a minute, but webinars, as we do right now are one part of our events and advisory, where we act as a neutral advisor, supporting organizations and defining their strategies in tools, choice, and other areas regarding the events we have outside of all the webinars we are doing, we have upcoming events. One is European identity and cloud conference, which will be held next time in May 9th to 12th in Munich, I would say it's just a master 10 event. You shouldn't miss this.
Then the other event is our so called consumer identity world tour, which will be a series of three events. One will take place in Singapore, one in Seattle, one in Paris. So these three events will then cover the area of consumer identity and access management. So for the webinar, some guidelines, you are muted centrally, so you don't have to mute or unmute yourself.
You're controlling these features. We are recording the webinar and the podcast recording will be available tomorrow and there will be a Q and a session at the end.
You can, however, end the questions at any time using the questions feature in the go to webinar control panel, and always a good idea to end the questions also during the webinar, once you have them, because then we have a good list of questions for the final Q and a session. This brings us to the agenda, the first talk. And the first part, I will talk about the various options organizations have to extend their own premise security model to the cloud. And why is about extending that? I think something sort of dispar, sort of a separate cloud security.
And the second part, then Barry co will talk about best practices and how to enforce a consistent privilege to access security model across public cloud, private cloud and on-premises apps and infrastructures.
And as I've said, after that, we will do a Q and a session. So when we look at security and what is happening around security, see some major change in the requirements these days. So obviously the thread landscape has changed and continues to change. We see far more threats. We see far more attacks. We have to react on this and we have to secure all the environments we are using.
And I think it's particularly challenging when we look at the reality of our environments, these environments become hybrid. And for most of the organizations, the cloud already is a relevant deployment model, but the cloud is not the only deployment model. And for most organizations, it will not be the only deployment model. Even when you have a cloud first strategy, most organizations will have some part of their it on premises for very long time.
And a lot of organizations will remain hybrid ever.
For instance, all the organizations which run their own manufacturing environments, their own plants in these plants, you have on-premise it at the end of the day, so that everything will move to the cloud. On the other hand, we also have the situation that we have more MSP models, so more access from outside to internal on-prem or even to cloud based services. So it can be rather complex. In that case, we have to connect to things which are not the scope of today. We need to, to do more the creation of all, what you do around security to build a consistent picture.
We have to challenge of compliance. So at the end, they all, this has to be done in regulatory compliant way. So with the cloud and all the changes we also have seen before around neutralization, we also have change in risk surface.
So the risk surface is significant or has already changed significantly, sort of about to continue to change with the move to the cloud. So traditionally we had our system administrators caring for the operating systems, the end user organization. We had our application administrators, which both, we still have caring for applications.
Then we started virtual virtualizing. The, and we had a little bit more complexity because it's not only the operating system, but it's a host operating system, the hyper wiser guest operating system, and the applications, things are more complex because the more elements you have, the more attack surface you expose. And then right now we have a situation that with the cloud and name MSP models, we bring in other system administrators, which then operate either our on premise SOP case.
Our on-premise host operating system, hypervisor guest operating system application, or where all that stuff is running in the cloud.
So we again have a more complex scenario. So all the communication in between, but reality is we will have both types of administrators. We will have both types of deployment models. We even have sort of non virtualized deployment models still plus the virtualized ones running on premises and in the cloud, this is changing.
And when we look at it from a business perspective and I'll take a model from the banking world here, basically it's not specifically a banking model, but I think it's very easy to understand the banking space. When you look at some new regulations, such as PSD two, for instance, they mandate banks to think about how can I provide other types of business models to my customers, where they can interface as all of, with me as a bank, but with other banks. So a lot of things are changing.
And so this traditional core banking business and the core banking, it in fact still is sort of accessed with traditional services by traditional customers.
But we are seeing a very strong tendency towards this traditional core must be accessed by new types of services. So we have new banking services, new types of banking business for both traditional new customers and which request innovative services. But at the end, this interfaces back to the core banking business.
And again, this means in a consequence that the world of it here becomes hybrid. In fact, it is hybrid. So the banking, it became a little exposed at least, but it'll get more and more hybrid. This also services provided in the cloud, which then at some point come back to the traditional core banking business, but also might be external players, external providers who are providing sexist. So within this world, also, we have to ensure that the core banking business, for instance, can operate at a standard speed, stable and reliable while the new business services must be far more agile.
We must ensure that this entire scenario is, is well protected. And we can't just say, okay, we have a security for security view on our traditional business and or the core banking business. And we have another one which only focus on the new services. We must look at it as an, in a holistic perspective as something which consists of various layers. That also means we must, for instance, expose and protect API. And so we have sort of a multimodal it or multis speed it as well.
So an it which consists of a core it where we have already built a layer around for more agile, it, this agile, it that might be internally or might be external to some extent, but it's really more the flexible things we build in new services we build, which operate usually then different types of operating systems for which are building a different manner than traditional services.
But at the end, it's one. So from a logic perspective, it's, it's one it and the application then.
So what we also then see is, again, we could look at a banking business where banks and EU are mandated to expose APIs to third party providers. It means we also have this outer API layer, which goes to an external, it, some stuff might then might run in the cloud. Some stuff might run on premises, but at the end, security has to be treated as a, as one thing as how can we protect information across all these layers across all the various elements involved in our it.
So we need to look at it when we look at it from a perspective security, we should look at it really as a complex environment where we need to protect information, regardless of where it is. Is it currently in the cloud?
Was it on premises? Is it a core system or in a system which is more in the, the, the level of actual it?
So we will not succeed if we try to have a different security for all of these various layers and the clue at the end of the day to secure stuff, from our perspective, it's identity, it's about controlling access of who has access to what in this complex distributed environment. And I go back to a, something I've written on quite a while ago is seven fundamentals for future identity and access management. And so very clearly we'll have to look at more than humans.
So we look at, have to look at the identity of things, devices, services, and apps, which are communicating with each other, which are interfacing with, with each other. We will have more identity providers.
So not all of these identities will be managed internally, but at the end, it's still about how can we ensure that if Martin Cooper is seen as consumer and locks in with a social network account, that we still can ensure that he only is allowed to certain the end it's regardless of where Martin and accesses, whether he accesses cloud service or goes down to an on-prem application, we need to ensure that things are done securely.
We will have multiple a providers, multiple identities. So many people who use different identities.
We have to understand these are always the same people, multiple authenticators, and here a little bit out of topic for today. But trust is a recommendation think authentication from your customer or from the user, not from sort of inside out. Most things we do in authentication to look at, oh, we need some sort of cross authentication.
Oh, we implement that authentication. That might be good for you, but the users might not be overly happy with it. Think it from users, you will end up as adaptive our indication, supporting multiple laws indicators. We must understand relationships, and we must understand the context.
And again, this goes back to two elements. One is what is the context of the user who's accessing data? The other is what is the context of the information?
So where's the data stored? Where is it held or processed? The risk might vary. And in this complex world, from my perspective, enough touched it already. It's highly important that you have one approach. It doesn't say that you need necessarily one technology at the end identity management always will consist of a couple of building blocks, not only of a single tool, but what you need definitely is one approach.
One strategy, one D print, one holistic view on how do you treat all the different parties, accessing all the different types of applications using different devices. So we have to consumers, customers, partner, contractors, employees. It's no longer about employee. Only days of employee only thinking, and identity management are history. They are accessing why variety of devices. And we don't know which device they will use tomorrow. And they might access stuff, applications, which aren't internal or the external network.
They might come in from an external or external network.
We need to support all these various technologies, Federation, web access, APIs, adaptive modification, privilege management. How do we ensure that privilege access treated correctly? How do we federate, how do this, all these applications? And it doesn't really make sense to think it about, oh, how can our consumer, how can we protect cloud services for customers and consumers?
How can we protect our web apps or even our non-web backend services for consumer and customers, and how do we do it totally independently for the contractors and the others, seeing it really in a combined and holistic view, it's the only way from my perspective perspective to succeed. And so my point clearly is hybrid enterprises need a hybrid. I am. So when I look at this very clearly digital transformation requires organizations to become more open than ever before.
I've once called it ABC, the new ABC, the agile businesses connected.
And that's, I think the, the challenge we have, we use services different, and we have users which are mobile. We have customers in a total different way of integration, far tighter, integrated, more integration with partners and all that stuff. We have to support this change, but there will be the existing it infrastructure. A lot of this will remain. Some stuff will move to the cloud, but a lot of stuff will remain on premises and hybrid enterprises.
In fact, most enterprises are hybrid need the hybrid it and hybrid it simply said needs a hybrid. I am how to do that and how to create such a hybrid environment. That's something very right now. We'll talk about. So I'll make Barry right now, the center and Barry, it's your turn.
So thanks again, Martin and good afternoon, everybody. My name's Barry Scott, and I'm actually the EMEA CTO for Centrify.
Now, for those of you that may not have heard of Centrify, we're a security vendor primarily, and we're specifically involved in identity and access management. So that means really we cover both identity as a service, which includes such things as federated single sign on to, to cloud SAS applications, such as Dropbox box office 365 and so on. And we also provide privileged identity management, which is kind of more the focus today with leaders for privileged identity management and identity as a service in different Analyst papers as well.
So the privileged identity management piece actually covers two areas. One of which is the secure management of generic or service accounts or share or whatever to call them, basically accounts that are often provided with apps or operating systems or devices. And don't have an individual owner. And the second side to privileged identity management, which should really be used for most non break glass situations is least privileged management and by least privileged management. What we mean is enabling a user to log in as themselves.
And then basically we assign them the rights to perform only the tasks or commands as, and when needed through their job role.
So in terms of the content of today's webinar, centrifies had now 12, 13 years of integrating Unix and Linux systems into Microsoft active directory. That's mostly what we were known for originally and also providing privilege management and session recording across windows, Linux, Unix, and network devices. Over the last few years, there's been more and more uptake of infrastructure as a service and somewhat strangely.
Some of the customers I talked to who two or three years ago, would've sworn blind. They would never use the cloud because of security concerns have since then for a number of reasons, moved rapidly towards cloud services from both the software as a service and infrastructure as a service angle. So I think we've seen a pendulum swing from everything being on premise. Then there was a headlong charge towards the cloud to all cloud.
And now it's come to rest in a, in a, a good compromise between the two, I think for most people within EMEA, which is the hybrid cloud area that Martin has described so far today.
And there's no doubt that one of the main concerns with infrastructure as a service and hybrid cloud generally is privileged access management. And you can see some figures on the slide in front of you. Now that relate to that. As you can see in the top left, there's a huge increase in cloud adoption and spend.
And according to a survey that Centrify commissioned recently, it's really interesting to see that a very high proportion of organizations are storing sensitive data in the cloud, although whether they originally set out deliberately to do so is another matter. You can also see the statistic that it's been stated. 95% of infrastructure as a service security failures will be the customer's fault. And half of those will be attributed to inadequate management of identities, access and privilege.
So it's really important that organizations don't go blindly into the cloud thinking they've offloaded all their security concerns to the cloud provider.
And Amazon have defined a very good shared responsibility model, which is very clear on what one can expect of their services and what customers of AWS are still responsible for themselves and understanding where the line of responsibility for customers, I, I think is critical. So I'll just build this slide out. I think so credentials are the main thing controlling access to infrastructure today, and they're under attack.
We all know that nowadays it's not just privileged user credentials that need to be protected either. Typically the bad guys will infiltrate a network through end user credentials or what we typically call end user credentials, maybe through a business partner that is access to your network over a VPN that isn't secured with multifactor authentication. Maybe that partner has less rigorous security controls than yourselves. And basically the hackers are trying to get inside the network and fishing is also a popular way in, by tricking users to give the hackers their credentials.
So to this must be added the fact that the perimeters effectively dissolve we're in a boundaryless world. Now we've data centers in the cloud with infrastructure as a service, we all use SAS services and access them from mobile devices. We expect to be able to access anything from anywhere and users. Don't always traverse a firewall based perimeter to reach the data or systems they need to work on. So perimeter based security, we're not saying it's, it's no longer needed, but it's not enough. And indeed in some states is some situations is completely redundant.
So that takes us to the place where identity is the new perimeter. Or in fact, as Martin was saying, identity is the glue effectively. So in terms of best practices for the securing, the cloud infrastructure and sort of getting down to it now, although some of what I'm about to talk about goes through or go through relates to AWS as the infrastructure, as a service environment, general points can be taken away.
And it's pretty generic for other platforms such as Azure, Google cloud and open stack.
So what I'll cover now is contained in our white paper and it's available off our website called six best practices for securing AWS environments. And we created it as an extension to the very good security principles detailed in the AWS documentation set. So the first thing is to adopt a common security model using and extending your on-premise access policies. So the infrastructure and applications can be deployed quickly and securely into the cloud.
Now, most organizations, not all but most have adopted Microsoft ad as their primary directory or source of truth. So they will want to be able to extend the identity and access management that they've been providing with that on premises into the cloud. I'll go into that in a bit more detail in, in some slides further on, and also I'll cover the alternative ways available to take your I enterprise IAM into the cloud.
So by extending our existing identity and access management, consolidating identities, and being able to use our active directory or maybe L app or cloud directory accounts, we can also eliminate the need for key pairs and local accounts to be used for authentication to the systems that we fire up in infrastructure as a service, which in turn shrinks the attack surface.
So ensuring accountability, that means that we want to know that a particular user was responsible for something in the I a, a S environment, and we can do so by using our existing ad user accounts at the OS platform level, as well as federating access to the infrastructure as a service providers, services and resources such as the AWS console. Now the concepts of least privilege are important on individual instances, as well as when using the services offered by the infrastructure as a service provider.
So in the case of AWS, for instance, they've got great built in role based access management at the service level. And we can tie that back to our existing active directory and active directory groups. You still need to audit everything. The infrastructure as a service providers have various tools that do some of this such as cloud trails in AWS, but you also need to be able to see what people have done on the instances themselves. So session recording on those instances and the ability to search and review sessions is very important.
Same as it is on premises with, with traditional on-prem infrastructure. And finally, we believe it's very important to use multifactor authentication wherever possible.
And it's far better to have a consistent approach and consistent tools for MFA across the entire environment, regardless of whether it's MFA for access to a SA service like office 365 or Dropbox or box or concur multifactor authentication for log onto a workstation, or maybe multifactor authentication when you use elevates their privilege on a windows or Linux machine, either on premises or in the cloud, we've re recently introduced adaptive multifactor authentication and launched risk based access where multifactor authentication can be invoked or access denied altogether based on the user's behavior being seen as different from normal.
So this uses machine learning and analytics and makes the widespread adoption of MFA easier because beyond the context of what we're talking about today to implement multifactor authentication, the user experience needs to be frictionless. Otherwise the users will resist the implementation of multifactor authentication.
So there's a number of challenge. Typical questions we hear from customers today.
And the first is really how should they integrate their infrastructure in as a service environments, into the enterprise questions, such as how to control access to the consoles use of multifactor authentication, use of smart cards, how to manage roles in the consult, how to allow outsource partners to have appropriate access. Martin was talking effectively about the number of different people that we need to give access to our networks. And there are many, many different people now that need this access.
And I read something recently that said that a hundred percent of companies allow external people access to their networks. So it's very important to be on top of that. Then we go down to the level of managing access and privileges on the instances themselves. So if you like, we've got through the, the layer of how can I access the infrastructure as a service environment. And then we've got to the instances themselves.
So the local route or administrator account needs to be locked down MFA should be used to control login and privilege management auditing of users needs to be done and access and authentic, quite authentication questions around the applications actually running on. The instances are gonna come up to.
So just going through a few of those questions specifically for AWS here, but as I said earlier, you know, a lot of this is generic and we'll cover different infrastructure as a service and cloud providers as well. So there's a recommendation not to use the route account, the AWS route account.
I either serve it the AWS service route account for day to day use. So we lock down that account by taking the password under our control, and we grant access via workflow for those break glass situations where the access is needed. And as I say, it shouldn't be used day to day. There should be more granular access used for the normal access control. So using federated access to the AWS console as well does not require IM users to be created. So there's no need for the long lived access keys that are usually associated with them in, in the environment.
And after authenticating to the user's desktop, they can then have single sign login using integrated windows authentication, a multifactor authentication or smart card login can be layered on as well if required. So by mapping AWS roles to enterprise users or groups in active directory privileges to AWS itself can be delegated and initially assigned using builtin workflow. Maybe you want to integrate with service now or an ITSM solution as well.
So the Centrify user Porwal, which I just mentioned above provides that single sign on access to the console, whether the user's identity, and this comes back to where that user is coming from to access it, whether the identity is an ad or LD app or in a cloud service or outsource partners, indeed can log in via Sam or Federation to the Porwal after authenticating using their organization's identity.
And in turn, they can access the console, assuming they've been given the, the necessary access rates to do so, as you probably notice, the console's used with infrastructure as a service providers, they're effectively SAS applications in their own, right?
And that's where our identity as a service solution is being used to provide the federated access. It's also where I think that the traditional idea of a privileged user is, is becoming quite vague as well.
It's changing from the guy or girl who simply logged on at a Unix Linux or windows platform level to perform privileged tasks and privileged users now need access to SAS applications to do their management. We've already seen the infrastructure as a service provider console use case.
And as time goes on more and more privileged access to infrastructure environments, things such as big data administration consult will be used rather than today, where some of these environments, you actually log on to the end points or servers in future, the management will be done through the, through the consults. So in terms of what you need out, an identity as a service solution, as part of the infrastructure, as a service, you need that single sign on for the internal and the external users for access, you need those users identity to be available from anywhere.
Be it may be in Google cloud ad LD app. You need to have provisioning and D provisioning to those things that that's offering. You need mobility management. If you're gonna be doing a multifactor authentication using a mobile device, you gotta make very sure that that mobile device is secured in terms of policy multifactor authentication as well. You need per app authentication policies and so on. So really that's, that's the size of that.
So in terms of extending enterprise infrastructure, identity and access management to public and private clouds today, we've got the data centers on the left side of our, our brick wall there, our firewall, and what we're doing, we're starting from a place where we have the on-premises ID may be held at various flavors of Unix, Linux, and windows. And we want, might wanna do some temporary large scale testing for instance. So we look at creating similar environments in IDs as your Google cloud.
That's all fine, but now we need to be able to log onto those cloud based systems.
And I I've got the go to webinar console in the way, so I can't see my slides hold on a sec. Oh yeah. So as I say, that's fine, but we've gotta log onto those cloud based systems. And that can be a challenge. Where are the identities gonna come from? So if you're committed to active directory today, you might look at extending your active directory over some sort of dedicated link, maybe configuring site to site VPN with a one way trust, maybe have a read only domain controller in the infrastructure as a service environment. A big advantage of this big benefit is operations stay the same.
The technology's all familiar. It's no different to how you might deploy at a different site pre-cloud era. And you have all the skills that you need.
The next thing you might wanna do is to completely duplicate your identity infrastructure, but that kind of goes against what we should be doing with identity and access management, where we should be consolidating identities, but here you have the benefits of similar technology.
So, you know, it's stuff you're familiar with, even though it's duplicated isolation, but operational duplication in terms of people and process and users with multiple identities, even if they have the same names, there's still multiple identities and you can guarantee that's gonna lead to such things as bad password practices. Another option may be to use the native service from the infrastructure as a service provider, maybe Amazon's IM as your ID or, or Google directory.
Now all of these services will have strengths for the particular infrastructure you're developing, but you're duplicating things operationally, and we'll have integration challenges between your on premises and your cloud environments.
And incidentally, the whole challenge is quite similar to what we may have done in the past with DMZ DMZs. So moving on to the next slide.
Now, another way of doing things here is what we have with the Centrify identity broker. And it's a solution based around our privilege service. And it allows using the credentials from your preferred directory. And as I've said, that's typically gonna be ad, but maybe L app Google or whatever, to authenticate to the Linux machine instances in the cloud. And we're seeing more multi-cloud approaches being taken, especially over the, I think the last few months, we're seeing more people looking at, for instance, AWS, plus a zero or Google cloud plus something else.
As people realize that underneath the cloud, there are actually physical machines that can go wrong and people that can make mistakes. So that makes it even more sensible to be able to use a common enterprise identity platform, regardless of whether you particular, I infrastructure is a service flavor today is as Azures Google or some other service or mixture of services.
So as a general approach, we want to be, it doesn't matter if it's on-prem or in the cloud, we want to be reducing the risk across our hybrid it environment.
So we see customers starting from the place where too many passwords, too much privilege. People have too much rights to too many things from too many places. And what we want to do is take them down towards the, the X axis here where there's less, less risk to their environment. And one thing is establishing identity assurance. So to do that, we want to be implementing multifactor authentication, wherever we can be. It access to SAS applications, be it access to on-premises applications from your local coffee shop, be it access to Oracle systems or whatever it might be.
We want multifactor authentication for all those different use cases, some of which are typically privileged and some of which are typically end user, and we want single sign on everywhere as well.
So that's improving our risk profile. We also wanna be able to limit lateral movement. So mitigating the VPN risk.
As, as I mentioned by Martin, we want to give people access to the infrastructure as a service system. So we wanna make sure we have secure remote access, be it on premise or infrastructure as a service systems that our partners need to access. And we've also gotta sort out app provisioning. We've gotta sort out access approvals so that the scope for lateral movement, if people do get in is much lessened and less risky, then we want to really go for the least privilege approach. We wanna grant just enough privilege for what people need to do as part of their job role when they need to do it.
And also granted just in time. So ultimately we're gonna get to a state where on a Monday morning for, for the sake of argument, when the environment is in a precent state, nobody should really have any rights above and beyond normal.
And of course, we've gotta log and monitor all this. We need to know who's been accessing what systems we need, complete replay potentially of any incidents that might have occurred, any sessions that have been used. So that's basically the, the general approach we would take to, to reducing risk across hybrid it environment.
Now some of these might be in different orders depending on the, the current stance you are in and what drivers you have, but basically it's that reducing risk to the right hand side of the, of the picture there. So just sort of, kind of wrapping up now, the solution for securing hybrid clouds and hybrid environments. We want to secure the surface service management, which, and that means give giving federated access to the consoles, the consoles that are effectively SaaS applications in the first place. So we can give our own on-premise users, our own internal users access to those securely.
We have multifactor authentication. We can give our partners access to them as well. Then once we've got in, we need to be able to have privileged access security on those machines. Those instances themselves that are running in those environments. And also we need to give enterprise access for the hosted applications. We might have external people that need access to apps running in AWSs zero Google, et cetera. So we need to be able to give them access. So just really tying up in terms of the Centrify solutions.
As I mentioned at the beginning, we have I an I'd a solution identity service, which is on the top left side here. And we also have a privilege management solutions, the, the privilege service and service.
We, as I said at the beginning privileged services, mostly about managing those shared generic non-human passwords. And the service suite is about day to day access to Unix, Linux, windows, systems, privilege management, and so on, but everything's based on a platform.
So it's important to give you an example. The MFA service is as important for giving the CEO access to NetSuite with our ID, a solution, as it is for having MFA for an Oracle DBA, upping their privilege to restart an Oracle database or something.
So the platform is very important in the Federation service as well, giving it federated access, be it to a SaaS application or, or to ultimately have access to a server. And also of course, there's the analytics service that I mentioned earlier, which is the risk based access to, to a lot of these functions. And of course we've got reporting, we've got workflow, all, all the things that you'd really expect. I'm just rounding off now for some additional resources. There's some solutions for AWS.
We've got a tech center for AWS and, and other cloud infrastructure as a service environment on our website, some white papers there and various other bits and pieces that might be worth a look. So thank you very much for your time.
Thank you, Barry. So we now move to the Q and a session. So it's time right now for the attendees to enter their questions so that we can pick these questions and answer these questions.
So, so one question I have here is what about orchestration and automation? It's important that as soon as machines are created, they are fully configured. And I would say probably not only configured, but secured. So how do you handle that?
Yeah, so it's a good question. And, and there's no point with all the, the new technology. If you have to do things manually, once a machine has come up, so people are gonna be using puppet, they're gonna be using Ansible, they're gonna be using all sorts of things. They're gonna be using gold images of, of systems as they come up on premise. So we do a lot of integration, orchestration, creating tools that will enable all of this, this stuff for want of a better word to happen immediately. The instance is created.
So usually when you fire up an image or you're doing cloud bursting, the some point at which during that coming up process or creation process, there's a point at which scripts can be executed to, to customize, to maybe join to active directory, to maybe configure the identity broker, to determine who can access this particular system. So it, it is absolutely critical that there's no window of opportunity when the instance actually first fires up when it's insecure, as you rightly say.
So we do a lot around automation and orchestration, be it PowerShell, be it general unit scripting or whatever to, to cover that off.
Okay. Another question I have here is the identity broker sounds interesting. How does it work?
Right.
So it, it's, it's a bit tricky to explain without a picture, but if you imagine you have your infrastructure as a service environment, and you've got a thousand Linux systems in it, that's all you have. You want to be able to authenticate to Microsoft active directory, because that happens to be your preferred directory of choice for all your internal users. So basically what happens is that those Linux instances are enabled through NSS and Pam modules. It's basically a lightweight version of, of the, the service suite module that we've been providing for years.
Basically what happens is you can type in Martin or equipping a coal.com on one of those units or the next instances. And it will go back via the wonders of the identity broker software to go back to your on-premises active directory and authenticate you to that. So it's really good in the environment where you want to use your active directory credentials, because they're the ones that you have lots of IAM type process processes wrapped around, but for whatever reason, it might be inconvenient for you to do a full on deployment of active directory.
Even if it's only a read only domain controller, it's still effort. Maybe you don't want to do that in that particular infrastructure as a service environment.
I, I hope that answers the question, but it's something that you really, it, it, it's a picture is worth a thousand words on that one. I think
So. So maybe you just touched the privilege service again, maybe you, so when, when you brought up that slide with the three offerings from there was the server suite, and there was a privilege service and within the service suite, there was also privileged management. So how do these two relate to each other?
Right.
So I think this comes back to what I said at the beginning, where there's actually two flavors of privileged identity management and privileged identity management. Isn't just about looking after a root password, looking after an admin pass administrator password in windows, or looking after an admin password on a network device, you're gonna need those accounts. Sometimes you're gonna need the Oracle account, but 90% of the time, I would say you shouldn't be logging on to those accounts because you lack accountability in such situations.
So what the privilege service does is it actually looks after the credentials for those accounts. It does lots of other things as well. It gives secure remote access. It gives auditing in terms of session recording as well, but it's, it's mostly about securing access to shared accounts, service accounts, generic accounts, whatever you call them within your organization. Whereas service suite is about least privilege.
It's about logging on as Martin or Barry, and then being able to execute commands within the scope of your role as more privileged users.
And of course you get the benefit then of accountability, both solutions do session recording. So the session recording, if you imagine a GoPro camera strapped to the privileged user's head, when they're working, basically it will record their entire session, but the privileged service, for instance, that's through, if you like a jump box through a connecting box, so you can watch and terminate a user session on there, for instance. But the problem with that is that very often people go around it, Unix, admins, windows, admins, they're clever people. They don't like stuff that's in their way.
So they log onto boxes directly. So with the service suite session recording, the ultimate output is the same, but it's done on the end point. So a customer might have a, a combination of critical servers being session recorded and being privileged managed with, with service suite and the accounts, the shared account service accounts, generic accounts for those particular systems being managed by privilege service or having their passwords looked after by privilege service and also for remote access, then jump box auditing is probably good enough.
So it's, it's, they're different parts of privilege management, but they also offer quite a few of the same features possibly in different ways.
Okay. We have one other question here. So if you have more questions, please enter these now. So these other questions, what do typical IA IA implementations look like among your customers today? How are people using ad in those environments?
Yeah, again, it it's, I can only answer it as I see it, which is a, a relatively limited view. It's just the customers that I talk to and the, the prospects that I talked to, I would say that, as I mentioned at the beginning, there was a headlong charge to the cloud after the initial sort of scariness of the cloud. And now we've come back to this.
As you mentioned at the beginning, Martin we're, we're in a hybrid cloud mode, and we always will be to some, to some extent in terms of the infrastructure as a service side of things, we're seeing a lot of AWS, we're seeing some people are going for purely on premise private cloud environments.
Generally though, I would say that the, the infrastructure as a service side of things, the public cloud, even if access through virtual private or created as virtual private clouds, I'd say that's to the four at the moment and it's happening more and more people are becoming cloud first, but that doesn't mean cloud only.
I think, as you were implying, you're still gonna have your apps on premises as well. And the legacy identity and access management solutions do have difficulty handling infrastructure as a service.
So that given the fact that a lot of the access to them is through federated access through, through web consoles and such likes. It might makes it very important as a service and the privilege management side of things as well to get to those environments.
But yeah, I'd, I'd say there's a, there's been a huge uptake in the amount of infrastructure as a service going on in terms of ID and how it's got to it. People are still making their mind up. Some people just naturally say, I'm gonna extend my active directory. I'm either gonna do it as a read only domain controller, or I'm gonna do it as a trusted forest. They'll probably treat the cloud as if it was a DMZ, but there's other people who have found problems with doing that in terms of cost, perhaps, maybe they don't want to deploy windows servers in the cloud for running active directory.
And so on, I'd say typically today, people definitely want to get their ID into the cloud to use it. And it's, it's kind of in between at the moment, lots of people love the idea of the identity broker functionality, because they, they really have got a lot invested in active directory and they don't want to just ignore all that when they go into the cloud. I hope that answered it, Martin. I wandered off halfway through. I'm afraid. Yeah.
I think, I think Barry a very good answer maybe to add to the active directory stuff. I currently currently see a impressively high number of organizations, which are for instance, restructuring, rebuilding their active directory still. So I think active directory will be here in many organizations for a very long time. So I think it's the reality relative we have to deal with. So we gone through all the questions. Thank you very much to the attend is for listening to this group, call webinar and raising your questions.
Thank you very, very much for you presentation and hope to have all of you soon again in one of our upcoming webinars and see you at EIC in a couple of weeks.
Yeah.
Looking, looking forward to it, Martin. It'll be good. Thanks very much.
Bye.
