Cyber Resilience Through SOC Automation

So good afternoon, my name is Paul Simmonds, I'm a fellow analyst at KuppingerCole and it's my pleasure to introduce to you this afternoon Amitabh Singh who's the field CTO EMEA from Palo Alto Networks and we're going to be talking this afternoon about cyber resilience through SOC automation. So without further ado let's kick off. I'm going to do a short introduction he says if I can get my uh of what's going on this afternoon. You are centrally muted, we are controlling all the features so there's no need to mute or unmute yourself.

We've got a couple of polls coming up so be prepared to contribute to those, it will make our job a lot easier because we'll have a good idea of who's on the call and listening and of course there is going to be a Q&A session at the end of this webinar. You can enter your questions at any time, you should have a control panel on the GoToWebinar system, you can enter your questions there and we will do our best at the end to answer them. And finally we are recording this and the recording and presentation will be made available for you to download in the next couple of days.

So this is the agenda for today, you've got me for the first little bit with an overview of understanding the modern SOC's requirements and then you've got Amitabh talking about the path to an autonomous SOC and the potential SOAR has to deliver value for your business which is what it's all about at the end of the day. So as I promised, the first poll, so the question is quite simple, just to give us an idea of who's on the call, whose business is running a SOC and your answers are pretty simple.

Yes, you run it in-house 24 by 365, yes you have some other form of SOC arrangements, there are, you know, you can partially or fully outsource, you can be doing it elsewhere with partners or actually three no, the business thinks it costs too much, there's no perceived ROI and ultimately no business case. So the poll is open. I'm watching the numbers come in at the moment. We're running about a third, a third, a third at the moment, which is quite interesting.

Oh no, I'm seeing that yeah, we've got about half of you voted so far, keep pushing those vote buttons please. We'll give you another sort of 20-odd seconds to get your poll in, please. Thank you very much.

Okay, so the results are in, looking at my screen here, the one that I'm looking at, the winner, believe it or not, is number three. No, it costs too much, no perceived ROI and no business case. So that's probably about as I would have expected, and a third of you say yes, we run it 24 by 7 in-house with 22% selecting number two. So thank you very much for that, it certainly helps us to get the results that we're looking for, and I'm going to hand it to you. So thank you very much for that, it certainly helps us in how we talk about and how we tailor this presentation for you.

So let's kick off, this actually comes from an original presentation by my colleague John Talbot, the definition and the need for SOAR. So hopefully people are dealing somehow, whether you have a SOC or not, with security instance, but the aim very much here of moving to SOAR, and what we're talking about this afternoon, is how we mitigate better. So the problem is, as you probably know from all the industry statistics, and you'll hear this from everybody, the vendors and us, and et cetera, et cetera, is typical mean time to detect a security incident is six months.

In other words, the bad guys have been inside your systems for typically about six months, which is quite concerning. And once you discover them, it takes on average about two months to actually start, to mitigate, to resolve that security incident. And if you crunch the numbers on a fairly, you know, on a decent size security breach, then you're looking at about a total cost of four to nine million dollars.

And that's before you get rid of the fact that you've, you know, lost lots of business confidence, partners may have gone elsewhere, customers may have gone elsewhere, because your stock, your value, perceived value, you're not a secure company, so why do we want to do business with you? So there's a real need out there to do what we do as security faster, and hopefully, from a business point of view, quicker and cheaper. And we think SOAR has a place to play in that picture. And ultimately, SOAR has these three functions. So can we orchestrate, can we automate, can we respond?

And we'll be talking a lot more about this. So why SOAR? So SOAR is there to bring technology convergence at the end of the day. It's about workflow automation, it's about management and best practice, it's about utilizing best practice, you know, what we call playbooks. If you are not operating a SOC, then a playbook is basically the instructions, the standing operating procedure, if you like, in which we respond to various alerts, instances, incidents, or whatever occurs.

And normally carried out at a basic level by level one analysts, and then level two analysts, and then level three analysts within your particular SOC. And if you don't have a SOC, that's going to be various teams within your business, whether it's the security team, whether it's the IT team, or actually your instant response team, which could include your management when it all goes horribly wrong. Most people will have some form of security instant platform, a SIM or a SIEM, depending on how you refer to it, which includes your vulnerability management platforms, your ticketing systems.

And that might be, as I said, if you don't have a SOC, that might well be your existing ticketing system in use by the IT department. The XDR systems, knowledge systems, alerts, reporting, etc., etc. And then finally, threat intelligence. And threat intelligence is incredibly important, because you need to understand what's hitting your business, not only from the point of view of your particular business. I used to be the CISO at AstraZeneca, and one of our biggest threats was the animal activists.

So we had intelligence coming in on what they specifically were doing and targeting within the pharmaceutical world, but also the general incidents that are going on. So let's have a look at some of the challenges that we have within our particular businesses. So the first one is this one, and this is why it came as no surprise that people answered to number three. 44% of you answered three in the poll. The cost of operating a SOC. Starving costs. Recruiting good SOC personnel are, you know, they are incredibly expensive. Once you've recruited them, you know, that's hard enough.

Then you've got to retrain them, and you've got to keep, I'm sorry, you've got to retain and also retrain your staff, because obviously they need to be keep their skills up to date with the latest threats, but also they need to be perceived as being loved so that they don't go to a competitor, because it is a very, very competitive world out there. And the other thing is staff numbers. If you look at what it takes to run a 24 by 365 operation, typically one head running 24 by 365 takes about five, four to five full-time heads to actually make that work.

So just having a level one, level two, level three, and a SOC manager, plus some support staff, you could be looking at 25 to 30 full-time heads. And it's interesting. I don't know why we're automatically advancing. But 25 to 30 staff, and you go to your board and say, look, we want to run a SOC, and actually we need to run a SOC, and ultimately we need 25, potentially 30 full-time heads, and your board typically will have a large intake of breath, if nothing else. The next one is how you derive value from a SOC, because ultimately playbooks take time to develop and refine.

They are very immature in most SOCs when people put them in. You have information overload within a SOC, therefore actually trying to spot the English term is the needle in the haystack. I don't know how much that gels with an international audience, but the British call it finding the needle within the haystack. And a lot of the time that's what we're trying to do, as security people and SOC analysts. They're trying to spot the real instance, the real instant of a bad guy trying to get into your system, or code trying to attack your system, rather than just your staff doing something stupid.

And obviously everyone's business out there has hundreds of products, so the time it takes to integrate all those products such that you get a full panoply of information really takes time. And so you can be a year, possibly two years in on a standard SOC, and you still haven't got the value that you promised the board when you went to them in step one. The next one obviously is inefficient processes.

So the problem is that if you are going to escalate to your level three SOC analysts such that you can take real action, there is a process in an existing SOC today that you need to go through escalating from level one, level two, level three. And the problem is if the level one analysts miss it, guess what? It never gets escalated to level two, let alone level three. And that's quite often why, even though companies are running a SOC, they are still getting hit by the bad guys.

Again, reduce time to escalation. So how do you get that escalation faster, quicker, cheaper? And immature playbooks, if your playbooks are still immature, again, that escalation process is not going to happen. So ultimately what we're looking for, the challenge is four, which is how we minimize instance, how we reduce the mean time to detect and the mean time to resolve. And those should be some of your key performance indicators that you are using within your SOC.

Or if you don't have a SOC, because it's great information actually to go to your board with and say, actually, these are my current MTDD and MTTR figures, and a SOC will help us bring those down. And then you can actually put a cost on that. And ultimately, your aim should be to automate responses wherever possible, because that is ultimately how you're going to minimize instance.

And also, as I said, start hopefully spotting that needle in the haystack. So what is your SOAR deployment looks like? So this is where we think SOAR is starting to go. Originally, we'd have had, if you'd have seen these slides 18 months ago, you would have probably had SIM or SEAM at the middle of this picture. And a lot of organizations out there are starting to say, no, actually, SEAM is just part of it. Ultimately, what we want at the heart of our SOC is a SOAR implementation. So you take your inputs from the security logs. You get API integration into SOAR from your SEAM.

You get informed by your intelligence systems. You integrate your subscriptions to your intelligence feeds. And ultimately, you have a SOAR console. And that can be either be on premise or in the cloud. There are various ways of implementing it. But as I said, if you looked at this 18 months ago, SEAM would have been at the center.

Now, a lot of people are now starting to put SOAR at the center of this. And we'll hear about that in a second. So the solution, automate as possible. Feed everything, it should say, everyone. Feed everything you have into SOAR. So the more information feeds you can get into SOAR, the better it can make decisions. And as I said, the aim is very much to get autonomous decisions. Leverage best-in-class playbooks. Because actually, 95% of what you are going to be doing in your SOC is going to be exactly the same as everybody else.

Most exploits out there are what we sort of refer to as spray and pray. In other words, it's not targeted at your business. The bad guys are spraying it out across multiple sources in the hope that that zero day that they're using or recent exploit hasn't been mitigated in your organization. So let's get it out quickly to as many businesses as possible, see how many hits we can get.

So again, leverage best-in-class playbooks. Let SOAR automatically respond. It's all about minimizing the blast radius by minimizing your response times. And ultimately, at the point that you need to escalate it, the key thing here is your level three analysts, the one who are going to make the decision that this really is something that you need to react to and respond to that we necessarily haven't seen before.

You give them as much information as possible to make really, fast decisions because delay, by the time you get it to your level three analysts, it's already probably affecting your business. So what we're talking about today is based on this. This was a white paper that we published back in January, automating the SOC. You can go and download it, obviously, from the company website. We will give these to you at the end as well, these links. And obviously, the slides are going to be available. It's based on this. So the original leadership compass we did was in October 2020 with John Talbot.

Obviously, things are moving very fast in the SOAR marketplace. So this January, the end of January, literally, hot off the press almost, our colleague Alejandro did an update to John's original work. So we have issued an update document.

And again, the link is there. You can go and download it with your Coupanger Coal subscription. I'll just give you one slide from Alejandro's document. This is what we regard as the overall leader slide, the headline slide, if you like, within that document. And as you can see, friends at Palo Alto are right up at the top of that. So it's really nice to have them here today to talk about how they see SOAR within environments that they are working with and give you hopefully some real world experience. So with that, I'm just about to hand over to Amitabh.

But before that, we are going to run a quick second poll. So here is your second poll. If you are running a SOC, and if you're not running a SOC, I suspect your answer is by definition is number one. But the question is, how automated is your SOC?

So one, very manual, lots of feeds requiring level one analyst interpretation and escalation. And number two, we're partially automated. Playbooks help escalate to level two and level three, but could be faster.

And fine, we're automated. And of course, the caveat here is yes, we could always do better. But we think it's fairly slick. So the poll is open. We will give you about 50 seconds to have your vote. And I will watch the numbers come up. So currently, the majority of you are sitting at number one.

Yeah, still remaining as the majority at number one. Yeah, we're running about 70-30 at the moment with number one. No one is voting for number three, interestingly.

Mind you, I guess that's why you're all here. So hopefully, you're going to get an awful lot out of this if no one is voting for number three. So poll is closed. So the results are in.

63%, number one, very manual. 38% of you are partially automated with playbooks escalating to level two and level three. And actually, not too surprisingly, no one voted for number three.

And again, I guess that's why, hopefully, you're all here today. So without further ado, Amitabh, welcome. Good afternoon.

I think, and thank you, Paul, for the introduction. And in fact, thank you, everyone, for the poll questions and the poll answers. Because that makes my life a lot more simpler because it, and Paul did say, it makes, it is something that is to be expected. And I'm here actually to talk about how we should do this. And I'm going to start with the poll questions. How we should change some of the things. So I don't want to talk about some of the things that were there. So I wouldn't talk about the standard slides. I will talk about what exactly is the reality of the current operations.

And the reason why most of us actually voted for option one and option two in the last poll that Paul did was just precisely that, because the existing approach to security operations is indeed a mess. We are reactive. And it's not that we are not smart people. It's just that whatever information that we're getting, it's highly filtered. It's a single source. It's too many complexities in terms of how does it work. So if I were actually to define the whole security operations in a slide, it would actually be more like this.

It would show something that would be like there would be too many alerts. There are too many tools, too little jobs, too many silos. And I think some of those things are emblematic of the fact that things haven't changed for quite some time. So for instance, phishing alerts are as much of a problem today as they were 10 years back. And I think it's because while the attackers can leverage automation to launch high-quantity phishing attacks with a click of a button, we still are actually trying to work on the alerts one by one.

And I think security teams are just not able to follow the right set processes while responding to these kind of alerts. So in a way, they need to coordinate response across email boxes, thread intel, exclamation firewalls, ticketing, and other tools. And each one of those tools have different consoles, data conventions, contacts, which really makes it difficult for security teams to fill in the gaps while minimizing errors. So if that's the case, what is it that we should be doing in terms of managing it? And I think SOAR solutions, as Paul said, were designed to address these challenges.

Because the first component of SOAR is actually orchestration. And this involves controlling and activating the security product stack from a central location. And the operative word out there is a central location and not multiple locations. That's one. And through a single pane of glass. And this is actually done through playbooks, which are task-based workflows that are coordinated across people, processes, and technology. And some of the people have asked me in terms of how does the playbook work. I would say, first of all, a lot of the playbooks should be out of the box.

And then it should be customized. But it's not just how you are supposed to investigate an issue or an incident that's important in this case. Or whether certain things have happened, you call up someone else to perform the remediation. In certain cases, like if you really find a major alert, your playbook should be able to dictate that you should be able to isolate a single user or maybe even a VLAN in case of a major issue. And that second component that defines that is automation, which is a subset of orchestration.

So within SOAR, automation involves finding those repeatable tasks and executing them at machine speed. Something that we know exactly is a big challenge. Those automation scripts and extensible product integrations really are needed to accomplish automation. Final component, response involves maintaining incident oversight as it gets through the lifecycle. Now within SOAR products, this includes case management, collaboration during investigation, analysis, reporting, after incident closure.

So I'm trying to actually differentiate the fact that when a security incident has happened, managing it has to be through a machine speed. It should not be that you are opening a ticket which is sent to an IT person who actually tries to respond to it when business hours happen. It's actually something that happens right then and there because your playbooks dictate that if there's a VLAN that needs to be isolated, and it's an approved playbook, so it's not a question of getting an approval, then that does happen.

And then the final response is in terms of trying to understand what happened, getting the forensics part of it, and doing it properly. So the next part that I would actually say is that we talked about the fact that you need to have integrations. And that's something that I've always said. When it comes to all of that, your XOAR, and something that Paul also alluded is that XOAR or XOAR tools are now the center of the universe as far as SOCs are concerned.

So the 700 plus third-party tools that are integrated with RXOAR really help us to do that because if you are not integrated with the third-party tools, it gets really challenging to manage the whole environment. And one of the things that we also talked about is that it's still a very manual way that feeds have to be done through manually. And I think I would actually argue that if your feeds are directly coming into the SOAR platform and it's ingesting those feeds automatically instead of manually, that takes care of that.

So your tool should be able to ingest the feeds in an automatic fashion. So just how does SOAR lead to an autonomous SOC? And that's what I want to actually talk about in my next slide. So what needs to happen is that in this case, with multiple integrations for the products and security actions, you have an automation or orchestration there. You have a real-time collaboration because your investigative capabilities ensure that you have a virtual wall room that you're managing incidents in. The case management is to sanitize processes.

And your threat inter-management takes up the repetitive tasks and actually makes sure that what needs to happen happens. So that is something that I think is actually the mantra of managing that. So how do we actually differentiate some of those things around this? I think the first thing I'd already talked about is through multiple integrations, or we actually said 700 plus integrations, that ensures that users can use one console for alert ingestion, for enrichment, and for response by collecting data across all the tools. We've got to be deploying visual payloads.

So either out of the box or in case once you've gone to the next level of managing SOAR to custom build payloads that coordinate actions across people, products, and infrastructures. And having those thousand plus automation actions across security tools really help to execute those repetitive tasks at machine speed so that you as analysts have more time to make decisions and investigate. Since we have talked about playbooks, it would also be good to talk about some of the playbooks that are existing. And I'd like to talk about some of the playbooks that happen in our own SOAR.

So these are the many of the SOAR playbooks that are automating repetitive tasks in Palo Alto software. So if you haven't seen an XOAR playbook, they would look like a flow chart. You can drag and drop these action bubbles to create if-then statements and kickoff actions in other applications. And the visual interface is intended to allow everyone to build XOAR playbooks without having to write code. And that for me is important. So you can also have business analysts and people who understand the business contextual or business context for the organization also be a SOAR analyst.

So it's not that you are not allowed to write code. Developers can choose to use Python or Java if they have the skills, but that's not essential. So you have the right mix and balance of analysts. And typically then the SOAR clearly has more of level three analysts, which is where we need SOAR analysts to be focusing on, as against the standard life cycle of level one analysts who for the first six months to one year of their job are doing logging and flogging tickets. So in the first column, we have the top level playbook for each technology or request source.

Now this sets up the flow for the response playbooks. And most of the analysis in the second column happens automatically.

So we, for instance, we want to calculate the severity of the ticket based on information like who is the user or what is the host. We pull up the host details from various sources, including ServiceNow where our IT teams maintain our CMDB. And if we want to know that it's a user endpoint or is it a critical application server or who's the contact for it, we get to know that. And then we also want to know if this is a privilege account or is it an exec. And then all the indicators are run through threat intel sources from previous slides and results are added to the ticket.

And we can even reach out to the back of Cortex exam and some of the other rules for logs for specific cases. So a use case that we get a lot of value out is sending users an email asking for information about an alert. Now whenever I have a user's name involved in a security alert, I'm usually going to reach out to them and ask them if they were aware of the activity. Do they recognize any of the files? What were they doing at that time? Because the email is in sent, user usually has the valuable feedback and they can reply to email which comes to the ticket.

So this is a departure from the past for many SOC teams where the ticket might have not worked right away and by the time you're speaking to the user, too much time has passed and they don't remember all the details about what they have encountered. So that's an important part that we have kind of changed out here. Now one of the things is that once the analytics or analysis is done, one of the two things will happen. If there is enough information to confirm containment or remediation actions are required, the playbook can proceed to those steps.

Or if there is not enough information, the playbook would insert from the analyst for a decision on what to do next. And these breaks are completely customizable. So you decide where the playbook should take action or break. And then we have built containment actions to be reversible. So in the event we accidentally do something that's in an unintended, it's easy to back out. Like if you block an active user, you can stop that or you can unblock that. But at that point of time, because your playbook says so, it's important that you block the users.

So having this foundation of playbooks in place with the kind of automation, we are able to take a lot of the repetitive tasks out. And I think that's possibly the most important part in terms of having this flexibility of having the playbooks in place. So let me show in the next slide in terms of what has been the results of implementing some of those things out here. So this slide shows some of the benefits of automation and machine learning translates in terms of time savings. So one of the first automation use cases that we decided to build was responding to phishing alerts.

We know that's a standard use case in most of the sorts. And we used to be an Office 365 customer for email, which of course we are no longer there because Office 365 is a big problem and is possibly one of the biggest challenges for security and compliance issues. But if you are, you can actually take the time out, which would take about half an hour or more to gather all of those emails and get this thing out and reduce that to two seconds.

Now, the way it happens is that when the playbook receives an alert from Microsoft through point of one of the users, the playbook would actually request Office 365 to begin searching all the related emails. And then we then went on to automate the rest of the steps in the phishing response. So everything from sending an email to the user to notify they've been falling victim to a phishing email. If they've given away the credentials, we need to reset those credentials. That's an important part because you can't wait far too long for that. We might need to block that email sender.

And if there's an attachment, then we might need to submit that to Wildfire and then or in a sandbox to determine if it's malicious. And then we want to block any malicious links in that email. So this one use case initially saved a lot of work.

I mean, I can estimate that by implementing this use case, we're talking about 18 to 20 business days of work that's been taken up. But the other one that I want to talk about is about the next generation firewall, the investigation of command and control next generation firewalls.

Now, this was something that was clearly a big issue for us where we were feeding our network, endpoint and cloud logs into it. And the machine learning is applying context and stitching those alerts together. So in this case, once we get alerts from network and endpoint and cloud, we stitch those alerts through XR. And then it goes as far as drawing the visualization of the attachment and all of the hosts that are involved, allowing the SOC to spend less time doing analytics and more focus on the containment and remediation. And I think that's the whole part about it.

Can you focus more on containment and remediation? So again, the big part is we are saving an issue which would have taken probably about a part of an hour or so.

I mean, three quarters of an hour. We are now able to do that in a few seconds. And I think that's the part that we need to start doing that, that having that. It's not that it's just a cost saving thing. It's also something that it really has an impact on efficiency, effectiveness, and also how fast we're able to get the work done. Some of the things that we know that we have talked about earlier in terms of how beneficial it is from an ROI perspective. These are the kind of use cases that determine the ROI of XO or XO products. So that's another thing that brings me to the next part.

All of us, almost every one of us, have seen the left-hand side of this chart. Anyone who's operating a stock or has an outsource stock will see this chart every month. X billion events coming out with X million alerts, with some real alerts, and finally certain incidents, and how many incidents are being managed. But as Paul said, it's not the left-hand side that's important. It's the right-hand side. How fast are you detecting those real incidents? How fast are you responding to the high priority alerts? And how fast are you remediating them?

If you're detecting in seconds, responding in minutes, and remediating in hours, that's actually what your SOC should be doing. And if you have that, you are showing the real efficiency of the SOC and effectiveness of the SOC to the principles and the right ROI. So in our case, we are looking at close to about 16 FTEs of automation and savings every year. And I think that's the part that we need to be looking at from a value perspective of the value that's generated for us.

And I believe that this is what we should be looking at in an overall basis on managing the overall effectiveness of the SOC in terms of doing it, managing it in a better fashion. So what exactly is the Cortex XO value?

Well, one is you've got to standardize and scale processes. So our playbooks really help you to codify and enforce a process that's coming across your security. These playbooks can be fully automated, fully manual, or a combination of two, with each scenario having its advantages with increased efficiencies. So you decide whether you want to fully automate or fully manual or a combination of two. This action alone reduced our weekly alerts from about 10,000 to less than 500. And I think that's a huge change that you are able to do that.

So that's one value I would recommend everyone to look at your SOCs in terms of how many layers are you fielding right now, and are you able to automate those alerts. And I don't think that without having the SOC platform, anyone can alert software. And as also increasingly, organizations are now making SOC as the center of universe for SOC. So without automation, it's going to be almost impossible, unless you have an army of analysts, which of course is not possible because you can't hire that many people with that kind of expertise.

Manager, you have to go for automation and reduce the alerts from being fielded manually to manage automatically. And then the next advantage is the response times. So even if you have manual SOC, there is going to be a certain amount of time lag between the time a person can respond, because that analytics have to happen. Now with the XO, you can automate thousands of actions across your security products, handing back time to you and the analysts for investigation and decision making.

So these automations can be, for example, alert ingestion, data gathering, response actions, updating information back to the point products. So all of those things, that would be almost impossible to define. And I think this is where it gets really helpful for the organizations to deal with things that are not possible otherwise. The last part that I want to talk about is possibly the most important part in the return of investment for a person.

Even though we say that it's coordinated actions across security products that have a process-centric view on how to respond to a particular incident, which is not tied to one product. So the playbooks give you an abstract view of a process, which makes it easier to replace one product with another when you need to. But there's another upside to that. If you are able to coordinate actions across security products, that's the only way you can actually manage zero-day CVs. Because CVs are such that someone gets into the environment, but then there are certain actions that are abnormal in nature.

By coordinating actions across security products and getting information across multiple sources in the right fashion, like network alerts that are coming in, like the endpoint alerts that are coming in, or the cloud alerts that are coming in, you should be able to get a picture that something is not working. And this is what we actually saw when we were seeing the SolarWinds attack in our own SOC that we would see that something is not right. And we were able to transfer that knowledge and insight into the SOC and stop that from preventing further.

And I think this is something that we have been even working in some of the more advanced spyware products like Pegasus, that having those kinds of spyware products would actually keep on increasing more in the future. The way right now that these are available only to governments, we believe the technology will change so much that it's easy that they will be available off the shelf for anyone to use once they're there, because the genie's already out of the bottle.

And the only way to understand actions would be to coordinate actions across security products, knowing what kind of alerts are coming in from firewalls, knowing how your endpoints are behaving, and be able to transfer your traffic into the right fashion and so coordinating what kind of alerts are coming in. So that is, I think, an important part that you are not just trying to manage existing kind of alerts with your SOC investments, you also got to be proactive that your alerts will increasingly become a lot more complex.

And if you do not have this kind of technology, it's going to be really hard for you to manage advanced SOCs in the future. But that, I think, that's all I wanted to share for this. So I would like to hand it over to you both to see if we are there now. Wonderfully insightful, as always. So the first question is from Dario, who says, if you want to staff a SOC, sorry, I'm peering at my screen because I've got a big 4k screen and my eyesight is going. If you want to staff a SOC with level one, level two, level three, 24 by 365, you still need a significant staffing.

So what is the minimum you can scale down to using SOAR? In other words, what are you seeing out there for yourselves as Palo Alto, obviously you're using your own product, but also the customers that you're working with. Are they able to start scaling back, particularly level one and level two and getting a return on investment that way? Good question, Paul.

So for, in our case, we of course have an added advantage that we have two SOCs, one in Tel Aviv, one in California. So that is kind of 12 hours away from each other. So we do have the follow the sun approach, but what we have also seen is that we don't get, we don't get our, we don't need a 24 by seven SOC. We are able to manage through automation, all of our alerts easily without any challenges coming on. And that's what most of our customers are also seeing increasingly.

If they are not large corporations, which are, which are working around the globe, like in your case, when you were working with AstraZeneca, they would definitely be working all around. So they need to manage a SOC, in which case they would, they can actually have analysts in the local countries and then manage the local business hours. What we're seeing is that the kind of tool sets that we're talking about, you do not need to have a SOC analyst in one specific center.

So the days of having a huge room with, with those LED screens and seeing those alerts, with those kinds of monitoring, the kind of things that you normally see in, even now in, in Hollywood, because you know, that most of the movies are still having a lag that they would want to see that and you'll see a cyber security big screen coming up. That is no longer a must thing. A simple laptop is good enough for an analyst to work in, in which case you can pretty much hire the analysts whenever you want.

But if you're talking about 24 by seven SOC analysts, I don't think we need to have that with the kind of automation that's built into the models. Because if you, if you are, for instance, a location-based entity, then your playbooks do take care of your off-hour challenges because at the end of it, they stop the business at some certain point of time and quarantine a specific user, even at one in the night, then that's the case it would be.

And, and someone actually asked me what happens if they actually quarantined the CEO of the company at one AM in the night. I said, then you got to ask what kind of playbooks have you set up on that? Because if you have set up the playbook like that, where if there is a security issue and you've quarantined a user, even though that user, and she's the CEO of the company, but I would, I would actually argue that's, that's how you are defining your, your security playbooks based on the risk analysis that you've done.

So, so defining playbooks is not, I say, I would say divorce from the risk analysis that you would be doing and setting them up. But last, and then you do not need to have a 24 by seven SOC, in which case you need about eight or 10 people to man them on 24 by seven basis and having night shifts in place. That's not needed anymore. That's good.

I mean, that's an interesting feedback. Certainly, I think for the people on this call is that it does change the, the dynamic and the ROI calculation that you're going to go to the board with, hopefully.

For all, for the third of people who answered three to the first poll we did, who said, you know, we don't have a SOC at the moment. So, you know, maybe, maybe that's your answer.

Go, go straight to a SOAR solution. So I suppose that brings us onto the next one.

You know, for all of those people who did answer number three to the first poll, which is we don't have a SOC because we can't justify it. If you are starting to sort of think yourselves as security people, yet we really should have a SOC, should I go straight to a SOAR based solution and just base my entire architecture and my, my pitch to the board around implementing SOAR from day one? My answer to that is that you need to have a couple of tools before you just have a SOAR in place.

So, so in the past, for instance, let's use the same information that you gave in your slides, Paul. In the past, you talked about the fact that SIM would be the center of universe and even smaller organizations are implementing SIM, which is why you saw the response in your first poll that we don't see any ROI. And simply because of the fact that implementing SIM is a multi-year project with very few return, very, very far less return on investment as far as cybersecurity is concerned. Yeah.

If you were to implement it, I would say the first and the most important part for a SOC would be to have an XDR feature in place because that's a starting point. The next part is, then you actually implement an XOAR on that. What we are actually trying to talk about, and that's possibly out of the scope of this call, but we should be talking about it after and please feel free to connect with me after the webinar.

We have introduced a product for specifically the organizations like this, who are thinking about not going or not implementing SOC, but having a product which manages the whole environment on an XOAR basis. So, the whole environment on an end-to-end basis, and we call it XIM, which is Senate Security Incident Automation Management. What it does is it has out-of-the-box playbooks, and it actually gets alerts from endpoints, network, and gives you the holistic picture without having to implement the SOAR solution on your own.

And I would say for organizations that are looking at having employees, less than 25,000 people should definitely look at that as an option instead of trying to have a dedicated XOAR first solution. Okay, and so I suppose the next question I've got on my screen here, and building I suppose on that, is in terms of what you do with the, you know, particularly with your SOCs, how much time has moved from doing tactical versus strategic SOC work, like proactive threat hunting? In our case, we are now doing only about 33 percent of the time as tactical work.

So, that's something that we have done. So, we are doing a third of the time on tactical part, a third of the time that we are doing in terms of building new playbooks, and a third of time in threat hunting.

Okay, yeah, interesting, as whereas before most of the time you'd be sifting through those haystacks trying to find that needle. Correct.

Okay, so one very dear to my heart, as I alluded to earlier, is we used to have all sorts of fun and games with animal rights activists. How does a SOC perform manual repetitive tasks, like checking intelligence feeds, and where do those factor into this?

Well, we have made our product in such a way that our product ingests the feeds directly. So, third intel feeds are not something that we would be actually giving it to the analysts, or they have to manually put it. Our XOR automatically ingests those feeds.

So, a simple example would be that if you're seeing in the environment a specific kind of malware that's there. For malware, we all know that they all have to connect back to a specific IP address. If that's blacklisted, then that's restrictive. That information is already fed into XOR.

So, in case any of those IPs within an organization start trying to communicate with any of those restricted IPs, then an alert is generated automatically in the SOC. So, you don't have to actually do that manually or structure that out manually. And that becomes an important part of the SOC. A simple thing that I've always tried to explain to clients, and I was talking to one of the largest automotive companies in Europe about this, is that they wanted to understand how does it work.

And I said, if you look at it, at any given point of time, there are 15 billion indicators of compromise that exist out there. And they keep on expanding by a factor of about 10 percent every month or so.

So, there is no way you can actually build it on in terms of changing that. So, you keep on building some old ones retired.

So, it's like a churn. So, the only way you can do that is if your XOR gets those kind of alerts directly from an external part. Because you can't just have that threat hunting done manually. Because there's no analyst in the world who can handle that volume on an independent basis. That would just overwork the analyst to death.

So, we actually have that capability that those threat fields are fed in. And it's not just that those threat feeds have to be from us. We also feed in threat feeds from VirusRotor for that matter. This is a Google company. We get feeds from multiple sources. And those all get into the XOR platform, which makes the life a lot more easier for the analysts.

Yeah, and it's probably worth pointing out to people that there are industry-specific feeds as well. I mean, I know the banking industry, certainly in the UK, if you hit one bank with a rogue IP, about 10 milliseconds later, all the other banks have blocked it. And there are multiple feeds out there like that, whether they're industry-specific or whether they're actually being rolled up as a service. I think that's a good point, Paul, that you're talking about. Because those industry-specific feeds plus coordination with NCSEs, respective NCSEs within the country is becoming really good now.

In Europe, we're actually seeing collaboration with ANISA, the European Agency for Security. So they are actually able to feed in all those feeds to all the countries.

Luckily, that has also had no impact on the UK as well. So the UK is still part of that. So there is a very strong collaboration in terms of, from a Europe-wide perspective, in terms of sharing those feeds between NCSEs and giving each other insight more and more. And that's actually becoming even more relevant because there is a huge amount of challenges that are there for critical infrastructure or companies that are in critical infrastructure industries. So those threat feeds are really important that could be shared, and they have to get automatically into the stock.

Yeah, I know the federal government in the US is talking about mandating some of this threat intel sharing. And there are big debates going around about the format that they're going to be shared in and anonymization and all of that. But we see these initiatives coming up time and time again from regional governments, Europe, obviously the US federal government, et cetera, et cetera. But there are big pushes to actually get those feeds out to people such that, yeah, we can automate better. Because I think, as you've learned from your presentation particularly, automation is the key to this.

Good. OK. I'm just looking at my question. If you want to nip a quick question in, you've got a couple of seconds left. We talked about what we need to have in place.

Yes, we have one question. If you missed the beginning slides from both presenters and a recording, this is being recorded. So if you missed the beginning, and particularly when we told you that slides were going to be available, yes, they will be, and the recording will be available. So if you missed any of it, you can go back and watch it.

Normally, that takes a couple of days to get out with the background people at Cobinja Coal to sort that out and get it on the website. But it will be available to you. I'm just going to wrap up with what we'd call in the UK parish notes. But any final thoughts before we leave you?

For me, I would say that for the folks who haven't actually implemented a SOC or haven't actually seen the value out of an existing SOC, an XO tool is really important from making sure that you are managing threats proactively. For most of our customers that we have seen, it's not a question of if but when security challenges will be there. There is a huge amount of new kinds of challenges that are coming in. I mentioned about threats like Pegasus in the presentation. These are no longer threats that people thought are irrelevant or can happen to others and not to us.

I have seen a lot of those things specifically at the critical personnel execs who are also facing those kinds of spyware activities now. So it's important that we've got to be vigilant. We have to implement SOC tools. Like all technologies, it takes a bit of a time before you are mature enough to do that. So if you start managing with playbooks out of the box right now, in the next six months, you would actually be advanced enough to create dedicated specific playbooks for your company and for your industry. But the important thing is make sure that your SOC is up and ready and doing it.

And if you don't have an SOC, you do have to invest into having an MDR services that actually provides you with those kinds of capabilities. The benefit for MDR services that's really important in this case and that's side-by-side is once you have alerts coming in and you need to manage a security incident, the only way you can do that is to have the right kind of forensic capability. And some organizations don't have to have that.

So again, your SOAR tools really helps you to bridge a lot of the gaps on an automatic fashion and also tells you what tools or what skills you need from an external perspective. So again, it's an important thing for you to see how to manage security on an end-to-end basis.

Yeah, and it's a great point to finish with because it's not part of this particular webinar, but there is the bit beyond it because ultimately at the point that you do get breached, there is a whole raft that you have to have in place before it happens to you because it's no good doing it after the event. So you have to have your senior management briefed on what happens in the event of an incident, you have to have your PR in place, you have to have your contracts in place with those third-party companies.

So not part of this webinar, it's a whole topic in itself, but just to say, you know, at the end of the day, as great as all these tools are, they're there to minimize the impact of you getting breached. The bad guys are out there and if the bad guys ultimately want to get in, chances are that they will. Your job is to ultimately minimize and mitigate as fast as you possibly can and SOAR is a great way to do it. So thank you very much. We've got about two minutes left. I'm just going to do the parish notes as they say. So the first one is this, KC Open Select. Please go and use it.

I'm sure you all know about this, so I'm set with time to go. The one I really want to talk about, he says, is this. If you have not been to EIC, I would thoroughly recommend it.

It is, obviously it was run during COVID as an online event. It has stayed as a hybrid event. I think we've got, KC's got hybrid down to a really fine art. So if you can't make it in person, then the hybrid event, please attend online. But if you can, I would thoroughly recommend getting to Berlin. Great event, lots of fantastic talks, vendors, it's all the offline discussions that go on at those kind of events. So absolutely. Topics this year, securing identities, identity for web 3 and the metaverse. That should be really interesting.

Decentralized identity, one very close to my heart, and lots more beside. So please, please, please register for that. Get along in person if you possibly can. I said I'd do it at the end. Here's a wrap-up of all the related research that's out there. So these slides are available, so the links will be available to you. So there's the automated white paper, the leadership compass update, the bias compass, and also the original paper going back to 2020. So those are your pointers. And obviously, I'm sure you know what we do as an organization.

But if this is your first webinar, then obviously research, advisory, and events and webinars are what we specialize in. And it's very nice to have you as customers. So thank you very much. And with that, he says, just leaves me to say thank you very much for attending. I hope you enjoyed it. I hope you got lots of useful information out of it. Good luck with implementing your SOC.