Advancing cybersecurity for modern LEO constellations – with Terma

This episode of The Space Industry podcast by satsearch is a conversation with Andy Armitage, Senior Architect at Terma, on approaches towards advancing the state of cybersecurity for modern LEO constellations.

Terma’s space business provides mission-critical electronics, software, and services for space applications.

In the episode, Andy and satsearch CEO Kartik Kumar discuss:

• Ground segment security & credentialing: The vulnerabilities of legacy systems, user access management, and using standards like OAuth 2 to secure credentials.
• Satellite key management & lockout risks: The operational delicacy of key cycling and the importance of following established standards like CCSDS to avoid getting locked out.
• System interoperability & hosted AI applications: Balancing open standards versus vendor lock-in, alongside the security considerations of sandboxing hosted software and leveraging AI in design and operations.

Find the episode now on your favorite podcast player! And please give us an honest rating and review to help us spread the word about all the important work going on in the space industry.

---

Related products

Products referenced in, or related to, the content in this podcast episode:

Click here to view the full Terma space product portfolio on satsearch.

---

Transcript

Please note that this transcript is auto-generated and may contain errors and inconsistencies with the podcast audio and therefore we can accept no responsibility or liability relating to the content and accuracy of the text on this web page. The transcript should only be used to accompany the audio, and it is the audio of the podcast which should be referred to in order to confirm any of the information provided in the podcast.

Kartik Kumar:
Hi everyone. My name is Kartik and I’m the CEO at satsearch. I’m subbing for your usual host, Narayan, and we’re going to be talking about a very important, pertinent topic, which is security of space systems.

This is a topic that I think really affects teams globally at the moment, not just because of the rapid nature of development of technology in the sector, but also the evolving adversarial landscape.

So staying on top of this is not just important for so-called new space teams, but also traditional companies as they scale up their operations and build new systems that are solving a variety of on-earth and off-earth challenges for customers.

So to help me delve into this topic, I’ve got Andy Armitage from Terma, who is a senior architect, to give his expertise and expert insights into this specific area.

Andy and I actually have chatted a few times previously. We worked together and published a spotlight article that you can find on the satsearch blog on “Closing the Security Gap in Space Systems.”

I’ll be linking also that blog article in the show notes for anyone that’s interested to go and read that article as well.

So this episode is a continuation of that conversation I’ve had previously with Andy. We found ourselves running out of time with plenty of exciting things to talk about, and so we thought it’d be a good occasion to invite Andy to the Space Industry podcast to have a chat further on this topic.

So welcome, Andy. Anything you’d like to add to that intro?

Andy Armitage:
Oh, it’s fine.

Kartik Kumar:
Okay, great. So I’m excited to have a chat with you today. As I mentioned, we’ve had some very interesting conversations previously on this challenge of managing adversarial threats that exist for space systems, and enabling operators to continue to maintain nominal operations, excellent performance where needed for customers, given this difficult landscape in which operators find themselves working in.

So I thought before we maybe delve into the specific questions, you can maybe just give me a sense of what your background is like in this area, what kinds of topics you worked on or you’re working on currently, just to help the audience understand kind of the context of our conversation.

Andy Armitage:
Okay. Well, I mean, I wouldn’t consider myself a global expert on everything about contacts with ground segments. I’ve had, over the years, I’ve had contact with various different ground segment interfaces, and also the business of securing the ground systems. The ground systems consist of mission control systems, planning, flight dynamics, GUIs, and things like that, and user user authentication, and ensuring that, well, the overall system is secure—as secure as possible.

One of the, one of the ways that you think about this is that if you were a, if you were an attacker, where would you choose first? What’s the, what’s the, what’s the first vulnerability you would choose if you were on the other side? And I suppose, actually, from our point of view, I’d say at the moment, I would probably put it somewhere towards the actual interfaces to the ground segment. Part of the, part of the issues as I’m seeing, I mean, unfortunately, I don’t control the entire world and can’t design everything. So, what is, is that of course you’ve got a, a mix of legacy, and sometimes the legacy is quite deep, so we’re talking about going back to even the early 90s. And there’s a huge investment in that legacy, and it’s a fantasy to think that you can just click your fingers and the next day everything’s going to be perfect. So the attitude has to be, where to look first, and what’s the first vulnerability, and fix that.

Of course, people, people have this attitude where, well, you could say secure by design. You design new systems with security in mind from the very beginning. And that does happen, and that is a great thing to do, if you have the chance. The trouble is that the reality is that you’re likely to come across systems that are rather mixed, and you’d be surprised that even in, even in very innovative companies, strong reputation in the space, but there’s still legacy behind it. And even, the interesting thing is that new space isn’t all that new, and they have legacy now. So, you hit on these issues.

Kartik Kumar:
So talking about, let’s say, what I would describe as what you’re talking about as sort of the weakest link problem, so where can intruders kind of find a weakness in a system. One of the things that came up in our previous conversations, and as touched upon in the article that we published together as well, is the vulnerability that comes from people and credentials. And specifically the fact that when people leave organizations or their roles change, and their rights and privileges need to change, that systems maybe don’t necessarily track that well enough, or you’ve got broken systems that are fragmented. And there’s this evolution of kind of using, you know, more dynamic systems that are able to infer that. We had a chat about, let’s say, whether that’s good, whether that’s not good. Was wondering if you could just share any perspectives you have on how to think about like the credentialing problem.

Andy Armitage:
Well, I mean, the, the approach that I think that we are taking, and that I’ve noticed other people in the industry are taking, is to use standards like OAuth 2 to basically get a token, which is your access rights that’s passed around, and that gives you a kind of global access to your systems at a certain level and with certain restrictions. And since those credentials have a limited lifetime, then they can expire quite soon. And that means that even if those credentials can’t be withdrawn instantly, the length of time that they will endure for is, is quite limited. And then, of course, the advantage is that if organizations change and people leave, come and go, then there’s one central place where you can add or remove those credentials.

I mean, that’s, that’s pretty much state of the art, and the more you can, the more you can use that, the better. The trouble is that when we start talking about getting into those legacy systems, then integrating that into those legacy systems isn’t always something you can do, but you can do your best. You can, for example, make bridges to those legacy systems, and that everything inside the bridge is secured in the way, in the uniform way that you want.

I think there is another issue there, which is that not all these identity providers are the same. There are standards, so we talk about OAuth 2. There are standards, but those the people who implement these standards are, you could say, opinionated. So they have a different, slightly different approach of what exactly is encoded in your token. Is it opaque? And I think there is an issue there that you, you have to keep your eye on, which is privacy. Some of these systems pass around tokens that quite trivially can be decoded, and it will tell you who that person is immediately. That’s not necessarily desirable, at least in my opinion. I prefer the idea that you could pass around opaque tokens. Those tokens are really only decodable by a system that has access to the back end, and that it is not possible to actually identify who—the only people who can identify who it actually was are the people who actually own the identity, rather than somebody listening in.

Does that make sense? I think privacy is also, you can take these multi-solutions, but you still have to keep an eye on how they work and what they’re doing.

Kartik Kumar:
Well, and systems like, or protocols like OAuth 2 or other identity protocols, they’re of course used across the web, across different sectors. Do you think that within space we have any needs that surpass that, that mean we need a space flavor of that as well, or are we good to look at these services that are battle-tested?

Andy Armitage:
Actually, I think it’s better to stick to battle-tested, because the kind of—I mean, there is an interesting point there.

The tokens that you get from OAuth 2 or ID providers are intended for a sort of user population of tens of billions. And actually, within any given space system, it would actually be surprising if you ever got to a total user population of 10,000. So that means that actually the length and the size of the tokens that you need could actually be smaller within a space system, and you could perhaps, if you don’t like the fact that the OAuth 2 token contains identifiable information, you could then translate that into a rather smaller, cryptic, opaque token, which actually hides the person’s identity and is more lightweight. And that’s just fine because your total user population is many orders of magnitude less. But I mean, that’s a different subject.

Kartik Kumar:
Okay, well, we’ve previously talked about that when you manage these kind of identity and giving people credentials and things like that, you’re dealing with systems that could fail as well. And in the worst-case scenario, operators or users on the operator side could find themselves locked out of their own plane from the ground segment side. Do you want to maybe share a little bit about this lockout threat that we’ve discussed?

Andy Armitage:
I think that actually touches on two subjects. You’ve got an ID provider. If your access to the ID provider goes down, then everybody’s locked out. And then so you have to make sure that your ID provision is high availability. That will usually mean that it has to be triple redundant. The challenge with that is that the back-end databases that they use to actually store these credentials and who’s logged in and what sessions, also have to be high availability and triple redundant, and keeping them synchronized isn’t necessarily that easy.

And I think the subject you were asking about was a bit more related to what we were dealing with when we were talking about maintaining the security on the satellite. And we were talking about when you’re doing key maintenance. And the problem with key maintenance is it’s a bit of a delicate operation, because if you’re changing your key and the satellite ends up with a different key from the one you thought it had, then you’re locked out of your own satellite. So it’s very important when you’re going through these delicate key maintenance processes, and key cycling is the right word, I think, and key cycling is absolutely necessary to maintain the system security, so you can’t just say, “Oh, we won’t do that.”

It’s very important to make sure that you’ve established very, very beyond doubt that the state of the satellite as you’re doing this critical operation is what you thought it was before you move on. Because if you made one error in changing of a key, something was missed that it actually went wrong, and then you just carried on changing keys, you’re going to end up with a satellite in such a state that you don’t know what state it’s in, and its keys are all different from the ones that you think it has on the ground, and all of a sudden, you’re locked out of your own satellite. You have to power cycle it, and you’ve lost all the time that that satellite was supposed to be serving its users. So yes, the operations—so the lockout issue comes in the, you might say, the IT systems on the ground, and then the lockout situation can come when you’re doing these delicate operations with the satellite itself.

Kartik Kumar:
And do you have any, from let’s say your hands-on experience, any tips and tricks for how teams can kind of mitigate issues relating to key rotation and the general architecture around key management?

Andy Armitage:
With the satellite, I really would recommend following the established standards. So I won’t say I’m a big fan of CCSDS because sometimes their documents are a difficult read. But I think once you get to the point where you actually understand what they’re trying to say and you’ve got past the documentation bloat, some of them are very well designed indeed. They’ve been tested, they’ve had test implementations. If you stick to those implementations and you use the information they’re providing, usually there’s a reason why they’re providing that information, and it’s to help you avoid exactly situations like locking yourself out of your own satellite.

So on the whole, I recommend follow the standards, and when the standard gives you an advice, do what they say. I’ve seen people kind of taking the attitude of, “Well, we know better. We don’t need to do that,” and that backfiring a little bit. Not disastrously, but it generally turns out that if you follow the standard, you’re a bit safer.

Kartik Kumar:
So one of the pushbacks against that we’ve also seen when we’ve worked with teams through satsearch is that in the age of speed and the need for economic efficiency, some of the CCSDS standards could imply a lot of time and expense.

Andy Armitage:
I disagree, actually. I really disagree with that. I mean, I’ve seen a lot of new space companies—really, what is a shame, I mean, you see a lot of innovation in new space companies, really great ideas, but they also build in their own bugs and legacy, and it’s such a shame when you say, “Well, actually, that was solved even way back in the 1970s, because they weren’t stupid back then.” And of course, some of these standards were written for things like onboard computers on satellites that were very weak. I mean, your mobile phone is a hundred times more powerful than what used to fly on a satellite.

So I think it’s a pity that we’re not seeing enough of the best of both. Does that make sense? That if you use what you learn from the past, bring in the new, bring in some of the innovative ideas, because they are very good. But don’t throw the baby out with the bathwater, as the expression we use. It means those guys who wrote those standards were not stupid, and actually, they have some good ethics to them, if you can get past the 10 pages of introductory material and cross-references and things like that. I think to some extent, the standards are held back a bit by being a little bit boring to read, and some of the more innovative people can’t be bothered to read them. But who knows?

Kartik Kumar:
So maybe there is a next version of these standards that is just simply more interesting for humans to read.

Andy Armitage:
I’ve been looking recently at a newer standard called USLP, which is a new symmetric way for satellites to talk to the ground and for satellites to talk to each other. And this is a really interesting development, very positive. But it does still suffer that sometimes you’re reading this and trying to work out, what do they actually mean? You can see that they’re trying to be compatible with the past, and they’re also trying to allow you to move into the future. And the dividing line between what are you supposed to design yourself, which would be kind of ad hoc and not standardized, or what are you actually supposed to adhere to in order to be compatible with the rest of the industry.

The cool thing about sticking to a standard is that if you come up with a component that complies with that standard, then there’s a much higher chance that it’ll work with a whole load of other components. And of course, that gives all sorts of benefits, economic benefits, because there’s a wider choice of components that you can mix and match and put together.

Kartik Kumar:
So you get interoperability as kind of like a free benefit.

Andy Armitage:
Yes, yes. And it’s also—this is opinion, of course, but we’re in an age where defense and security has become quite high priority. And I think when we look at countries that are perhaps struggling to increase their defense spending, and defense spending is competing with other needs in society, it is important for our security to get the best value for money for our defense spend. And we will get the best value for money if there’s a certain amount of choice of supplier and common ecosystems that all comply with, rather than gated ecosystems from this prime or that prime, and these don’t ever touch each other. If you can mix and match with suppliers because they comply with standards, then actually in the end, the whole of our community and society could actually benefit from that because our money would go further.

There is a counter-argument to that, which is that if things follow open standards and there’s a security hole in that standard, then it’s easy for the enemy to—but then you patch, you fix, you close the holes, and move forward.

Kartik Kumar:
What we see sometimes as well is this desire perhaps actually to move away from the open standard to something proprietary because it can create vendor lock-in, which can have some sort of economic benefit if you have market power.

Andy Armitage:
It’s part of the—all credit to them that the new space operators have done amazing things in bringing the cost down from when I first started, it’s wonderful. They’ve brought the cost of access to space right down. But that gives them an economic potential issue, which is that, you know, if building a satellite or building a constellation of satellites is super, super cheap—we talk about airlines going from legacy airlines to low-cost carriers, for example. And you can see with the low-cost carriers what they do, right, they try to upsell other things. And of course, they want those upsold other things to be theirs, and so they have a certain interest in being vendor locked in. Which unfortunately is a pity because that goes against this problem of interoperability. To be honest, I think given the situation, interoperability isn’t going to be a choice. It’s something we have to do because all our security depends on it. We need to be able to get more out of what we’re spending on defense.

Kartik Kumar:
Well, this raises a question for me which you might or might not have an opinion on, but one of the things that we are seeing happen is kind of these two, as I classify them, two worlds converging, which is the world of, let’s say, what was new space 10-15 years ago, which was experimental, high failure rates, doing things cheap and quick, and then the more traditional mission design, mission operations, which was very, very rooted in minimized risk, test, test, test. Now we see these worlds kind of converge as the newer players are finding they also need to afford their customers a level of reliability, while let’s say maybe the traditional players recognize the need for agility. Do you see these two worlds really converging that way in the conversation and security context?

Andy Armitage:
Yes, very much. And actually, I think that’s one of the nice things. Obviously, you can see I’m old, and I come from a time when you had some rather non-agile, perhaps somewhat monopolistic, very large companies. And I think one of the things that was quite gratifying was to see that in response to this competition coming from new space, those very large companies actually changed. And I think that’s quite an achievement, to be able to make a company with 150,000 employees change its culture and become much more agile. You have to admire the fact that their management were able to make that change in quite a short time as well. So I think that’s something to be optimistic about, that even big organizations that at one time you might have written off and said, “It’s hopeless,” actually, they change, and that’s nice to see.

Kartik Kumar:
So that brings with it, I guess, this other question, which is that we see, other than in a few cases this verticalization trend, there’s also this kind of partnership model where you have solutions being delivered to the market with an array of different organizations coming together, with each having boundaries and interfaces. And when it comes to the security challenge in that, as we previously discussed when it came to our previous article, this question of how do you secure, quote-unquote, “end-to-end” the chain is complexified by the fact that it’s crossing not just team boundaries, but also organizational boundaries. You’ve got a lot of systems of systems to orchestrate. What are your thoughts on how to approach that in this ever-evolving landscape?

Andy Armitage:
That could be a long discussion by itself. One of the most exciting things going on, I would say at the moment, is that a satellite is perhaps seen more as an edge platform where it’s running customer, it’s hosting customer applications and giving access perhaps to the instruments and actuations of the satellite to hosted software. And that hosted software is basically the customer, so you’re providing the satellite as a service.

Everything to do with operating the satellite and securing the data link to the satellite is my bread and butter business. It’s what I’ve been doing all this time. But what’s interesting is how you sort of extend the whole security chain from the hosted software to the client, and it’s really their business what they do. It’s none of our business what they are actually doing. We’d like to know, but it’s really their business.

Now, there are risks involved in putting hosted external software on your satellite. Onboard software is something which is probably the most paranoid environment you can imagine, because one wrong memory access in traditional onboard software and your satellite just stops, and that can’t happen. So there’s various techniques being used to sandbox the onboard application to make sure that its access to, for example, the payload is very, very constrained, and that there is no possibility that a bug in the client software could propagate out into the whole platform, or, for example, to the other customers. In some sense, that is quite similar to the concept of a data center or a cloud service, where they have a lot of third-party hosted software, and it must be absolutely impossible for one of them to make the whole platform crash, and it must be impossible for one of them to see into the information of another. So sandboxing and the techniques for sandboxing is definitely an interesting point.

And then, of course, there’s the issue of secure verification and authentication through the whole chain, meaning that application that’s running onboard the satellite is mine, the data that comes from there only goes to me, and only I can decrypt it, for example. And that is actually where I think it’s going to be one of the most exciting issues in the future. There’s lots of people experimenting on this and there’s studies on it, and there are different techniques of how to do it. What is going to be the most interesting one is how to do that in the most resource-constrained way so that the satellite itself—or it doesn’t necessarily have to be a satellite—can be a highly constrained environment, so that this overhead that you put on to apply security to the hosted software and its ground client is really, really minimized, but still has that sandboxing security and the impossibility of one application affecting the other or affecting the performance of the satellite itself.

Kartik Kumar:
If you permit me, I might push the boat out a little bit and ask you something that’s very of the time right now, which is that we have seen even with some of the sandboxing done by the AI frontier labs, that these kinds of agents that get deployed seem to be able to sometimes even break out of the sandboxes. What do you think that means?

Andy Armitage:
I think behind the scenes there, when I hear that, I’m not necessarily convinced. I think that they did actually give them permission to escape the sandbox somewhat. The problem was they didn’t realize the full consequences of allowing it to do that. I think there may have been an element of media hype in there. And, of course, on one side of the AI debate and the other, there are people who would very much like, for the purposes of getting clicks, for you to believe that AI is extremely dangerous. I do think that it is something we’re going to have to take care of, but I don’t think it’s quite the threat that the media would want us to worry about quite so much.

Going back to our original subject, which was cybersecurity of ground systems, I really dread the moment when somebody sets one of these AIs against us. One mindset you have to have is be humble. You don’t want the evil eye to turn to you. Preferably be more secure than anyone else so that the more likely target will be somebody else, because if you stand up and say, “Oh, this is 100% secure,” the next day somebody is going to prove you wrong. Never ever fall into the trap of hubris, because the next day somebody will prove you wrong, and the thing that could prove you wrong these days is an AI.

I don’t want to digress too much, but in these architectures, usually you end up with a database in the back end. Some one or other form of database; it can be a column store, it can be a traditional database. And unfortunately, there’s really no common standard across those databases for authenticating access to it or secure data at rest. There are specialist products that do it, but in the end, the state of the art is one where you have to accept that if you’re going to use a database, you’re going to have to accept that its access isn’t necessarily all that advanced. It’s designed to be very, very fast and to store data extremely efficiently, and that does come into conflict with security. So you have to watch out that the boundaries around that database are quite well protected.

Kartik Kumar:
Maybe as a final question, just to cast an eye towards the flip side of that AI coin, we had this very brief conversation, and there was mention made in the article as well, of potentially the benefits of especially these LLMs and conversational tools in assisting security engineers and architects to explore the design space—

Andy Armitage:
Yes, I think that’s interesting. One of the things is people are quite used to the idea of vibe coding using a coding assistant. But of course, you split this into sessions, and in the next session, you think, “Oh well, we’ve done this and it’s wonderful,” and in the next session, you turn it around and say, “Critique this. Critique this from a security point of view. What are, if you had to find holes in this, what would be the worst aspects?” And you get a good response. So you can turn the AI against itself and criticize its own work, which I think is a very useful way to work with it.

I think the future will be really, really exciting as we use LLMs, not so much because you can converse with them in English or because they can generate code, it’s partly as a part of the aspect of how they work means that they’re capable of planning their work. If they can plan their work, then you can ask them to, for example, compose a way to get out of a certain scenario or fix a certain problem. And I think the future is really going to be exciting when it comes to, for example, “We have this anomaly. Show me this anomaly in a way that attracts my attention without overwhelming me, and then propose a justified way out of this anomaly,” and to do that quite spontaneously. What you don’t want, of course, is that the human just goes, “Yep, yep, yep, yep,” you want the human to be in the loop and actively thinking, but I think that’s going to be something that really is an interesting area of future research.

Kartik Kumar:
Well, Andy, it’s always fascinating talking to you, and every time we talk, I feel like the time just flies by because we have so many interesting things to discuss. I’m super excited to invite you again to the podcast, because I’m sure there’s many more topics for us to chat about. Even in this half hour or so that we’ve spoken, there’s been a lot of very interesting insights for teams out there in the market today. And as I said, there’s much more to come, and I’m sure we’ll have many more discussions and many more areas of this topic of security relating to space systems and ground systems to come.

Thank you again for being here today. Before I close out, are there any things you want to mention still, anything we didn’t touch, anything you want to share with the audience?

Andy Armitage:
Ah, it’s a pleasure talking to you as always, and have a great day.

Kartik Kumar:
Great, have a great day ahead as well, and yeah, we’ll share all of the show notes and do the usual publishing online for our audience to be able to access this recording. If anybody has any questions for Andy, are they welcome to reach out to you as well directly?

Andy Armitage:
It depends. If there’s tens of millions of them, then maybe filter them. But I think if it’s in manageable numbers, then yes, sure.

Kartik Kumar:
So if you’ve got a question to follow up with Andy and you think Andy might have a perspective that can help you, feel free to reach out to him. Otherwise, you can reach out to us at satsearch as well if you have any further questions about this episode or future episodes. Thanks again, Andy, and looking forward to speaking to you again soon.

Andy Armitage:
Yeah, you too. All the best.

Kartik Kumar:
Thank you for joining Andy and myself for another episode of The Space Industry podcast by satsearch. If you have any comments, feedback, or questions, feel free to reach out to us. And if you’re a space engineer working on a cutting-edge space mission and you’re looking for any products or services, please visit us at satsearch.com. In the meantime, go daringly into the cosmos, until the next time we meet.

---

Further reading

• Spotlight: Closing the security gap in space systems – with Terma
• Spotlight: Your mission planning system will break before your rockets do – with Terma
• Scalability and expandability of ground stations with SDR technology – with Terma

---