Techstrong Gang – April 9, 2024
Alan, Mike, Mitch and guest Chris Blask dive into the DevSecOps implications of malicious code that was deliberately injected into open source xz software to create a backdoor.
Then, in the wake of receiving a failing grade from the Federal government, they discuss the degree to which Microsoft has a unique set of cybersecurity issues.
Finally, the gang turns its attention to the role public-private partnerships should play in improving cybersecurity.
Transcript
Hey, everyone. Welcome to a cybersecurity Tuesday here on the TechOne Gang. We've got cybersecurity coming at you from a lot of different angles, but we'll probably discuss some more than that.
You're watching Textron Gang. Hey, everyone, back here at Textron Gang. We've got a great gang line up for you today, especially since we're talking cybersecurity.
We have all our cybersecurity heavyweights out here. Let me introduce them to you, first of all, coming at, at us from the Mile High City, our CTO and, uh, tech Strong Research analyst, principal, Mitch Ashley. Hey, Mitch.
Welcome. Hey, good, good day. Happy Tuesday, man.
Happy Tuesday. And then coming at us, not from the usual nautical setup. He's actually up in Canada where unbeknownst to him, he has a perfect view of the eclipse, and we're gonna hear all about that, the one and only Chris Blast.
Hey, Chris, how are you? Loving life. Good to see you folks.
Good to see you, Chris. And then, of course, joining us here, live in our Boca Ratone headquarters, our Chief Content Officer, Mike, the Dancing Machine, ard. Hey, Mike, how are you?
That's A, that's gonna be, requires too much explanation, I Think. Yeah. We're not gonna get into it, but Mike, it's another video.
Yeah. Another time. But we, we've got, uh, cyber to talk about.
Why don't you kick it off? Yeah, yeah. Well, there's been some interesting developments involving an open source package that the Linux distribution was heavily dependent upon.
And it turns out that one of the, so-called legitimate contributors was putting some malicious code in there on purpose, and it created a dependency and a back door that people could exploit. And I guess I'm gonna jump to Chris right here, but is this more common than we realize? I mean, are people kind of taking advantage of the, um, goodwill of the open source community to start injecting malicious code into these things and creating dependencies in ways that we don't appreciate?
I mean, how, how broad a problem is this? I, I would, you know, the, the clear answer is yes and no. Right?
You know, I, you know, everything will be okay. However, right? As always, we're moving through time together where we have capabilities and for various reasons in the security world, you know, the attackers, people who wanna exploit things, tend to take their first step, and they're taking that step because suddenly they can, you know, could you have done this sort of thing 10 years ago or 20 years ago?
Yes, maybe, but the effort would've been too great, or impact too low or whatnot. So we're moving in step, right? You know, that this, you know, he has, we discuss this all the time in the supply chain world, right?
This is software, bill of materials type of stuff. Where can I tell what's inside things? And there's a, a phrase I found myself using a lot in, uh, in the last couple of years, time to transparency, right?
You know, and this is another good example of one of these things where, in this case, if it hadn't been for some random, you know, developer noticing, you know, some 500 millisecond delay, we wouldn't be finding this now. And it would just take too long to find it, you know? But obviously it's, you know, the, the exploit is sort of a classic, it's not even cyber.
This is just, you know, we've been doing this sort of stuff for thousands of years. People like breaking into things. Somebody found a way into things and it would take too long to find them.
So we need, we need to lower the time to transparency and these sort of things. We obviously can't be doing it by hand, you know, going through every piece of code. So it makes us look at these relationships.
How do we attest to what's inside things we're about to find out. Yeah. You know, look, this is legit.
I mean, thank God for this guy at Microsoft who found this. But, um, you know, the, one of the things they teach you in law school, and they're teaching you how to draft contracts, is to try to anticipate every eventuality, you know, so how high up the chain is the eventuality of someone who's working with, seems to be working legitimately on code for months and months and months, and now starts injecting malicious code into things. You know, do we have deep like sleeper rings that have been put in here by, uh, nation states, or I just, again, you know, as someone who's been in in security for so many years, it's, it's so frustrating to how, how, you know, how do you plan for these eventuality?
I mean, you could try to plan, but how do you really stop this kind of stuff? Or do we just put everything into response? You know, Alan, I think one of the things about this that stands out, or there are several things, but one of 'em is they think the person who injected this malicious code in, in the actual tar process of the files that got distributed has been con working with the project for a couple of years.
So somewhere, I'm not sure exactly how long it is, but was became a contributor. Slowly adding, getting more involved, getting more involved, to the point where a lot of trust was built up and then boom, now account good have been compromised, but they don't think that's what happened. This is the, uh, cybersecurity equivalent of a sleeper cell, right?
Right. Mm-Hmm. This is, that's what I was trying to An account sitting out there just getting ready To, well, wasn't that that?
Or was this a, you know, a good guy who, you know, who, who's the doctor in Dune? Dr. Y Ywe, y who, Yeah, Youi, Youi, Youi.
You know, did someone kidnap his wife and force him and break his, his training or something? Imperial training? Yeah, I think that could happened.
Um, and, and at some level, who cares? What, what really matters is that this happened, and how do we prevent it or detect it and respond going forward? Chris, what should the security teams be doing with their development teams?
Because there's all this open source code, it adds tremendous amount of value, no doubt. But, um, when there's an issue or a patch or some sort of problem arrives, we gotta wait for some open source team to go fix it. And frankly, a lot of those folks might be thinking about it as a hobby, and they're not getting paid to do security patches, so they might not actually prioritize that anytime soon.
So how do we kinda create, uh, some sort of management workflow around open source software? Well, in short, we do now, right? You know, this is something we're all in together.
Open source software is behind everything. We couldn't be having this call right now. And, you know, if without all that, so you, you know, there's a lot of security.
one-on-one in this, right? You know, figure out who you are, what's your criticality, what's your biggest risk? Um, for most businesses, the biggest risk, you know, has nothing to do with cyber.
You know, you'll, you know, you start a small company, it'll probably go outta business. Most do, right? And for lots and lots of reasons that it won't come down to a cyber hack.
Well, it's like Baltimore, you know, uh, just like a lot of our, our friends, you know, as soon as a ship hit hits a peer, you should start getting people asking, could it be a cyber attack? It's like, yeah, probably an industrial accident. 'cause those kind of happen all the time.
So what should you do? You look at if, if code, if you're all about services and code and so forth, you know, and, and you have the resources and perhaps you're, you're a likely target and all those sort of things, um, then you should be looking at the kind of things that, uh, you know, that are the, uh, the good practices of the people leading in this space. You know, call out to anybody involved in the supply chain security space.
Companies like Schneider Electric, look what they're doing. You know, how do they get, you know, reduce their time to transparency? They can see what's going on, whether it's on the detection side, you know, if you don't know you're compromised until too late, that's a problem.
Um, or it's the response time. You know, if it takes you six months, you know, to find out where you put that code, you know, that's a problem. And there are, as always, this is what I mean by inevitability curves.
Like, there's sort of these bumpers on the possible futures. And as you approach one, you just, everybody starts to lean away from it. You know, if, you know, this is another example of one of these issues, everybody in the world should be thinking about this a little bit.
Um, you know, maybe a tiny bit. 'cause it doesn't matter too. Maybe a lot, because now's the time to start considering, you know, can I tell, and to your point, you know, Alan, so much of this comes down to contract language, right?
A lot of this can't be fixed without, you know, looking upstream in your supply chain and saying, am I really putting the responsibility where it needs to be? You know, if I need to figure something out in this window and it's gonna take longer, maybe I need to change what I'm requiring of the people upstream. Yeah.
And without, You know, on, on that note. So that Anymore, go ahead. On, on that note, Chris, you know, Mike, you said something about, you know, is DevSecOps all that, is it widely adopted?
Is, you know, where are we on that dev sec? That's an ongoing debate. Our ongoing debate.
The, but the fact of the matter is software supply chain security is DevSecOps. Mm-Hmm. Right?
That's, that's this whole thing in here of shifting left and, and trying to get to this code. And so when, when, when, I know we're in the middle of the, got DevOps and, and DevOps next research. com and Security Boulevard, it seems that maybe most organizations are not as far along the DevSecOps curve as we would think from all the noise it makes.
But ask them, are you doing something around software supply chain security? And I bet you most are saying, yeah, we have to. CISA said we have to.
The government said we have to, it, it's imperative. We don't want to be the next name. The company, Mitch, I'd love to get your thoughts on this, but it seems like it's not just a technology issue, it's kind of this process thing.
'cause what happens is the security people don't seem to understand relevance. So they basically come up with a list of things for developers to go fix. Developers have like maybe 10% of their time to go address that.
And they look at what the security team sends over, and then when they chase it down and either the code wasn't actually running, or the application isn't internet facing, and they look at the security guys and say, you keep crying wolf, and we don't pay attention. So what is the breakdown here? Well, I think it, what you're saying is a good pointer that for a lot of this, you can't solve it from one perspective or the other alone.
You have to kinda look at the full context of, of what's going on, if that vulnerability truly is reachable, accessible, et cetera. I, I think the, the thing about DevSecOps, we need to think, to Alan's point about it, is supply chain security. Well, if it's supply chain security, then it's middle out.
I mean, it's end to end because we've gotta check the, the supply chain of our own development processes, right? It could be introduced in, in a library that would get off of an image. It could be a vulnerability could be introduced by a developer writing some code or a library that we have that gets an update.
It also could happen at the very end of the process of the code gets distributed and put up on whatever, or put into a server, put into production or up on, you know, a, a base image or somewhere else to download this. I, I think the other thing is that all software is vulnerable. I mean, you think about o uh, the open source software, the amount of things that we use.
I mean, this is one tiny example. Yes, it's widely distributed and it's relied upon, but there's a lot of other software in the Lennox kernel that, and it's the same way. So I kinda like Chris's point of part of being on an open source team, as you have to be able to respond when there's an issue.
And you have to have multiple people involved who can do it. And I think a lot of projects are that way. I worry about more of the abandoned projects that probably are the greater danger.
Mm-Hmm. Orphaned, orphaned projects. Chris, I think you were saying this, but I just want to drive the point home a little bit more.
Do we need to make sure that every piece of open source software, that somebody's curating that thing on our behalf so that when there is an issue, there is somebody to go fix that. And, and sometimes that may be a third party managed service specifically to go isolate it or fix it, be until we get the primary fix from the open source team. But do we need to kinda rethink our workflows to account for the probability that there's gonna be another one of these?
Yeah, I, I think we need to continue to think more than rethink. Right. You know, and I, you know, it's interesting 'cause I haven't really gone there with in this form before, but DevSecOps, right?
And is, you know, nothing more, uh, Textron than that. And one of the things I find fascinating the last couple years working with, you know, with side beats, you know, transparency company pays me to do stuff. So I may be biased, but you know, it's FBO management, right?
And one of the, my, my thoughts, my predictions of this transparency era as we start to put more communications in place, is that DevSecOps teams get along better with the rest of the company. And we found that actually happening in real companies where it's like, you know, can you see where your SBOs are? Can you match 'em to your vex vulnerabilities?
Things? What else is good? Alright, we're not fighting with DevSecOps so much.
'cause now we can understand, oh, that's why they want something. As opposed to you as security people. We like to, if we have like to, you know, we have a, a negative tendency to say, if you don't do these things, you're a bad person or you're a bad management team, you're a bad company.
Instead of saying Yeah. Understanding, you know, being clear with each other is like, you know, I understand that I'm security, but if there's not enough money to pay the salaries, then we're not even a company. So how do we talk to each other in the time available?
Again, that time to transparency thing, and this sort of stuff that's going on in supply chain right now is helping vendors and customers have better communication, specifically helping DevSecOps and development in other parts of the company talk to each other. And that's more useful than all the technology. 'cause now you can communicate about why you're doing things.
So that goes to the heart of DevOps, right? One of the things DevOps isn't about tools in spite of what people out there may think it is about culture, it is about communication. It is about breaking down silos between disparate teams like security and development in ops and testing and what have you.
So I'm, I'm glad to hear you say that, Chris, because, you know, I think the, the DevOps guards are smiling down upon you for, for recognizing that that is exactly what we're supposed to be achieving with DevOps. Right? We may not have the best tools, we may not automate everything.
We may, you know, we could always have better quality, but when we can deepen those lines of communications, good things will happen. I don't know. I'm doing this a long time and I, there's log four J before this and God knows what before that.
And every time it's the same thing. By golly, this is a wake up call. And then about 10 minutes later, everybody rolls over and hits the snooze button and they move on.
It's just the alarm going off again today, right? You know, it's very today. Well, We, we change, right?
You know, you know this, you know, we go through evolutionary plateaus, right? You know, and you're right. You know, you know, I, you know, I, I look at these sort of things like Log four J or Stuxnet or whatever has interesting little tools along the way because yeah, we all go wake up call.
That's not really a wake up call. It just sort of level your game up, you know, now you need to do this much. Now is it gonna be exciting?
And, and as thrilling as that wake up call, no. Is it gonna become something boring? 999 level that we thought when we were all excited about our wake up call, but we do 85% or whatever.
And it's, you know, you look at the attacker side, a lot of exploits that used to work don't work anymore because, you know, security teams and corporations are changed. So we're evolving together is always a new challenge. And, and we're not, uh, as a Marcus Ham, you know, the closest you get to the father firewall, he and I had had this long, uh, debate for, for a couple decades, right?
And it's, it's, uh, you know, can, you know, but you know, Marcus would use the space shuttle, right? You know, the spat shuttle was a bad idea because we should have engineered it properly from the beginning. My argument is maybe, but we wouldn't have, we never would've done it.
Right? And it's the same sort of thing, you know, could we, as engineers or as security people, we can say, well, we should have been right the first time. Or, you know, and, and Fred Cohen, I have been doing this radio show and interviewing a lot of, you know, old timers, even by our, our standards, right?
If you go all the way, you know, Viner, you know, he's been doing a series of Viner, and you go all the way back to the beginning, it's like, could you, have you built it more secure at the beginning? No, you couldn't have, was there an ideal technical way to do it? Maybe, but that wasn't gonna happen.
And what we get out of it actually is better, you know, it's, it's more realistic, it's more fungible, more flexible, more redundant. But we settle into these modes where it's, well, it's worked for the last 18 months and I haven't addressed A, B, C, and suddenly it blew up. Alright?
From now on, you're addressing A, B, C, build it in F comes up. You look At, It sounds like software should come with a warning label. Well, doesn't it?
It's somewhere in that five there, it's in that fine print somewhere. Well, I, I think, I think the point is security is relative to a point in time of what you need, right? Mm-Hmm.
What I needed in 1990, or what I needed in 2010 was very different than what we need now, right? To Chris's point about this evolving. So if it was a light bulb and turn it on and we've solved it, that'd be, you know, that that wouldn't happen, right?
That that's just not how it works. No. So, uh, that's why this is an evolving, you know, we all have to change with it as well as try to change our, our response to it.
Uh, it's not a, it's not a black and white issue. You know, I'm gonna end this segment with a quote from the infamous or famous or whatever he is Donald Rumsfeld. He's not alive anymore.
But you go to war with the army, you have not the army you want, and sometimes not the army you need. But anyway, Hey, You guys are gonna be talking about this at RSA, right? Absolutely.
We're gonna be, well, this is gonna be all well and what's AI gonna have on this? We'll talk more about that in a minute. You know, in our next segment, the cyber guard, we were praising the Microsoft fellow who found this backdoor, the cyber guards giveth, and the cyber guards take it away.
In our next segment, Microsoft gets a failing cybersecurity. Great. We're gonna take a quick break here.
You're watching Textron gain Cloud native now is the web's leading resource for the growing cloud native ecosystem. com is your destination for news, thought leadership, features and webinars on cloud native architecture, Kubernetes, serverless, cloud native application development, microservices, service mesh, cloud native security, and more. Stay on the cutting edge of modern application development at Cloud native Now, All right, and we are back, I think for the first time in my memory, at least the United States government has actually called out a vendor over cybersecurity issues.
In this case, they were picking on Microsoft and basically calling them out saying, you know, they need better processes and the software's not as secure as it should be. And frankly, does that come as a surprise? It's called Patch Tuesday.
It happens all the time. And we all know exactly what the security issues are. But Chris, let's start with you again.
As did this strike you as a unique and B, aren't there other vendors that are gonna have the same issues? And so we're just gonna start calling 'em all out. How's this gonna play out?
Uh, not unique and yes, all vendors, right? You know, and, and Microsoft is a, is a great target, right? You know, and, and you know, we've been picking on them for decades and quite often they've deserved it, but sometimes they haven't.
Right? You know, you know, turn of the century, you know, 20 years ago, and Microsoft used to be, you know, just a laughing stock, right? And they men, but they were making a lot of money and all security, early security people are, are, are harping on it.
And then they took security relief seriously. You know, they hired a lot of really good people. Jeff Jones is still there, you know, top flight people.
They actually made really good secure products. And kind of what we're talking about in the last segment, there was that wake up call. And I think they've kind of gone to sleep since then, so they probably need to wake up again.
And that, that just happens, you know, 20 years of it's eroded away, right? Shades of a trustworthy computing initiative. It's funny you mentioned Jeff Jones.
I, yeah, I, you know, I'm, I'm Facebook friends with Jeff Jones, but I haven't, you know, you don't see him out there as much as we used to, or maybe it's just me. I'm not looking for him. But yeah, I, I think, I think Microsoft is, I don't want to go around the table naming names, you know, I like all these companies, they're fine.
I use their products. But you know, there's a bunch of big companies that have, that have gotten complacent, that have been good at security in the past and aren't really that good now. And if they don't, you know, and, and the companies all think all are making money in their own business, so who knows, maybe they're doing the right thing for their shareholders, but it, it doesn't go on forever like that.
They have to continue to renew. So I, I think Microsoft gets a bad rap though, because of, they do have a target on their back. I, I don't know if their cybersecurity grade is any worse than those guys down in the spaceship in the valley or, uh, or, uh, or the, the alphabet and, and all of these other companies, you know, who does security good.
You know? And even if you do good, is it good enough? Right?
So I get the government, you know, and, and, and of course we, in the security industry, as, as, as, uh, Chris mentioned, it's a cottage industry to crap on Microsoft for their security. And it has been as long as I'm in this industry. But, mm-hmm.
That being said, they're not, as Chris said, they're not always, I, I think they get, they take a lot of crap unnecessarily and they kinda lead with their chin, you know, I'm not sure. Well, Let me ask you this. We live in, uh, a society where there's a lot of litigation.
Is there gonna be some sort of class action lawsuit aimed at these companies over these security issues? Or is that all hidden in the user agreement that nobody read? Probably, I mean, look, there's no lack of attorneys who would jump at the chance of a class action lawsuit against any of the tech giants.
And, and let's make clear, whether it's the US government or the eu, Microsoft, Google, apple meta, these, these companies are all in the crosshairs right now, right? For, they can't take a glass of water without someone, you know, screaming something about antitrust or insecurity or, or unfair or what have you, an AI to boot. But I, I do think that, I mean, to, to have a successful class action suit, given the state of eula eu, you know, EULAs that come with this software, you would have to show gross negligence, which is a very high bar compared to normal negligence.
I don't know if it rises to gross negligence. They're not that complacent. I, I, I play the, uh, the Mike Vard philosophy.
I'm kind of cynical about this to, to quote, uh, game of Thrones. This is an incidence of shame, shame, shame. You know, the government trying to shame Microsoft for this, right?
And, and, okay, well, let's shame at and t let's shame everybody else that got hacked last week. This just happened to be in, in the government servers or not in their servers, in their service that they're using for Microsoft, for email and other things. And yeah, it needs to be secure.
And now they haven't found a flaw in it. But you know what, uh, as users of this, these technologies, we know as security professionals know all of it's gonna get hacked in some way, some form, some shape someday, multiple times. And so, you know, sounds like the government's sitting on its ears or sitting on its hands and, uh, oh, bad thing happened at Microsoft.
Let's, you know, get out the red flag and shame 'em. I think it's, I think it's, well, maybe it helps them take it more seriously. I doubt it.
I think they already take it more seriously enough. Chris, Chris, what's your thought about, is the government in a position to actually evaluate these things? Because sometimes I wonder, um, you know, where is the level of expertise?
Who's measuring the, the, the standard for security for any software vendor? It is interesting you ask, right? You know, 'cause you know, I do a lot of public-private stuff, right?
You know, in the, with, in the supply chain space. And I saw on our list of topics for today, you know, public-private sort of things. And we need to understand like anything else, you know, the governments, you know, governments like the US government, you know, have certain strengths and weaknesses unless, you know, to, to, to contra pose that, you know, imagine this.
So the North Korean government has other strengths and weaknesses, right? And, uh, one of our, one of the weaknesses of a government like this is that need for transparency. It gets very expensive and it gets clunky and hard to do things if I can't say, you know, gimme your tax money and I'll give it to my, my best friend, you know, uh, as a contract.
So it gets hard to do things, you know. But, you know, we have, you know, enormous federal government with enormous resources that's got amazing people. Um, and amazing organizations can go on all day long, but they're not nimble or not fast in general, and they have other downsides.
Um, and I think to, to Mitch's point, I thinking the same sort of thing. If I try to put a positive spin on this, if it's nothing but, you know, the US federal government, you know, just poking a major company just to get their retention might work, might not. I don't know.
Um, but I think the, I I think the net net is probably right enough, you know, it could have been some industry re review group coming up with the same sort of conclusions. And, uh, well know to be clear, you know, I'm not, I don't know exactly where Microsoft is in the security world right now, I'm just thinking about it with y'all. But I would get the, I get the feeling they've slackened a little bit and they can use a little poke.
Um, and, but the government people are good. They're not making this stuff up, right? Whether it's the context or I think the private sector is better at putting it in context.
'cause we can act differently. We're less bounded. Yeah.
I mean, look, you know, what they say in football, there's holding on any given play. It's just a question of whether the referee wants to call it or not. That Was basketball championship game there.
Yep, that too. So It was a pick by the way. It was a, it was a good call.
Okay. Mitchell's way did, It was a pick. But if you call that every play, we wouldn't have a game.
It's a moving pick. You have a point there too. That and that, and that, that is the point, and that's the point to hear, right?
Um, so all right. We, we, we whip the whipping boy. Let's see who, what falls outta this.
That, that's kind of my take. Let's take a break here on Techstrong Bank Gang. We're going to come back and we're gonna talk more about this public private partnership and relationship that Chris referenced earlier.
You're watching Textron Gang. Hey guys, this is JJ Manila with Mitch Ashley co-host of CISO Talk, where we have engaging bite-sized conversations for current and Gen CISOs. You know, we have some of the best conversations on CISO talk with some of the greatest talent in security people like Andy Ellis, who talked to us about optimizing security strategies and how to navigate the boardroom.
Lisa Bradley came on and talked about vulnerability management bug bounty programs and why SBOs aren't the solution to all your software security problems. Steve Reynolds was also another great guest, and he talked to us about what not to do when a security incident happens, What not to dos are great, but we also had Eve Mailer and Steve bitten on talking about security, uh, and third party software, SAS applications, and weaponizing ai. So go ahead and join us for the latest episode of CISO Talk.
You can find us by going to Tech strong TV slash CISO talk. And we're back, and we are gonna talk about this public private partnership thing. There's a, NIST is out there and, uh, has this large backlog of things that they're supposed to be doing in terms of vulnerabilities and all kinds of things that hopefully that are gonna save us from ourselves.
But, um, we've also seen pictures of some of the offices where some of these folks work. And well, it doesn't give you a lot of confidence that says that this is the cutting edge front end place that's gonna be able to identify all this stuff. So, Chris, let's start with you.
What is your sense of what's going on in the, on the public side of this in terms of capabilities and resources, and what should the role of private organizations be to help out? This is a, a perfect example of my whole obsession with evolution and curves and and so forth. You know, I, I get asked this one a lot over many, many years, and, uh, I think a good starting spot is, I always get this wrong, 96 or 98, where there's a presidential directive that there shall be, and the information sharing and analysis center where the public and private sector will get together to talk about cybersecurity.
Um, that order came out and immediately you didn't get, and not a single isac, you got six or 12 or whatever. As we have these information sharing nodes now for a quarter of a century that have been developing the healthcare isac, the automotive isac, some of them, uh, the energy sector, financial sector, ISACs, are very, very functional. And along that path, things like CRAs, the Cooperative Research and Development Agreement, uh, legal artifacts were developed between the federal public sector and private sector entities like non-profit ISACs, to allow them to, you know, to collaborate.
And if you look inside, you know, the US federal government, the, uh, the nip, the National Infrastructure Protection Plan, the sector coordinating councils, you have all these structures that had developed over that time, this last, you know, quarter of century or so. Um, and they, you know, look, before that we didn't have that cooperation. So for those of us who sort of grew up during that, you can say it's not as good as it should be, or it needs to be this, that, or the other.
Um, and as long as it keeps moving in that direction, in the, in the more recent term, you know, the public private working groups around supply chain security, it started under the Department of Commerce, um, that have been, uh, under cisa, under the, under the Department of Homeland Security, cybersecurity Infrastructure Security Agency. And our acronyms out there, um, have just gone through two years of creating working group teams, you know, creating sub teams under those producing, uh, documents that are private sector driven. But we have a public sector forum, you know, form platform to publish those on and to have those conversations under.
And I think right now, literally right now this month and this and this year, uh, I think that particular public-private activity is, is leveling up. I think we've learned some good lessons over the last couple years. And I, I think, you know, as one of the active, uh, participants in that, it's up to the private sector.
We have to actually believe it, take ownership, lead it, use it. You know, I like having a federal government platform, you know, if I can get a, if be part of a group that can agree on something, we can publish that, we can propagate that in lots of ways. gov, that's handy.
But, you know, to our last segment, the government doesn't necessarily have the answers. You know, we're literally out here making this stuff up for profit every day as fast as we can. Government will catch up.
So private sector has to lead, but we need to understand the capabilities of a a and the benefits of a public sector partner and actually work with 'em. Yep. I, you know, look, quite frankly, I don't think organizations like NIST and Mitre, which is sort of a quasi-governmental thing versus nist, um, get enough credit, right?
These, these guys have relatively modest budgets, and the amount of, of stuff that gets put on their plate is, is pretty substantial. I think they were always designed to be part of public private partnerships, right? Uh, mire, certainly NS may be a little less so, but I, I also think give them credit for recognizing that they need, they need to do this because the backlog, the, the, the mission has grown so immense and so big that they can't go it alone.
They, they just can't go it alone. We, like, as Chris said, we like having the federal government get behind something, even if it means giving Microsoft a failing grade or something. But the mission here is, is too critical, too big, too complicated.
We need these kinds of partnerships. I feel like we're not doing nearly enough. The truth of the matter is, we're at war.
The bad guys are out there banging on our infrastructure and their nation states and their criminal syndicates. And if this was any other space, we would be mobilizing all kinds of resources on a, on a par with something like what we might have done for World War II or something where we would converge, you know, the general Motors of the world to help build armaments and all this other stuff. We need that kinda level of initiative across a public private partnership.
There's just not enough urgency here. It's like too much of a, feels too bureaucratic. It doesn't feel like we're gonna go out and actually solve this issue.
It's more we're gonna go out and talk about it. But Mitch, what do you think? Well, I mean, I think there's two ways to look at this.
One is what is part of a national defense military strategy and what is part of a public sector strategy, right? If you, if you put your, um, we are at War hat, you're gonna look at it from a, you know, national security perspective on what we have to do. You know, we have our offensive as well as our defensive.
I think what this is about is saying, look, we have to level up our game, kind of to Chris's point of, we already crowdsource a lot of the work that identifies these vulnerabilities, right? Um, is the government in the u unique position of being able to classify those? Um, not really.
They could, there are other people who can do that too and work with them cooperatively and help get more done. Maybe we're, you know, maybe it's worth looking at, are we looking at everything and we should be looking at a subset. I'm sure they've already felt out a lot of this stuff today.
So what the government's in a, in a good position to do is bring people together and host resources and process and communicate, right? And they've done a fantastic job with, you know, with Mitre and, and NIST and, and, and groups like that. So I applaud 'em for saying, Hey, let's think about how we do this differently.
'cause, you know, we've been kind of sitting on our laurels, assuming we're gonna get this funding every year. And I guess that's not true. Let's think about how we do this.
And given the current funding situation, I, I go, Chris? No, no, Chris, you go. I, I think space is a, is a, is a good example, right?
You know, 'cause you know, in the sixties and seventies when we were all kids, right? You know, the government spent a huge amount of money, you know, to, to, you know, do space stuff. I'm a big space geek and, you know, being in the, in the Space Coast and watching space Fal, Falcon Nines land on ships in the ocean.
Holy cow. Um, it's easy to, to see the difference, you know, in the sixties and seventies. There is no commercial way to build spaceships.
It's not happening. It's a government sector sort of thing. And similarly in cybersecurity through the nineties and so forth, you know, there wasn't, you know, cybersecurity wasn't this huge.
There were no big companies behind it. So the government, you know, has had a, a outsized role, but it's getting smaller as we're all discussing here these days. Yeah, NASA's wonderful and everything else, and we still need, you know, that sort of, you know, national interest in space.
But go SpaceX, you know, building fly rockets, you know, that's become a, a private sector thing. So let me, let me weigh in on the space issue though. Why aren't we on the moon?
Why aren't we on Mars? Have we, have we bifurcated our attention and, and handing off the, probably the most important scientific missions of our civilization to a bunch of capitalists who are trying to figure out how to do this for profit? And there are some things that don't belong on profit.
There are some things you do for pure science, and you see what comes out of it. And there are some things you do for national strategic and, you know, reasons. And I want, I'm not a big fan of private space.
I, I think private space has a role when we commercialize space, but we're not up to commercializing space. We're still in the discovery phase. And, and it's almost pure science.
And I'm sorry, Chris, you took me on a left turn here. I'm gonna speak up. Well, Chris, let's Wait.
Counterpoint. Chris, let's pull it back for a second here though. Um, going back to our first block on DevSecOps, are we spending too much time and effort on mitigation and, you know, quote unquote research on what you might call the cybersecurity equivalent of forever drugs.
So we're going to treat the issue, but we're not gonna fix the issue. So do we need to reallocate our, our resources to go fix the problems versus spending billions of dollars on mitigations? Well, it depends, right?
You know, you know, I, I'll see if I can mix maritime and space and cybersecurity altogether, right? You know, you know, ships are, are imperfect things, right? And they leak all the time in the dupe, you know, but how much time do you spend patching holes or, or dealing with it?
And how much time, you know, when is it time to redesign the whole bloody thing and build a new, whole new boat? Um, but I think the, my short answer to your question is no, I think we're actually doing all right. You know, the whole redesign of everything isn't gonna happen, right?
That it's such a, you know, change of process is such a cost to so many different people. I kind of think that's off the plate. And kind of to the, to the, to Alan, to your point about space, one way to look at our experience in space is that we're lucky that there was this weird geopolitical thing when we were kids.
We actually got to see this ridiculous space flights, like those were tin cans. It took like a third of the na, the GDP to, to fire something up into space. And now we're at the point where companies, you know, supply satellites because they're making money selling, you know, internet services to crazy people on boats.
Um, that allows us the public sector. We can back up a little bit, and I, I share some of your concerns, but we like cybersecurity. We need to think about this space thing a lot, but we don't need tax money for it.
We, you know, for all of that, we can focus back in that public sector on just the parts we actually care about. So we, yeah, we're, we really should be looking at the dawn of the space flight was like 20 years ago, not 60, 60 years ago was a fluke. You know, that was, we weren't ready for that at all.
Crazy people on boats. That was your cue. No, no.
He's the crazy guy on the boat. I don't have satellite, uh, internet on my boat. He does.
Um, just to set the record straight, but hey, you know, I, are, we, are we ever gonna see Zein Pike go into warp speed here? I mean with, with a private space program. Anyway, hey, who knew we were gonna end on this in today's text on gang.
You never know where it's gonna go, but we're time. Yeah. Chris, you'll have to come back next time.
Give us a report on the Eclipse Mitchell. We'll see you on the next gang. Mike, you're off to Google next?
I am. I'll be Dialings next from Las Vegas, so we'll see. Absolutely.
I'll be here manning the, the, uh, the headquartered desk. Until then, though, this is Alan Shimmel for all of us here at Textron. You've just watched Textron Gang.