So yes, what I'm gonna talk about today is in security automation. We're gonna be talking about some of these strategies for success and also strategies for failure. I like to talk about strategies for failure because I'm a younger brother, I have two older brothers and I learned a lot from their bad examples, and I think we all can learn from bad examples. So let's get started a little bit briefly about me. Who am I? Why am I talking about this? I am principal security researcher at MasterCard and also a cybersecurity professor at Utica University. My doctorate when I, my research focus was on security automation and adaptive cyber defense, really targeted on the financial services sector. Started out very early in the security automation arena before there were sore vendors, security orchestration, automation vendors. So let's go ahead and get started. First of all, I always like to ask, you know, why are we doing security automation?
You know, and the, the first answer I would say, if, if you're doing this to reduce costs, save money. If that's why you're doing security automation, go ahead and stop. If you're doing that to save money, just go ahead and quit now. It's really not a good strategy and we'll cover more why, and we'll come back to why these organizations that I spoke with during my research, why they implemented security automation and what they've seen from it. So first of all, real quickly on the current state, why are we, why did we even start implementing security automation? Well, of course, one was dealing with the asymmetric advantage that the attacker had because the attacker gets to choose the time and place and, and you know, we have to respond, we have to respond quickly. There was of course, once of vulnerabilities out there. It's very quickly exploited and can be used repeatedly if we're not ready to respond.
So we also saw, of course, the increased sophistication of attacks. When we're dealing with detecting some of these attacks, it becomes increasingly difficult. So, especially targeted by very highly motivated attackers. So like advanced persistent threats or APTs. Cause when they start attacking for one thing, they're going to pivot. They're going to change their methods, they're going to move about in order to achieve their target. So when you're facing a highly motivated attacker like that, it's kind of difficult a lot of times to detect those. So we had a lot of problems. We've kind of felt like the lady here trying to hold back the great white shark. I'm a scuba diver, but I don't think I would do that. And we also saw the need for speed, right? Where our human centered approach, where the human was always in the loop with everything that happened, just could not keep pace where in and by attack attempts all the time.
And so we, we saw this real need to, of course increase, increase our speed of detection and response. And finally, as any of you have been in this industry, I, we, we, we just don't have enough of us. And I'm, I'm in my other job where I'm, I'm teaching, I'm trying to teach more of us to come along. So cuz we, we need more. So the conceptual framework that I built, and I actually used this as part of my doctoral research, was how we had to address both sides of the equation to really address that gap. There's a huge gap between how long it takes an attacker to compromise versus how long it takes for us to detect and respond. And I saw it as a two sided problem. The first half was about increasing our detection speed, reducing the time and cost to respond. And that was by using automation and intelligent sharing. The other side was about trying to impede the attacker using things like a deception, which I've spoken about at this conference before. Deception and adaptive defenses. So by combining those, hopefully we could decrease that gap today, of course is focused on the top half of that, the automation.
So why when we try to speed our detection response, what are we really, why are we doing this? What is really necessary when we have a very complex cyber environment? I would say it's, it's impossible for an Analyst to have full situational awareness without some sort of automation because there are just too many parts to bring in there. We talk about automated enrichment. This, this allows us to improve that Analyst situational awareness by bringing in data from all over, right? So it's bringing in our internal data as far as the, the host, the, the network as well as external data to provide full situational awareness. So this photographer here might realize the penguin he's trying to photograph, he's looking for him. There's one right behind him. He doesn't know that. Then the human, So we talk about the concept of the human being currently in the loop. So the human having to be involved in every movement, every decision, but moving more to a human on the loop where the human is, we're, we're freeing the human to do what they do best, which I always talk about is the discernment, the decision making. That's where humans are adding their value, right? It's not in the repeated lookups and things like that. They're, they're not really adding value there. And then also improving the intelligent sharing to try to try to decrease the use of reuse.
So back to the initial question, why security automation, if we're not doing this to reduce cost and save money, why are we doing it? Well, there are a lot of benefits and I'll say from now, from going through the rest of the presentation where you see the orange boxes with quotes, those are quotes from some of my research participants. So why are we doing this? Well, first of all, increased visibility and decreased time to detect what, what we found is there are, there are a lot of events that most organizations weren't seen before they automated because they didn't have the throughput to do it. Analysts doing stuff like marketing it as false positive cuz they just don't have time to look at all these. So that gave us the increased visibility and also the speed to respond. And that's really where I like to focus is how much, how much greater visibility, how many more events I'm seeing and how quickly am I responding to 'em because that's what really matters there.
They're time savings and efficiency gains. But that was more around, we're having the efficiency in our processes, allowing our analysts to do much more advanced work, allowing our analysts to do threat hunting that they, the, the things that humans are much better at and that they love to do. And a side benefit we saw was this process consistency and being able to use this to train new analysts cuz we have to go through the process of documenting our playbooks and our, and that it really gives us a good education material for new analysts. So it's really good. And then so some of the main use cases that we've seen with security automation, the first one really around probably the most frequently used and cited was this idea of event enrichment and co-relation. Because in that, you know, the, the event triage, if you've ever been in a, in a security operation center, that that triages what really consumes a lot of time and effort going out to all the various data sources.
Hopefully they're collecting all the data they need. In this case we're able to do that enrichment by going, you know, pulling in endpoint endpoint information, host information, user information, all this internal data, but also the external enrichment from contextual from outside vendors, outside sources and present that situational awareness so that a, an Analyst can make an informed decision and very much related as the intelligence processing. Cuz most of these financial services industry companies, as you can imagine, have a lot of different intelligence feeds coming in. So being able to process through those and rapidly determining what is relevant and not relevant to our organization. Automated response is really not a lot of work in that, what I've seen initially, but there are some around quarantining and blocking. So quarantining had possibly infected endpoint blocking specific network traffic and that and then detection and prevention use cases a lot of times around things like fishing emails inside or threat detection as well as, oh I already mentioned the email one.
So yeah, and malware remediation's another big one there from a detection and prevention. So kind of the use cases, they've all implemented. A real quick case study that we did, this was a integrated pilot and I would say that each of the organizations involved, they were all using different automation platforms and what we were able to do was the FSI sac, the financial services information sharing analysis center along with Johns Hopkins and the US Department of Homeland Security did this pilot. And what we were able to find was that the overall process, so this was the process of the FSI sec getting in an an ioc an indicator of compromise processing that getting it out to the respective financial institutions and responding overall, that process cut from 10 hours to four minutes. That means we can respond much quickly. And this, this allows us also when something hits one, they can quickly respond through all the financial services industry. So it, it's a great benefit there. So keys to success. So I talked, I said we talked about success and failure. I wanna talk about success first. I kinda like it better.
So first of all, the requirements I say from, for successful security automation, you have to dedicate the resources up front. Don't let anybody tell you that you don't need resources to do security automation. You do. And they're different resources possibly than you already have. You have to build that team the necessary skills that that team's going to have. First of all, some sort of leadership that leadership's going to help define the priorities, what, what use cases we're looking at and get the collaboration across the various teams that you need need, you're going to need an automation engineer. This isn't necessarily, this isn't your soc Analyst determining how to engineer a process, right? Get someone that knows what they're doing, skilled in the platform you're implementing. What I found you from my experience and from talking with others, you're also going to need development resources. Sure you can plug and play the security automation, but what we found the use cases when we start getting into what to do in particular cases when maybe a source wasn't available or it took the wrong move, that there's a lot of custom development we were still doing and most of that all in Python.
And then build that pipeline, make sure you know what your priorities are and, and take a very structured approach to how you're implementing those. Then you have to focus on those quick wins. You know, don't, don't go after that, you know, we'll get into what not to do on the next one. So go go into the focus on those quick wins. And what I mean by that, what I, what I urge 'em to do is if there's processes that are fully in control of the security team, take those on. Don't go causing issues with external teams or having all that headache first. Do it internally. Build up that trust because you're gonna need that trust and competence as you move forward. Also, make sure you have well defined process before you automate it. Always look for ways to improve the process as you do it.
And then low risk, high rewards. That's why I, I urge everybody look at don't go for the process. You know that that one really big hard problem I've been trying to solve is probably not the first process to implement with automation. Instead look for those that have very low risk, they're not gonna cause any business impact but they possibly could save a lot of time and money so that you can rededicate your resources, Things like that in Richmond process and most definitely build that organizational trust. You know, that you have to have confidence in this throughout the organization.
You know, and I like the one quote you see on the bottom about the, when you start trying to step into other people's areas, what he was referring to. And that was that they went and started trying to implement some automated responses into the network and the network team really, really pushed back on that hard until they could come to some mutually beneficial use cases, let's say. So keep that in mind, you go and I always love the, you know, make sure your processors are working so you don't do the dumb stuff faster. That's my favorite one. So that's how we succeed. How do we fail? Again, I said I'm a younger brother, I learned from the mistakes of my brothers. So how do we fail? There's a lot of ways to fail security automation. The biggest one is saying, I'm going in this to save money.
If that's the reason why you probably will fail, the one exception is if you are completely satisfied with your current visibility, your security's working a hundred percent automating it, we'll save you money and we'll do it quicker. The other one's, assuming that I can do it with the existing resources I have, it's just a side gig. Anybody could do this. It's an easy tool. You just plug it in and and plug all these things in. No, you, you do need to have specific resources to help with this. I would say also understand it's not a once and done your environment changes over time. You have to keep going back. Somebody needs to go back and reevaluate all these automated processes regularly to make sure they're still correct and going at with no clear priorities or pipelines. Just let that sock Analyst decide what he wants to what he wants to automate.
Yeah, we'll figure it out. And I've put these up cause I've seen organizations try these things and then the one about focusing on those biggest problems, right? Going out there saying here's this problem I haven't been able to solve. I got this new shiny tool, it will do it for me. Very big way to fail quickly. And of course the high risk if you, if you want to derail a security automation platform implementation quickly shut down some vital part of your business network. You, you will. And then just automating the current process, right? This is your opportunity when you're bringing this I, I look at implementing this as the opportunity to reevaluate all those processes. Are they correct? Am I doing them right? And that's why I say it, it takes a lot of resources, it takes a lot of time. And then of course destroying organizational trust just by automating the wrong things, tramping all over, destroying things.
You wind up looking like this guy looks pretty tough. Football game I guess. Or in America we'd say soccer, I dunno. But yeah, so, so be careful with that when you go out there. I i, I think I, one of the points I made in the earlier panel and, and it's one that I like to hit home is be careful also what you measure. What you measure will drive the, the what will drive behavior. If you're measuring this simply as a cost saved, that's what it's gonna be viewed at by your senior leadership. Then two years later you're going to get the question, why do we still have all these analysts? Because they're still gonna be there, they're gonna be doing different things. Instead measure this as increased security, increased events, increased visibility, increased quicker time to respond, look at it as an overall security operation center metric, not as a automation tool metric.
And I think that was all I had. See oh yeah, I threw in a couple just little examples that people that download can take just kinda showing how all these things go together. Quick, simple. I think one's on a file hash indicator coming in and how we would respond and then one on malicious file response and quarantining showing how it integrates all these different pieces. It's really neat. But I tell you that they look real simple when you first start, when you start exploding these things out, they get really complex real quick, right? And that's it. And then you have the resources. So I open up for questions. We have time.
Thank you very much Donny. Really great presentation. I fully agree. I would focus more on the positive sides, but I think especially in cybersecurity, we must learn also from the negative sides impacts the mistakes we did in the past to not do that. Again. We have one question from the online audience. Biggest advantage of security automation compared to the human is he faster or more accurate?
Is is not more accurate, is only as accurate as those that automate that program. The automation. So just like any other software development really, it's going to be more, what do you say? Consistent, not accurate, more consistent. So it's like in sports we hear this, I hear this all the time, the team's doing really bad and they say we need more consistency. No, you need lack of consistency. So, and that's where it's important in the automation. Yes, you're doing the process correctly. And when we're talking about repetitive task, especially in enrichment, it can be more thorough than the human because one given Analyst may not be getting all the sources, he's taking shortcuts, you know, the automation will not take shortcuts. It's going to do what you told it to.
Cool. Great. Any question from the onsite audience? Just give me a second for the microphone. Okay,
Thank you. Have you seen companies that did the, the low risk automation and that are now moving to medium high
Risk? Oh yes, yes. Definitely. And, and that that just, it's building up that trust not only within the security team but with throughout, because it's, it's scary. I'll tell you that when you start first moving into those automated response, now the way we've way I've seen that done is what we call, first of all putting that human on the loop. So let the, if you have that process, so have it running and recommending, so it's showing what action it would take your humans evaluating that, seeing if it's cr, seeing if that's the right response. Only once you build up the confidence from your sock, your security Analyst that yes it's making the right decision, then you let it start actively responding. It's kind of a reinforcement learning process you want to
Go through there. I like the per principal get you. So, but during some of my engagement sector I had, and obviously companies they do mostly low collection, rigor, gang creating, collecting logs and then creating actionable teams, creating actionable resources. For example, what do you see during your activity doing your research for example,
Right? A lot of them when, when they're implementing, by the time they were implementing secure, most of 'em by the time they're implementing a security orchestration sort of platform, the ones that I've talked with already had a security event management system that was already collecting all those sources. So that was one feed coming in, right? And from there it was about then doing the, trying to do more advanced co-relation of that data within the so and do doing the response. So it's kind of working hand in hand. And that's why, you know, it was kind of when this first started, I assumed that a lot of the sore vendors would start being purchased by other and that's exactly what's happened. Yeah.
Get them. For example, we follow
Up. Yeah, Palo and Block and FireEye all bought orchestrators.
Perfect. Just in time. It's exactly one o'clock. Perfect. Thank you very much Donnie. Great presentation. Thank you.
