CyberWire Daily - Behavioral transparency – the patterns within. [CyberWire-X]

Episode Date: August 1, 2021

President Biden's Cyber Executive Order includes provision for a software bill of materials in government contracts. It's a critical and necessary first measure for protecting the software supply chain. To defend against cyber attacks like the ones that affected SolarWinds and Colonial Pipeline, organizations also need transparency about the way the software in their supply chain behaves–how, and with whom, that software engages in and outside of their networks. In this episode of CyberWire-X, we explore how behavior transparency can give organizations an advantage by distinguishing between expected noise and indications of compromise..Guest and CyberWire Podcast Partner Caleb Barlow shares his insights with the CyberWire's Rick Howard, and Ben Higgins and Ted Driggs from sponsor ExtraHop offer their thoughts to the CyberWire's Dave Bittner. Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the CyberWireX, a series of specials where we highlight important security topics affecting organizations worldwide. I'm Dave Bittner. Today's episode is titled Behavioral Transparency – The Patterns Within. President Biden's cyber executive order includes provisions for a software bill of materials in government contracts. It's a critical and necessary first measure for protecting the software supply chain. To defend against cyberattacks like the ones that affected SolarWinds and Colonial Pipeline, organizations also need transparency about the way the software in their supply chain behaves, how and with whom that software engages in and outside of their networks.

and with whom that software engages in and outside of their networks. A program note, each CyberWire X special features two segments. In the first part of the show, we'll hear from industry experts on the topic at hand, and in the second part, we'll hear from our show sponsor for their point of view. And speaking of sponsors, here's a word from our sponsor, ExtraHop. And now, a word from our sponsor, ExtraHop. Stopping advanced threats with network detection and response. Let's face it, cyber attackers have the advantage. ExtraHop is on a mission to help you take it back.

Regain the upper hand with security that can't be undermined, outsmarted, or compromised. With complete visibility from ExtraHop, enterprises can detect malicious behavior, hunt advanced threats, and forensically investigate any incident with confidence. When you don't have to choose between protecting your business and moving it forward, that's security uncompromised. See how it works in the full product demo, free online at extrahop.com slash cyber. That's extrahop.com slash cyber. And we thank ExtraHop for sponsoring our show. To start things off, my CyberWire colleague Rick Howard speaks with Caleb Barlow, CyberWire partner and former CEO at cyber resiliency firm Synergist Tech. The second part of our program features my conversation with Benjamin Higgins and Ted Driggs, both from ExtraHop, to explore how behavior transparency

can give organizations an advantage by distinguishing between expected noise and indications of compromise. Here's Rick Howard. I'm joined by Caleb Barlow, longtime cybersecurity practitioner and former vice president of the IBM X-Force Threat Intelligence team. He knows a thing or two about how cyber adversaries attack their victims. So Caleb, President Biden signed his executive order on improving the nation's cybersecurity back in May. One of the requirements was for vendors to provide software bill of materials or S-bombs to their customers. What's an S-bomb? Well, you know, if you think about it, it's kind of like, you know how when you, you know, buy a box of Corn Flakes, right?

The ingredients are on the back of the box of what is in this. And as we've all tried to get healthier, you know, we all kind of look at the back of the box and go, all right, what am I eating? Is this corn syrup or is this sugar? Well, a software building materials is kind of like that. What's in there? Well, a software bill of materials is kind of like that. What's in there? And the reality building software nowadays is that you don't start from scratch and build everything. You borrow tools and APIs and capabilities, both from code repositories, from open source, but also from various cloud tools and vendors. So when you look at a software bill of materials, it's really about understanding what's inside the box

so I can then decide, hey, do I trust this? And is it good for me? Not any different than the ingredients label on a box of cereal. Well, I got to tell you, Caleb, that having the ingredients on my Captain Crunch hasn't made me any more healthy. Well, we probably need to talk about that if you're still eating Captain Crunch.

But seriously, right? Like, we've got an entire, you know, if you think about it, we have an entire generation now that pays attention to what they eat. And, you know, I mean, look, my kids that are teenagers, they don't always eat the healthiest things. But they do know enough to look on the back of a label and go, oh, my, that's just chock full of sugar. I'm going to go get something else. In a lot of ways, security professionals have got to start doing the same thing and look at something and go, wait a second. This is chock full of open source. Do I know the pedigree of what's in here and who built it and where it was built?

So, okay, I have a list, and I agree that's a good idea to know where all that's coming from, but how does a security practitioner on the back end, how do they use that information? What can they do with that? Well, I think the reality is they're probably not doing it themselves directly. They're probably using a service either from a services firm or, you know, there's a whole cottage industry that's been built up to help people understand what's inside their software. And most importantly, when is there a vulnerability inside a piece of software or hardware that they may have deployed in their environment? So a very common tool set is to buy a set of tools that will scan your environment,

take an inventory of what you've got, hardware and software, and then alert you of when there's a vulnerability or something to be concerned about in those ingredients. So again, this isn't probably so much about a CISO sitting down and looking at every software package and trying to decide for themselves if it's good or not. It's more likely enabling a service or another piece of software to monitor that for them

because the reality is what's inside and if if that is vulnerable, could change all the time. I mean, look at how often we update our Microsoft technology to the point at which we've reserved one day a week just for doing that. So you see this as being an opportunity for young cybersecurity entrepreneurs that could provide this as a service. They would be the go-to vendor for their customer. They would be the experts at all the software that's out there and then advise their customers about what they should do about it or maybe even be given the permission to upgrade their software packages if they were found wanting.

I think that industry already exists. The challenge is the ingredients label doesn't exist on a lot of enterprise software packages that they were found wanting? I think that industry already exists. The challenge is the ingredients label doesn't exist on a lot of enterprise software packages, right? So although the industry is already out there today to say, oh, hey, you know, there's a vulnerability in SolarWinds in this particular version, or there's a vulnerability in this particular version of Microsoft Exchange, you need to get it patched. And oftentimes those tools will also help you with the patching. Hey, you're using this particular version. It has this particular issue. Here are the IOCs and TTPs associated with that. You know, if someone's actively attacking it in the wild, and then also here's the patch or point you to the patch or in some cases actually

facilitate the patching. The difference is the industry today often doesn't know what's inside an enterprise software package. And that's where this is the first step to starting to fix that. But I think there's a bigger thing underneath all of this, Rick, which is that at the end of the day, the U.S. government is doing something very interesting to influence the private sector. government is doing something very interesting to influence the private sector. So, you know, rather than passing legislation to say, hey, private sector, you know, you need to do the following things to get your act together on cybersecurity. What they're doing in the light of, you know, SolarWinds and the, you know, and the, all the recent major attacks is they're leveraging their procurement power. They're leveraging executive orders to influence the private sector through the purchasing power of the U.S. government. And I actually think that's not only a novel way to approach this, but it'll probably be pretty effective because the U.S. government purchases an awful lot of software and hardware.

and hardware. Well, it's amazing to me that this is a pretty technical thing. And it's a relatively new idea compared to some of the ideas that government has tried to do in the past. The fact that it's coming out from a presidential decision directive, that a president is giving us this order on this technical thing, does that mean that these S-bombs, that an S-bomb is a silver bullet? Is it going to solve all of our problems, or is it just one more thing we've got to do? Of course not. It's one more thing we've got to do. But you hit a key point here, Rick, which is this is now a presidential directive, right? I mean, just think about that for a second.

The president of the United States is giving us effectively a technical order, right? The United States is giving us effectively a technical order, right? But if anything, that just helps to articulate how big of a problem this is for our nation. So what you're saying is it's a different way to approach the problem as opposed to passing legislation that says, you know, you all should be better at cybersecurity because that's what basically most legislation has been over the last two decades. This is something directed at procurement, right? That you have to do this or contractors aren't going to get the contract they want. So it's a different angle and kind of innovative for the government to do this. Absolutely. And you know what? This has been going on for years in the private sector, right? If you're a manufacturer of a product or good, who influences you on quality, on cost, on availability? It's your retailer, right?

So this dynamic has been going on in supply chains for years. I think what we're actually seeing as we're talking about supply chain today is supply chains doing exactly what they're designed to do. Coming back around and saying, hey, what we're doing today is not acceptable. So if I'm going to keep buying from you, if I'm going to rely on you as my supplier, you're going to need to do some things differently. And just as we see the U.S. government flexing their muscles, I think we're also going to see banks, manufacturers, energy companies start to leverage their muscles in a similar way to say, hey, I need to know what's inside this software or hardware. I need to know who you're working with and where you built it. And I need you to demonstrate to me, not just tell me that you have good cybersecurity, I need you to prove it to me by having a third party either assess what you're doing or better

yet, validate what you're doing. So if I, I totally agree, this is a fantastic idea and we all should be doing this as, you know, best practice. But if I was going to, if I was going to ask you to place this on the Gartner hype cycle, where would you say it is in the journey? Is that the beginning or are we further on down the path that it's almost going to be useful to us out of the box? Where would you put it? Oh, that's an awesome question, Rick. I think we're right at that, you know, that inclination where you start to see the formation of the hockey stick, right? Yeah.

There are lots of companies out there that are kind of in this space. These capabilities aren't necessarily mainstream yet. And some of them are far more advanced. Well, to bring it back to the hype cycle idea for a second, I agree with you that it's at the beginning. Everybody that I've talked to about it says that this SBOM idea is right at the beginning and we're all very excited about it. But for it to become useful, somebody is going to have to figure out how to automate it all. Because right now, it's just another requirement, manual requirement that we have to collect all this information and do something about it. So until it can plug into our existing software deployment stacks, and then give me some

automated reports, and then in my fantasy world, be able to offer suggestions to patch it or to take it offline or whatever the recommendations are going to be. I don't see this as being too useful anytime soon. I'm thinking five, ten years. I don't know. What's your estimate there? Well, I mean, here's the thing. I remember, and I'm going way back here, right? But I remember in the early days of Lotus Notes and being kind of part of the team that would work on that stuff. Lotus Notes?

Man, oh man, that's go back a while. I didn't know. I'm old. I've read about that. But here's the thing. Oh, please, you were around then. But here's the thing, right? 30 million lines of code. I can't only imagine what it's at now, right? But there was code in there that Ray Ozzie wrote back when he was probably in his 20s that was still in this thing, right? It's true. It's very true. Oh, it's totally true.

And there's nothing wrong with that, right? We have to kind of acknowledge that these things exist and say, hey, I bet you some companies don't even know what's in their bill of materials because this thing's been too long. The problem I have with all that, and I don't disagree that there are issues like that in almost every piece of software that we run. But what do you do about it? If you brought up the SolarWinds attacks, a lot of people had that platform running in their organization because there isn't a lot of competition out there. You've got SolarWinds and maybe two or three other vendors. wins and maybe two or three other vendors. So the option is you run it at risk if you found out about it, or you rip it all out and bring in somebody else who probably has similar issues. So I don't know how that solves the problem too much, except it gives you something else to worry

about. Am I off the base there? Well, you're not totally off the base, but I think to a certain degree, we have to hold all of us accountable for the cybersecurity posture of our stuff, right? So we all have a fiduciary duty to look at the code that we're producing and say, look, can I say with a reasonable level of attestation that this is secure? Have I done all the things that I need to do to secure that? And, you know, the first step, as we saw in that executive order, is we better know what's in it. We at least need to know the ingredients. Now, you know, you get into all kinds of issues around trade secrets and everything else, but we're going to have to do this. So we've got to start somewhere. I think the wrong answer is to throw our hands up and say this is an unsolvable problem.

Yeah, I totally agree. And I would be glad to have it as an automated capability somewhere down the road. But let me ask you this, and let's turn on a dime. This SBOM is really the main thing it would work against is supply chain vulnerabilities, right? Is there something else we can be doing in the meantime? What else should security practitioners be thinking about as we figure out how to build this SBOM capability? I think the next thing we really need to be thinking about is actually advancing how are we looking at our suppliers, right? So, you know, kind of the state of the art, if you will, is you hire a services firm to go out and evaluate your suppliers, which usually involves asking them a bunch of questions, right?

So, you know, you ask them 40 or 50 questions of what do they use and how do they secure it. Once you've filled out one of these, everybody learns how to fill them out in a way that will pass. That's really not securing anything. All that's doing is creating a whole lot of work for a whole lot of consultants, by the way, including my company, to go out and do that work. But is it really changing the dynamics on the security posture? No. Let me come at it from a different angle, an angle that I think would have more impact sooner

than all of this SBOM stuff, which, by the way, I'm not saying it's a bad thing. I want to reiterate that. It's a great idea. I can't wait for it to come to fruition. But here's what I propose that we do today. I really think that we should institute a zero trust strategy for all of our supply vendors, right? And I know zero trust, it's become such a bad word because nobody really understands what

it is, right? But what I mean by that is, if I'm running SolarWinds, let's say, and I have the SolarWinds platform in my environment, I better know exactly, okay, what that software, what the administrators, what those accounts on that platform can do inside my environment. And watch it like a hawk and give them no permission to do anything of consequence inside my organization, right? And if I have to let them do something of consequence, I'm going to watch those transactions and make sure and triple check them and triple authorize them. I think that would have a much bigger impact than the S-bomb will have, you know, in say five to 10 years.

What do you think about that? I think you're spot on. And I think these things actually go together because one of the things you can do is collide these two ideas to say, hey, here's the deal. You know, we want to see your S-bomb and ideally you produce that, but anybody that can't produce that or won't produce that, then we better treat them in a zero trust environment, right? Because, you know, let's face it, there are certain situations where you need to bring in a vendor and maybe there's some legacy reason or some other issue of why you need to move beyond

zero trust. Well, in that case- There's always that reason, right? So yeah, go for it. There's always that reason. So, you know, but here's the really, you know, here's a great way to think about this. To your point, Rick, if I can't get the bill of, you know, so if I've got one of those exceptions where I've got to trust this vendor, then I think, again, it's completely reasonable to go and say, I need your SBOM. I need a full third-party assessment from a reputable firm. I need to know everything about what you're doing because I have to trust you. If for whatever reason I can't get that, they're a startup, it's too early, it's an intellectual property problem, whatever, or it's built in a country that maybe I don't completely trust. Well, in any of those reasons, absolutely has to be zero trust. I think at the end of the day, what we're learning here

is you have to look at all of these directives, right? Whether it's the work that's happening with CMMC, the presidential directive, it's all about getting a more robust supply chain. And I'll give you a little idea of why this is so important coming from an industry which we operate in. So from our own data, we go out and do a ton of work in the healthcare space. 76%, 76% of America's healthcare systems fail in securing their supply chain as measured on a NIS score. So just think about that for a second, right? Yeah. And this is critical infrastructure. And it's not that they're not trying. They're just not investing fast enough to keep up with the adversary. Good stuff, Caleb. Thanks for coming on the show. We appreciate it. Thank you. Next up is my conversation with Benjamin Higgins and Ted Driggs from ExtraHop, our show sponsor.

We've seen modern organizations need to move faster and faster to be successful in delighting their customers or their stakeholders and to survive competition. That's Ted Driggs, head of product at ExtraHop. As they've done that, the budget for security, especially upfront, has not kept pace. So instead, we now trust our vendors implicitly more than ever, and our vendors change their products' behaviors faster than ever to meet our needs. So that's created a situation where it becomes very difficult for analysts to understand what's in their environment, what behaviors it should exhibit, the consequences for interdicting those behaviors, and therefore it's very hard for them to block anything or take

action without a lot of fear and uncertainty involved. So just to key off of that, that's Benjamin Higgins, software architect at ExtraHop. Say you have a server, say it's running Windows and it's running an app, perhaps like SolarWinds Orion, and maybe you've also got an agent or some other admin software installed on that server. And perhaps you get an alert from one of your security products, or maybe you're just doing a threat hunt and you want to explore the DNS queries or the network connections for that server. The problem is, how do you quickly filter out known good network activity? If you've ever looked at DNS logs or net stat, which lists active network connections on a machine, you're probably familiar with this feeling of wondering what all of this activity is. So today, what you have to do, it's often not hard, but it can be very time-consuming to track down and investigate each behavior one by one. And the interesting thing when it comes to at least enterprise software, vendors already publish lists of some of their behaviors, in particular, external network behavior, for sake of their customers that are running that software in a lockdown environment where they have to configure their firewall to allow these known good connections to occur. So some of what we're going after with

behavior transparency, it's really just a small step beyond existing practice where we want to add two things. One is in addition to behaviors being listed on a webpage or in a PDF, we want to have a simple machine readable format that can be consumed by various tools and solutions, including firewalls for that use case I just mentioned, and also seams and EDR and NDR products or whatever custom tooling that companies might have. And the second is to have all of this information in one place instead of being scattered around the web. So with these relatively minor additions to existing practice,

we ultimately think that security analysts will be able to answer questions much faster about behaviors they see and potentially help catch supply chain or similar attacks when they do occur faster, especially when they target servers and server software that tends to have a more tractable network behavior profile. So that's behavior transparency in a nutshell. And what specifically is the challenge here? I mean, you mentioned that there's just so much information traversing the network. Is a lot of this separating the signal from the noise? Yeah, I think that's a big piece. Like I mentioned, I've had this experience many times when I'm looking at my own devices.

When I'm looking at net stat or similar output, you see all of these destinations, all these domains and IP addresses, you sort of wonder, like, what is all this stuff? The truth is, like Ted mentioned, software changes rapidly these days. Even at the OS level, whether it be Windows or Linux or something else, there's often a lot of different OS components that are reaching out in addition to the server software that you're running, as well as whatever sort of supporting tooling

or agents that you have. So that ends up being, even though it ends up being a large list, and most of the time, it's a completely benign list. But if you do have something that pops up on there, let's say you have a list of a hundred domains, a hundred DNS queries, which is probably a conservative number. And then one day you have something new that shows up on that list. Well, if you haven't already done the work to categorize all those other 100 items, your first step is first establishing that those are known good, that those have been documented by their respective vendors. And that work can be time consuming.

So the hope is that once you eliminate all that known good stuff, you're left with this sort of much more tractable list where you can do that manual investigative work. And you can find these potentially malicious behaviors much faster as a result. And this is not as simple as a who is, it's worth mentioning. So as we see software vendors themselves using third-party components, for example, for telemetry or analytics, if I see acme.appanalytics.com being invoked with a bunch of API requests, the whois information for that might not say that it's Acme Corp, but appanalytics.com may or may not have any ownership requirements

over subdomains. Maybe it was someone who just signed up for this fledgling app analytics service and chose a name to disguise themselves as something that's much more widespread. So one of the challenges that we've run into is that traditional tools for assigning ownership to things don't work well in these more complex ownership or partnership scenarios. And as an analyst, I'm now sitting there kind of puzzling over like, okay, this is a properly signed request, but it's by this company App Analytics. Do I need to go ask Acme if they use App Analytics legitimately? Who do I contact for that? Do I call my support person? Will they even know? How many

hours am I signing up for myself just on hold or in emails to get this answer? And then if I get this answer, great. That's not going to be a particularly satisfying return on investment to spend two hours trying to run this down and just find out, yep, that's a thing that we added a release ago and it's standard for our thing now. a release ago and it's standard for our thing now. Can you give me some insights? What is it like on the other side for the folks that you work with? In other words, the folks who are implementing behavior transparency and are seeing the fruits of that effort, what are the benefits that they're seeing there? So there's something that we're going to talk through at Black Hat in quite a bit more detail,

but we're going to look at four scenarios where the behavior transparency can help here. Some of these aren't built yet. Frankly, we're still working on building out an initial catalog, and we've been vetting requirements for it and scenarios with some partners. But the broad strokes are that this can be used in multiple places in the SOC lifetime. What a great example is with a SOAR partner, if, say, a scanning detection was fired, somebody could use the behavior transparency database to look up scanning on that particular port number and then report back, here are the softwares that that could be.

report number and then report back here are the softwares that that could be and then the analyst doesn't have to go look for themselves they now have software and ideally even links to documentation for each of those pieces of software explaining what it's doing that for another example would be the hey i've got a device in my environment and i'm trying to make sure i know all the software that's on it let's take those connections that it's making, run them through the behavior transparency database and see what software is on that device. So now I can use this to make my CMDB more accurate, more up to date. And then once I have that profile, I can now, to Ben's point, come back again and say, okay, knowing that this is the software that should be on there, tell me what connections it's made that are not explained by that piece of software.

How is this enhancing my relationship with my suppliers up and down that chain? You know, the people who are supplying me and the people I'm supplying things to, is this making it easier for us to keep tabs on each other and make that more of a trusted collaboration? Is that part of this, Ben? Yeah, I think so. So when you're in the situation where you're running software in a lockdown environment, you've got to publish this list and enable your customers to actually have it work in that environment. But I think when it comes to the completeness or the accuracy of that list, there's absolutely room for error. And that comes from a couple sources. One is like as you're updating software, that list of external destinations might change. Or it could also be because there's maybe a more obscure feature that it's only when you enable it do you talk to a new external destination.

And the hope is that instead of having just these one-on-one conversations with vendors, that potentially when you have this information centralized and you have more eyeballs on it, that there can be more collaboration and more back and forth as to the accuracy and completeness of the list. It also, for my downstream partners, participating in behavior transparency makes me a less exciting target for a supply chain attack. Because in order to get that behavior into the behavior transparency manifest to avoid it sticking out as an obvious oversight, somebody is going to need to make a public amendment to this repository. So that creates a lot more opportunities for someone to identify the bad behavior and to then burn whoever it was that emitted that update in addition to disavowing or otherwise retracting that false domain claim. So you could imagine, for example, in the SolarWinds Orion case,

let's say that the compromise of SolarWinds had been complete enough to push something as SolarWinds into the behavior transparency database. the behavior transparency database. At that point, the expectation is ThreadIntel providers are going to be very interested in looking at new additions to this database and who they came from. That domain is going to very clearly stick out as not being anything SolarWinds-related, and the expectation is that there's kind of a security in numbers that comes from a bunch of people looked at that domain and went,

huh, what is this? This doesn't match anything else that SolarWinds has done historically. It's not reflected in their website. We should reach out to them and ask, what's going on here? To make Ted's point in a different way, any vendor that's already publishing network behavior information would be benefited to publish that in this new format in a centralized place because, you know, a couple reasons. Like Ted mentioned, it makes that vendor less of a target for supply chain attacks because a potential supply chain attacker is going to see, like, this vendor seems to care more about security,

seems to care more about security, seems to care more about having people have eyes on their software's network behavior. And the other reason is, even if they were successful with a supply chain attack, having this information published in this way improves the chances of someone else catching it faster. So it would still be bad news, but it would be much,

you know, the harm would be reduced or minimized by being caught early on. So it really helps take you off of that list of potential low-hanging fruit. Yes, exactly. Yeah. Well, you mentioned earlier that you all are presenting at Black Hat on this.

Can you give us a little overview, a little preview of what we can expect there? You're going to have a little more time than we have today to dig into some of the details, yes? Yeah, so we're going to be going more in-depth into where behavior transparency in partnership with multiple security vendors or directly consumed by SOC teams would enable better decision-making or faster decision-making with better information at various points during the work of the SOC and of InfoSec teams. So everything from during procurement decisions,

CMDB building, threat hunting, and responding to alerts, where behavior transparency can be used by different stakeholders at each point, as well as an example of what a manifest might look like. So for folks who want to learn more about this, what's the best place for them to go for that? So today, the best place is to go to extrahop.com slash behavior transparency, all one word, lowercase. We've got a brief description on there and a form that you can fill out that we're using just for this purpose for people who want to get involved. On behalf of my colleague, Rick Howard, our thanks to Caleb Barlow for sharing his expertise and to ExtraHop's Benjamin Higgins and Ted Driggs for joining us. CyberWire X is a production of the CyberWire and is proudly produced in Maryland at the

startup studios of DataTribe, where they're co-building the next generation of cybersecurity startups and technologies. Our senior producer is Jennifer Iben. I'm Dave Bittner. Thanks for listening.