Technology

Protecting military space technology from bad actors

It doesn't get more cutting edge than military space technology, so that means security practices need to be top notch and updated just as frequently.

Tom Temin@tteminWFED

August 20, 2024 11:23 am

10 min read

With new technologies comes new ways that bad actors can get a hold of your software. It doesn’t get more cutting edge than military space technology, so that means the security practices in place need to be top notch and updated just as frequently. To find out how it’s going about that, Lt. Col. Laila Barasha, material leader at the Evolved Strategic SATCOM (ESS) ground segment with the U.S. Space Force, joined the Federal Drive with Tom Temin.

Interview transcript:

Eric White Lt. Col. Barasha, thank you so much for taking the time.

Laila Barasha I appreciate it. Eric, thank you.

Eric White So why don’t we just start with the, what your secure software development efforts look like? Give us an overview of some of the applications that you all are using to secure or need to secure, where those are hosted, whether it’s in the cloud or if it’s handled by an outside party?

Laila Barasha Before I talk about the Evolved Strategic SATCOM software applications, I would like to start off with an overview of what Evolved Strategic SATCOM is. So, evolve strategic SATCOM is the follow on satellite constellation and satellite capability for the nextgen nuclear command control and communications architecture for the United States. So it’s the follow on to AHF. In that umbrella, there are five different segments within ESS that are software application based. So the first one is the space vehicle software, and this basically controls all the functions on board, the satellite and the payload and the functionality to provide communications to U.S. forces, joint and international partners. The second is a mission application suite, and this is the software that resides on the ground segment that will allocate those space resources to ground users and ground terminals. The third is an in band command and control capability, which is another subset of software that does 24/7, control of the communications on board, the payload and the bus. There is a fourth software application that is an out of band command and control. And this is control of the overall satellite constellation. And then the fifth portion that I believe we’ll be talking about at length today is that framework and integration component. And within that framework and integration component, that is where all the API’s reside, the cyber security aspects, the digital twins, the system architecture. So that framework is, that is the baseboard, where all the other applications will reside, for the ground segment, for ESS.

Eric White So it’s really, is that fifth sector that is, as you mentioned, what we’re highlighting today. What makes that up? Does it find itself larger than the other, as far as manpower and needed software goes?

Laila Barasha I wouldn’t say that it’s larger, but it is the component that will control the API’s and how the other software interfaces with the overall constellation and assortment of applications. So it’s the first in the shoot. We do have a software integrator and framework provider on contract, and they are on the hook to to ensure that those APIs that are given to the other mission software developers interface accurately. They police the standards, but they also control all of the the system requirements to make sure the data flows are are cyber secure from the start, you know, they have a zero trust architecture, and we’re requiring digital twins and digital engineering aspects to ensure that we can warn game and do cybersecurity threat analysis through this digital twin that resides with the framework and integration vendor.

Eric White So is that the main reliance that you all are going for when ensuring security and in developing new software and updating your current one, it’s all about just the zero trust and keeping keeping tabs on that contractor that you have in place?

Laila Barasha So you asked about reuse of software, and so I, I believe there was a five year effort to really understand the legacy software its cyber vulnerabilities, could we reuse any of the software? Was it compatible with this modular, open system architecture that is, you know, the best practice to ensure cybersecurity in a system. And so we realized very quickly through this analysis that the legacy software probably was was not reusable, and so we started from scratch with those blueprints in mind. So the framework and integration component, it’s not reusing any software. It’s going to ride on a very thin framework that does just the bare minimum to allow the software developers freedom of movement to create their own subsets of modular system components in their software, but also with cybersecurity in mind built in from the start, and so we’re not reusing the legacy software. However, we do have it all. It’s all government owned, and so we have the blueprints. We’re just not reusing that software because cyber security is such an important piece of our architecture. Again, this is nuclear command, control and communication. So on a bad day, when President picks up the phone, President hears a dial tone. So this system is will be alive during really bad days. So obviously cyber security and being a threat informed, risk based software architecture, we have cyber security built in from the start.

Eric White We’re speaking with Lt. Col. Laila Barasha. She is material leader at the Evolved Strategic SATCOM ground segment with the U.S. Space Force. And so is that sort of the modus operandi when it comes to new hardware and new pieces of equipment that you all are working with, or even just a new part of those other four sectors that you mentioned? Are you all going to redevelop or develop code from scratch every time? Or is this stuff applicable to newer and more updated software and hardware?

Laila Barasha In terms of the framework and integration piece of the puzzle, that is all new software, but that’s so we can build in cybersecurity from the start. But when you start talking about hardware, because we are the follow on to AHF, we are compatible with the existing user terminals, because user terminals are typically, you know, the the long lead items in any system. And what we’re seeing is we will be compatible with those legacy strategic terminals that age have currently services. And so from that respect, we’re not redoing the software within those hardware components, the user terminals, or the user terminals, obviously, with updates for crypto, because it’s a next gen system, so crypto is going to have to be upgraded and a few other limitations within their software. So obvious upgrades to them. We’re not coding those from from scratch. I guess, what comprises of a backbone framework and architecture, that is what we were coding from scratch. That’s the framework and integration piece. So overall, with the five different lines of effort, there is some hardware. There is obviously some some components of legacy systems that we still have to work with, like legacy Space Force, SCN for the C2 scheduling is really what it boils down to. So the components that we absolutely needed to redo from scratch because of cybersecurity concerns, we did. And those aspects that are functioning as needed will be upgraded as needed. That was also part of the calculation.

Eric White You’ve been using the same term, we created those with cybersecurity in mind from the start. I wonder if you could just explain a little bit about that, because that sounds like coding. And you know, how do you ensure that a safe code has been compiled, you know, in a fast moving production environment, and that it will interact with the new systems and those legacy systems that you had mentioned?

Laila Barasha If you look at cybersecurity requirements across the board in the DOD, everybody references typically the RMF compliance. So it’s a system RMF compliant risk management framework, and so there’s this whole laundry list of items that vendors have to adhere to in order to be cyber secure. Last week, there was the CMMC … that was released, also standards for cybersecurity within DOD systems. Now if we set that aside as okay, this is the regulation for cybersecurity. You can be RMF compliant and not be cyber secure. So what are the aspects of cybersecurity that really ensure that ESS as a whole is cyber secure? And so we have the zero trust architecture built in. And we told the vendors from the start, cybersecurity is our number one key piece in this software development architecture, and so part of their incentive structures on their contracts are to go through cyber intrusion from DAFRED teams. And so DAFRED teams will look at that compiled code, will look at, you know, the system architecture, the digital twins, and they will tell us whether this is cyber secure software before it ever gets to operational deployment. So from development, from the start, we have these cyber components from third party, FFRDCs universities and the DAFRED teams that are providing that system level analysis of is this a cyber secure architecture again before it ever reaches operations.

Eric White Now I’d be remiss if I didn’t ask, you know, I’m talking to a member of the Space Force here, and this is not the usual SEC DevOps conversations that we’re used to having with other federal agencies. What aspect of, you know, that these systems are being deployed in space? Does that add any sort of difficulty, or is it just kind of, you know, standard practice, and you’re just applying it to space technology?

Laila Barasha I believe this is standard software best practices. Obviously, there is that level of complexity, because you are fielding code out in space. You are fielding code that needs to, you know, communicate with space. But overall, the standards of systems, best practices, the DevSecOps pipelines, the agile, the scrum eye, everything involved in building good software, those are standard best practices across the DOD. And so what I can tell you is, in the Space Force, we have a category of certification for some of our young software coders called Super Coders, and those are service men and women that undergo software certification. They understand software and best practices and how to code. And I actually have a couple of them on my team that have helped me develop, first the request for prototype proposals, and then they helped me analyze all of that software in order to pick the best vendors that are the most cyber secure with the software writing best practices. So because we have these certifications in the Space Force, and I’m blessed to have those members on my team to help me analyze that software were able to develop an acquisition strategy that allows for the best of breed software coders to be our vendors, and then also to hold those vendors accountable. So I would say that is probably the only differentiation between Space Force and perhaps some of the other departments, but for us, super coders have been an intrinsic part of developing best practice software within the DOD.

Eric White Lt. Col. Laila Barasha is material leader at the Evolved Strategic SATCOM ground segment with the U.S. Space Force. Thank you so much for talking with me.

Laila Barasha I appreciate it, Eric, thank you so much.

Eric White And you can find this interview at our website, head to federalnewsnetwork.com/federaldrive. You can also subscribe to the Federal Drive wherever you get your podcasts.