What Is Threat Intelligence?

In this episode (originally recorded in November of 2021) we speak with Palo Alto Networks, VP of Threat Intel, Ryan Olson. Ryan helps define what threat intelligence actually is and how to get started building a program. He aptly reminds us that producing threat intel for the sake of threat intel is a waste of time. More importantly you first have to ask yourself, “Who’s going to be using this information?”.

Tweetables

“Producing threat intel for the sake of threat intel is a waste of time. What you should be doing is thinking ‘Who’s going to take the information that I have produced and use that to make a better decision?’ Because that's the goal of threat intelligence, to help a system, or a person, or a team, or a company make better decisions that will help secure them better.” — Ryan Olson [0:04:24]

“If I could give people one recommendation, if you can get access to your SSL traffic so that you can decrypt it and you can inspect it, you will have a much better chance at detecting bad stuff in your network than you would without it.” — Ryan Olson [0:29:58]

Links Mentioned in Today’s Episode:

Ryan Olson on LinkedIn

Unit 42

Unit 42 on Twitter

Unit 42 Palo Alto Networks Careers

Secure applications from code to cloud.
Prisma Cloud, the most complete cloud-native application protection platform (CNAPP).

Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.

Transcript

**NOTE: Generated via ML. Expect crazy stuff to be translated by an imperfect algorithm that may have never actually been said by the host or guest :-) ***

[00:00:30] MC: Have you ever wondered what it takes to build a threat research program? I mean, we read all of these reports that come out from these groups all across the Internet from multiple different vendors, and they sound cool. But how can you build your own threat research program? This is what I really wanted to dig into in today's episode. And we've got an awesome guest. It's Ryan Olson. He's the VP of Threat Intelligence at Unit 42. That's Palo Alto Network’s elite threat research group. And he talks about how Unit 42 started. He talks about what are the metrics you should be focusing on. So, I really hope you enjoy this episode. And I think you're going to find it useful. Even if you're maybe not in a technical role and you're just curious about it, this episode is for you. So, make sure you listen. Take notes. And if I could ask one favor of you, would you mind leaving a review for the podcast on wherever you listen? Whether it's Apple, whether it's on another platform, please leave a review. It makes a big difference. 

Enjoy the episode. 

[INTERVIEW]

[00:01:33] MC: Ryan, thanks for joining us today.

[00:01:35] RO: Thanks for having me on, Matt.

[00:01:37] MC: Awesome. Well, let's just start off by telling us a little bit about yourself and your role at Palo Alto Networks. What do you do?

[00:01:45] RO: Yes. I lead the Unit 42 threat intel team. I joined Palo Alto Networks about seven and a half years ago now. So that was 2014, early 2014 when I came on board. And at the time, that company was a lot smaller. We had a thousand employees or so. Primarily a network security company. They had just launched this new product a year or two earlier called Wildfire, which was this malware analysis platform. And our CSO at the time, Rick Howard, had come to me and said — Who I had worked with in the past in threat intel, said, “Hey, we want to build a threat intel team Palo Alto Networks. We've got all this data coming in from Wildfire. And we need people to start looking at it and not thinking about it from the perspective of, ‘Hey, can we just fix this one security issue? Can we issue a new signature? Can we do something like that to protect against?’ But to look more holistically at the data, and start better understanding adversaries. What can we do to defend our customers against those better? As well as who can we share that information with? Can we publish reports on it? Can we share with law enforcement and others and sort of build up our capability to share intel in the industry?” So that was the mission that I picked up as Unit 42 leader then. And then we continued that forward. The team grew with the company as we built new capabilities around endpoint, as we acquired new companies in cloud and otherwise, IoT. All the areas of security that Palo Alto Networks operates today, we grew the intel team to support those functions as well. And today, a much bigger team. Part of a whole business unit now that's conjoined with the security consulting group. And we continue that mission today, though. Look at all the data we have. Tried to understand the threats better. And to help the people who can use that information to secure themselves better do so.

[00:03:26] MC: That's great. Now, if you were sitting across the table from one of our listeners who was wanting to build a threat research program at their company, where should they start? How would you advise them?

[00:03:36] RO: Yeah. So, the first thing I'd recommend anyone looking to build a team, either threat research or threat intelligence focus in their company, is to think about what are you really trying to accomplish? Over the, I guess, the 16 years that I've been working in threat intelligence, a lot of people have said, “Hey, we're building a threat intel team. What should we do first?” And my answer is typically don't build a threat intel team, unless you've done X, Y and Z. Because if you don't have control over patching, let's say, or you don't have good visibility just as a security team into what's happening on your network and your endpoints, you probably shouldn't invest in an intel team first. You can probably make a lot more progress by getting those things done and secure in your network. But if you've got those done, threat Intel can be really valuable. And you should be thinking about what are you trying to accomplish? 

So, who's going to be your customer of your data? So, producing threat intel for the sake of threat intel is a waste of time. What you should be doing is thinking ‘Who's going to take the information that I have produced and use that to make a better decision?’ Because that's really the goal of threat intelligence, is to help a system, or a person, or a team, or a company make better decisions that will help secure them better. So, who's going to be your customer? Who's going to get the report? Who's going to get the data, whatever that's going to be? And how are they going to use it? Because once you have that sort of established, then you can make choices around what kind of team do you need? Do you need people who are going to build and perform malware analysis? Do you need people who have linguistic capabilities? Do you need people who are focused on cyber fraud? Because maybe that's the road of threat intelligence that you're going down. But it really is going to vary a lot based off what you're trying to accomplish, because no one's going to start their threat intel team with 50 people. That's not where you begin. You begin with one or two people, and you start trying to tackle a single task. And then you grow from there based off your success, based off your ability to help the people inside your organization do their job better. Because threat intel is really a support function when it comes down to it.

[00:05:31] MC: Now, do you see — I know you've been doing this for a while, right? Over seven years, just at Palo Alto. And I'm sure a lot longer than that outside of Palo Alto. Do you see organizations that have threat research teams? Is it more of those kind of the large multinationals? Or have you seen kind of the medium-sized businesses doing this as well?

[00:05:52] RO: Yeah. So, I'd say there's a lot of diversity, because there's a lot of different ways that people are approaching throat intel. So certainly, large companies, banks, fortune 50 kind of companies, they're going to be a company with a large SOC and they're going to have an intelligence group of some kind. Someone who's helping to inform the specific threats against their organization. 

As you move sort of down market, I guess would be the right term, to a smaller org, what you're likely going to find is a single person, threat intel guy that they've got inside their sock. Typically, it's someone who is in the SOC, and they sort of were the person doing the highest level, tier three, tier whatever you would describe it support. And they've now graduated to they're not the SOC person anymore. They're the person who is sort of just focused on what are these big threats. Who can interface with the SOC and supply that sort of really high-quality information to them that's going to help them make better decisions. 

And then as you go below that, instead of having an intel team, what you end up with is — And this is also very effective, a SOC that is using intelligence services, data feeds or other products. And they're working on how they just fully integrate that into their automated SOC. So that instead of having an intel team inside their SOC as they're looking at a hash, or a domain, or something else, that they have access to the right sources of information that can then tell them, “Hey, that domain you just saw, that's a command and control server. Or it's related to this malware family. Or to this particular actor group.” And that's, again, helping from a decision support perspective. It's helping them say, “This should be the right step I take next and defending against this threat.” So, I see threat intel used across all sizes of organizations, but you typically see it moving toward less strategic and more tactical as you move to a smaller org.

[00:07:38] MC: Now, I know that in the last few years, there has been the advent of this whole new field of automation security called SOAR technologies, right? Security, orchestration, automation and response. Where's the intersection between what SOAR does and what I guess I would call classic threat intel? Where do those two kind of come together? I guess, how have you seen that change over the last maybe three or four years?

[00:08:02] RO: Yeah. So, threat intel can be a data source for a SOC. It should be a data source for a SOC. In some cases, that happens entirely behind the scenes. So, for example, let's say you're using Palo Alto Networks products, and you're buying our firewall and you're using the threat prevention product, you're going to benefit from our threat intel team who's looking for new threats and helping inform the signatures that are being deployed. Helping to ensure that we've got good coverage. So, there's a threat intel sort of base to what most security vendors are doing. 

When it comes to the actual SOC, SOAR products typically rely a lot on information that's coming in from different sources. So, you have information that's coming in from your own internal visibility products, your logs, your logs from your firewalls, your logs from your endpoints, your logs from your domain controller, your logs from your cloud products, whatever they are. That's one thing that you're working with. Some of that might be incident information. And when you have an incident that your SOC is handling, they need additional information about whatever the threat is. 

And as a SOC responder is going through that process, they're going to see something like a hash of a file that their AV has detected as bad. And as they're going through their process, they need to make choices, “Okay. Is there something that I should just wipe the box, move on with my life, inform the user that we've restored from a backup? Or is it something more significant?” Because if you got a more sophisticated actor in your network, at that point, you're making a choice to say, “Oh, we can't wipe this box. We need to start monitoring this box. Know what the actor. Where else have they gone inside the network? We may need to do some more work.” That is where SOAR tools are really there to help automate the really simple processes. And some of those gather these pieces of information. And that's where Intel really integrates with the SOAR tool. 

In the past, before you had a SOAR tool in that way inside your SOC, you were probably doing this either manually. Meaning you’d get an indicator and you go look it up in a system. Look it up in a second system and a third system to say what do we know about it. Or you roll your own. You access their API and you build your own custom tool to go pull this information down. And that was a lot of higher-end SOCs who are saying, “We've got to pull off our own tools to access these API's.” And SOAR tools really just simplified that. They said, “We've got so many things that people should be able to automate. If we can integrate with the sources that they need commonly, if we can define the data types that they're commonly using, FQDNs, fully qualified domain names, or hashes, or IP addresses, whatever their flavor URLs, if we can define those and the source of information for them, we can either automatically capture that information for the SOC user and present it or make it just a button click away. And I think that's really transformative for a lot of SOCs, rather than having to have more manpower or the right manpower, the right people in place who have gone and written these scripts in the past and done all this work. Now, it's basically just click to connect these things together, which makes it a lot easier. The right information to make a better decision, threat intel.

[00:11:01] MC: So, going back to what you said a little bit earlier when I said if somebody wants to build it, what are some things they should look at? And you said make sure you're doing the basics. Kind of right patching, right? Kind of security 101 things that are probably still some of the biggest reasons that people have incidents, right? 

I'm a big fan of metrics, right? Being able to quantify the things that you're doing. And I'm curious if there's — Even if you just can think of it off the top of your head. Is there certain metrics that maybe if there's a CISO or some program manager who's listening, and they're thinking about, “Okay, it's near the end of the year.” Maybe they are in the process, or maybe they've already put their budgets in for ’22, and maybe they're trying to make that decision. Is building a threat research capability in my organization something I want to do? Is there a way to quantify that? Like, are we ready? Like, almost from a maturity standpoint, right? I don't know. What are your thoughts on that?

[00:11:57] RO: Yeah, it's certainly hard to quantify the maturity level of an organization. But I would say, as you're moving from — Let's say, you're done putting out the fires. So, you feel like you've got a handle on patching and all the compliance things that you need to do. And you've got an endpoint network security in place. You have visibility on what's happening inside your network. You should pat yourself on the back and say, “Wow! We're ahead of a lot of people.” And that's fantastic. And now you're thinking about you don't want to end up in the news because you don't want to be a CISO who was breached in a SolarWinds event or something else. And now you're saying, “I've got to report to my board. What are we doing to ensure we're going to be secure against that?” And you're not going to be able to say, “We patched everything, and we use the right AV and everything else.” That's not going to stop that. 

At that point, you're saying, “I need to have people in my organization who are hunting for new threats, who are looking for things that aren't an obvious indication that there has been a compromise. And for that, I need to know what do those look like? Because if they're obvious, if they're going to get caught by your AV, someone's already discovered them. They've been found. But if you want to be on the cutting edge and you need to know that, in a certain situation, if your endpoint logs a command from your data from your active directory controller, that might be evidence that it's been compromised, or someone is sort of poking at it, you sort of need a threat hunting team who can go and look for that, and they need to be well-informed. 

So, the place where I would say you should start looking to invest in threat intelligence at the human level, not by a service. Indicator feeds can be very useful depending on what products you're using. You should be thinking, “What do we want to achieve next? Is it a tactical goal of identifying intrusions more quickly?” And then it's a support function. You're measuring how quickly does your SOC identify that intrusion? Or how often are we discovering these threats inside your network? It's a challenge when you say, “We're going to find 10 bad guys in our network every week.” That's a terrible metric. You don't want to find 10 bad guys in your network. You want to find one and then ensure no one ever gets into the same route. 

But think about what the teams that the intel team is supporting can measure as far as their success and how your team's input to that can improve it. That's how I think about it for KPIs. And for maturity, it's sort of the same thing. What is the next gap that you have? You can't hire your way into security, in a lot of cases. People are expensive. Lots of people are really expensive. So, what is the very next best thing that you can do with headcount that you're adding to the team? The point that you get to that with threat, Intel is really going to be toward the top of the stack. You've got a really well-staffed SOC. You've got all the tools that you need in place. And now you're saying, “I want to find out what's the unknown stuff inside my network so that I can ensure that we're going to be defended against these really more significant threats.

[00:14:43] MC: So, when you look at threat research that's done on-premises versus the public cloud, from your perspective, what's really different? And maybe how should companies be looking to address any of the gaps? And think about it through the three lenses of people, process and technology. How do you see that?

[00:15:03] RO: I would say that it's very, very different. The thing that's the same as you're still are dealing with adversaries on the other side of the table, and they're still trying to accomplish the same thing. I was talking to a colleague a few years ago. We were talking about do we need to go and invest in cloud threat research? And I was sitting with them, and they were telling me, “You know the Kill Chain. We've got the seven phases. It's the same Kill Chain you've got to go through, whether it's in the cloud or not.” 

And what I did was I was saying, “True, they're still those steps. But it's very different.” And I opened up the list of AWS services. At the time, there were — I don't even know what there are today. Seems like hundreds of them. There’s a lot of them. And they all have all these names and everything else. And I said, “I've got a whole group of threat intel guys sitting out there. And they have been doing this for years.” And I said, “But if you ask them —” And I look through the list and I said, “If you ask them what role does Amazon Lightsail play in the Kill Chain? ‘They would say, “What is Amazon Lightsail?” And that's the problem we have. Because you might understand how the bad guy works. And you might understand how, on a Windows system or on a server, you need to capture data to identify that that threat is operating there. But in the cloud, the services are different. They operate in a different way. The way that people can attack them is different. Instead of worrying as much around have you patched every single vulnerability? You're much more concerned about what is your access control look like? How secure are your keys? Who can access this and from where? Because when you're working in public cloud, instead of having this hard, crunchy outer layer of a data center, all of a sudden, everybody might be able to poke at your thing. 

So, I think that's really different from a technology and from a process perspective, and from a people perspective, because it is different people. You need to have folks who understand all of these cloud services at a pretty deep level to be able to make those quick analogies to say, “Is this kind of service, it operates in this way? This is how an attacker might take advantage of it. If they were to take advantage of it, this is what it would allow them to do. “All those things are different in the cloud. And I think that's an important realization many folks have had recently when they're dealing with cloud incident response, or sort of trying to secure their cloud deployments.

[00:17:18] MC: Yeah. I mean, I think from reading the threat research, both things that are put out by Palo Alto Networks as well as other companies, it seems that — And I think one of the statistics I read was 65% of cloud security incidents were the result of customer misconfigurations. 65%. And one of the questions I often get is why is that number so high compared to on-premise environments? 

[BREAK]

[00:17:47] MC: Prisma Cloud secures infrastructure, applications, data, and entitlements across the world's largest clouds all from a single unified solution. With a combination of cloud service provider API's in a unified agent framework, users gain unmatched visibility and protection. Prisma Cloud also integrates with any continuous integration and continuous delivery workflow to secure cloud infrastructure and applications early in development. You can scan infrastructure as code templates, container images, serverless functions, and more while gaining powerful full stack runtime protection. This is unified security for DevOps and security teams. To find out more, go to prismacloud.io. 

[INTERVIEW CONTINUED]

[00:18:38] MC: I'm curious. I mean, I have my own thoughts on it. But why do you think that number is so high, specifically around misconfigurations in the cloud?

[00:18:45] RO: A misconfiguration in the cloud is incredibly different than a misconfiguration in a data center. So, a few years ago, it's probably four years ago now, there was this huge rash of ransomware attacks against MongoDB. People were — Bad actors were taking over a MongoDB database, encrypting the whole thing, leaving a ransom note and saying, “Pay us if you want your data back.” And people were like, “Why is this happening to all these MongoDB instances?” 

And as someone who's deployed MongoDB in the past in a data center, by default, there's no security at all. There isn't even a password. At least at the time, this was the way it was. Because it was expected to be deployed in a data center where you had other controls that limited access to that machine to only the system that needed to access it. But then you shift the model over and you say the place we're going to deploy this is in a cloud instance, which is going to be wide open to the Internet. And all of a sudden, there are thousands of them open to the Internet. That's a misconfiguration. A misconfiguration on behalf of someone who probably didn't know better necessarily that they needed to take some other action. They probably thought this software will be secure. Or maybe they deployed it. It's a really small project. They didn't want to worry about all that. Causes them challenges for actually adding authentication. But all cloud instances, from deploying buckets for Amazon S3, to something, to anything, basically, it comes down to how have you configured this system for access control? And if you make a mistake, the wrong mistake, you could configure it for everybody can access this entire thing, which is just not possible in a datacenter. 

In a data center, you would have had to go through, and people will complain about this to the end of time. So many people to open up ports in firewalls to be able to poke in from the Internet to be able to get to your server that there's no way you're going to do that on accident. But in the cloud, it could literally be a checkbox. And that's very convenient, but also potentially problematic, which is why 65% I would completely believe. I'm interested in what the other 35%. I bet you, there was also misconfiguration in those cases, but maybe just not exclusively misconfiguration.

[00:20:51] MC: Yeah, I think you're right. I mean, I would have answered a similar way, and that what existed? And I see this all time when I speak with clients that are either just moving into cloud, or maybe they've even been there for a couple of years, is that the governance processes that were in place in the on-prem data center, those have been built over the last 30 or more years, right? So, you got 30 years of people process and technology around governance, different layers of checks and balances. And all of a sudden, even if you've been in Cloud for five years, well, that's still only five years, right? And it just takes time in many cases to build a similar level of governance around it. 

And I guess, like you said, you'll hear especially from developers, right? We need to be able to move fast in order to compete. And that's a valid, valid business need. But it's like, yes, cloud does all these wonderful things. It allows you to move quickly. But if you don't build compensating controls of some sort, you are going to end up with 65% being misconfigurations.

[00:21:54] RO: And you sort of have two choices. Like the way that those controls and change review boards and everything else were built up over the last 30 years weren't because someone sat down 30 years ago and went, “You know what we should do? Let's build a change review board and think about all of these things.” They experienced pain. They had somebody on a Friday afternoon make a firewall change that shut their whole business down and required everyone to work the whole weekend. And now they have a rule. There're no firewall changes on Friday afternoon. And you got to go through these other steps. And your options are go through that pain and build that process up or think about it in advance. Think about at least the common stuff that you might be able to control for. Build a policy that ensures that the simple things other people have experienced, that's also part of threat intel, is know what other people did wrong. Understanding breaches that are occurring every day. Knowing that 65%. That fact alone are related to configuration should make anyone say, “Okay, what do we need to do to get control to make sure we're not one of those and we don't experience a breach because somebody mis-checked a box or made another simple choice? Because we'd rather not feel that pain. No one wants to spend their whole weekend dealing with an issue like that, because somebody made a mistake. No one did it on purpose. It was just an accident. And you'd also don't want to build up a change review board over 30 years. It's going to be a whole different world in 30 years.

[00:23:18] MC: Very true. And I can personally attest to that. We had a rule at many moons ago when I was a firewall administrator. We had that rule. Because after spending a number of weekends, because somebody's like, “Just push this one change through.” It's just this tiny little thing. 

[00:23:31] RO: It’s really small. Don’t worry. 

[00:23:32] MC: It’s a really a small change. And then all of a sudden, whatever the rule set fails while it's deploying, and none of your firewalls work. And then you're there all weekend. And the person who requested to change, their home with their kids. So yes, we definitely had the like no changes after noon Eastern on Fridays. So, yes. You had to go, though. 

[00:23:47] RO: Absolutely. I mean, bad guys would agree to that one. 

[00:23:50] MC: I know, right? 

[00:23:51] RO: No breaches Friday afternoon.

[00:23:52] MC: No breeches must occur before noon on Friday. That's it. Monday through Friday. Yeah, that's true. That's true. So, I know that Unit 42 obviously — As you said, you guys have expanded a lot over the last number of years. And I'm just curious. You have kind of the insider view of all of it. But what are maybe some recent areas of threat research that have your attention that you think our listeners maybe should be aware of?

[00:24:19] RO: Yeah. The things that the last year we've talked about it a lot, but it's been on my mind for the better part of three years, and I think we're going to talk about a lot in the future, is the software supply chain. The SolarWinds attack was one that sort of brought this to everybody's radar. But from a — It was a huge attack. A lot of organizations were compromised, because SolarWinds was compromised, and they have a lot of customers. From an impact perspective, though, it wasn't like everybody who had the software experienced a lot of data theft. It was relatively targeted beyond that. But that is not what I would expect in the future. The fact that you have other people software running inside your network, which is true of every single network, your operating system, all your other software, you oftentimes also have vendors who have access to your network, managed service providers of all kinds, they have access to your network for legitimate purposes, but they may be compromised. 

Everything that we do around patch vulnerabilities. Let's make sure that everyone's got multifactor authentication. It's all really important in keeping out sort of the basic attacks that could just poke in and attack your network anytime. But the real sort of Trojan horse, I will say, to use a security term in a different way today, for most people's networks is those almost insider threats, where something is allowed to be inside the network, but can be compromised in a way that gives them much more access that's going to be harder to attack. 

And SolarWinds, that attack was very successful. We've seen other attacks this year, the Kaseya VSA attack was sort of in a similar vein, with managed security providers being or managed service provider being the route that came in. But we've seen these attacks for years. And we've seen antivirus programs that had Trojans injected into them. A few years ago, Unit 42, wrote about a BitTorrent client that had had ransomware injected into it that was targeting Mac systems. We saw, even at the library level, this is five years ago almost Apple's Xcode product, a version of it had been modified and uploaded to a bunch of Chinese web servers, so that when people were downloading Xcode from China, they were getting this version that would modify their iOS apps before they uploaded the App Store. It impacted hundreds of apps that was installed hundreds of millions of times. That software supply chain is a way to get to things that you just can't get into other ways. And it doesn't have to be a really advanced attacker. It just has to be someone who's saying, “You know what? Software vendors —” There's so many small software vendors who have huge products, and a 50-person team, and none of them work in security. And if they're compromised, all it takes is the ability to access their source code and modify it. And you can get access to so many people’s system, so many people's important devices, phones, and otherwise. That's what people should be thinking about. That's one thing, at least, once you've got the other stuff handled.

[00:27:09] MC: Obviously, you're right. This has been a huge topic since SolarWinds. I know Unit 42 published a report, I think it was just in the last two months, around supply chain threat specific in the cloud. Let's just — Without maybe focusing specifically on cloud, but what are — I think many organizations, as they look at their budgets in ‘22, this is like probably number one for them. Where do you — Obviously, you hear the term zero trust bantered a lot about. But from your perspective, your years of seeing threat actors, seeing how they work, where do organizations? Where should they be looking to, like really focus to get the highest return on investment when it comes to addressing supply chain-based threats?

[00:27:52] RO: So, the thing that I like most about the concept of zero trust, which I think everyone — I don't think there's anyone who says it's not worth pursuing. I think everyone is basically like how would we technically achieve that? But let's say, as a goal, being able to inspect and authorize every single transaction that's occurring on your network. That's effectively — You know who it is. You know that it's authorized. You know that it's not bad content that's being transmitted. I love that concept of it and the pursuit of it because, one, it would make a software supply chain attack something that you could prevent. Because, presumably, that system that was compromised would be acting out of the ordinary in a way that was different from what was expected. 

But it's also true for an insider threat. Someone who's gone rogue inside your network, if they are doing things that they shouldn't be authorized to do, they're acting out of the ordinary, it's something you'd be able to detect. You have the right visibility for it. And the same for malware, and ransomware, and every other threat. If you can get to that point where you do have complete visibility inside your network and you are authenticating every transaction between a system as well as the user who's on it, and you're able to inspect that traffic to be able to say, “I can see that this doesn't contain malicious content,” you really have achieved a very high-level of security. And it's one that not every organization is going to get to. But I would say people thinking for next year, as you're pursuing that route, I wouldn't say go and look at — You should know what software is running inside your network. You should be aware if any of them have experienced the software supply chain attack. But I wouldn't say ask them offer their source code and tell them you want to have spent millions of dollars reviewing all of it for something. Because I promise you, they didn't intend to be compromised. And they're looking at their source code, too. It's going to be pretty sneaky for how it gets in. But if you can pursue those aims for zero trust, you're going to defend yourself against supply chain attacks, a lot of them, as well as all sorts of other threats. 

And normally, when people are talking about zero trust, like they're somewhere along a journey toward it. They've got some level of visibility. And the thing that I have found a lot of organizations missing the most visibility is around encrypted traffic. So, if I could give people one recommendation, if you can get access to your SSL traffic so that you can decrypt it and you can inspect it, you will have a much better chance at detecting bad stuff in your network than you would without it. So many actors, they know. They know people aren't decrypting SSL. They either aren't capable of doing it technically, or they haven't got the sort of authority inside their company to say, “We need to go inspect this traffic.” And if they're not doing it, you're going to miss most of the threats.

[00:30:26] MC: I think you're right. And I think it's obviously the technology to crack open SSL has been around for a very long time. So I think — I know I've spoken with at least a number of clients, probably not so much in the last two years, but right around when GDPR was really kind of coming into its full force. Companies are like, “Well, I can't do that anymore,” right? But, obviously, if they work with their privacy teams, they'll find out that, at least in my view, you’re actually like, “In order to be compliant with GDPR, you almost have to do it,” right? Otherwise, you're not providing that same kind of standard of care.

[00:31:00] RO: Yeah. It's certainly still possible. And you don't have to decrypt everything. If you've got the right technology in place, it's not like it's an all or nothing where you say, “I have to either let every single website be fully encrypted and opaque to me.” Or look at Suzy down the hall’s medical records. Like those are not a binary choice. You can make policy choices around that and have your users agree to those policies, and get everyone comfortable with it from a privacy perspective. 

But especially for new websites, websites that haven't existed for a long-time, websites that aren't — Things that we would classify as healthcare related, or banking related, or something else. Yeah, crack those open. Look at the traffic. Look at that content, because that's how it's going to come in. It's very unlikely that you're going to see the threat that came into your network that didn't come through an encrypted channel at some point. Even if it was over email, that's going to be encrypted at some point. Maybe you can crack an email open at a different spot, you’ve got it. But it's a worthwhile endeavor to go down to get access to that network traffic.

[00:32:01] MC: So one thing that we know from — I know, from studying leaders over the last decade or so, is that leaders, they’re learners, right? They're constantly looking for how they can kind of see what's new and see what's around the corner. How do you specifically continue to learn in order to stay on top of things in your role?

[00:32:19] RO: It's sort of just part of being in threat intelligence in general. I don't know how many sort of jobs are like this, but people pretty much expect me to know about everything that's happened all the time. 

[00:32:29] MC: You do, right? You know everything. 

[00:32:31] RO: That's the expectation. So, that means that I need to follow a lot of different sources to know about what breaches have occurred recently. How did the breach occur as far as what was the best knowledge that we have about it? As well as what techniques were employed in that breach for people to get access to the information? 

So, for cloud breaches, just as an example, if people are compromising containers, if they're doing it through new means, if they're escaping from virtualized systems, all of those are pieces of information that I've got to be able to capture. So, I read a lot of news about breaches, in particular. And I use a lot of information from social media, because that's really useful. And I rely a lot on my team. They are a great filter of things that are new. So, we have a chat channel where, basically, are just people dropping in new piece of thread intel every week, of new breaches, new malware, whatever it might be. And I don't need to — At my level, I don't have to have really in-depth knowledge of how a piece of malware operates. I was a malware analyst a long time ago. I'm no good at it anymore. I don't need to open IDA Pro and reverse engineer things. But I do need to be able to understand is what this new piece of malware is doing something that's novel? What does it allow the attacker to do that they couldn't do before? And is it something we're going to see in a lot of cases? Or is it going to be pretty narrow? And that just means consuming a lot of information from lots of sources. 

I listen to podcasts. I don't read security books anymore. Security books — When it comes to big concept security books, I will read. When it comes to security books about threats, they are going to be out of date by the time they get published. It's just not possible for a book publishing process to tell you about something new. It is very helpful to go back in history and learn about what has occurred. But as far as new threats, you got to stay on top of every breach course you can get, other vendors especially. Like we publish a lot. But there are so many vendors who are discovering new things and talking about what's occurred. I recommend everyone consume all of it. And keep that in mind that everyone is — In some cases, they have a desire to make something sound more important than it is, especially vendors. That's one thing that we try not to do. But you'll have a report come out that says, “This is the greatest, biggest threat to 7 trillion systems all over the world. New protocol vulnerability has been discovered, and 4 billion devices on the world habit.” And my next question is, “Have any of them been impacted by it?” If the answer is no, then the question is, “Will it be or not?” The number of — I don't know. IoT vulnerabilities that have come over the last three years, where must be every device on the planet has a network stack vulnerability at this point. But how many of them have been — People have been impacted by it? I think that number is still pretty much zero. So, yeah, I don't know if that answered your question, Matt. But a lot of sources, that's my best answer I can give you.

[00:35:17] MC: So, I know that you know before the show you and I were chatting, you're saying about all the hiring that you're doing on your team as Unit 42 grows. What kind of roles are you guys hiring for? And how do people find out about those roles?

[00:35:28] RO: Yeah. So, you can find out about all the Unit 42 roles on the Palo Alto Networks careers webpage, which I don't have the URL handy for. But Google Palo Alto Networks careers, and you'll get there. Unit 42 is hiring for specially cloud security consulting roles. We want people who have great background in cloud security to assist our clients who are experiencing cloud incidents. We're also building a cloud engineering team to support that group. Just with tools, we’re able to deliver scripts and other systems basically to help them do their incident response job better. We’re hiring product managers. We’re hiring more threat researchers as well. So, yeah, check them out. We need great people. And there are a lot of great people out there.

[00:36:06] MC: That's great. So, if our listeners, if they want to connect with you and Unit 42, what's the best way to do that?

[00:36:12] RO: Yeah. The two that I'd suggest, unit42.paloaltonetworks.com. That's the main website. That's where we publish all of our research. And from there, you can link to everything else that we do. And follow the Unit42_Intel Twitter handle. That's where we tweet about stuff. We've got quite a few people who are following that now. We chose about two years ago — Occasionally, we have a topic that we might want to publish a blog on. But publishing a blog takes quite a bit of time. But we'd be like, “Let's just drop this on Twitter, just so that we can share this thing that we found.” So, there's quite a bit of content that just comes out there that you'd never see in the blog, because we just want to share something short that we discovered. So, check both of those out.

[00:36:49] MC: Awesome. Awesome. Well, Ryan, it's been great chatting with you, learning about kind of your background, how you see throughout research. And it was just really great talking to you. Thanks for joining us today.

[00:36:58] RO: Thanks for having me, Matt.

[OUTRO]

[00:37:06] ANNOUNCER: Thank you for joining us for today's episode. To find out more, please visit us at cloudsecuritytoday.com.

[END]