- Welcome to The Cyber5, where security experts and leaders answer five burning questions on one hot topic on actual intelligence enterprise. Topics include, adversarial research and attribution, digital executive protection, supply chain risks, brand reputation and protection, disinformation and cyber threat intelligence. I'm your host Landon Winkelvoss, co-founder of Nisos, a Managed Intelligence company. In this episode, I talk with security architect at Marqeta and co-host of Hacker Valley Studio, Ronald Eddings. We talk about the fundamentals of automating threat intelligence, including the automation of forensic artifacts, such as indicators of compromise, and more advanced levels of automation, including actual attacker behaviors in the environment. Finally, we talk about metrics you use to show progress for security engineering program to the senior executive leadership team. Stay with us. Ron Eddings, welcome to the show sir. Would you mind sharing a little bit about your background?

- Absolutely, name is Ron Eddings, I am a co-host of the Hacker Valley Studio podcast, and during the day I'm also a detection and response lead at a financial technology startup.

- Cool, so today we will be talking about security automation, particularly within threat intelligence. So thank you very much for joining, this is gonna be an exciting episode. So starting out, assuming a mature security operations center, or cyber fusion center, walk us through the basics of cyber threat intelligence automation.

- cyber threat intelligence automation really needs to start with the use case, defining the use case, really understanding what questions are most vital for your organization to answer. Being on both sides of the fence, working as a vendor, and also working on a security team building security programs, more often than not, I find that security team members don't define their use cases. If you define your use cases, as in which threat intelligence capability we want to solve for, i.e detecting malicious binaries on a device, that's always the first place to start. If you have the tools in place, I like to look at, all right, what capabilities do these tools have? And then start walking the dog on automating some of the manual steps that are involved with those tools or those capabilities.

- Give us a couple examples.

- The age old example is automating phishing from a threat intelligence perspective. Before you can automate this type of use case, you have to first understand what are your capabilities and how much of this use case do you want to automate? I've worked with countless organizations and sometimes there's not a phishing mailbox that all of these phishing emails go into. And sometimes we also don't have the capability to automatically extract indicators from phishing messages like URLs, file hashes, so on and so forth, understanding the capabilities of your tools and marrying them with a use case. So if we want to automate phishing, what do we wanna automate about it? Do we wanna automate the detection of malicious phishing emails, or do we wanna automate the response that we send our internal users that report these phishing emails? Understanding where we want to automate in these use cases is really critical.

- I've talked to enough mature security programs, and a lot of them say, before you can really begin to automate some of the types of things you're talking about, particularly in threat intelligence, you almost have to go through a data acquisition strategy around storage and logging components before you can really be in a place where you're ultimately automating, you know, bad behaviors, whether that be IOCs or behaviors. First, would you agree with that? And I guess in addition to that, what storage and logging components really need to be in place before you start taking automation to the next level?

- Yeah, I would 100% agree. And my partner in crime, Chris Cochran and myself, we created this framework called EASY. And the E is for a list of requirements, that's really defining the use case, the A is for assess your collection plan. Before you can automate anything, really, you have to understand what do you have at your disposal? What pieces of data can you leverage to help yourself even more going forward? Sometimes organizations and security teams, they'll automate something that there's already a solution for. When you're looking at your SIM, for instance, understanding what do you have stored in your SIM, that is a great data warehouse for external threat intelligence and also internal threat intelligence. But if your organization is mature enough for a threat intelligence program, you likely have data spread across many tools. So understanding the lay of the land is really gonna be that step number two for automating threat intelligence.

- Yeah, I mean, I've talked to large organizations but not so mature security programs. You come in and on day one, they say, "okay we wanna be able to detect, you know, an APT," but they're only storing, you know, let's say a month of windows event logs. That's likely not gonna catch an APT when you've only stored, you know, a month's worth of event logs. So what are the different types of logs that are, you know kind of critical to be able to acquire in your experiences?

- Wow, the more the merrier at the end of the day. But I do agree with the event logs is a great place to look as much network traffic as you can collect and store is really great. The danger with collecting network traffic is it can become over cumbersome and bleed to very large bills, but the more network traffic that we have about our critical assets, our crown jewels, the devices that are helping our organization make money is gonna be really vital, but also cloud logs for many organizations were going through a digital transformation where migrating from on-prem to cloud assets. With looking at assets in the cloud, you might not have to collect as much network traffic, you can collect the actions that are made on these assets. So for instance, which user is spinning up cloud instances, these cloud servers, who's doing that, and collecting the information and metadata around some of those actions is really helpful

- When a program starts to mature and they starting to integrate some IOCs into a SIM from a feed, and they ultimately wanna start automating attacker behavior. So we're really talking about moving right on the MITRE ATT&CK framework. Would you prioritize attacker emulation of TTPs of various APT crime groups? Or do you start with basic frameworks such as MITRE ATT&CK and kind of like work your way left or work your way right?

- I've had a bit of experience doing both, trying to tackle attackers through understanding the TTPs of a specific group, but also of trying to implement MITRE ATT&CK matrix capabilities. And from my experience, just looking at from where I was at the past and where I'm at today, I would go the MITRE ATT&CK route, understanding what capabilities you can detect and defend against is really gonna be critical for how you handle the TTPs of an APT group. If an APT group is able to live off the land like you were just mentioning, maybe they're able to escalate privileges and mask their activity. If you don't have the capabilities to detect against that or to mitigate those threats, then you're gonna be really struggling to get that APT out of your environment if you're able to spot them in the first place. But coincidentally, if you start to implement MITRE ATT&CK matrix capabilities, then you may also by happenstance fine APT behavior or activity on your environment.

- So, a lot of, you know, industry experts have told me, you know, that you want to work your way right from left to right, really on the MITRE ATT&CK framework, right? So starting with recon elements and the ability to do conduct reconnaissance to gain the foothold, to moving laterally, would you kind of agree with that approach as well?

- I would agree with that approach. And I agree with the approach because when you look at the MITRE ATT&CK matrix, the capabilities on the left are a little easier to automate. When you look at things like scanning, enumeration of hosts, you can typically have some luck of detecting these types of behaviors through just classic rules or expert systems that analyst build or anomaly detection. When you look at things further on the right of the MITRE ATT&CK framework, you have capabilities and threats like, data exfiltration. For data exfiltration, you really want human intervention, you want the human in the loop to review the impact and the severity of that threat. So I would absolutely agree. And there's also a really great matrix called the Cyber Defense Matrix, and it talks about areas of the kill chain that are great for automation or great for technology, and also areas of the kill chain that are really where you want your security analysts, your incident responders, you really want them in the parts of the kill chain that require remediation follow-up and more digging when it comes to an alert

- Let's get technical here for a couple of minutes. What are the major technologies and even programming languages that you generally use from an automation perspective?

- My bread and butter has been security orchestration and automated response. When I first got into security automation, it was not called SOAR, but however, over time security coined security automation with SOAR, and SOAR has an element of incident response. When I'm looking at SOAR in general, and how do we automate security alerts and events, I'm really heavily focusing on Python. I'm using Python to take data from one API and use it as input for the next API, that's where the beauty of SOAR really comes in. And SOAR is also great for threat intelligence. When you are taking an action or get a new piece of information about APT, a threat actor, you typically wanna take that information and search in other tools to see if that information can be cross-referenced, correlated, and bring the results into a central location. So I'm a huge fan and implementer of all things, incident response related, but also all things that can help me automate security events, but my vote is always gonna be Python. Go is also a great resource to start to use for automation, especially when it comes to threat intelligence. If you're doing any type of attack simulation, you might need a programming language or a technology that can do many things at once, and Go is a great language for that.

- A lot of cyber threat intelligence programs are getting to be mature and have the interest certainly of the board for many companies. And of course, one thing they'll come down is ultimately what are the metrics you use? What kind of frameworks do you use to measure success? I think that we've even had a lot of listeners, you know, comment on the show that certainly the ability to derive metrics from intelligence programs is certainly a maturing facet in a lot of programs. What metrics have you found successful in communicating the value of security engineering automation? And finally, what can not be automated?

- You spoke about how security teams and threat intelligence programs are really starting to become more mature, and I also agree with that. I think that at the end of the day, security teams are focused on protecting the crown jewels, which is the money for an organization, maybe it's also the data, but that translates into some type of monetary asset. After you've hit that goal, and you feel as though you've secured your organization, you really wanna show how much time that you're saving for the work that you're doing. And this is really one of the great things about automation. Once you've built your security program, you can start to automate the collection of metrics. And one of the metrics that I always like to collect are the meantime that it takes to do an action. I like to focus on meantime to detection. This is how long does it take me on average to detect a certain threat, whether it's an indicator from an APT group or just the fact that a security event was triggered. After I look at meantime to detect, also meantime to respond is another great metric to start to automate and collect against. If you can prove to your stakeholders that you're saving time through collection and automation, it might lead to more funding for your program or at least reduced manual efforts for your team. So the meantime to detection, meantime to respond, but there's many other metrics that I like to look at too, like meantime to remediate, and also just the sheer number of events or groups that I'm tracking at a given time.

- How does that work out in practice? I mean, is it JIRA flow charts? Is it red teams in pen tests that are where you look to actually detect the meantime? Is this recorded in confluence somewhere, I guess? How does this actually work in execution?

- There's a few different ways, one would be through automation. When an event is observed, you would collect the timestamp. What time did this event happen? When the event was bubbled up to the security team, what time did we detect the event and start to store and case management, maybe JIRA? Now, that's also another great metric to capture when that event happens. And also the meantime to respond, capturing the time that an owner was assigned a ticket in JIRA, or an incident in their case management solution, is really how you start to walk the dog and start to capture all of these meantime to do an action.

- What in your opinion, can not be automated and truly takes world-class analysis?

- New threats. If we have not seen a threat in the past, it's very difficult to start to automate something that you know nothing or very little about. So for instance, if there's a new APT group that comes out of Austin, Texas, that's where I'm at right now, if there's a new APT group that comes out of Austin, Texas, how do you know all of the information about this APT group? You might be able to detect the fact that they attempted an attack against you, but you don't necessarily know all of the contextual information around that APT group. But I guess in other words it would really be gathering the context around the threat. Is very straightforward to determine that a threat exists or a threat was attempted, but retrieving the contextual information about the threat and making sense out of it is really where you need a human. And I don't see that being automated anytime soon.

- When you said the context around a threat that can't be automated. Can you derive a use case? You know, what was the part that was automated? And then what was the part that really needed an analyst to dissect it further and provide, you know, more context that ultimately led to a stronger action with regard remediation.

- There's been a few situations in the past that I've had to really focus on manual triage, the manual parts, and I could not automate it. And this example was for a new binary that was surfaced, because of an APT group, they somehow gain access to a device, they put a binary on the device, and also sent data back to a command and control. Well, none of this was really caught besides the fact that they sent data to a command and control server. The access to the device was not caught, the fact that the binary was dropped on the device was not caught, but the network activity was what we caught automatically. And when you look at this attack from like a higher level or more holistic view, we didn't have all of the other contextual information with our alert that was automated to say, "this was this group or this is how the attacker got onto the device, and all of the actions that they did after they got on." We had to do quite a bit of manual work to make sense out of all of the contexts that we had in our alerts, and also the context that we had and just our SIM that didn't bubble these events or informational events up to us.

- Ron, you are a master of your expertise. We appreciate you coming on the show today For the latest subject matter expertise around managed intelligence, please visit us at www.nisos.com. There we feature all the latest content from Nisos experts on solutions ranging from supply chain risk, adversary research and attribution, digital executive protection, merger and acquisition diligence, brand protection and disinformation, as well as cyber threat intelligence. A special thank you to all Nisos teammates who engage with our clients to conduct some of the world's most challenging security problems on the digital plane, and conduct high state security investigations. Without the value of the team provides day in, day out, this podcast would not be possible. Thank you for listening.