Steve Pye - Here Comes The SOAR

hi welcome to here comes the saw uh getting rid of my sort of beatles pun early on in the title there but for anyone reading that title and sort of thinking well that's a bit ominous don't panic slow's not here to take our jobs it's here to help us get rid of those menial tasks um leaving humans to make decisions and focus on key areas so a little bit about me uh currently i'm a thor product owner and technical lead for a global mssp i've been doing that role for about two years but i've been involved in soar for about the past four so a bit about the talk um the ubiquitous nature of saw was kind of

essentially the origin of talk we're getting more and more customers that are interested in saw more vendors that claim to sell solar products and jobs that are popping up left right and center it's a product with great potential as long as you know what you want and why you want it but i just want to go over some of the things that we've seen last few years where actually maybe you can sort of benefit from our experience a little bit so hopefully there'll be some useful things that you can use to maybe ask those questions of your own sore programs or guide your own saw experience if you haven't sort of started down that track

yet um that being said if you are fully embedded with saw in your environment this talk might not be for you it's more sort of like those early hints and tips and things that can hopefully uh guide you and bit of a disclaimer this is just my experience and opinions it's totally cool to disagree with me i think i'm wrong i'm almost certainly not correct on all of this not all solar platforms are created equally um be wary of any company that tells you that it has sole capability so is not just about automation stores everything all those built-in commands many of the platforms that are out there at the moment you know in reality maybe

they're an sa platform or an sr platform they might do some of the automation some of the response but they're not doing all the four elements or all three of the elements at least if you've not already chosen a solar platform make sure you buy something that suits your purpose if you just want something that's going to enrich your scene data then use a theme that's got submit like smart response or pre-built workflow workbooks if you need a full sore environment then that's what you should be looking for some of the companies that say maybe they've got a seamstor solution they actually expect you to write a lot of your own integrations for the text and

if that's the case really well you could just hire a developer it's gonna be a lot cheaper give them an online ide you know get them to write a few sort of api hooks if you're using the sole platform outright you should have those orchestrations written for you for security technologies you know some of them out there are offering 600 built-in out-of-the-box capabilities that you can start using you know pretty quickly once you've given it a few credentials so on top of that as well sir environment should age with ir as well so it's not just that you're running some orchestrations you're not just looking at seamless you're actually potentially going to be running full breach

environments of investigations within within the soil platform itself so when buying the soil platform i'd say we really need to focus on each of the elements orchestration commands should be simple and easy to use automation should be written for us uh if not then you're going to inherit a lot of technical debt you need to employ devs if the api changes then you're gonna have to get them to update it depending on how many technologies you're integrating and how many commands you're running i can zoom rack up if one of those devs leave you know you're gonna regret it so should also be using ir like i've mentioned the response elements literally in the name right we want to make sure that we

can record our investigations we want to be able to build timelines lines show the evidence of everything when when we you know you know when we find a compromise store all in one place and have that make the life of the ir team easier you know get away from that traditional note-taking thing make sure it's all collaborative in saw a bit of a disclaimer source definitely not a silver bullet even though i might talk about it like it is uh there's still a lot of hard work involved uh but it's definitely a first step towards that sort of single pane of glass that we sort of want in in security out of the box as well

not always a good thing you shouldn't necessarily just be looking at some uh because maybe the number of out-of-the-box integrations uh if the integrations are there don't do anything for you or it's not for technologies that you've got you probably want to maybe reassess if that sole platform's right for you based on some of the companies that we've analyzed and sort of looked at their technologies the security technologies and then compared that them to a vendor uh you can actually end up with a suite of technologies and only a handful of them have usable apis and then only one of those apis is actually in the saw platform in the first place so you've really got

to make sure that you assess your own need against the platform and don't just pick it based on on like a number same thing goes for playbooks it's all well and good having a thousand out out-of-the-box playbooks and uh you know capabilities there or workbooks whatever you want to call them but if none of those playbooks solve a problem that your company has then you've just got a load of space getting taken up on the box and it's you know it's not really worth it um worthwhile using it obviously if you still submit that you've already purchased or maybe it's been rolled into one of your products it doesn't mean that you can't meet the

criteria but uh you know you can still deliver on some of those things and you should still look into it and if you end up finding that say you're using a theme and you're using that sort of automated capabilities with that you're going to hit a wall at some point maybe that's when you sort of say now it's time to invest in soar as a natural sort of platform once you've chosen the solar platform uh you're going to want to get everyone involved you're going to want that from you know day one really you don't just want a sore team that works in splendid isolation so everything you produce is going to have an impact even if you don't realize it

it's really easy to get carried away with you know solving those first few problems that you see and you actually don't realize the impact that it's had on the wider business so if you focus on only one individual or one team you're going to get quite a blinkered view of the real impact of the problem as it as it relates just to them but that can actually end up causing your problems down the line so you know think about that as a simple example you might have um the saw is looking at seam alarms it's enriching some of the data and then it'll go put some sort of remediation in place and then you know it's going to

happen in a couple of seconds this might be saving your first and second line some time and effort making them have a better job it's also going to reduce the potential impact on mtr and ttr of the given indicator or you know security incident but at the first line really going to have considered things like when the ioc should be timed out and removed from that block list or who needs to know that the block's been put in place you know does an itsm solution need to be updated for reports and things like that so the more people we get involved when we identify a problem and a potential you know sore solution the more likely we are to get us right

the first time so and that comes from knowing your stakeholders knowing who you need to deliver deliver the successful implementation it goes beyond the development and the automation and you know you need to get involved with process analysts you need to get people that can track the pro the progress of your implementations and you know make sure that it's successful and that they're delivering value so on top of that you're gonna need political buy-in from stakeholders you're gonna need people in the c-suite that can sort of say get it done you're gonna really need to make sure that you've got as many people backing it as possible to make sure that you don't get stuck with

those blockers last thing you want is a backlog of cool stuff that you've made and some sort of politics is holding it up so soon you get those people involved sooner you're going to achieve value from use cases uh when i say use cases key distinction here for me is playbook is just submit that does the doing it takes an input it does some cool stuff and it makes an output a use case encapsulates that solution that little bit of technology the playbook but it's also all those other dependencies the stakeholders the sign-offs the definition of done you know all your requirements and how often it's delivered as well also for me thor is about delivering use

cases not just playbooks so uh internal politics really is the sort of biggest pain point for for me when it comes to sort of delivering tours my internal companies external companies whatever it is if you can find the right person you can often sort of expedite the delivery of things but you've actually got to go out there and find them so make sure you do do things like stakeholder mapping like really try and find who the key holders are who are the people that are responsible for making sure that you can get those credentials to a.d that you can put that block in place because it's been pre-approved that sort of thing uh with that as well it's you know

the more people you've got involved the more experts that you've got connections to thor engineers or your developers that are making your use cases and helping build out your sole platform they're not necessarily needing to be network engineers or you know proxy theme firewalls sort of streams whatever they just need access to those people so the more people we're bringing on board the more likely we're going to get these sort of right decisions made when we're implementing a block or responding to alarm you know so think of it this way would you rather have your team able to send you know a simple message an email or something like that and a proxy get block gets put in place

or follow a more traditional method where you say you know what let's raise the ticket and then we'll wait until someone finds that ticket picks it up reads it and then goes action it with saw you can get that response in seconds and you can actually empower people that have no knowledge of how to use a proxy system a theme system whatever it is to actually go do things with it you know get that remediation pull back that log data or whatever it is so yeah for me by having those experts in the first place you can use their expertise put it into your soil platform and then empower other team members to sort of essentially get a

self-service capability for you know various security tools um this is pretty true as well when it comes to intel decisions so if you're making a decision on fret intelligence like you know if if indicator is found in list go do remediation make sure that it's not your development engineers and making the choice on what is bad and what is good don't just rely on a tool or an open source intelligence list or whatever it is saying this is bad make sure you get your friend intelligence team involved or your ir team or whatever to actually really classify those iss that you might be making um a decision on so uh and then finally for me like uh i've

talked about you sort of saw team as maybe something a little bit separate so a strong saw team for me should involve your engineers that's someone that's going to build out those playbooks and really understand all the functionality of orchestrations can help sort of train you're going to need people that are good at integration someone that can actually go out there have the conversations and make sure that you can connect your saw environment to your av environment to your theme environment to your firewalls so you can start pulling in commands from each of them and actually you know some of some of the parts is essentially greater than the hole or whatever it is so uh

and a bpa as well you're gonna need someone that can come in a business process analyst uh and do what needs to be done go find those stakeholders out work out what the problem is in the first place and actually get that mapped out and make sure that you are delivering value but you're also sort of mapping that and you're able to communicate it to your stakeholders as well uh and bonus on top of that anyone that's got strong people skills people might get upset about saw being rolled out they might feel threatened by it so sometimes you need someone that can kind of help you there measure success for me is one of those

really important things once you've got everyone involved and you've got a platform you actually need to know that you're being successful i think we need to move away from those you know traditional sla type monitors and start using the platform for what it is you can actually develop metrics in-house for how you deem us your saw program to be successful and record them in the platform so you've got access to them real time you might have a you know web app access and and phone app access where you can look at that you know at any time of day and go yeah we're actually really getting benefit from from this platform so if you develop

your metric try and make sure that it's recorded in your playbook uh in your use cases use that sort of concept of metadata to record your success as well as go out there and do the security thing that you want it to um i've got three examples that we can sort of say here at the moment so we know that we've saved someone 18 hours with one playbook because it'll take on average 18 hours to do the thing manually or in the traditional way and we can do it in about five minutes so we save them 18 hours every time that runs equally so i can tell you last month you know we're running close to 6 000

use cases in automation so it seems like decent metrics and that with a single set of use cases we saved 60 grand a year in labor but you know are these actually what they seem money seems great until it becomes a stick to beat you with if for the platform cost you a certain amount do you end up having to save the equal amount in label to actually pay off your own platform because i know that people aren't measuring their av and their theme platforms like this and there is a scene a security platform this is an investment focusing too much on money as a metric it sort of means as well you end up

focusing on time and labor saved and not necessarily the things of the best security benefit uh equally so 18 hours time saved it seems seems great until you realize that this is probably going to be an outlier in most organizations so does this mean that if you create your next playbook and your metric if time saved well when the next playbook use case takes four hours and then the next one developed only saves 10 minutes things like that these are gonna look awful by comparison right so make sure that your keyhole stakeholders when they see these metrics they see positivity they see that reinforcement of of success and value money and time you you're not going to keep that that's

consistently high once you've got those sort of big wins out of the way uh use cases ran a month as well it seems pretty cool you're like oh yeah we've you know done nearly 6 000 use cases but really who cares there's no value in that number right what are the use cases what are they automating what was the impetus behind putting the use case there in the first place so we could run 10 playbooks in that you know nearly 6k and they could have huge impacts save the company from a natural compromise and you know they're valuable but they're lost the next 5750 might just be closing false positives so even though metrics seem really cool and

seem like they're going to show that success really try and think about well what is it that we're really trying to get across and what is it that we want to be measured by a bit of an example of that this from the real world um we had saw informing a customer of an event uh within literal seconds of it occurring and it took the humans that were kind of monitoring that event and creating tickets around it in the 90s platform another three and a half hours to tell the same customer about that data and about that event that had occurred that three and a half hours was still within sla so by those traditional

measures yeah well done that's that's a security success right that serves as a success but in real time that's potentially you know three and a half hours that an attacker could have been dwelling on the network so for me using saw it's time to get rid of those traditional metrics as slas and really move towards that sort of like what's the value we can bring it's that resolution doing that thing in seconds not hours you know so choose your metric i think mttr's probably one of the best ones and then once you've chosen it stick with that um one of the old managers i work with sort of said the last thing we need to do is

automate chaos and it kind of really stuck with me so when we are choosing what we're going to want to uh automate you've really got to understand why you're doing it and what it is that you're going for you know don't don't just try and automate as much as possible in one go pick the things that have those values that meet those metrics that we sort of just talked about we want to understand the actual goal of the thing that's being automated if we're looking into a process just because it works one way now doesn't mean that's the way it has to work as an automation we really want to focus on what's the input what's the output and

kind of don't worry you can use your saw platform to do the process bit of it so an example here uh we had a request in to essentially create a single pane of glass which can be achieved for this specific example in a solar platform pull in all the alerts and the priorities from different platforms put it on the single dashboard so we could achieve that it seemed like a pretty good goal but then when we started sort of workshopping out with the customer we realized that the reason that they wanted to see everything in one place is that they could tell people to respond to it a little bit faster so we soon realized there that even though the goal

seemed to be a single plane of glass dashboard it wasn't the real goal was response and a faster response so then instead we started working on how can we close those alarms down close those alerts down and actually resolve them because if you can access that data you can probably go do something about it so by implementing saw for them we were able to say yeah you can have that visibility if you want but you can also have the resolution happening before you even sort of get the chance to see it so really for me not automating chaos is all about making sure that the thing you're automating is following the sort of correct reasoning

that it's not just uh trying to automate the thing that's done now but it's trying to automate the reason for the thing that's done now getting the correct output not necessarily following up the same process so once you know what you want to make you need to start making it so slowly does it right uh the way that we deliver that is an incremental steps right so we'll take a use case and we'll break it down it might be the first thing that we do is focus on an action from that playbook so can we get the data from one place and present it to the user in an in in another place we're getting that value

straight away we don't have to be all singing and dancing once we know that's working it's working consistently then actually we might want to enrich it okay we've got the data can we add some more uh information from a cmdb another security solution that sort of thing deliver that get it consistent save people's time because they're able to use that enriched data and you've maybe saved them 60 of their job then move on to respond actually take those playbooks and sort of say well now that we know what the data is and we know that we're consistently getting it and that our users are able to react to the data that we've enriched can we can we just make that decision

for them in the first place can we go put that remediation in place so you then you build it into respond you do not have to do everything out the bag make those small wins collect that value early doors and you're gonna see that actually you know slowly does it it's a much faster way of delivering your value and then look at reuse the beauty of saw is everything you build kind of fits in like you know bit of a building block or a jigsaw when you develop one solution it might be that multiple teams can use it or that actually if you've got something that can go put a proxy block in place well

is there another use case it can use that so the more incremental building blocks that you use the more that you've got to sort of play with and actually start delivering your value later even faster so definitely sort of take it slowly take it incrementally and you know building those iterations essentially basically like agile one of the ways that we're sort of talking about slow delivery as well is making sure that you've got that priority don't rush into it don't try and take everything on all at once and try and deliver everything in parallel right if you try and deliver like say 11 use cases at once you're just going to find that your context switching too much

you're only showing gradual gains and stakeholders will start getting frustrated and you really don't realize the value until much further down the line by actually slowing down and sort of taking on just what your team can do you can start to realize your value a lot sooner if you focus on two or three priority use cases and you start delivering them you deliver them faster then you're claiming that value of it much earlier so it's a serial sort of development and incremental development i feel even though it's gonna seem slower to your stakeholders is actually a much faster way of getting success from soar and people struggle with a priority thing sort of like this concept of

if everyone's got a fast pass no one's got a fast pass right if everyone's coming to you and going my thing's a higher priority then nothing's highest priority if everything's high priority so you've got to be pretty strict in sorting out what your priorities are whether that's money mttr who's asking but make sure you do that and you know learn to say no to the people saying i need this thing now because all it's going to do the more you take on the faster you try and work the slower you're going to get that success than that value so yeah finally just to end um you know what's my opinion also where do we think we're going in the future

so is not something that we should be worrying about if you've got those problems and you get them in your environment your sore team not just a sole platform remember it's not a silver bullet but your sword team and the broader people that support you getting everyone involved a sub program can be those solutions you're gonna get some profit you're gonna get some value to your organization by using it whether that's reduced mttr you're gonna get happier people whatever it is so i think rolling out saw really can be a proper fresh start it's a way to move away from traditional metrics and do things for the right reason not because they've always been done that way you know oh

well we always put this into an excel sheet and then into this and then to this is actually the data that you want just like one thing that you could grab straight away you know think about actually doing things for the reason that we're doing them not just because it's the way that it's always done uh i think with saw we're gonna have to start using that as you know in our rfps as well because if products and security products don't offer apis i don't think we should be looking at taking them into our organizations anymore we have to make sure that the more security alerts happen the less people that we can employ to actually go look at them the

more easily we need to be able to interact with them so they're gonna need apis so i really think soar should become a key decision maker or will become a key decision maker when coming to purchasing security technologies as well so um yeah with that really i'd probably just say thanks for your time hopefully you've got some of use and if anyone does want to talk then you can sort of hit me up on you know linkedin twitter or something like that and ask questions so thanks a lot