Oh, good afternoon. My name is Paul Simmonds. I'm a fellow Analyst with Ko Cole and joining me this afternoon is Peter Jeni, a product manager from bait. So that's welcome everybody. Welcome, welcome everybody. And you know, good afternoon if you're in Europe. Good morning. If you are in the us and it's probably past your bedtime, if you are listening in Asia. So we're gonna kick off this afternoon's topic is preventing data breaches, moving to a modern approach to breach avoidance. Before we kick off just a little bit about Ko Jaco. If this is your first webinar, we are an enterprise it research advisory, decision support and networking Analyst company. We provide research services, advisory services and events, just like this one.
And before we kick off, just to say that we have two things coming up for your calendar in the new year, the first digital finance weld in, in Frankfurt, and that's the beginning of March. And then of course the, the major Ko Cole event of the year, which is the European identity and cloud conference to be thoroughly recommended in Munich, in Germany in the beginning of May, 2017. So without further ado, just some guidelines, you are muted centrally, so you don't have to mute or unmute yourself. We are recording this webinar. So there will be a recording podcast recording available to you tomorrow. And there is Q and a. So you have the ability to add questions via the go to meeting web panel. So please fill in those questions and we can pick them up and we can then answer them either during if it's appropriate or we will save them to the end.
So the agenda for the next hour is a two parts and then Q and a, I'm going to talk a little bit about breach history and some issues and solutions to consider particularly about communicating risk of the board. And then Peter is going to talk a little bit about how to do risk within your business, how to visualize risk within your business and, and provide some deep visibility into potential threats and fingers crossed that that will include a live demonstration. So let's start, hopefully everyone on the call understands this one breaches are not good for business. It is as simple as that, some really good sources I've, I've included the URLs to them. So you can go and read them offline, but 93% of breaches are presentable, are preventable. And, and ultimately the bottom line is that the steps to mitigate the cost of breaches that do occur are not taken. And 59% of users admit they would likely not do business with a company that suffered a data breach. In other words, data breaches are not good for your public profile. In the UK. We have a major tele telecom provider who suffered a breach talk talk. They lost somewhere in the region of a hundred thousand of their, of their customers when they suffered a data breach. Ultimately these things are not good for business.
And I don't need to tell you this. I'm sure breaches happen every single day. This is just a, a list of data breaches out of Wikipedia of the, and it's only the 200, 2016 high profile data breaches that actually sort of get notified. I had a quick look before this at the list of data breaches and cyber attacks just for this month or last month. Now, of course, November, 2016, 456 million known records exposed, which is quite scary. And it's worth pointing out that actually probably 415 million of those came from the breach at friend finder. But of that for me really interesting was 15 million of those outta the 415 million were supposedly deleted accounts. In other words, the users had deleted the account, but when the breach happened, the bad guys still got the deleted accounts and that's quite scary and brings into question, I suppose, the whole right to be forgotten under G you know, that's the exist today, but will exist even more in the future.
When GDPR comes into force other high profile breaches out of November, Michigan state university, 400,000 student staff records, the Royal Navy in the UK had to notify 134,000 sailors whose personal information was compromised with the stolen laptop, 600,000 risk of identity theft in the us out outta the department of housing and urban development. They happen every single day. And what's the response. Well, the response is we are getting to the point of, you know, what we call breach fatigue. Yeah, it's just another data breach, isn't it. And we get them day in, day out. And unless it's a really big high profile breach, now it's unlikely to reach the mainstream until I actually went on. Even though I live in the UK, you can probably tell by the, the British accent, but even though I live in the UK and I read the BBC news online until I went to the specific page that actually recorded breaches, I didn't know about the breach against the UK Royal Navy.
It's unlikely to reach the mainstream press, unless it is a really big high profile breach these days. And you know, what happens is it the standard default for most large corporates? And I've worked as, as global CSO for a couple of large corporates in my time, the PR instructions are no comment which actually can be quite detrimental. And we'll talk about that in a minute. And if you go to the board and say, well, you know, we, for a long time, certainly, hopefully not recently, but certainly back in the nineties, security would play the fear, uncertainty and doubt card. They would go to the board and say, the sky is falling. Doom will happen. And you tend to get what we refer to as the ostrich reflex, the board puts their head in the sand and says it hasn't happened to us yet. It's unlikely to happen. And anyway, what would happen? Do we, you know, we don't have anything important or worth stealing.
So, you know, that's that, that is the, that is the reality out there. So what are the, what are the common failings leading to a breach? Well, here's the, the, the 2016 Verizon data breach investigations report. And as you can see, what is going on, where do, where do the, where do we get the breaches from? Well, you know, the, the big one out there is hacking and malware, but climbing really rapidly social engineering and climbing also because of the complexities of our networks, these days, error, misuse, and the leveling offers, you can see there sort of, you know, physical issues and environmental issues. We are seeing a lot of malware out there and a lot of hacking that that's going a lot, a lot of automated tools that, that are going out there. So, you know, what's, what's causing this well, first of all, you know, the hacking and the malware, we have a lack of patching.
It is as simple as that, we aren't patching our systems. It's difficult, it's hard to do people aren't doing it. And therefore, actually, most of the hacks that are going out there, if you actually drill down into the details of what people are being hacked by, that are leading to breaches the malware and the hacking that is going on there are, are attacking, known vulnerabilities that have been out there for ages and ages. So we have a major lack of hygiene. And of course, you know, as we've all seen in the press, we have the internet of things coming up and internet of things, devices, especially, you know, when we're talking about, you know, kids' toys that are now internet connected, the odds on them being updateable even automatically updateable are very few and far between. And it's probably got a very low grade unpatched freeware operating system, probably Linux in it that is easily exploited either now or very, very soon in the future when someone discovers the whole in it, is that likely to get patched.
The answer is no, it is very unlikely to get patched. Well, the common one, we stolen passwords and credentials. We all know about poor password management. And the last one, a lack of timely detection. The expectation is that when people do the reverse engineering on a breach is that the attackers have been in the network for a significant period of time. And the thinking was, especially with the high profile breach, such as the Sony breach estimates of how long the bad guys were in Sony's network, doing reconnaissance vary, but anywhere between six months and a year. So they've been around for an awful long time. We are not detecting them. We're not finding them from a business point of view if, as the technical side of things from the business point of view, ultimately it security strategy generally for most organizations out there, not that not necessarily the large organizations that have full-time security teams and CSOs, but that is a, you know, that's a 1% case. Most organizations don't have an it or a security strategy that matches the business needs. And generally, the reason for that is there is a total lack of board focus on it, security, and the board's concept of risk doesn't match an it or a security measure of risk.
So here's the problem. This is what, you know, I've called the risk discontinuity. The board ultimately is there to make money for the company. So, you know, they look at risk and say, what risks will we not accept? What risks are we prepared to take or need to take to deliver on our strategy? What risks are the stakeholders prepared to bear and what to what level, because it is all about investment risk to make money at the end of the day, and what resources are required to manage those risks it, on the other hand, not security, this is, it are, we've got these systems. So what risks are we taking? Well, how long can we put off patching? Because patching systems in a lot of cases is really difficult, especially if you're running a 24 by seven operation, you know, can we deliver projects on time and on budget?
That's the risk, you know, will key vendors remain in business. If you look how many key vendors that we had 20 years ago, and how many still exist, you know, the majority don't and ultimately applications, can we support the key applications and meet the business need? And there's the discontinuity that you, it looks at risk one way. And in long ways, it's very binary, which I suppose you would expect from it. The board is, is a lot different it's financially based. And what I found when I was a, a global CSO, is that actually it security sat in this sort of middle area, which is, you know, can I determine, can I be the translator that translates it risk into board risk and vice versa? So you are translator sitting there. And the hardest job I always found was actually having the tools and the data that I needed to go and communicate risk to my board in a form that they could understand. And remember, you know, as much as we talk about risk and there's a lot of discussion about risk and there's lot of, lot of discussion about communicating to the board. The one thing I would say here is that a board's risk appetite and how you translate it to your board is down to individual CU individual company circumstances. There is no one size fits all solution. What works for their company over there really well may not work for my company and vice versa.
So how do we communicate to the board? Well, the first thing is, do we, the cost of security, cuz if you don't understand the cost of security, you can't communicate at the board because ultimately the board talks in pounds, dollars, euros, whatever they are counting. You need to understand the value to the business of what you are doing and you know, any, anyone who says, well, yeah, you can't measure the cost of doing security. I would say, well, you shouldn't be a CSO. Ultimately that is my experience. You can always translate it. Every other part of the business is required to show return on investment in pounds, dollars or euros to the board. It and security should be no different. You need to understand the cost and the savings of not doing security. That's another way to look at it. If we didn't do this, what could it cost us? And yes, there's a fudge factor in there that says it costs, you know, we could have a major breach. We could just get hit by umpteen viruses and spend a lot of time doing cleanup. It does have a, to it, but ultimately you need to turn risk into money and then finally measure everything. The old adage, if you can't measure it, you can't manage. It is incredibly true.
Back in, back in the nineties, my, it was one of my, my global CIOs mantras. She used to say, if you can't measure it, you can't manage it. It's not hers. It's, it's used a lot in a lot of industries, but ultimately you need a way of measuring what you do to prove you, what you do has value. Also what you do has little value because there's stuff we were doing 20 years ago that we are still doing, because we've always done it. You need to stop that. If you are measuring, whether it has value, you can turn around and say, actually, we've got better ways of doing that. Or we've got this other tool that does this better, or we can consolidate tools and get rid of that. And quite often optimizing what you have or saying, actually, if I can have this tool or expand the use of this other tool, then I can replace this one, this one and this one. And actually quite often you'll find it comes out to a zero sum gain. I don't have to go begging to the board for extra budget.
And the last one is, understand the limitations of what you do, particularly coverage, especially in these days of cloud your data, your corporate data and the risks of a breach of your corporate data. Now comes from a lot of different places. It could be a cloud breach. It could be a supply breach. It could be a joint venture breach. It could be a laptop going lost is in the case of the rural Navy. It could be the hackers, get into your network, but understand where you measure, what you cover and, and also understand is that what you need to cover in today's modern global networks that we actually put together. So how do we communicate this to the board? Well, the first one is generally the board, unless you are an Amazon or an eBay or somewhere like that, the board do not understand technology for the most part.
So always use analogies wherever possible, understand the business goals and tie your projects, your initiatives, into solving a business goal. Because if you want to get funding, then you need to understand just going in with the fear, uncertainty and doubts, self won't work, because they will do the ostrich trick on you, put their heads in the sand and say it hasn't happened to us yet. Why do we need this? So understand how you're going to deliver against their business goals with your initiatives, recognize why the board is asking a CSO or a security manager who whoever you are to be in their meeting, you need to align business goals with the security message. You need to deliver a consistent message. It's no good going in one month and say the sky's falling because of this and going in the next month and say the sky's falling because of something else until you've actually solved.
The first thing you told them about, then you don't deserve to go in and tell them about something else. And then being, you know, be able to answer the classic boredom questions. How secure are we? If you can't answer that one, you shouldn't be talking to the board because you will get asked the question. You know, what's our security posture compared to our peers is the other favorite one that you get asked all the time and finally, you know, what gaps are do we have? How do we fill them? And what will it cost? What's the return on investment?
So finally, before we get Peter plan to be breached, here are the full pillars of, of modern information, security prevention, detection, mitigation, and instant response. And the first thing to re recognize. And the first thing to tell your board is we will have a breach. It is as simple as that, it's not a question of I'm going to protect you. Absolutely. It's a question of, we will get breached. The question is how badly a potential breach necess states, a business wide response. Do you have roles to find other people trained? Are there alternatives because when it happens for real, you will have people away on sick leave in the wrong part of the world. I had a major breach, instant I, which happened on Christmas Eve quite a few years back now. I happened to be on a, on holiday in South Africa with my family when my phone went and trust me when I didn't take a laptop with me because I was on a holiday for two weeks, it was incredibly difficult to actually be part of that, that whole instant response that did affect the entire business.
When all you are sitting with was a Blackberry on a poor internet connection in the middle of, of Cape town or outside Cape town. So do you have alternatives? Have you had a plan? Has it been tested? Has it been, first of all, tabletop tested, has it been tested and are all the key players actually involved? Because the question really is, is who should be involved? Normally the plan is written by it or it security or information security when actually the key players in an incident are going to be your senior management, your legal people and your PR people. So if they are not involved in a writing the plan and B table topping the plan and then testing it, then you have a major disconnect. And that's what most people find it was written by it because it seemed to be an it thing when actually it's a business thing and it's the business people who actually need to write it and be involved with it. So in conclusion, you need a solid strategy to prevent breaches.
Is it communicated to the board in terms of risk? And most people don't have a, a solid strategy, which is why there's the question mark on there. Can you detect the problems? Can you detect the issues and the breaches across everywhere you have either data and or legal liability. Do you have a strategy in a plan how you're gonna mitigate it? In other words, minimize in the optimal way, is there an instant response plan for when it happens? Has it been practiced, are the key players, including senior management in that team? Yeah. If your CEO was not involved in your exercise, then you have a problem because when you have a major breach, it's the CEO that is going to be in front of the cameras. Is there planning for non-availability of personnel and escalation and has it been tested and tested and tested again, simple as that, he says, so that's my bit, I'm
Now going to do a,
We're gonna hand over to Peter
And we are gonna try
Live dangerously for a live demonstration, Peter, over to you.
Thank you, Paul. Thank you for the very insightful talk. I really liked when you and how you emphasize the importance of risk and being able to manage risk and see risk and communicate risk to, to the board and other stakeholders. Because in my experience, that's how profe security is done professionally. You have, it is always thinking about risk. There's always thinking about the biggest risk and always thinking about how to mitigate those risks and choosing which risks to, to mitigate. So connecting to that, I believe there's quite a big risk, quite a gap, quite a big gap in the security posture of most large enterprises that even the board is not available aware of. And in those scenarios, the first possible thing happens when you don't even know that you are at risk. When, when you don't even know the risks that you are taking.
And that is the case of privileged users. That is the case of system administrators, the ones who have access to your core infrastructure, the ones who have to manage your core infrastructure. Now they pose a really large risk first and foremost, because they have to have access to all of these systems. They have, you know, they have to, they're the ones who have to wake up in the middle of the night to bring a side back from backup. They're the ones who have to be able to install patches really fast in a maintenance window. It is a must for them to be efficient. And as a result of that, you don't want to, to make them jump through different hoops. You want them to have access to what they need access to. But on the other hand, that's a problem because that means that they would also have access to sensitive user data.
They would have access to critical parts of your infrastructure. So it's a risk and you want to regain control or what they really do have access to. You want to be able to revoke access if they are transferred to a different department or they leave the company. So that is one of the big challenges here. The other is maybe the simpler than, than signing access. And that is simply knowing what they're doing. And when you're talking about SA means, when you're talking about administrators, it is not such a simple thing to solve first and foremost, because they tend to walk off the beat and path. They're not using the, the interfaces, the UIs, the APIs that, that are designed to be audited, where activity is designed to be recorded. Whether they're looking under the hood, they're connecting to the servers via SSH or RDP via talent.
That's their job. But auditing that kind of access is not an easy thing to do. And if you don't know, if you cannot measure, if you cannot see what they're doing, how would you be able to manage that? And how would you be able to see if they're doing anything risky and a little top of that? How do you ensure that they cannot erase their traces? You are talking about admins. We have the capability to turn off logging facilities. We have the capability to turn off different kind of audit measures that you implement because they have full access over the services that they're managing. Just think about stress. Like if you, if you read the news today, and even yesterday, there were a couple of articles about an it operator working for Expedia who used his access to access data from the CEOs and other senior managers computer, and use that for inside their trading.
And in that case, these admins could use their privileges to their own use. They could misuse their own privileges, but also it's not only the case of, of this currently malicious employee attackers know that these people have the well proverbial piece to the kingdom. Their account is a really attractive target to attackers. Most of the large scale data breaches that we can read about in the news at some point involved, hijacking the account of, of a privileged user, getting the credentials of a privileged user, either through fishing or using some exploit on their endpoint computer or by some other means. At some point, the attackers gained access to one such account and all these thing combined mean that privileged users mean a huge risk to, to your enterprise, which is a thing that you on one hand want to measure. And on the other hand, want to have the option to mitigate.
So this part, when I will try to show you this inaction, so what I will do is that I will show you how C admin could this user privileges. And for the sake of the presentation, I will take the account of my colleague, Daniel BOGO, and hijack his account. And we'll dig around on a server and steal some data mean it's hypothetical situation, but it is pretty close to how an attack would go down. So I'm logging into a server as an administrator, as a route user. And as I've said, I'm hijacking the account of my colleague Daniel. Now, here I am. If I take a look at the server, I can see that, well, there is one other user logged in while he's been idled for quite a while. So that's not that interesting. Now I don't want to be discovered. I want to raise my traces.
So the first thing that I do, and the first thing that I can do, me being an administrator on the system is to check if the logging subsystem is working, if my actions are being logged. So I'm checking the status of the logging subsystem. It is indeed working. So yeah, why not? I should just stop this. So let's check if it was in this stopped. Yes, it was in this stop. Let's, let's actually remove historical logs to make sure that even the fact that I logged into the server is erased. Any, any evidence of that fact is erased. Let's just check if it is indeed removed. Yes. The log files are removed and logging subsystem is not working. So nothing is logged from this point onwards. Okay. So, but I also happen to know that this server contains it is actually a database server that contains user information.
So let's check it out. Let's see what kind of information can we find here? Let's login as the database admin and let's take a look at the database. What we have there. Yes. We have one table on this server, which is called users. Let's see what kind of columns it has. Well, it seems to be a pretty interesting table. It has username addressing credit card information in it. So that's pretty interesting. Let's see. What kind of data do we have here? Yes. It seems to be valid names, CMA address, and the credit card numbers. So if I can steal this piece of information, probably I could sell this database on the black market pretty easily. So let's just do that. Let's dump this database. Let's steal this database. Let's look out, let's dump the database to file the users. Yeah, that's the one. Yes. Let's just zip it up. There you go. Let's copy to my own computer.
Let's give it a, a fine name, which will not raise any suspicion there. Yep. And let's clean up after myself first. Let's just remove all, all files that I've created the zip file, the, the SQL file. And let's turn the logging subsystem back on to make sure that there's no evidence of, of anything that I've done. So let's restart this. Let's check it's status seems to be running. Yes, it is indeed working. So we are all good. Okay. So let's just do a quick recap of what I I've done in just in the course of, well, four short minutes, I've logged in using the hijack credentials of my colleague, Daniel. I managed to steal a lot of sensitive user data credit card numbers and contacting formation. And I managed to do that without any chance of being discovered later on, I managed to erase my traces.
All of this means that I, I have managed to put the company at a huge risk without, well, putting myself at a large risk. What can we do with that? How can you ensure that? How, you know, if something like that really happens in your network? Well, there are two big challenges to solve. First and foremost, you have to be of error that something happened. You have to have the information. And well, as I described before, that is not a trivial task. I could, you know, disable the OS subsystem recording this data reliably is, is a challenge that needs to be solved. But also if you ma, if you solve that problem, then comes the, the problem of well measuring its risk automatically. Because even if you record all administrative access to all critical service, that would result in you having large amount of data.
And it is great to have that data for forensics analysis, for threat mitigation, for the scenarios that Paul have described, when you want to figure out what has happened, to be able to fix the system, to be able to close the doors close, remove the back doors that the, the attacker left within the system bottom, to be able to proactive, you have to find some way to automatically measure the risk of every activity in real time, so that you are able to intervene as soon as possible and not just after the data breach happen. So let's see, how can we solve those challenges controlling and monitoring. Somebody who has access to that server in question is, is not easy or solution to that is to be independent from that server or module or monitoring appliance, which call shack on TrollBox is a network based appliance that is placed on the network installed on the network between the computers of the administrators and the servers, the services that they're managing. It transparently, intercepts the traffic, the administrative traffic, going to these service and records, everything, and is able to control the traffic as well. So let's see, actually the session I've just done was recorded by shark control box. So let's see what, what was recorded about my activities.
Let me switch my browser and let's take a look at the recordings we've made. You can see this session here, which is the session that I've just performed. Let me just zoom in very quickly. You can see that a lot of information was recorded about this session. It recorded. When I, when did I start my session? When I finished my session where I use protocol SSH, or if I use protocol RD. In fact, in this situation, I use SSH it's recorded that I authenticated as user Daniel Bargo, but on the remote server, I, I, to the remote server, I logged down with the route user and it also recorded a couple of other pieces of information about this, but the recording went deeper than that. We did not. Didn't only just record metadata, rather we recorded what happened within that session. And that's where it becomes really, really interesting because you remember what was the first thing I did?
The first thing I did was to disable the logging subsystem. And this is what you can see here, even though logging was disabled OED and out logging was disabled. We still have a recording of what has happened. We still have a recording of every single command I issue, including the fact that I disabled the ODed subsystem. And we can go even beyond that, actually we don't only have the comments. We don't only have metadata. We have a video like recording of every single keystroke and every single character that appeared on this screen. This is what you can see. Now, this is the very same session that from a couple of minutes ago, and you can see, well, how the attacker in this case, me disabled logging and dumped all the database. This is a very powerful piece of evidence. I think it could be used even, even board presentations, but definitely in court. Actually, we have seen such recordings used in court because it is so easy to show. This is what the attacker, this is what the malicious insider did. These are the comments they issued. This is the thing they saw on their screen. And well, here is how they stole the data.
Okay. That's great. We have the data for forensics investigation, but as I've said, that's, that is by itself, not enough because simply there's just too much data. I mean, you can see that there are hundreds of sessions here, every single R every single day. And, and it's just a test system. The real life scenario admins produce hundreds of sessions every single day. And to be able to assess the risk level in real time is a really powerful thing and allows you to, to become preventive and proactive instead of just being reactive. And that's why we went beyond just recording. And that's why we analyze every single session in real time. And I will try to show you that as well. So let's take a look at, or behavior analysis module, which we call blind spot, because it is covering the blind spots in your security.
Let's take a look at the session of my colleague, Daniel, whose account I've stolen. Now you can see that based on his activities on his previous activities, we have built up a behavioral profile for him. We know when he is usually active, we know that he is coming in, usually at around nine 30 and goes home at around six 30 UTC. We know that these are the hosts that he's typically using. We know that these are the coms that he's typically shoeing. And we knew a couple of, we know a couple of other things about Daniel. We know, for example, that he's more likely to use the RDP protocol than the SSH protocol. So he's likely to be windows, admin, not unique admin. Now, what you can see down here is that how each and every one of his activities are compared to his baseline in real time and how a risk score is assigned to every session.
And this includes the, this very session that I've just made. So this is the SSA session that I've made, and you can immediately see what kind of risk analytics we do here. We, we see that there were some things about this session that were strange, and there were some other things that were somewhat okay. And altogether we assigned a risk score of 83 to that session out of hundred, which is a somewhat high number. Probably this session would be worried to be investigated. So what was wrong about this session? The activity, the point in time in which I did this activity was pretty normal. I mean, it was within the normal activity hours of Daniel. Now, the host I connected to that was more unusual. It looks like Daniel has never connected to this, this target server, nor did his peers ever, ever before. So that's quite strange.
We can go, go and take a look at individual data points about this activity. For example, we can see that the fact that I did this activity on a Workday was pretty normal. I mean, Danielle is working both on weekends and Workday's a bit more on Workday. So there's nothing strange about that. But the fact that I was using SSH that is highly unusual because he's more likely to, to use RDP. He has to use some IA SSH as, as so that he, he never really used before. So that's, that is also strange. But again, as with the recording, we, the analysis, we are also able to go beyond just metadata and we can take a look at different comments that were issued within the session. And you can see the very same comments here. The, I should do stop belonging, subsystem. The, I should dumb the database.
And you can see that these commands are compared to the baseline of Danielle in which there were some pretty basic commands, like network configuration of things and those kind of comments, but definitely nothing about stopping the logging, subsystem, nothing about removing files and nothing about accessing the database or dumping the database. And even furthermore, we also analyze the typing dynamics. We sew within this session. So as it turns out the way you are typing or the way you are moving, your mouse can be used to identify you pretty well. And that's why we are analyzing the individual key strokes and every single flick of the mouse within these sessions. And we compare that to the behavioral baseline, the biometric baseline of users. And in this case, it could identify that it was in fact, me and not Daniel, who was typing within that session to there's a lot I could talk about, I would love to talk about or algorithms, but I want to leave some time for questions.
So at this point, I would like to end my part demo and conclude with, with a quote from the same Verizon data breach investigation report that Paul wrote some numbers from, because I really do love this quote because I think it summarizes pretty well, how someone should relate to privilege users and administrators. So you should really love them. You should trust them because they're the ones who, who, as I've said, keep your service running. They're the ones who keep your business running in, in most cases. But also you have to realize that their credentials are extremely attractive targets for attackers and the result of that, they pose a huge risk. So you should monitor and let me analyze the hell out of their activities. Thanks a lot. And I think now it is time for us to accept questions.
Fantastic, Peter, thank you. Thank you very much. That was brilliant being, I'm an ex techie. I definitely appealed to me and it just shows, you know, this is what the bad guys are after. Isn't it, it's, it's privileged escalation ultimately, you know, that's absolutely absolutely. That's what they're going for every single time. It's admin, admin, and admin. So very simply, if you've got a question to ask, please use your control panel that you should have on the go to webinar. There is a section there for questions, get typing your chance to ask, ask questions, either myself or Peter. I I'll kick off with one because it occur me when, when we've I was watching the presentation is that obviously you were using SSH, which is what, you know, best practice recommendations says you, should you be using a secure shell as opposed to Telenet, which as we all know, is everything clear, including the username and password, but so, you know, best practice says we should use SSH, but yet you were monitoring every single keystroke that was going on on that SSH session. So, right. Where, where were, where were you monitoring to achieve that?
Well, I, we were sitting on the network and well, we, what we do there is that we perform well, well controlled man in the middle attack against these protocols. So in that sense, we have to have to hack the protocol to be able to monitor it, but that, that there's a very well control thing. And it also enables us to, to have quite a bit of a control over what we allow there. For example, we can allow only certain level of the protocols to, to be able to prevent people from using old versions of SSH or even prevent them from using Telenet. And also that enables us to, to control the keys. So I was focusing on monitoring. I was focusing on editing these sessions, but also there's a lot of use in being able to control these sessions and being able to act as a jump host. So if you have a separate entity that controls the credentials to these target servers, then you don't have to give them to these individual users. And again, to be able to play the role of the server for these clients enables you to do that.
No. Lovely. Thank you. And, and just a, just, you know, a comment on that, it goes back to that discussion with the board of, do you understand where your critical data actually is residing? So have you had that discussion? You know, what is critical there there's stuff that obviously you are legally obliged to do. So in this case, you know, there were there's, in your example, there was credit card information. Therefore you are liable under PCI. You are probably liable under, you know, data protection and in the future DDR. So, you know, that system was probably fairly obvious in terms of, yes, it needs to be monitored and protected, but there will be other systems within your organization that actually you won't necessarily realize the importance of what it contains as an it person or a security person without that discussion to the board and discussion to your senior management.
And it's identifying those critical systems. Certainly when I was chief information security officer for, for AstraZeneca, we used to have a thing we called the critical set. Yeah. They were the critical set of systems that if there was a problem with them, it was share price affecting simple as that. So, you know, you can't monitor all 137,000 IP addresses that we had on our internal network, but you can give your attention, love, and attention and focus to those critical systems with, within your organization that can do that. Can do harm damage, especially if they get breached.
Absolutely. Now, just, just going back just for one quick question, speaking about your, your CISO experience. So you mentioned as a CISO, you have to be ready to answer the well quite trivial question of how sec you are. We and I am dying to learn about how did you answer that question? There's so many ways to answer that question. So many wrong ways to answer that question. And so many good ways to answer that obviously. And I'm really interested in what was your typical answer to such questions?
Well, the, the answer, the answer was it varied over the years. So when we first started getting asked that question, which was back in 2001, 2002, at that point, the only thing we had at our disposal to measure that was vulnerability assessment. And so we started off and I got one line on a PowerPoint. So on the quarterly business reviews of which my boss, the global CIO had to go and attend and present at. He got one slide along with all the other, you know, business heads. He got one slide for all of it. And therefore I got one line on his, on his slide, which was how secure are we? And so we looked at it and we said, how many vulnerabilities on all of our systems across all of our systems? Do we have where the attacker could walk in and get admin with no special with basically with either very easily or known common tools?
How do you answer that question?
Well, you
Tell them, how do, could you enate those services? Yeah, we
Did. We enumerated it. So we, we literally was systems that Sy the percentage of systems that were not vulnerable to admin escalation out of our total system. So we had 60,000 systems at that point. And when we first measured it and, and my CIO looked at me and said, I can't give this to the board. And I said, look, we can only get better. We had 22, we had 22% of our systems that were secure to that definition.
Wow.
In other words, I think over yeah, 80% of our systems were vulnerable to a really simple privilege escalation attack, and it forced the business to get better in what we did.
That's, that's a really scary figure.
It isn't it. And okay. That was 2001, 2002. And, and it progressed over time. So we got, we got smarter in, in how we measured it, but at the end of the day, it goes back to the old adage. If you can't measure it, you can't manage it. And believe me, it didn't stay at 22% very long, because if you are presenting that number to the board every quarter, it better be going in one direction. And one direction only absolutely be careful of be careful. You know, everyone says, we want board attention. I would just say, be careful of what you wish for.
Right.
So, so let me ask you a question. So how do you turn risk from your system and, and, you know, fantastic. I, I looked at that and thought, oh, I could really use that in, in my old, in with, you know, my old career and it absolutely fantastic tool. How do you take that? Or how do your customers currently take that and, and turn that into stuff that you can present to the board?
Oh, well, that's a lot, depends on the boards we are talking about. You said that most of the boards wouldn't understand technology. I, I think that is, that is slowly changing as, as more and more companies start to become technology companies or companies that are highly driven by technology. They start to understand more and more out of it. And that means that we can put more and more tacky things in front of them. But I think on one hand, just the fact that they can talk about this huge gap that they do not have covered when it comes to privileged users and how this solution fills that gap by, you know, recording what they do by doing risk assessment or what they do that is a really powerful and very simple message you have, you know, 200 C means we have access to every single piece of information that you have, including user data, including your IP.
And now all these people are being monitored and all their activities are being analyzing real time. So that's pretty powerful and pretty simple, but it's like binary thing, but a pretty strong proof of return on investment. Now, if they're willing to go deeper than that, then we can show, you know, the things you expect top and average risk level over time, top incidents over time, top incidents in last number of highly scored incidents in the last months or last quarter, those kind of things can be counted and can be displayed for them. We, we have those reports built into the product. We have integration to, you know, all seems Splunk and all these kind of things that people would use for reporting. Another good thing they could present is how, what kind of savings it means when it comes to forensics investigations. So you can talk about things like, well, previously, if you can Analyst two days to grab all the logs to go through all the logs, find all activities, to be able to figure out if it was indeed an incident.
And what was strange about this activity now it's, you know, just looking at the dashboard and that is again, very tangible and very measurable thing, how long an instant investigation takes and those kind of trends could be shown to the board as well. And if they're really, really tacky, we have some built in very scientific self evolution methods that actually measure the efficiency of these algorithms. How well can they find well hijacked accounts and those kind of things, how many false positive, how many false negatives they're producing and produce really nice charts about that. So depending on the level of their technical expertise and interest, we can talk about a bunch of different things.
Yeah. And, and I think it's worth saying that, you know, at the point that you actually have a major breach, then, you know, when you have the television cameras sitting outside your, your front door and your CEO needs to go out and make a statement to the press, then for them to go out and say, we don't know how they got in. We don't know what they got. We don't know when we'll be back in business, actually Rex your credibility. They can't go out and say, no comment. You know, that isn't an option when you've got a TV crew out there, especially if you're in, in the public face. So to have the kind of tools at your disposal that allow you to say very quickly, this is how they got in, this is what they got. This is how they did it. This is the amount of damage we know exactly. You know, they got 2000 records, including credit cards of our customers. At least if you go out and say that, and you can say, we know how they got in, it's been stopped. They're not getting anymore. We've limited the damage immediately. And we know what they did, how they did it, etcetera, et cetera. It gives you an awful lot more credibility rather than having to say either no comment or we don't know which actually is what happens in, in the majority of cases.
Right? Absolutely.
So it's yeah, no, it's, it's, it's, it's really tough. And I, I wouldn't, yeah. I wouldn't want to be a CEO in that position without, without that. Well, I wouldn't want to be a CEO in that position, but ultimately reaches happen. You need to have that information at your disposal very fast, cuz doing, you know, say, well, we'll do the analysis and hopefully we will logging the right stuff. And maybe we'll get back to you in two weeks. Unfortunately, you know, the speed of the internet, doesn't cut it anymore.
Right.
So by my watch, we are coming up to time. I'd just like to say Peter, thank you very much. Thank you for the live demonstration. It's always much more fun. I think. And people can for
Me as well, actually for me as well, it is much more fun to do a live demo than just slides. So well thank you for the opportunity
To do this. You're very welcome. So I hope you've all got something out of it. You, you enjoyed the live demo and take away, you can go and replay this. So this is gonna be available from tomorrow as a podcast recorded webcast and just really remains to me to say thank you for attending Peter. Thank you very much for the demo. And it's been our pleasure to host this session and that's it. Thank you very much.
Thank you everyone. Bye
Bye.
