Good morning, ladies and Tren. Welcome to our equipping, our call webinar, closing the loop between audit and action. Meet compliance needs with privileged access management. This webinar is supported bys. The speakers today are Indy Harris engineering directors and me Martin equipping unfounded principle Analyst, a call before we started some quick information about copy, a call and some housekeeping information on them. We'll directly dive into the topic of today. Copy a call is an international Analyst company. We are head for in Germany with offices and Singapore. And in new, in, in the us, we focus on information security at, in access, risk management compliance and all areas concerning the digital transformation. We support our clients with our research events and advisory research includes for instance, our leadership compass documents events includes our webinars, but also our conferences. And we do advisory in a strictly when a neutral way, for instance, supporting and strategy, roadmap, definition, tools, trust, and other topics.
We have a couple of upcoming events, so we will do our consumer identity world tour again this year, September in the us in October in Europe and then November in S Singapore. And we will do our cyber security leadership summit in Germany and the us as well. And then next year in may, we will have, again, our flagship event, which is European identity and cloud conference, which will be held in Munich. Some guidelines for the webinar. You are muted central. You don't have to mute or run with yourself. You're controlling this. We are doing a recording and the podcast recording will be available by tomorrow. And there will be a Q and a session at the end. You can enter questions at any time. The more questions we have, the more likely the Q and a session will be. So once you have a question trust, enter it in the questions area to go to webinar control panel, which usually is at the right side of your screen.
Having said, this, let's have a look at the agenda. So I will talk a little bit about approaches towards restricting privileged access and sort of open the, the theme regarding why you need this for audit for risk mitigation and for information security. And the second part in Andy Harris, we'll talk about privileged task management as an approach for efficiently restricting privileged access. And he will also talk about how to monitor and record administrative activities and identify outliers and anomalies. As of said, after that, we will do our Q and a. So that is what we will do today. And so we have some terms in the title of this webinar, and I think it's very important to have a little bit of a differentiation and clarification for some of these terms. So we have this term of compliance and compliance factually means that you meet the laws and regulations audit. That means that you are doing what you say you are doing and that you can historically prove it. So the audit comes in and you prove that you did the things as you plant. And as you declare you on the other hand, the action is what you actually do. So it might be a little different from what you tell the auditor, particularly it might be bigger than what you trust do for audit. So action can be significantly more than trust doing what the auditor wants and trust fulfilling. The compliance needs.
Audit compliance obviously are tightly related. But the important thing is, and that I think is the important really the important point for today's webinar needs are compliance in our audit, make you secure. They can help you in making you secure by implementing some of the right controls and other stuff, but factually it doesn't mean that you are necessarily secure enough. So checklist compliance is not enough, but taking the right actions can make you secure, will make you sicker. So it's really about going beyond compliance and audit. And that's even more important in a, in a world where we have changing requirements and changing requirements, which factually really affect privilege management. So we have this area of threats and attacks, and we all know that there are sort of ever increasing attacks. We are facing as an organization and the days where we said, well, we don't know, are we, we are not attacked.
These days are passed. I think the only thing is, do we know that we are attacked or don't, we know that we are attacked, but we are, but we are under constant attack take, we have different deployment models to deal with. So how do we protect the cloud? How do we deal with privilege management, elevated privilege in the cloud? How do we protect access of managed service providers to our services? How deal with, do we deal with things? How do we integrate all this? So for instance, our trying to move legal life cycles with what we do in privilege management. And finally we have ever increasing requirements regarding compliance. When we look at privilege management, we also should be always aware about that it's that was where it started. That was very much this focus on, on sort of privileged account management part or the shared account management part, which is of the theist that was very much focused on, on personal versus shared account and managing shared accounts.
But that's not all we have on the other hand, the situation that we have, people who might use their personal accounts and no shared account at all, and might have highly elevated privileges. So people with high privileges in the SAP environment, operators on the windows system and other stuff, and we need to understand what they're doing. We need to get grip on that. We need to control it. And that is where then the sort of second essential element of privilege management, which is session management comes into play. So privilege management factually is bigger than, than trust share accounts. And I have created a very simple graphic, which sort of looks at it because we have let's look at the, the middle tier, so to speak. That's sort of this common shared accounting. So we have multiple persons which have access to one account, which they, which has certain types of entitlements to access the system.
So it's a shared account. Obviously there's a challenge in that because more than one person knows the credentials, so we need to do something around it. This is where privilege management started and that's still important thing. So never shared credentials, obviously. But we also have this situation also very common one where we have a user who uses his account with certain entitlements to access a system. And that system uses another account with certain entitlements to access another system. So it might be here in the middle, the, the weapon, the application server, and then the backend, it might be a database. So this is the typical technical or functional accounting, but we also have these individual accounts. And that's the bottom line then here, which have entitlements to access a system, which just have highly elevated account privileges, but are using individual account. So that is what is happening.
The challenges, things are getting worse with all these external threats these days. So factually it can be that individual person, but there also can be an attacker who takes control of these accounts of these persons and which in fact, then act with this account and at attack our system. So by just managing who can use that account, we are not done because it might be that Martin Kuppinger seems to use that account, but factually Martin Cooper's account got hacked and someone else is doing it. So we need us to understand, is this what is happening here? Really what we expect to see, or are there Analyst in there, other things we need to look at, we need to go well beyond this account protection and also session recording towards understanding what is happening. This leads us to what I call the privilege management life cycle and the privilege management life cycle.
So in my perspective is we, we need first need to, to understand the challenges we are facing. We need to identify the British accounts and the risks we need to protect. So this is for instance, the duration shared account password management, while identification might be done. This discovery part, we find in many of the solutions. So where are all these accounts? Then we need to monitor session monitoring, for instance, to understand what's happening. We need to detect what is going wrong. And that is where also technology comes into play. How do we detect, how do we understand that our things are going wrong? The animal is the outlier, stuff like that. We then need to respond. For instance, shutting down sessions, restricting access, things like that. And we need to use all that knowledge gain to improve what we do and to get better and better and better.
And as I've said, the challenges that the world is changing. And so when I look at how typical attacks are running today, I think this becomes very obvious because we have sort of a red face where someone creates an attack. This gets dark red because once this attack is starting, it's first it's undetected. So there are things going on. And no one knows because only D one who created the attacker who created this attack really knows what he's doing. Then someone detects this, the analyzer starts, there's a patch. So we are getting from yellow to green.
The patch is developed, it's distributed and sometimes it's even deployed. So in some cases, things are going better. So if you have an automated patch deployment, like you have, for instance, the windows operating system, or so it might be worse. If you look at how long it took half of the MUN servers to be patched regarding the house lead attack. So things can be good or worse. And over time, the number of unpatched systems is decreasing. The challenge obviously is we have a certain period of unknown attack patterns. So there are things going on that typically affects privileged accounts. So many of these attacks affect privileged accounts because attackers always are going for the highly elevated privileges. And then we have a known attack pattern. And at this area of unknown attack patterns, we need to better understand what is happening here. So protection can be only done by identification of anomalies.
And later on, we can use sort of the standard technologies. So we need some advanced technologies, more the behavioral analytics in the broader sense where we understand things which are different in the behavior, changes in the behavior and traditional things like signature based and malware. They only become effective in the later stages. So particularly with respect to the use and app use of privileged accounts, we need to implement adequate technology. And our target always must then be using such technologies also to minimize the unknown events and detect incidents. So we have this collection, we have correlation and analyzes. We use some advance analytics for detecting this. And at the end, this should help us to end up with some black events, the known incidents, some white ones, where we notice our regular events and a Cray area. So this sort of the pure bit of events and incidents and our target always must be to minimize the Cray area.
So the Cray area is where our problem really? Yes, because for the white area, we know it's uncritical. We can react automatically in an automatic manner it's required, but frequently we don't need to do anything for the black area. We know that there's a problem, but we know the problem. We can react in an automated manner, or we at least know how to react. Maybe manually on that. The gray areas, where we need people, where we need people to analyze it. And this is where our problem always turns because we don't usually have enough skills and people skilled people to do all that work. So technology must help us to reduce it, to focus us on the critical things. That's where the action comes into play. Again, helping us to minimize this, analyze it with good information provided. This is the way we need to move forward. So the other element of the entire stories we, as, as we know that at hackers are always going after the highly privileged accounts. Obviously the other element of it is how can we restrict what such accounts can do? So restrict the elevation of privileges. There's a what in, so the what perspective is, what can a privilege user do? So can he access a system or not?
What can he do in that system or around that system? And what's which skill does he need to do what he needs to do? So we need to, to look at restricting that, making it easy and always, you know, when, when people say we need, oh, I need administrative privileges. Most people don't need administrative privileges. Most people don't need shell access. They just need to do certain tasks. And we need to look at how can we restrict what people can do. The less they can do the less their accounts are at risk. So why obviously staying compliant, enforce, and least privilege. So give them all the entitlements. They need mitigate a security risk. That's what I've been talking about over the last couple of minutes, split responsibilities, for instance, across service and support levels. So again, that's something which is important. If everyone has she access and can do a lot on the system, it's hard to enforce the responsibilities.
And it factually goes back to least privilege. Although although only define access for MSPs when you're working this piece and also simplify operational activities. So if you have two, many possibilities, this doesn't help you doing your job efficiently. So if there are only certain tasks you need to do, and you only can do these tasks, life is simpler. So how can we do that? We can do the best share account password management, which is very cost grain. So it restricts the access to account. We can do that by session monitoring, which is more fine crane, but frequently there's no restriction in real time. Sometimes there's some detection of what is happening in the session. And then we can raise alerts and we can react and stop block the session, et cetera. But it's, yeah, it's limited in what we can do. And anyway, it would base we based on you have a, you can do a lot of things, but if you do the wrong things, then we alert and react or later on, do some forensics.
It's not really restricting what people can do. Obviously we always have an element of identity provisioning, access governance. So where we go for individual accounts and assign them only the entitlements they need. So we implementation of duties, controls and all that stuff. This is absolutely mandatory. There are some tools around privileged elevation management, where, which then for instance, can restrict the commands. You can execute on a Unix or Linux shell, et cetera. But this is very commonly, very intrusive to systems, limited to certain platforms and types of access. So it's not the broad solution. And there's this approach we find very occasionally, but we find I'm sure Andy will touch on that, which is around task management. So really defining individual tasks, which can be executed, but not more. And these things together are the things which help us to not only comply to the audit requirements, but to also mitigate security risks, getting more secure. So we definitely need to think about think beyond the pure sort of audit checklist and compliance checklist. We need to be better to protect our corporate ground tools, the information, the systems we have with that I hand over to Andy and Andy will talk about privilege, task management as one approach for efficiently restricting privileged access. And he also will look at monitoring, recording administrative activities and identifying outliers. And anomal beliefs with that. I hand over to Andy and it's your turn.
So good morning. Hopefully I'm gonna show you how to never feel the again. And I'm gonna whip through this presentation at a far speed because I might jump out and do some actual demonstrations of bits and pieces. So it is required to tell you who we are. We are a, we do these things, the task management, the access management session recording and the behavior analysis. That's that is that quick. So ten second recap from what Martin said is that compliance means that you meet the laws. It doesn't make you secure. Audit says that you can do what you say you do, and you can prove it, but it doesn't make you secure and actions of what you actually do. And those are things that really do make you secure. Martin also brought out some other useful things about technical shared and personalized accounts. And if I, hopefully I'm gonna, I've got some notes here.
I'm gonna try and pick up on those as I go through, I've added an extra slide from what Martin said, and that is to always assume that your end points are dirty. So always assume that the environment that your users come from is dirty. It's been compromised by malware, and always assume that your user has been compromised. And if you work on that basis, you know, your, your security mindfulness will, will drive you into secure states. So the approach that I'm gonna look at is the auditor methodology. So what does auditors, what do auditors look for and how we gonna provide in the answers that they need? So it helps if you think like an auditor. So the auditor wants to know what your policy is. They'll pick a random example and ask you to prove it. And typically they're gonna say, who did what, where and when, and this is kind of their opening gambit, and they'll choose something reasonably simple and they'll expect a hundred percent result.
Then they'll pick a probable case. That's slightly under business as usual. So you proof you've got a backup who knows the passwords for your sands would be a good example. In my view, nobody should know the passwords for sands, but NAS boxes and sands are notorious for not having their passwords changed forever. And the other one is the ice busy accounts, virtual machines use. And just as a little side thought, if you ever wanna break into an organization, if you were able to steal the backups of the virtual machines, you would have a gold mine. So sands and NAS are important things to protect. And then they'll look for edge cases. So for example, if you've got a full database backup and you've got the incrementals, you know, what, what would happen if you tried to recover a database when one of your database cycles was missing, because it was corrupt, that kind of thing.
And then they go around looking for weaknesses in particular, what some of the things that we've come across is that some of our customers are not only being audited by auditors that are coming from the big four accountants, but they're coming from insurance companies now because you've got cybersecurity insurance and the cybersecurity insurances are going far more for weaknesses. And they'll be asking questions like, well, what can third parties do on your systems? How can you see what third parties are going on, are going on? And they're, of course they're expecting a hundred percent coverage. And they're looking for any weaknesses because they're looking to increase your premium, which I guess is obvious business. So when it comes to privilege access management, there are two types out there. There's the proxy type, which is what we are. In fact, we might be one of the rare proxy types and there's the vault types.
So you'll be, you are kind of, you are aware of the kind of password vaults and things are out there now would evolve. You have to remember that you are revealing your credentials all the way to the desktop, which you really need to consider dirty. And the person compromises, we said before, and with a vault, your credentials can be used concurrently. So whilst you might reveal the U the credentials to a user and they can use it for a legitimate reason at exactly the same time, they can use it for a nefarious reason, which is really important with a proxy. And I'll, I'll show you some architecture in a moment, the credentials, they never go anywhere near the desktop and they never go anywhere near the person. So not only can you not fish the person because they can't find it in the first place, you can't use malware to extract the credentials and they can't use the credentials to make a connection that they're not allowed to because they haven't gone. So they can't make the lateral movement and lateral movement. If you look at the way that a tax buildup is really important. So when you've got a, a proxy, the other important thing is there is no method to bypass session recording. You can't go, oh, I've got credentials. I'll run off to another machine and use those that haven't got session recording. You are effectively forced into this session recording environment. Yep. Right? Okay. So this is the architecture of our product.
Not that our products not, I really wanna go into our product. I really want to go into auditing and all the rest of it, but there's two lines. There's a top line, which is the SSO line, which takes you through to the machine. And the bottom line is the task engine side of what we do, which is where you are implementing tasks on machines. And I'll, I'll go into that a little bit later, going back to what mortgages want. You have to prove your policy. So this is a way a method of Le of laying up policy. And if we look, if you can see my mouse moving, these people are allowed these SSO methods and these tasks on these systems at these roles. And because you are in a proxy based environment where you are funneling the connections through high speed proxies, there's no method of bypassing.
So the policy that you see here is the policy that's absolutely defined across the top. Here is a couple of other interesting things. And that is whether you are forcing session recording or this one's not ticked, but there's another one here for change tickets. So change tickets is what you said you were gonna do, or what you said needed to happen. And if you implement the change tickets here, that creates a, a really good extra layer security, cuz then that's, that's like saying to the hacker that not only have you gotta take over somebody's machine, so you've got to know their identity. When you go and attack the machine, you need a change ticket to perform that attack. So I guess you could raise your own change ticket. I wish to steal your database, but that's, that's not gonna work. So there we go. So that effectively says what I've already said, really, that you can't bypass the policy connections can't be made out of, out of band.
And here's another interesting thing if the data that your privileged access management system and the data that your systems are recording back to your scene is different. Any discrepancy between the two that is absolute proof of an attack, okay. There's one exception to that. And that's break glass. I might talk about break glass a little bit, but I'm, I'm gonna watch the time. Cause I know I started at 10 18, so I'm gonna skip, I'm gonna skip out of this for a second because I just want to, I want to skip over these sides quickly. So this is a situation that you start with where everybody knows the shared accounts. And a lot of people will tell you that shared accounts are a bad thing, but having been in this business now for I've been doing this for about eight years now, I've beginning to realize that shared accounts are actually quite good things.
And in fact, when you go on to personalized accounts, which is what policy and compliance tell you, you need to do, they, they get worse. It gets it's. You create a situation where you create way too many privileged accounts, and then you can't keep track of them. And you gotta think about when people leave and when people join and all the rest of it. Anyway, that's the situation before privilege, access management. Everybody knows every password, every password's human memorable. And it's really easy to compromise. Once you've got something like our PX M platform or any privilege management system, the password should all change to be very complex. And these are actual example. Actually our passwords tend to be 128 characters long unless you in a windows environment, windows, doesn't like 'em that long. And then what you're doing is you are mapping the identity of these people coming in, and then you are pushing them out to roles, which is quite neutral.
So that means that you can have one person that has, that has access to multiple roles on a machine. And that's important because most of the time, when you go on a machine, you just wanna do a quick tech out just to see that everything's working. And occasionally you want to go onto a machine and make a change. So the difference in roles is quite important and being able to prove if we go back to that policy thing there, if we go, if we go back there and you've got these slides here and you've got different roles and in another policy, you've got a policy that says, this is an auditor role, or this is a check-in role. You can tell which role was used to do, which job which is quite useful. Anyway. So there we go. This is just a little bit of an aside because because privilege access management is one part of an eight sided story of getting everything sorted and playing well with scenes.
In other words, delivering all your information to system monitors is quite important because what we have to do is as we pass connection through us is say that this identity used this role on this system for this task and task could be something they did that come online or task can be prepackaged, which we'll talk about. You have to be able to pick out unusual behavior. And I think this gets really interesting because having looked at this for a long time, we have realized that it's incredibly easy to create false positives. And the only way that you can really pass any audit is with the meta knowledge of what was going on at any one particular point in time. Because in the real world, you have a whole bunch of people from your different teams, from your help desk team, from your CI admin team and from your DevOps team.
And they've all got potential access to high privileged accounts. In fact, we call that latent threat, but on odd occasions, people have to actually use that access. And this little example that we're looking at here is from our own system. And it's from about a week and a half ago, when a VMware virtual switch went wrong and spewed all of the VMware management traffic onto our main network and caused the massive a storm. And then our infrastructure come, DevOps chat, Peter Koal here. He triggered, you can see these little red dots. He triggered these little red dots left right and center. As he went round to systems that he wouldn't normally use trying to work out, which one was misbehaving. Now of course in this world, it generated all sorts of alerts. But as I sat on my desk, I could look over and see that Peter was a struggling manfully with a up storm.
So although it's generated alerts, that's important. And we think that over generation of alerts, and we've seen a bunch of products out there, we call, we turn them pixie dust, actually that say, as soon as you do something unusual, generate alerts is not a good idea. And in fact, with machine learning, what happens is you have one of these products and you get to the end of a month and you do some month end things and it generates things and you get to an end of year and it generates things. And it's not until with machine learning and AI, you tend to need, you know, tens of thousands of incidents before you get a proper view on things. So we think auditing along with alerting is a much better way of doing these things, especially when the volume of privilege users in a typical organization is between, you know, 20 and a thousand.
Who's performing. Yeah, who's performing what actions on what this diagram here, which you, you can't see in detail, just play it that you can't see in detail is a really useful graph of who does what on our system. So this column here is people, this column here is tasks. And this column here are the systems. And what I find quite interesting is that the top two users here are business users interesting in the all in there as well. And Tom's in there. But what this shows is in our environment with our own privilege management system, it's actually our business users running more tasks than any one of our admin users. And there's that Peter down there, you can see there. Well, I'll take you a little bit deeper into some of those.
Yeah. Policy is under scrutiny, then you practice a hundred percent proof is what you need. Ah, and then this slide helps us. Let me just slide this down so I can read my own slide. So this effectively is, is the flow through our privilege, access management privilege, task management products re represented. So you've got at the first stage, you are enforcing identity. Then you are taking action, right? Making the SEO. So, or running a task enforcing policy with the right time, the right permission, the right ticket, for example, then giving it least, least privileged by saying, you only use this report to do everything. And then finally on the systems, you log everything. And remember the it's getting logged twice. It's getting logged once by us on the way through. And it's getting logged again by your system. So there should be a correlation between the two.
I'll that again? Ah, that's just a simple reminder that when you're in the cloud, you haven't absolved responsibility and this kind of takes some GDPR elements as well, because it just reminds you that it's always your data, but it depends on how you've bought your cloud service. How much of the security that you need. So for example, if you've got a cloud data center, the only security that they're really providing is the hypervisor and the San, and you've got everything else. Another way of putting that is to say, if you've already got security vulnerabilities in your on-premise implementation, when you lift and shift it to the cloud, you'll be pleased to know that those security vulnerabilities move with them as well. And then when you go all the way to cloud apps, which is, you know, if you are using Salesforce or something like that, the most important part security is administration.
So if you've been adding lots and lots of temporary users and giving them passwords and then not clearing out the users, when they move on, that's where a cloud cloud, implementation's gonna give you some problems. Okay? So going back to this compliance idea, an auditor might ask you what can an individual do? And this is, this is mine. So this says that I'm Andy Harris, I'm a member of these profiles. And I've got access to all these machines via profiles using those accounts and whether or not they've been recorded, whether or not I've even used it. So there's a difference between here at the top. These are systems I've actually used. And then this lot here, if you like, is that latent threat because there's systems that I do have access to that I haven't used. And then at the end of the year, somebody should show, well, why is Andy got access to all those machines?
And it could be for that once in a while problem, when there's an art storm or it could be that I should have that access taken away from me, but there it is. It's, it's, it's shown in clarity for you there. And then look at it the other way round. So you take from a system. So you say here's a system, here's a device who can access it. This set of people here can access via these profiles and whether they have or not. So again, we've got a list of people at the bottom here who Luke won Freddie doing in there. We've got a list of people down the bottom here that have never accessed the system. And then you've got a recent system queue there, and that shows you who's been issuing some tasks. So if you want to reduce the search space of audit, the best way of doing it is to take away all of the logging access that you can and rebuild that as task-based access, which makes life a lot easier.
So prepackaged tasks, I'm gonna show you one that we do here, actually. So this is our own example. We've got a phone system that is connected to the internet with a whole set of phones on it, and it's got its own internal firewalls. And then we've got a, another firewall. And then we run a task engine that then delivers out to our users down here. And we've got a set of business users that need to know what phone calls were made at what time and to who, because they have to be checked back against GDPR records. So we have to make sure that we've, you know, we've got permission or we've got a relationship with somebody so that we can make a call. So that means a business user is having to reach into a database. That's on a machine that's behind two firewalls and you definitely wouldn't want to give 'em a privileged account into the phone system because all sorts of odd things could go on.
So we, I could actually show you the details of some of that in terms of code. Other things that I wanna talk about are things like known vulnerabilities because it's alright us saying, oh, you mustn't use.net one and you mustn't use Java and you mustn't use this and you definitely shouldn't be using windows 2000 or windows server 2003, but there's applications always in businesses that just can't be dropped. And even, you know, today's dependencies become tomorrow's legacies. So we have a system that we call map server, and that's effectively like a security cell where you stand up a copy of all of the dependencies that you need to run a legacy application on there. You put the legacy application on there. So that means that when the auditor comes along and says, right, okay, got net two or every version of window seven, that's running got net two that haven't got these patches applied instead of having to search through your entire inventory of systems or your entire state, and possibly even worry about your third parties that are coming in and managing the application, you know, that those machines are in one place and that they're double firewalled off and they have their policies locked down so they can't be updated.
So that makes that's that's that auditor thing of knowing where things are and taking the vulnerabilities that you can't shift and put them into a safe security cell.
And in fact, this, this is the attack cycle here. This entry malware escalate privileges data searching exit, which is it's exactly the same process that Martin described earlier, zoned and isolated. So summing up if I've got this right, if you are using proxy based, Pam, you cannot bypass the policy. You cannot bypass the session recording so that the records that you have are the truth and the policy is the truth. In other words, nothing happened outside of that. If your seems recalled any difference to your pan system, something else is going on, somebody's using an unauthorized account tasks. So making something like restart a print queue, or return call stats from a PBX, restart a SAP server, restart as enterprise. If you make them wrapped up into tasks, no user that uses those tasks needs direct SSO. They can't have errors. They can't issue errors because they can't mistype things.
And everything happens faster. Haven't talked about business efficiency or return on investment or anything like that, but that's that area, the oh, bit of spelling error coming in, spell it, Chris question, coming in there, the audit process that right, the audit process gives you valuable insights into both security and business efficiency. So for example, we have, this is coming off one of our interfaces and it shows you how much user engagement you've got. So you can see that Peter and Dan have used the system an awful lot. And you can see that they've got a lot of device connections and a lot of tasks and things like that. We can look at things like our session analytics, where we can see what channels have been used over time. What tasks have been used over time. And we can see these peaks that happened during that a storm. And because we know that there are peaks during the a storm, we can then apply our own human intelligence to the data intelligence that the product's given us. In fact, I've think I've got, that's the corporate PBX, that's the template library. And I did have behavior analytics running at the moment, which is posture latent threat and the classic suspicion over time. And if I rock this round a little bit, I should find that these, yeah, these points up here were Peter from the actual practical example
And
It is 10 42. So I believe I've done my, I think I've just delivered 24 minutes. I've got one minute left, but I'm ready to take questions now.
Okay. Thank you, Andy. For this insight full presentation, let's directly move to the questions. And I said before we are done was the first two parts of our webinar today. And right now move to the Q and a session. So if you have any questions, please enter these questions into the area questions and then go to webinar control panel. We already have a couple of questions here and I wanna go through these. So the one question is what happens to credentials that have been revealed through break class? What can I tell my auditor?
That is a very interesting question. Break glass is break. So bright glass in our world is where you are going to make a connection that is outside the proxy. And we think whenever you break glass, it means that there's a set of credentials that are going to be used that are out, that that potentially will be used outside of any session recording. And that's where we feel that you've got to step in and make sure that those credentials get life cycle management, the moment that you don't need them. So then you have to look at the reasons why you're break glassing in the first place. So typically you may break glass because a machine is broken down and that machine is restored from backup, and you might need to move back into the past. Now, if that machine is safely up on the network from a backup, you won't need to break glass because a serum can say that machine is in the past, move back into the past, pick up the old passwords, regenerate them up to the new ones. But if that machine needs to go away or needs to be worked on somebody's desk or needs to be worked on any side of a DMZ, you will need those passwords. So in that break glass zone, you're not being recorded, which is why you should treat the, that you should look, especially at not breaking glass and pushing everything through tasks and everything, the connections.
Okay. Thank you, Andy. There's another question here. How can I see if accounts are created outside of the Pam solution? So I'm personally, I'm a big believer of having well defined application onboarding process and a tight integration of trying to move a lever process of identity provisioning and privilege management. So really to tie these things together, but you probably also have some specific view on this question. So how to deal with accounts and to see them if they're created outside of the Pam solution.
Yes. That, so what we do is you, in fact, this, this question goes all the way back to what you started, which was, was the tech shared and personalized accounts. And if somebody goes off and then creates an account on a system that you're not aware of, then you can mark that account as unapproved. Could you pop the, is my screen being showed at the shown at the moment, Martin?
No, it's my screen, but I can quickly handle back to you a second. Here you go.
Okay. Show my, so I'm actually gonna dive off now into a serum and I'm going to go into accounts. And what I'm gonna do is I've got a whole set of accounts on this system on actually there's many systems here. So I will go and put in, let me just put in PBX and see what happens on PBX. So here we go on PBX. We can see that there's a set of accounts that are absolutely fully managed and they are Jack, Tim ack, and they've all got root access. So these are accounts that have been created by the privilege access management system, and then could be destroyed at the drop of a hat. Okay, we've got a password known account. So that's the root account which is known. And then we've got a set of another set of fully managed accounts. And then we've got one account down here that's approved.
And then we've got a whole bunch of accounts here that are not approved, but I happen to know that most of them were, most of them were, are part of the phone system. So what I can do is I can change states to approved, let that happen and I can change MongoDB DHDP and this one I can change it to approved and what will happen now from this point onwards that's postfix, which is also approved. So what would happen from this point onwards, if any account is now created, that is not created by the pan system is found on this device. And this device is scanned every four hours for new accounts. It will erase, it will raise alerts for you. And again, at that point, you will have a complete tie up between what your SIM system says and what your, and what your Pam system says. And if there's any difference somebody was using the account that they shouldn't be. If I take this away, one of the slightly interesting things about our system is that you get a massive number of unapproved accounts, but I should just tell you that's because if you look at all these accounts here that are unapproved it's because we run about 250 different Pam systems here. And quite often there'll be accounts that have been created by another pound system. So we're not really bad lads after all. We, we do know what we're doing. Okay.
Okay. Thank you, Andy, for just demonstrating what you intended to say, and you already talked about alerts, you touched alerts. And so that fits well to the next question, which is, can I get alerts and specific rules or use on devices? The answer probably. Yes.
Yeah, yeah. So, yes. Yeah, you can. And then you've got your email subscriptions down here and then we've got a bunch, we've got a bunch here, so, sorry.
I'm back to the other slide. So we are currently not seeing your system.
Oh, okay.
It probably doesn't matter that you, but the example that I'm looking here is there's a chat called mark Redmond here, and it generates an alert whenever he makes a connection to a power strip. And why are we alert on that? Why are we alert on that? I don't know, but we were, obviously, I actually, I do know why we do that. Cause mark Redlands, our test engineer, and he probably wants to see that he gets an alert every time he accesses a power strip. One of the interesting things that we do, our Pam system by the way is we use it to access a power strip, to power down all of the systems that we don't need overnight and then power back up again. So we are using our power system as a major contribution to energy conservation. There's an idea for you.
Okay. The last question I currently have, so if there are more questions, please enter them now. But the, the final question I currently have is can I use task this, my third priority health desk? And do I get stats or statistical information on that? Do you wanna demonstrate something or just talk?
I think I'll just demonstrate a few things. Okay. Actually is, is my screen still being shown? Yes.
Okay. The, the, I think the example I've got here at the moment is not, is not a third party, but if we consider that our internal sales force are effectively a third party compared to our dev system, there's a, there's a few things I can show here. So this screen that you're seeing here is generated by elastic stack. If people are familiar with elastic stack, and if I go to task analytics, I will go down and show you the, this display that we saw earlier. So the head of our internal sales is called Lauren and Lauren runs get call stats against our PBX on a very, very regular basis. And then we might want to have a look at that and say, well, you know, what is that task? And as an auditor is another little question we can look at. We say at an auditor, how can you prove that Lauren, who is a business user, hasn't got unreasonable privilege access to the PBX system and to show you that I will pull out a template.
So in this template here, I hope you can read this. I've got a high resolution screen. So it reads beautifully for me, but I'm just going to slice over here that I've got this thing here, this command here. So this is a command that runs an asterisk query and it is provided with a database username and password. So what you, what you don't want is that username and password being embedded in any script or any program and beautifully is not here. It's, you've got SQL username here and you've got password. And these things are substituted in by the Pam system, which is actually doing this over an SSL protected SS H link, which is quite useful. And then furthermore, you probably wanna look at this asterisk query to see that it's not doing anything that it shouldn't do with the password. So we should look for that, which is I got that.
I pulled that up in GitHub here. So here it is. It's got the password using get pass. So that's come off the command line. Now that's a good secure program in practice because instead of just reading off the command line, you use the function get pass, because that makes sure that it's not revealed and it's not kept in the logs. The, you know, the message logs of the, of the Linex system. And no matter what happens, whether we successfully get the connection or whether we fail the connection. The very next thing that we do is null password. So this is an example of secure coding practice. And then if we want, we can go and expect the rest of this program. And we find that all that this program does is an SQL query. So we can go back to our, we can go back to our system here.
We can go to profiles here and we can go off and find PBX admins, PBX statistics. And we find that Lauren is not allowed. See this tool section here, it's completely blank. These four people are allowed no direct access to the PBX system at the access level of route. But these four people are allowed to do get call stats on this system with the access level of route, which is effectively what you need to get the initial login. Oh, that's the other important thing about the database, the database that never exposes itself to any port other than 1, 2 7 1. So that's how that lot fits together. So that, yeah, I, I know that was quite quick, but that is the chain of what happens in a task. And it's actually quite easy if you think about it, you know, if we need to change these users and we need to grant somebody else access to this task, if we need to say, oh, Jeffrey, you know, you need, I won't do this cuz Jeffrey shouldn't have it.
But if you say Jeffrey needs to add this task, I've only gotta hit the same changes and they're done. Then if somebody leaves, I've only got to remove them from this table. It's it's that easy. If I then make more complex tasks, because I wanna say, get tasks for this section or that section, I can add these down here. And that granularity is really quite useful. And you know, I could even come along and say, well, really what I wanna do is I wanna make sure that these, you know, these are only, these are only in access to, in a particular time window or something like that. So I can do something like this and say, right, okay. You know, you can't run this task outside of working hours or what have you. That's not a good idea. So we won't do that.
Okay.
Okay. Right.
Okay. Great, Andy, that was a very detailed explanation for that question, with that. We are we're anyway done with all the questions we had. So I think we, we delivered really a lot of information to the audience. I just wanna quickly hint on related research. So we have a couple of not only these three, but we have more, these are three samples of relevant research in the context of this webinar. So have a look at these and with that, I wanna thank you. Say thank you to you, Andy, for your presentation and the insights you provided. I wanna thank say thank you to all the attendees of this school and call webinar. Hope to have you back soon in one of our other upcoming webinars. So thank you very much and have a nice day.
Thank you very much, indeed.
