State-of-the-Art Privilege Management by Design

So good morning, ladies and gentlemen, welcome to our today's cooking cold webinar state of the art privilege management by design. This webinar is supported by beyond trust the speakers today. My name is Matthias. I'm going be presenting first webinar and I will be doing the moderation. And the second part, Brian chapel, director of technical services and APAC of beyond trust will join us. And before we start some housekeeping, and first of all, some general information about cooking a coal as an Analyst company, Ko a coal is providing enterprise it research advisory services, decision support, and networking for it. Professionals. We do this through our research services, where we provide several types of documents, including our leadership, compost documents, comparing market segments. We do advisory notes looking at various topics. We do vendor reports, executive views, et cetera. We do this through our advisory services, like where we provide advisory to end user organizations and vendors.
And we do this through our events like webinars like this, or through seminars, and very important for us. The conferences we are currently preparing the digital finance world in Frankfort. This will be an event covering strategies for developments and changes happening in financial services currently. So everything ranging from FinTech to big data, into new business models between mobile decentralization and the blockchain. Our main event is the EIC, the European identity and cloud conference. And the next one will be held in May, 2017, again in Munich. And we hope to see you there. We are just in the middle between these two and the keynotes of the recent versions of this cloud conference and identity conference are still available on our website as, as downloads. So please consider having a look at our website for all the events using B URL given below. So the guidelines for today are centrally.
So you, as the participants, you don't have to take care of this. We are recording this webinar with the recording and the slide, get slide X going online on our website tomorrow. And there will be a very important Q and a session at the end of the webinar. And you can enter your questions right during the presentations at any time using the questions panel of the software that you're using the go to webinar panel. And please do so, so that we can start the Q and a session right away with a good set of your questions. So every question that comes to your mind's tapped into the,
Especially during Brian's presentation, so that we have a good Q and a session, the agenda consists of three parts. The first part will be my introduction into our today's topic as an Analyst. So it's an overview called building blocks for a fundamentally secure privilege management strategy. Then after some 20 minutes or so, Brian from beyond trust will take over and he will do a deeper dive into designing a multifunctional integrated solution for real life privileged account management. That will be the second third of, and the third, third will be question and answers. We are really looking forward to that. So that's it for my initial words. And I will now start my first part of the presentation building blocks for a fundamental, secure privilege management strategy. Again, it's a good thing always to start such a presentation with, with some figures this time they're taken from the Verizon data breach investigations report, which is a great resource when trying to understand what's going on in security and in data security and in technology there, one important part is the sentence that most data breaches involved, legitimate user credentials. That means that there were access rights assigned to people that then were used inadequately. So 63% of all attackers used week default or stolen passwords. So it's still it's good old combination or bad old combination of user name and passwords that are yeah. Escaping the actual owner of these credentials. And important is maybe something that people typically don't look at that we will look
Take. This is then exploited. So 82% that the compromise happens within minutes and 68% within days. That means that the exfiltration is possible for days up to months. So nobody realizes that that's the key message behind that. And in general, there is a growing gap between the compromise and the detection. And that's something that we will look at later on, in more detail. So when we are talking about privilege management today, there needs to be a good business case for that. And it needs to be a good set of drivers behind privilege management. And these are the typical ones that come to our mind
Important ones. So the idea is to prevent and detect insider threats. So to understand there is somebody within your organization who does something that you really don't want to happen. And of course, when you, when we look at the internals, we also look at the, at the external attackers. So we want to prevent and detect breaches by external attackers for good reasons. Of course, we don't want to show up in the news taker tomorrow, and I'm not saying the word Yahoo today, protection from targeted malware, aiming at privileged accounts. We all know that malware is now designed to get access to privileged accounts, to make sure that you can then take another step within an organization's it environment. So there is malware delivered through mail drive by downloads on websites that is currently really aiming at privilege accounts. So the idea is to make people responsible and accountable for, for their own work and to prevent them as far as it is possible from a technical point of view from happening something that they don't want to happen. We want to improve efficiency when it gets to privilege management. That means that only those people who are really required to do administrative work should actually have this exit rights, but if they need it, this should happen
In general privilege. Management is aiming at reducing the overall attack surface. We will get to that later on as well as this is one of our key design principles. When we look at security by design, but reducing the overall tax service means, yeah, people only have a few entry doors into our system and not many that we don't control a good reason for privilege management typically is that somebody already found out something that is not going on correctly within an organization and it's processes. So regulators, accounting firms, internal and external audit are good candidates for actually identifying privileged management issues. And the last point on my list is that we want to make sure that if we do, for example, outsourcing of administration, to partner companies, to data companies, two external,
That this is handled in a way that is adequate for our processes and that we can actually control that. And that is a more and more important part of privilege management control of outsourced administration. If you look at privilege management processes, we use this term P XM because it's privileged account management, it's privileged user management. So we use the access as a, as a variable, as a placeholder for all the possibilities that could be in there. If we look at these processes, we typically see this, yeah, this flow of steps within such a such a process. I said before people need privilege access and they request it through, through a system that is able to do so. And there is some approval. So here behind that is how do we authorize people to have privileged access? So we don't want to have this guy having rude access 24 hours a day, seven days a week, but we want to make sure that people only get access when they need it and the access that they need.
So privilege invocation is then the next step. So once it has been requested and approved, so the next step would be then to say, the privilege is actually involved granted for the amount of time for the given task. And that means we are, how do we invoke the privileged access? We do it just in time, we approve the invocation and maybe we do this via a proxies or that we have insight into what's happening. And that is actually exactly the next step monitoring privileged access means how and what do we monitor? What can we look at while somebody is using privileged access or is done automatically, how do we identify undesirable behavior? And how do we respond? Of course, this must be clear for the administrator that there is this type of control in place, but it's also a means of protection for the admin.
After the work has been done, privilege needs to be revoked revoked. So how do we do that? We verify that this has actually been taken place. So has this been done adding quickly? And actually then the administrative process is over, but from our point of view, understanding privilege management as a whole, it is not already over because we want to understand what actually happened in that session. We want to learn for further sessions to identify typical behavior, to identify later on non-typical behavior. So the outlier outliers that do something that we don't expect with access, especially if it's highly privileged. And we want, of course detect rope behavior, probably behavior that is not really done by the person who is logged in, but by somebody who has compromised these login credentials and actually the, the most, well, not the most important, but an important step is breach detection and response.
So what happens if you really identify something went wrong during this session, something happened that we did not expect to happen. And it was executed by somebody who has rightfully been assigned with his access, but he did something or she did something that we did not expect. How do we understand the overall threat L landscape and how do we, we define and implement and, and execute adequate response measures ideally immediately. So this is what we think from a, from a general point of view, an important part of, of privilege management as well. So to have some precan responses that can then be started ranging from yeah, control preventing some operations to the termination of the session, if really, so this is what we as an Analyst company think is a good approach for privilege management. Now let's have a look at the reality in many organizations as of now.
So we are in 2016. So something has happened in the meantime. So first steps are really made. There are organizations who are really mature when it comes to, to privilege management. And there are many where the first steps are have been made or just being made. So traditional access management and access governance is in place and management is really understood as something that needs to happen. And what typically happens is identify there are really important systems, SAP systems, databases, everything that has to do with money. These are typically protected through project driven approaches while they don't want to wait for a global approach, but the maturity has to improve. So the reality actually means that these systems are typically still flawed. There, there are that there is room to improvement for the politely. So we have point solutions which do not necessarily scale to the enterprise scale.
We have no automatic integration into overall processes. So security is not only privilege management, but privilege management is an important part of it. So typically if you introduce a new application into a, into an organization, there is no really need to say, okay, I need to implement it and integrate it into my privilege management. So no obligatory onboarding, many processes are still manual and overly manual. What happens if the system changes? Do we really react from the privilege management point of view? Do we analyze ourselves? Do we consume threat analytics information from the outside to correlate that with our privilege management and the analytics that we might do? Very simple thing, but still always the case use of pseudo many organizations in, in, in units environments still use as pseudo. And this is something that is difficult to track and usually gives more privileges than you than you would need.
And one important thing, of course, still people are using shared passwords without adequate measures to make sure that this access then is personalized. So root is the traditional shared password accounting. So this is something to prevent here. And that is what I meant here. Still the use of root or other master accounts, the DBA, the, the windows administrator is for tasks that would not require these access rights. Of course, many organizations would like to have that, but it's not easy to achieve the privileged single sign on. So you have been identified as a user. Me being Matthias has access rights to the administrative account in five systems. So you get from the personalized, single sign onto the access that you need in the actual system. So, and of course, while we are looking at strong authentication for, for many users, so two factor authentication for banking is quite, quite natural today, but we typically do not have strong authentication for administrators and they are allowed to do almost anything.
So there, there are lots of issues still in the organization. So there's room for improvement. So to getting, getting to a better well integrated privilege management with which is our topic today is of course an important part. So there is no overall security strategy for privileged accounts, which is the main thesis of this slide. So room for improvement, not nothing but room for improvement, some more figures, which I actually borrowed from an, from an, from a survey that, that beyond trust executed. But I like the result of that for some definitions of like, because there was this question asked to 700 people within various industries. So how well protected against privileged misuse our tier one business critical systems and is the one so 26% said no protection, again, privileged accounts, and more than 25% of all organizations that have been surveyed here are neither managed nor controlled. And this is, this is something that does not only offer room for improvement, but they, this needs to change dramatically because this is something none of the 26% of organizations can, can afford to, to continue to do.
So when we say security by design as a, as a basis, and we say privilege management, state of the art privilege management by design, as the main topic of this, of this presentation, we are want to have a short look at what security by design actually is. And in its initial phase of security by design was targeted at software hardware development to make sure that the systems are by design free of vulnerabilities, and it's difficult to, to attack them. And this is usually done by best practices by implementing good experiences into the, the design of the, of the system. So key principles are reducing the attack surface. So making sure that there are only a few entry points to the system making security security, or a high security, the default option, nothing that needs to be switched on click now, UN secure, no security is the default and reducing security.
For example, by assigning privileged access is something that needs to be done deliberately, but secure is default that makes security simple, and there are other methods to make security simple, but to make sure that the system overall is designed as simple as possible makes of course, the users, the developers, the architects, much more sure that they can implement a secure, simple solution. The principle of lease privilege, only the access that you need, and nothing else is the security by design principle. And this is something that we all know from access management, access governance only give the people the access rights that they and the backup administrator does not use through privileges. If we have these privileges implemented, we can easily get to second easily, so you can get to segregation of duties. So to make sure that once you have privilege within a business process or within a chain of ongoing transactions, that you only have the rights that only cover one aspect of a process.
So no something like requesting something and approving the same with the same identity, this segregation of duties. And of course, implementing that and integrating that into a system is that means we have a multi multilayer security. So if one measure one control fails, there is a second and a third and the fourth, which actually then catch the issue that has happened because issues can happen happen. And failure is an option in such a system because access changes. So if it happens, the important part is to fail securely. So have an adequate response, even in case of failure. And once we have failed, we need to learn from that. And if we map all these principles over to privilege management and this, the idea behind today's webinar, and I think Brian will have a look at that as well.
The tax surface, if we take the first point, then privilege management is implements this in general, very dramatically because privilege management is a single entry point to privileged accounts. So we reduce the attack surface. So we have to pass through privilege management systems. Applying strong privilege management to new systems is the default. So you make security simple, and it's a security by default. So you cannot implement a system. This is a process. This is a, probably just a policy, but make sure that people cannot administer systems without going through the adequate process through privilege management and using a proven methodology, of course, makes security simple. Once you're used to using privilege management, you are fine because your admins, although they might be revolting in the, in the beginning, they will learn that privilege management is also for their benefit. So again, privilege management can reduce access rights. So only the necessary privileges, least privilege privileges and privilege management can also enforce sod aggregation of duties. And especially when it comes to privilege access multi security, if you have access requests plus session monitoring, plus behavioral analytics, you have three layers of defense.
And even if this is request is approved, this shouldn't happen. You might realize something is going on that you don't want to happen during the session monitoring well defined response teams is something that is a typical response within privilege management and learning from earlier, faces feeding back to constantly redefined a refined redefined detection is also the implementation of the security by design principles within privilege management, getting to a mature approach very quickly. This is based on, on a cooking, a call report and a bit extended. So how do we get to a mature approach towards privilege management? And I hope, and I think that Brian will, will elaborate on that as well, is that we have lots of measures in place that make sure that privilege management is executed adequately traditional management discipline. So shared accounts like passwords and keys, hopefully better keys than passwords.
The enforcement of lease privilege only when needed, as I said, with the request of access rights and approval of access rights for, for an update for a patching, for a backup. So the limiting of scope, the implementation of segregation of duty. So to summarize all this implement strong authentication, as I said before, this is something of importance, especially if I administrators implement application control, make sure that also applications using are handled adequately. It's not only people. It's also processes, it's synchronization processes, it's a monitoring processes and they need access to privileged accounts as well, implement a good application level risk management, understand where to start, which are critical access rights, assure, trust, something that is also part of privilege management. Although it's not a technical and not a, a easily deployable task, just make sure that you can trust the people that you give access by vetting, by understanding who they are and what they do, and to integrate enterprise something that we will see in the next slide. And my final slide before I hand over to Brian is the integration into an overall enterprise security approach and to implement on basis of that, a consolidated monitoring to understand what happens in the whole technology environment in your whole, I, it, and maybe OT environment as well to understand that there is a breach here and there's something happening with a privileged account might be correlated. So my final slide would be an overview of a privilege management landscape that goes
Beyond the traditional privilege management architecture, but implements a good basis for security by design. So if you look at the core of a privilege management, then we have everything that we talked about before. So arranging from one time passwords to privileged single sign on over to session management ranging from monitoring, recording forensics, and more even to
Controlling as a second pair of eyes, the ongoing session, but these are the core features and there are more features currently being designed. And this is something that comes up in, in many solutions. And, and I think Brian will talk about that. It's anomaly detection identifying the outlier and also application privilege management as mentioned before, but the right part is still open. And I think that is important that we use this information and that we extend this information to get to a higher level of security and to get to a more comprehensive approach. So integrating this privilege management into an overall security landscape is something that really helps in implementing a solution that is based on the security by designs principles. So if we integrate with the traditional identity management processes, especially with identity provisioning, that might be an important part. So because an account that is deprovisioned cannot have access to a system, and if this process is working fine, so you
That point and also feed the information into a scene system or R TSI, realtime security intelligence system, to understand what is going on as, as a whole within your it environment. And the last part is integration with threat intelligence. So you consume, and you provide information about ongoing threats about your current security situation and with chapel from beyond trust. But again, short reminder to our participants, please feel free to add all of your questions. And I hope there are some already into your questions panel of the webinars of your, on your screen. We will come back to that later in the Q and a session after Brian's presentation. And so now I would like to hand over to Brian and I'm really looking forward to his presentation of how this really looks in real life.
Okay. Thank you. Thank you everyone for taking the time to, to come and listen to us today. I really appreciate that and just sharing my screen now. So hopefully you'll be able to see my slide deck and let's just get that out of the way, get rid of my panel. There we go. So as you know, Matthias kind of really set out for you, the, the kind of basics around the, the architecture, the general principles behind securing your environment. And I'm gonna kind of dig into a few of those areas in a little more detail, but before we get into that, I really just wanna give you an idea of who beyond trust are. Because despite us being one of the, the leading companies in, in security space, we often find that company people have not heard of us. I like to think of us as the best kept secret in it.
Security, you know, who wants to tell the world what your locks are made of or made by, but, you know, beyond trust have been around for a good while. And I explain that a second, but really here is just a principle of who we are and it's, it's a nice marketing phrase. The, the basic things that attracted me to beyond trust in the first place was that it was about trying to reduce that amount of information that's coming toward you every day, that tsunami of data that you have from the security space and put some context around it. So that, that actually makes sense for your environment and allows you to assess the risk of security within your environment, or, or privilege that you're assigning and, and be able to take good actions, you know, to actually make good decisions quickly. So you can get to actions which are actually going to improve the scenario and above all that, the thing you want to do most when you're thinking about your security environment is make it simple because a simple security model is much easier to manage than something that's massively complex.
So really that's a, that's our mission statement that that's what we are trying to do for you. But as an organization, we've actually been around this year for 31 years, and we have been in the privileged access management or privileged account management space for that entire period. We've originated a lot of the technologies that are out there. There are many companies who've come along behind us and, and have imitated, which is, you know, always a very flattering thing to do. We are still a privately held company. We've been profitable for every year that we've been in operation. So we are, we are well managed and we're not going anywhere. So as a security partner, we're a secure security partner. We've got in excess of 4,000 customers across the world. And we across the world with teams operating outta those, you can provide you with local knowledge and local engagement, a quick kind of view across some of the spaces in which we have customers.
And we use the, the fortune 500 listers as a key indicator for that. So these are the kind of numbers of each of the verticals. So you've got financial, aerospace, energy, utility tech, software, entertainment, healthcare, retail, and communications in there. We are well represented across the majority of those organizations. And many of them have been customers for more than a decade. So, you know, we are in there, we know what we're doing, and we have some of the largest organizations in the world who are using our software currently probably to protect some of your data and provide services to you. So, you know, we, we have a very good pedigree. There, we are not some kind of company that's just appeared out of the, out the ether. Some of you may be aware of a company called C a, which is what we originally called.
We became beyond trust in around 2009. When we acquired a company strangely be called, called beyond trust, top standard before. And we thought that their, their name was a lot cooler than Semark. So we, we took on beyond trust and we think it really does represent where we are, you know, rather than just trusting your users in the network to have privilege, let's go beyond that and let's help them have the correct access into the system at the right times, so that there's less onus on them to, to, to take that responsibility. So I'm gonna work through a subset of Matthias segments that he had in his presentation. And talk about some of these in, in more detail. So we're gonna start with reducing the attack surface. And, and this is a core thing. I always imagine my network like a big bubble, because attacks can come from any direction.
And that attack surface, this is what we're presenting to the outside world. It is, is the visible pathway, our network to the internet. So we need to think about how we control access, where are we poking holes in that bubble to allow access through? And do we know where all of those holes are? So the first thing we kind of need to think about when we're thinking about reducing our attack surface is actually know what it looks like. So this is commonly done through, you know, technology such as vulnerability scanning. And in that you want a vulnerability scanner, that's not just gonna scan your servers or your routers or your firewalls. You want something that's gonna scan all of those things. If it's got an IP address on it, it could potentially be an access point into your network. So routers scanners, firewalls, workstation servers, mobile devices that are hanging on wireless within your environment, even the cloud services you're subscribing to and virtualized environments that you're operating with.
All those suspended machines are potential risk in your environment. So you want to get visibility across all of those systems. And this is something I'll keep going back to is about visibility, about knowing what's out there. It's very hard to prac to plan a, a good journey from a to B where you don't know where a is. You gotta know where you're currently standing. I've been into a lot of organizations where I can look across their tool set that they have implemented already. And the best analogy I have for this, it's a bit like going into their boardroom with a handful of a four sheets and throwing them onto the table. The boardroom table is the attack surface. The tools are the sheets of paper. And by the time they've all settled, you'll find there are sheets by themselves. There are big gaps in between.
Some of them, there are some that are overlaying one another. So, you know, understanding what you've got in your environment and how it's providing you coverage is an important thing, because then once we've got that visibility, we know what we're looking at. We can begin to analyze the business impact of the gaps that we have. You know, it might been in entirely legitimate hole in your network that you need to have there for your core business. You know, if you're a web hosting company having Porwal eight block, 80 or 4 43 block to the outside world would kill you a business. That's a necessary thing. We need to be aware of that. And we need to assess the business risk and impact that exists around having those holes in our, in our attack surface. When we're talking about the vulnerabilities that are identified through that attack surface, you know, what can be accessed through those holes, we need to be able to prioritize those vulnerabilities.
And most tooling will give you a nice list from higher, medium, low, and informational kind of severities of the vulnerabilities, but that really doesn't tell you much. I can, you know, quite honestly, there are a limited number of those vulnerabilities, which have known exploits available for them. Majority of hackers are not gonna spend months, weeks, you know, days, weeks, months trying to break into your network when the next IP address that they can check has got, you know, known vulnerabilities in it, for which they have tools that will just allow them immediate access in. So it's important to remove that low hanging fruit and minimize the risk within your environment. So once you know the severity and you've got a probability that there's a known exploit for it, you can assign a risk value to this. We can now begin to then prioritize our vulnerabilities by risk, get rid of the ones that exist in the toolkits, and you will give the maximum benefit to your environment.
And now when we're demoing this, you'll often see certainly in my lab that certainly about position three or four, when I saw it by risk that I'm into the medium or even informational levels of vulnerabilities that exist within my environment. I encounter lots of organizations where they're working their way through the highs and the majority of the stuff they're fixing is academic. So make sure that you are focusing on the things that are important, fix the things that are gonna be the biggest risk to your environment. First sounds, you know, I know we all know this. Sometimes there are these phrases. We just have to say out loud just to reaffirm them. And as I say, when we're mediating these vulnerabilities and, and discovering these vulnerabilities, we wanna look across everywhere. Our data exists. Really. You don't assume that your cloud vendor is gonna be scanning their environment.
They probably are, but are they looking for the same things in the same way you are for you to have confidence, make sure that the tooling that you are bringing in is giving you that confidence by giving you the visibility across all of the areas that your data exists in and giving you ability to check for those, those vulnerabilities and make remediations within that space. So reducing your attack surfaces is one of the critical first starts as we start to think about implementing security. So we we've, we've dealt with the attack surface. We've got that much better than it ever was. We haven't just built a nice big wall around it. We've actually been intelligent and we're effectively through this remediation across the different systems. We're building walls around every system in our environment. And you know, this is a critical thought process for approach.
We begin to think then about the security of the systems within our environment and security by default. And I always talk about building a solid foundation, and this was the best image I could come up with this. So here is here is our security on the as network on the top with a really solid foundation. And that foundation's made up of, for me, four critical pillars to start with configuration management is one of those areas that I think people neglected to a large degree. You know, it's, it's complicated to build default secure configurations and to maintain those in lots of organizations, you will have gold builds that you use to apply to systems during their, their construction. That's actually gonna provide you with, with stability, but how do you then maintain that moving forwards? How do you ensure that changes that are being made to those systems are not diminishing that base security?
You wanna make sure that foundation is solid and stay solid. And you're aware of, of the impact of these things, because, you know, if you erode your foundation, even if you look at this diagram, if I take off a corner of this foundation, part of that house is gonna fall, and you've gotta think of it in these terms. If you build a good solid foundation, then you've got good visibility, good knowledge, your a point is really solidly set, and we can then make much better decisions as we move forwards. We kind of talked about vulnerability management earlier, but initially there, I was talking about the attack surface on the outside, and I did mention it, but you know, every system in your network thing with an IP address has an attack surface. So vulnerability management inside your network is as important as it is on the attack surface because once somebody gets inside, if you've got an insider attack, then that's the key focus.
That's where they're gonna be looking for further vulnerabilities to move laterally across your environment. Privileged account management Matthias mentioned the, the shared accounts that are out there that we are using, you know, shared admins, shared roots, domain admins, all these kind of things, getting control over those and ensuring, you know, who has access when they used that access. And what did they use that access for? You know, that's fundamental in being able to ensure that you've got accountability within your environment for the privileges that are being assigned and then privileged access management, where we kind of go a stage beyond just managing the privileged accounts. And we're talking about the access that users have within their own accounts. And in that, you know, network systems for, for decades have not really helped us in that space. And I'll come back to that in a, in a few slides to give you a bit more infer about that.
But, you know, as an organization beyond trust can help you in all of these spaces as a single vendor, giving you one platform to actually look at all of this information and, and have a consistent view in terms of risk. And this is another, you know, it's a critical thing. Cause when you are thinking about, you know, communicating with your, with your senior management and I use vulnerability management as an example here, cause it fits quite nicely. Yeah. When you're trying to communicate the state of your environment, if you go to your CEO and you say, Hey, we've got a thousand high severity vulnerabilities, he goes, Hmm, you say, we've got 2000 medium severity vulnerabilities and he goes, Hmm. And I can guarantee you, he's thinking, what am I gonna do next? I wonder what the drive home's gonna be like and how the hell do I get away from this person?
Cause I have no idea what they're talking about. And I know this because there's a 30 year techie myself. I'm thinking exactly the same thing. There's no context around it. But if you can go to that person and say, 50% of the systems in our environment are high risk. The next words after their mouth will be, how do we fix that? And it's also very easy metric to demonstrate progression on. You can show those figures over time, diminishing quite easily. And this is kind of leads me into the next kind of principle that we're talking about there, about making security simple. Here's kind of a thought about that idea of all of the tools that we have in our environment and how they are arranged within our, our systems, the majority of networks I come across, look like this. There are tools everywhere. Half the time.
You know, John bought a tool over there and then left a few years later. Nobody really understands what it does. Nobody really wants to take it out because if they don't understand what it does and the information that that might be gathering is being lost. Each one of these tools is doing its own thing. And, and it's important when you're selecting tools for your security environment to think about tools that work well together that are, you know, have APIs that have, you know, mechanisms to share data so that you can actually bolt them together to build an even bigger picture. You're never gonna find one tool that does everything. And even, you know, it's beyond trust. We don't claim that we are that sort of a bullet. It doesn't exist. You've gotta make sure that you exist. You are taking tools from organizations who recognize that and are helping you in ways of bringing that data together to get you that clearer picture.
So, you know, eventually you want to be looking toward a scenario where your tool set looks a little bit more like this. We know where each of our tools are. Each tool has a specific job and we know what it's there for. And we know how we can use these tools together to achieve the end point. You know, it's a, it, it seems really simple as a thought, it is difficult to do in practice, but you know, once you've got con visibility across things like your, your attack surface, you've got your vulnerability management under control, you've got good configuration management. You can really then begin to see that there are clear gaps now in my environment. And I know where those are. So I know when I'm looking for my next tool where I need to put that on my tool board here and, and, and actually make sure that I'm covering the gaps that I actually know that I have, cuz I've got a good solid foundation about my network environment.
And, and that foundation is, is simple as a brick. You know, we are talking about very simple terms there. Then when we start getting on top for the monitoring, the forensics, the tracking, all those kind of things, we can get more elaborate tools because we know clearly how they're gonna fit within our environment. And when we've got these tools, we need to be when we're selecting these tools, we need to be thinking about what we're actually trying to protect and it's data at the end of the day. I, I think every company is an information company, not necessarily information technology company, but an information company. Having, if you make something, a product, having somebody steal a lorry load of your product, that's an inconvenience. It's something that most companies can recover from having someone steal how you make that product better, cheaper than all of your competitors that could be fatal for an organization.
It's that knowledge, it's that IP, it's that information that we are really trying to protect within our environments. And I think of security in terms of layers. And again, as I say, as not one tool, you need lots of tools that are, that are layers. And I refer to as the onion because you know, nobody really wants to take an onion and bite into it. It, you know, it's gonna make your make you cry and it's gonna make your, your, your mouth feel uncomfortable. But you know, there are very few recipes out there in the world that you can make without a good onion. You know, it's, it's a fundamental base, but as you unpeel the layers of an onion, if you hold up each layer of the onion, it's kind of translucent. And for most of our users, they're only gonna be ever be working through one or two layers of the onion.
So if I think about the onion and we add more and more layers for one or two layers, it's still visible. The users are gonna see some changes to the way they work. And I'm sorry, you know, security by designers are change and change. Unfortunately actually involves things changing. So yeah, yeah. Things are gonna change a little bit for the users, but we wanna make it as transparent as we can. So one or two layers is probably not gonna impede the user in any way, shape or form. And, and we are actually gonna maintain the productivity of the user because of the other benefits we gain through them needing to do assertions about their, their understanding of using privileged accounts. But for the hacker who wants to get in through lots of layers to the center of that onion, you can see on the screen now it's APA.
They can't get all the way through. We've made it really hard. And the majority of your hackers are gonna stop after two or three barriers because the next IP, as they say is got a really easy way in they're into the network. There are privileged accounts everywhere they've moved laterally, they've found data and you are on the news ticker the next morning as having been exploited. This is how you kind of make security work for the users in your environment, their experience pro experiencing appropriate security, one or two layers, not too deep, not too complex, and it's allowing them to, to, to operate, but we are actually stopping the more intense activity. I think I'm running just a little bit behind time here. So I'm gonna speed up a little bit. So once we've got kind of the idea of our, our core pieces in controlled, you know, we've probably got controlled over our shared passwords, et cetera.
We've done our, our vulnerability. We can look at things like lease privilege and now lease privilege is a concept. As Matthew says, we're probably all aware of it from IAM, but this is the first kind of recorded instance of it actually being written down all the way back in 1974, by Jerome seltzer. One of the places he wrote this down around that time was in the Malix operating system handbook. He was one of the architects of that, which was the, the full father to Unix and pretty much every OS that we use today. But it's difficult to actually segregate privilege in that way. What we tend to see as networks have this scenario saying, you have administrators and you have standard users, and that's how it should be. You know, admins run it standard users, do everything else that lasts about two minutes after you turn the system on. And the first user calls to tell you that they couldn't do something and they now need, you know, super user privileges.
We now have technology out there that allows us to, to, to manage this. But we need to think about how we're actually using privilege. I mean, who needs elevated privilege? I'm sure in your networks, the majority of users, particularly in the windows space have got privilege because they needed to install something or they occasionally needed to change their IP settings or some other kind of element within their system. They don't need admin as a person to do their job. It's just individual elements of it. So do they really need it? Well, you know, no, not really. Was the, did user wake up this morning and decide, yes, I want to be an admin. The truth is that the user clicked on something. The user tried to run something and that process or application told them that they needed more privilege or the application needed more privilege.
So the truth is least privilege. When we are thinking about it, we should be thinking about application privilege. And, you know, I can tell you from my own experience, I worked in a major pharmaceutical company with 110,000 users that when we are thinking about least privilege, and we think about users, a big chunk, you know, I can't think about the security requirements of 110,000 users, but within that organization, they had about 2000 applications. So if I'm thinking about application privilege, now my, my, my scope has narrowed dramatically. I mean, obviously much more dramatically than this. This diagram would actually show, but it's certainly reducing for everybody. And, and applications are great. They don't change jobs, they don't get promoted. And their privileged requirements very rarely change. Once you've established, what privilege an application needs. It doesn't change. All you're ever controlling is who has access to that application that privilege.
And the application provides you with a very nicely targeted thing to say, this is where I'm gonna apply this privilege. So if we think about privileged apps, even if you're pessimistic and you say that 10% of your applications needed privilege, I've gone from 110,000 users to 2000 applications, to maybe 200 applications that actually need privilege. I've simplified my security model, many magnitudes, 200 things in reality. I could probably think about that myself. Now, my security team can all be thinking about the big picture and actually then their next decisions are much more pointed and much more capable within our environment. By applying lease privilege. We also enable things like segregation of duty, because I can be very specific about the privileges that I'm actually granting to users. By saying, you can run this application privilege. You can run that application privilege. I can actually start to enable them to do more things than, than you might normally expect.
So specific application privileges, being able to say, you can run this application, but only in this particular context is great. If I add general application privileges to that as well, all the other things that they can do, I suddenly have the ability to have segregation of duty. Cuz I can say that this group of users can do these tasks. This group of users can do these tasks. And those two sets of tasks can be entirely separate. And I talk about it in sets of tasks, because if you think about when we're managing this, when we're trying to think about this in our heads, for those of you who remember Venn diagrams, this is kind of where we're going. We've got a set of all of the privileges available within our environment. And we want to assign a particular group, a subset of those privileges where a lot of tools begin to fail is that you will have those kind of subsets and they will need to be entirely separate with beyond trust.
We realize that actually you need to have sets that can overlap. We need to be able to sign privilege in some bizarre ways at times, but this allows us to model the security that you need in your environment in a very flexible way. By using this idea of sets the toolings work with the set of users, with the set of privileges and with the set of systems. And then you can begin to assign those things across one another and you can have different sets of different access to different environments, all managed within one place all easily visible because it works in the way that we think as human, we call this smart groups and, and it's all a rules based system that enables you to, to quickly and easily manage systems in those groupings. Couple of last things to talk about. So I talked briefly about appropriate security and it's one of the things that I want you to bear in mind when you're thinking about designing, we've got like here, we've got a, a low risk area, our medium risk area, a high risk area.
And we might in there consider end user systems, service systems and sensitive service systems. You don't want the same security across all of those. If you apply your sensitive service systems, security to all of those, you will impede your users excuses to turn it off. You've gotta make sure you are being appropriate. So maybe for end user systems who are just applying some control over what they can do. And when at service I might control and monitor. And when I get to sensitive service systems, I'm doing that even more tightly and actively monitoring them, watching what they're doing live. So this is kind of what you wanna be thinking of. Think of that onion, make sure that each layer is appropriate. It's the least it can possibly be. But then when you add them all, you're actually getting to the kind of control you need for your sensitive service systems.
I'll let you pause this. If you go and review the, the video it's on our website, it's, it's kind of another view of the stuff that Matthias gave you view of it really just shows you that in that survey, it's still clear that even in 2016, today, there are still issues with managing privilege across the environment. And a lot of it is about not realizing what tooling's available and, and making that logical step of building that solid foundation first, rather than looking at the, the new wi thing. So as my final slide here being better, I mean, you start at the top, get visibility, then you identify your objective. What are the things you need to fix for any security project and any project engage? The key stakeholders. It's not just the management, it's the operations teams. It's anybody that's going to touch and affect their work.
You get them engaged. They will come along with you on the journey and it will make your life so much easier. The tool should make your security model simpler. If it doesn't make it simpler, it's probably not the right tool for you. Security is hard knowing all of it is hard. Everything should be making that easier for you. And then you implement that appropriate security, the right security in the right place at the right time. And then we go through the whole cycle. Again, it's cyclical. Security is every day, it's fundamental. It should be baked into your it practices. It's baked into your company practices. Anyway, you can't get into most buildings with that key or a key or something. So it's baked in physically. It should be baked in technologically as well. So thank you so much for listening. We've got some, a little time here for questions and answers. I'm happy to run over a little bit. If Matthias, if we've got some questions that need to be answered, I apologize. I've run a little longer. I am very passionate about this and hopefully that's come across.
Yes. Thank you, Brian. Thank you for these, this great presentation with a great special focus. We're moving over to the, to the Q and a session. And again, the reminder, if you have some questions left, please let us know you run long. I run much longer. So we have only a little time for, for questions and answers. I will start with one question, which is actually quite diametrical to what we've heard now, but from your experiences across the different sectors that you showed in one of your first slides, is there something when you implement security and especially privilege management that are common to all the industries, are there some typical, low hanging fruits when it comes to privilege management and implementing security that people could take as a takeaway from today where to start or where high risk is most probable?
Yeah, I mean, absolutely. I, as I say, cuz I think every company is an information company, the verticals I don't find actually bring a lot of concern. There's regulatory compliance is there. And you know, we have a lot of focus on that and reporting around that space. But when you think about the fundamentals, it's about user access into the environment and making sure that it's appropriate. The two areas that are first places, I always say to people to focus is manage the vulnerabilities, get that kind of attack surface under control as much as you can, because that's gonna be the first egress point or ingress point. And the, then the shared privileged accounts, it's easy, low hanging fruit. You know, tooling can find those accounts. They can take them under control. You've then gotta workflow on top of it that provides you simple access. So that even at the base level, you just know who's accessing.
And when that's gonna give you so much more control, if you're rotating those passwords and you know, you are, you're actively recording those sessions as well. Suddenly you've got another layer of control on that and you are now fully in control of those most vulnerable accounts in your environment, past the hash attacks, golden tickets, all those kind of things become harder if not impossible when passwords are changing regularly. So, you know, you get enormous bang for your buck in, in addressing those two things, things first. And if you think about every attack we've had in the past several years, it's in through a vulnerability use privilege to move laterally and it's invariably some kind of shared privilege like a domain admin account.
Okay. Thank you. Yeah. One last question because we are really getting close to the end of the hour. Yeah. I I've presented on my slides. The idea of integrating privilege management into an overall security concept from your experience in, in all, again, across the industries and across all companies, is this an idea that is already accepted and already implemented? Are people really thinking from a more holistic point of view?
I think I'm certainly seeing more movement in that in this year. And certainly the back end of last year, you know, we've opened up relationships with companies like sale point to actually, you know, kind of have that end to end visibility across identity and access management. You know, not just about what you're assigning, but how you're assigning it and being able to prove that you've made those assignments and more and more auditing and regulatory requirements are expecting you to have those kinds of capabilities. I think as we move over the next few years, we'll also see a bit more convergence between it operations and it security because those two things are intimately linked as well. And that's gonna help in bringing that coherent identity picture across those, those companies and the companies that get in first. And I'm always key on this, you know, at the end of the day, do you want to get into this and, and do it before it becomes an actual requirement? Or do you wanna be, have your competitors watch you run around, fixing it when it does become a requirement while they carry on doing business. So, you know, it's be preemptive in these things. They are coming, they are gonna benefit. So, you know, be, be a leader in this space because it's gonna make your company that much better when, when the, the proverbial hits the fan.
Okay, great. Yes, we've been that's that was lots of, there might be some more questions left, open. Our mail addresses are on the starting slide of this webinar and the slide will go on live tomorrow. Latest and contact information is of course available for both of us through our companies. So if there are any other questions left, please get in touch with us. We will be happy to answer them. I would like to thank all participants of today's webinar. Of course, especially I would like to thank Brian for taking his time for sharing his exper experience and expertise in this security area. I think that was a great look also into real life aspects of, of securing your corporate infrastructure. So that's it for today. We're getting to the end of this webinar. Thank you all for joining us today. Have a great day.