Brandon Bailey is a Senior Project Leader in the Cyber Assessments and Research Department at the Aerospace Corporation.
He performs cybersecurity research on ground systems and spacecraft systems to better protect our critical space infrastructure.
He will be speaking about developing a tactic against space misuse using Space Attack Research and Tactic Analysis, or SPARTA.
And with that, please welcome once again Brandon to the Aerospace Builders stage.
Thanks a lot.
Appreciate you guys coming in here.
So , just by a show of hands real quick, who has not heard of the SPARTA work that we've been doing yet?
Has not.
Good.
Alright, so we're going to spend a few minutes introing what it is and what it isn't.
Just to, because I know I'll get this question, these slides are already available on the SPARTA website.
So, on the bottom here, if you go to sparta.aerospace.org slash resources, there will be a PDF version of the slides there.
As well as, there's links throughout the presentation for lots of resources, papers, things that we've been doing.
So, I'm not going to touch too much on my background, but basically I've spent the last 10 years either trying to hack into ground systems, of operational systems, or hacking into like digital twins, like last year at DEF CON, as well as attacking kind of real spacecraft.
So, I've got a background in this area, and it kind of fostered the work that I'm going to talk about today.
So, what's the problem we're dealing with when we think about cyber and space and things?
And we just saw the weather balloon discussion a minute ago.
He was talking a little bit about authentication and encryption at the end.
And one of the things you'll notice in the space domain, which is probably similar to what you just saw, is encryption authentication are kind of sometimes mainstays of the security approach.
And unfortunately, that is sometimes the only security that's implemented on these systems.
And what we're seeing with the difference in different attacks, you know, with supply chain, or very other attack vectors, insider threat, and things like that, we need to think outside the box.
So , if encryption is like your only defense on a satellite, you're more vulnerable than you realize.
And you need to think about how do we actually, you know, get above that.
So , aerospace is a federally funded research and development center.
We are basically a non-profit research institute for the government.
And we're trying to, you know, lead advancement in this area.
There's a lot of great things that are going on.
You know, the Hackasat has been going on for a few years.
And there's other entities and national labs in this space as well.
So, one of the things we noticed a few years ago when we really got into this problem was there was a lot of articles, papers written that talked about cyber as a problem in space, or cyber as a threat to space.
But it was a black box.
It was basically a cyber boogeyman that would just get you and attack your space system.
But no one ever decomposed the problem into something manageable.
You can't solve a problem unless you kind of understand the problem.
And just saying cyber will get you is not really helpful.
So, what we've been doing is really have a concerted effort on our end is to push out information in the public domain, as well as in the government sector, to get the information out there.
So, what we're seeing with the commercialization in space and the boom that's happening in all the startups, we can't necessarily keep all this security information and the way you need to protect the space system kind of behind lock and key.
It needs to be shared.
We need to benefit with what we've seen in other industries, from the industrial control system to just DEF CON in general.
Getting the word out, getting people educated on the problem is a big thing.
So, we've been working on identifying what we call the requirements, the countermeasures and things like that.
And the way we view this is we want to use threats and or TTPs to help push the corrections.
So, what we have in the federal space...
You were here yesterday and saw the White House talk, right?
We have a lot of compliance and legislation and various things.
But sometimes we don't have the low-level details that we need to really mitigate the threat.
So, that's just kind of what we're trying to do with this product and we'll talk all about it.
So, we feel like if we can help define what those right requirements are, help define what are the critical controls and critical defenses you need to build into a space system, up front, we're going to be way better off.
And one of the reasons we need to do that is, it's pretty apparent if you're not aware, but this is just an example.
This slide kind of cut off at 2018, but you're seeing a kind of an increase in security incidents for space systems.
So, you see the red line indicates the operational satellites and the blue bars are kind of the incidents that we're seeing.
So, you're seeing a little bit of that correlation between the more we deploy out there and the more incidents.
Now, this graph will probably get a little different looking when Starlink launches because there's thousands of satellites and you don't have that proportionality yet on the attack side.
But this does show that correlation over from the 60s until now.
We continue to get incidents as it relates.
So, when we were looking at this problem, we were saying, okay, how do we decompose this to something manageable?
And what we're trying to figure out is mission impact.
What is the potential impact to a space system from a cyber perspective?
And we back this up with Space Policy Directive 5, which basically says that you need to identify existing and anticipated threats and mitigate those.
And it talks about it at the space system level, and the space system is ground, link, and vehicle.
So, what we were really concerned about was, okay, let's look at the TTP, the threat action.
So , yeah, there's actors out there, there's nation states, there's varying levels of people that are doing the things, but it doesn't help you that much of knowing who's doing it.
It's what are they doing and how are they doing it is the important thing.
And if we can really decompose that problem down, help people get educated on it, we're going to be in a much better situation.
So, we said, all right, how would we document TTPs from a space cyber perspective?
And we said, well, hmm, I think there's a framework out there that exists that does decomposition of TTPs.
It's called the MITRE ATT&CK Framework.
10 years from 2013 to 2023, 10 years running, it's kind of industry standard.
So, we said, okay, call our friends at MITRE and say, hey, are you guys working on something similar?
They said, no, not really.
We said, all right, cool, let's do that.
We're going to basically use your open source framework like ATT&CK, but we're going to kind of put our space spin on it.
And then we're going to integrate a bunch of other information.
So, we felt like cybersecurity matrices have been kind of the industry standard in the last 10 years as it relates to communicating this type of information.
And we wanted to help fill that kind of critical knowledge gap on adversary behaviors.
And that's what we did.
And if you think about the way the MITRE ATT&CK Framework is currently built, and from a TTP perspective, it's really focused solely on the stuff that's on the ground.
It doesn't really talk about how you would actually attack something like a space system.
So, from that perspective, you want to make sure you kind of understand both, because the ground is an attack vector, obviously.
So, from a TTP mitigation perspective, the MITRE ATT&CK Framework is where you want to go.
But once you get to the point where you're no longer attacking a Windows or a Linux system, and you're trying to pivot and have some sort of impact on a space platform, that's when you kind of, what's called pivot, which is a concept published on MITRE as well,
that pivot into something called Sparta.
So, what we found out, you know, after doing this, talking to a lot of people, putting this together, it really is kind of the first of its kind of body of knowledge.
Because one of the things we're really focused on is, some people get really squirrelly about saying, oh, well, why are you documenting all these TTPs for space?
Well, that's just the why of why you need to implement the security that we think you need to implement.
So, some people would say, well, why do I need to do X?
Why do I need to put some sort of AI, machine learning, intrusion detection on a spacecraft?
Well, if you can't articulate the threat, then they're not going to implement the countermeasure.
So, for us, the means to implement the countermeasure is using the threat and TTP.
And that's what we've really been focused on.
So, every individual technique that we have has some sort of countermeasure tied to it.
And that's really the benefit of what we're trying to publish with this work.
And it's not just us.
So, we've had some international collaboration as well.
When we first launched Sparta, we got contributions from the European Space Agency.
We got contributions from John Hopkins, some individuals at NASA here and there, and other agencies.
So , this isn't just, hey, go listen to these few people at aerospace.
It's been an international collaboration, and we want to continue that.
Most recently, we started working with Cyber Inflight, and he's down here in the front.
He's basically, they maintain a database of attacks against space systems, and we've integrated that information into Sparta.
And we continue to extend invitations for anyone who wants to collaborate on this information.
So , go to our contribute page.
The list keeps growing as we go.
So, if you're into this type of thing, please jump in.
So , what would we actually do with Sparta?
And this will kind of wrap up the introduction before we jump into the attack chain stuff.
So, first and foremost, what we feel like Sparta is really meant for is the space system developers.
So , I think it was Chad Luck, who was here yesterday, who worked for SpaceX, said a really good question to the White House OECD folks.
It was like, well, how do we know what are the right controls to implement?
And so, what we wanted to do is basically say, hey, we want to educate developers, engineers, people who build these systems, on what is the actual threat, TTP, that could impact their system, so they can implement the countermeasure.
Because if they don't know how someone can impact their system, how are they going to know how to fix it?
And so, what we've seen in the past with security in general, with like NIST, Cybersecurity Framework, or Risk Manager Framework, those are general guidance and abstracted levels of information.
So, what we're trying to do is help bridge the gap between threat, TTP, to countermeasure, to even NIST controls, and some level of requirements, and we'll show you how that works.
But basically, educate the developers, get the countermeasures implemented.
Another one is people who are actually doing monitoring on the ground.
So, some people actually, from a defensive cyber operation perspective, some people monitor their network for security impact.
That's a novel concept, right?
Monitor the network, look for, do the detect, and defend.
So, if you're thinking about monitoring the ground infrastructure, and you have Splunk, or you have Elk Stack or something, those type of things can really understand TTPs from the MITRE perspective, because that's how they've been programmed.
But now you have something that can educate you on what to look for, how to build dashboards from a TTNC perspective on space.
So, that's something we feel like it can help with as well, because you see something go across the wire, if you don't have the context of how that can be bad, which Sparta helps you with, then you have a gap.
Another thing we're seeing, and we've gotten some really good adoptions, if you're not familiar with the Space ISAC, the Space ISAC has a watch center that they just set up in March, and essentially what they're going to be doing is tagging all their threat intelligence reports with the appropriate Sparta TTPs as well as MITRE ATT&CK TTPs and things like that.
So, we feel like from a threat intelligence, threat reporting, attack chain building, education of actual things out there, this can be used for that purpose.
That's mostly a lot of the examples that we're going to talk through, is kind of this threat intelligence, attack chain reporting aspect of it.
Assessments and tabletops, so if you're in the federal space, or I guess technically even the commercial space now, and you're responsible for some level of compliance audit through NIST 853, or now even ISO 27001, Sparta has basically all of our information counter-correlated to all those frameworks.
So basically you can go in and say, if I don't implement ISO control 5.6, what space context does that have?
What kind of gaps do I have?
If I'm not implementing NIST control AC4, for instance, what does that mean in the space context?
That's all information that's now in a tool and is publicly available.
And one big thing, education and training.
So we heard this yesterday during the ONCD discussion, was we have kind of a shortage of skilled people in this area, space cyber area.
That's a problem in cyber in general, but it's even more so a problem in the space context.
So what we did was, let's take virtually all the knowledge that we have in our collective heads, and let's put it in a repository, in a database, so that we can all kind of start from the same sheet of music.
Instead of gatekeeping information and saying, oh well, I know how to attack a space system with cyber, so pay me a lot of money.
That's not going to help the nation, right?
So we want to get all the information out there as much as possible and raise that bar of what we call common knowledge.
And like I said before, we continuously outsource this information.
Crowdsource the information so we can get input from everyone.
So you can always email sparta.arrow.org and we'll take new TTPs, new defenses, whatever it is that you can come up with, corrections or whatever.
Okay, so we'll start talking about the meat of this, the attack chain development.
So if you think about attacking a space system, it can be an attack chain, right?
If you're thinking about, I'm going to do some sort of RF injection, RFI injection, or I'm going to basically attack the ground system and not only move through the network and whatever.
Basically, Sparta can help you kind of do all those things.
And one of the things to think about is attack chains and attack flows, different terminology for different people, but basically you can document kind of every step of the way.
And that's important to break these things down is because, for instance, if you were to go look at the Viasat thing that happened in February, there were multiple stages through that attack chain where if certain countermeasures were implemented, it would have actually stopped it.
So it's really important to understand not just, hey, this was the vulnerability at the end that got us, but how did they get from point A to point B?
And having frameworks like ATT&CK, Sparta, and these other things like this really help understand that thing.
And this is not to be confused with the cyber kill chain because these are different things.
The cyber kill chain is a little more, you know, it's just phases.
It's not really, and it's a sequential order of things.
ATT&CK chains and Sparta and these other frameworks are a little bit different.
It's more than just a sequence because it breaks things down differently.
It gives you, talks about, all right, how do they achieve initial access?
How do they escalate?
How do they laterally move?
Whatever it is.
So one of the benefits of using something like Sparta to do this, so, you know, we've seen other frameworks that are out there.
They basically, sometimes you have to go in one framework to see the TTPs and go to the next framework to see how you defend against those things.
So what we're trying to do is actually aggregate all that together on one spot.
So if you start using Sparta to build ATT&CK chains, we have tools that I'll show you that can help you get educated on what are the countermeasures and show you exactly how, what you need to do to kind of mitigate those all in one place.
That way you don't have to go to like, you don't have to go read this 700 page NIST document.
You don't have to go read, you know, a thousand controls from REV5.
Or you don't have to go read the ISO standard to understand how all this interrelates together and helps you mitigate the cyber issues on your space system.
So if we have time at the end, we'll show a little demonstration of those tools that can help.
All right, so let's jump into a couple of ATT&CK chains just for the fun of it.
So if you've seen the talks that I've done in previous aerospace villages, I did a replay ATT&CK, which is a very basic ATT&CK in the space context.
Basically replaying the RF signal to call some sort of execution on a spacecraft.
Last year, did a memory injection ATT&CK on a PowerPC 750, where you could corrupt the memory space and basically render the embedded processor useless.
And then we'll do a couple of new things, just for the sake of doing new ones.
And then I'll break down something from SISAT 2023.
So if you are not aware, back in April of 2023, Thales Group, which is a European contractor, basically carried out a controlled cyber experiment on an operational asset at ESA.
And we have documented kind of how that works.
So if you think about building ATT&CK chains and what you need to know, I put some resources here for people to help you understand.
I'm all about using what information is valuable.
And it doesn't matter if SISA produced it, it doesn't matter if MITRE produced it, it doesn't matter if some European agency produced it.
If it's valuable information, we're going to use it.
So we're going to talk about... I have some screenshots from a DHS paper that talks about how to use the MITRE ATT&CK framework to kind of document ATT&CK chains.
But that exact same concept applies to Sparta, because it's built the same way.
So these are all the resources that you kind of have here at your disposal to kind of build ATT&CK chains and what that looks like.
So the next one is... so this is a paper from SISA, and it's a good paper.
So if you don't really understand, all right, this ATT&CK happened, or this ATT&CK chain, how do I build some sort of ATT&CK chain whenever there's an incident?
So SISA wrote this really good paper that says, this is kind of how you do it.
And they wrote it in the context of ATT&CK, but it applies to any of these frameworks that are built like this.
So basically, you find the behavior, and then you can potentially put it into...
ATT&CK has a thing called Navigator.
Sparta has a thing called Navigator.
And what you're trying to do is find the behavior, find the why, find the tactic.
Are they trying to get initial access?
Are they trying to execute?
Are they trying to escalate?
And then identify what's the technique or sub-technique underneath that.
So it's pretty basic, but this is a good document to kind of help break that down.
Because it helps you understand, all right, step one of any ATT&CK is initial access, right?
So what's the behavior?
How do they get initial access?
And then it's, all right, once they got initial access, what did they actually do?
How did they gain initial access?
And then so forth and so on.
And there's a lot of resources you can use within these tools to help you do that.
So just wanted to throw this paper up there for people who aren't familiar with it and want to kind of dive into ATT&CK development.
This is a good resource.
And then once you have the technique identified, you can identify the sub-techniques and then you can kind of map all this stuff out.
And it's all written here.
I'm not going to kind of belabor the issue.
But the takeaway here was it's a good 15, 20-page paper, 30-minute read to kind of really get accustomed to using these frameworks to kind of do ATT&CK development.
So let's move in to one simple ATT&CK chain.
So this ATT&CK chain was basically done in 2020 at DEF CON, Aerospace Village, and it's on YouTube.
But this happened prior to Sparta, right?
Sparta was something that we built and deployed in 2022 in October.
So the reason I'm bringing this up is basically think about how beneficial it would be if we retrospectively went through and looked at all the past incidents that we had, right?
And then we started rewriting them, these reports, or redoing the analysis with these frameworks in mind from an ATT&CK chain perspective.
Because what does that allow you to do, right?
Over time, you're going to trend.
You're going to see what's the most prevalent TTPs that are out there.
So what is the most highest risk area that we're at?
And this is why working with CyberInFlight was such a good thing for us because they've already done all this analysis of a hundred and some different attacks that have happened.
And then we work together and basically come up with a translation mapping of what they had versus Sparta.
So now we actually do have some level of trend over the last 15 years of what are the most prevalent TTPs from a space perspective that are out there.
So this is just very simple.
I'm not going to dive into too much.
But basically, from an ATT&CK chain perspective for a replay, you record the RF, you replay it, and then it causes some sort of impact.
So this is what it would look like, and this is just some screenshots from that demonstration in 2020.
Basically, we've done eavesdropping, the TTP of eavesdropping, as the RF signal was being transmitted, or in our case, a simulated RF signal.
And once it went up there, you could see the command counters in the top right corner.
They're at 1.
We replay the traffic, they go to 2.
Not that impressive, right?
A counter went from 1 to 2, so it's not that big of a deal.
So then, in that demonstration, what we did was, all right, let's basically leverage the fact that this replay works, and let's modify the bits that get sent and cause a different action.
So we recorded the actual action of a command, just a basic ping no-op command, but then we manipulated the data packets and then re-sent it again, and then caused some sort of reset failure on the vehicle.
And this is what the thing would look like.
And this is why I'm advocating for doing things like this, because this is a very basic attack, so people generally know how to prevent replay attacks, encryption authentication, basic principles.
But the concept is, if you throw these things in Sparta from a TTP perspective, you immediately get feedback in the tool that says, oh, these things in the green, these are the countermeasures you should consider implementing to mitigate that thing.
And then you can kind of pick from there, like it'll give you a list of ones that you want, and then you pick the ones that are most applicable for your attack chain, or what you're trying to do.
This is the one from last year.
This is a memory injection.
So basically, similar thing, you do a bunch of reconnaissance, you've got to figure out the memory layout and a bunch of things like that, and then you've got to actually get your initial access, which in this case was through the ground system, to send the packet to the simulator to cause the effect.
So from this attack chain, the way this works is basically, this specific one requires a lot of reconnaissance, because you basically have to do some sort of inspection of the memory layout and the memory contents and how that works.
But in this case, all we really did was review the documentation and the fault management.
So if you're into the space world, and you're wanting to learn how to really attack a spacecraft, just go read the ICDs and the fault management documents, because it is just full of juicy data that says, don't do this, it'll crash.
So as a hacker, what are you going to do?
You're going to do that, right?
So I bring that up because some people don't really understand or realize, from a space perspective, how critical what I would say that reconnaissance step is in the design information.
So if you've seen any reports over the past 20 years, their adversaries are basically eating their lunch from an exfiltration perspective.
It is a huge issue to get your design artifacts, especially your fault management and your software, exfiled.
Because that can be the first, that's the pre-attack, that's the first step to generate things.
You're not just going to be able to send a signal and have an impact, right?
You have to know what kind of signal you need to do.
All that's in the design docs.
So the reconnaissance is extremely important.
And make sure you keep that stuff under close hold.
It's very important to do that.
So this was just some screenshots of showing, you know, of the attack chain.
It's nothing crazy, but basically what we did, and you can watch that video from last year on YouTube, but basically we figured out a way to construct a packet, a CCSDS ring, and send that CCSDS ring through the front-end processor to the vehicle to basically cause the denial of disruption.
So what we did was come up with the right contents of the frame, shoot it across, and then you see the segfault, basically, in the PowerPC, which killed the system.
So why does that matter?
Why is it important to break that down?
Very similarly, you break down those TTPs, Sparta tells you which countermeasures you need to implement to mitigate it, and then you can pick out which ones you want and then go from there.
And you kind of see that on the right.
Those are NIST controls.
It's an eye chart from here, but when you get these charts, you'll see how that works and how we type.
Here's another thing.
So this is another example of, like, design artifacts.
So this is a very basic attack on NASA's core flight system, which is open source.
So if you go on GitHub and you look at their individual design artifacts and how that system works, it tells you this is how the system works.
And the way it does is, like, in this example, it's like, oh, every time our flight software starts, we run this basic thing called a relative time sequence.
Relative time sequence one.
So if you're a bad guy, you're like, oh, well, every time the thing runs, it's just going to run this, basically this script, you know, while I'll just inject in there and see what happens.
So that's what we did in this specific attack, right?
So we were simulating a supply chain attack in this example just to kind of show, hey, this can be, you know, some people think of, like, a supply chain attack as being, like, something super sophisticated.
This is one example.
This is just one line in a C file that's buried down into the flight software.
And static code analysis isn't going to find it because it's basically, it's a legitimate command.
So if you think about space, to me, some of our biggest vulnerabilities in space is more so using the system against itself.
So it's not, in my opinion, it's not, oh, a buffer overflow on the satellite.
Those do exist, and those could be impactful.
But it's more so of actually just using the system against itself.
It's a cyber-physical system, and there's a lot of trust between the ground and the spacecraft.
So you tell it to do something, it's just going to do it.
And it's not really built from the perspective that says, oh, I'm going to attack myself against some sort of intrusion.
Yet, that's why the countermeasures that we have in our system are important.
So all I did in this demonstration in attack chain was something pretty basic.
Was basically injected through the supply chain in this example, and said, all right, look, I want to basically tell this thing to reboot after like 60 seconds.
So basically, if this was real, right, you would put this one line of code in, and then every time the system boots, 60 seconds later, it reboots.
And then it just reboots, and then it just reboots.
So you never actually can kind of get going until you figure out kind of what happened.
Similarly, put the attack chain, countermeasures, go from there.
So here's another one.
So there's some CubeSats, obviously, that are out here.
There's the Moonlighter thing that's going on out there.
And I hear this sometimes, and I heard this in Europe, in that SciSat.
I was kind of surprised, because they were talking about how, well, even to this day, a lot of the CubeSats, these smaller academic things, aren't implementing, some of them aren't doing any encryption, and some are maybe barely doing authentication.
And it's like, well, some of these CubeSats actually have maneuverability.
They have reaction wheels, right?
So if you don't have basic protections on these things, like authentication and encryption, it's very easy to do bad things.
So this is just an example of kind of showing an attack chain and how that would work, right?
You do some recon, right?
You got to get the design information to kind of know what it looks like.
But once you kind of get that command database, so this is another thing that people talk about in the context of space, right?
There's the design artifacts, but there's these command dictionaries.
So one of the things that some people don't realize is a lot of times they use the same command dictionaries in the lab environments that they use in operations.
They don't make changes, right?
So people think, oh yeah, well, my command database is under lock and key in this operational system.
But for the two years you were developing it, it was just on some guy's laptop that anybody could get access to.
So it's not really that hard to get this information.
People need to realize that.
So this example basically just analyzed what the command structure looked like in the CCSDS frame, and then pushed this value to it.
And then what you get is...
Let's see.
It might just play.
Oh.
Yeah.
So this is pretty basic, but basically all it is, it's, you know, the kubectl and then all of a sudden you shoot the wrong type of command because the encryption is not working right and it just starts in a freefall tumble because you...
Actually, it wasn't like, oh look, we sent a buffer overflow to this thing and it corrupted the memory and did something crazy.
No.
You just told it, hey, increase your factor of your momentum on your reaction wheel by a hundred times and it'll do it.
Because this is like, not set up to not do that.
So that's some of the important stuff that people need to understand and realize that these systems need to be built with less trust and, you know, I don't like to use the term zero trust necessarily, but the tenets of zero trust make sense in the context of space,
right?
Segmentation, least privilege, don't just do anything the ground says because the ground says to do it.
It's very important to do that.
And if you were to model out these attack chains in something like Sparta and you get the countermeasures, you'll be able to figure out what you need to do.
So what I did was basically took these four attack chains that we built.
So you think about, if you're building a system and your people say, you should do threat modeling against your system.
Well, this is kind of a macro level of threat modeling to an extent.
So I took these four attack chains that, you know, let's all make believe that this is one system and not like four different simulators.
So I modeled out these attack chains in Sparta and then I basically said, all right, these are the things that I care about or that I think is most likely to happen on my system.
Sparta will shoot out the countermeasures and then you can pick out the ones you want.
So something you can do in Sparta is export everything in Excel because if you're an engineer in this room who doesn't love Excel and so we've made everything in Excel exportable so people can do all their data transforms they want in Excel.
So basically, map out the attack chain, dump it to Excel, you can start pulling out all the countermeasures, miscontrols, you can even get down to the shell statement requirements if you want.
So we have a couple hundred shell statement requirements that are implemented in Sparta as well.
We're going to increase that number over the next year.
So keep in tune for that.
And we're continuously pushing out releases.
We pushed out one this week.
And I'll show you a few features if I have time of what that looks like.
So if you were to put those four things in there, the countermeasures would light up, you can pull out the information in Excel.
It'll show you the countermeasure name, it'll show you what miscontrol, it'll show you sample shell statements, all that stuff.
This is kind of the importance is trying to answer that question that was asked yesterday.
It was like, what are those important controls and why?
And if you do attack chain development or you do threat modeling, you can in using these type of tools, you can get to that control list.
It's not, hey listen, because some compliance exercise told me that I'm a moderate level impact, so let's go from there.
This allows you to do threat modeling to an extent and generate those critical controls.
The last thing here to kind of go through is this thing, the operational hacking thing that happened.
So basically, this took place in April, sponsored by ESA, and it was performed by Thales Group.
And it mimics a little bit what we're seeing with HackASet 4 over there to an extent.
It's a controlled cyber experiment basically is what it is.
So what we did was we said, okay, even though this is a contrived cyber exercise, let's analyze it like it was a real attack.
So we said, alright, let's look at what this Thales did and let's break it down in the context of Sparta because what we had, when this first went in the news in April, we had customers coming to us and saying, well, what do we need to do to protect ourselves against what just happened there?
And so I was like, well, one easy way to do that is actually just, alright, let's do the analysis, throw it in Sparta, spit out the countermeasures and say, does this make sense?
And it actually worked out the way we thought it would.
So we wrote a long article on Medium already and the link's in the charts, you can go read it, but we'll do just a little snippet of it.
So one of the things that's interesting about Opsat when they did this event is Opsat's designed as an experimentation platform.
So what that means is its mission is for the user community to upload software to it to do science.
So if you think from a cyber perspective, initial access is basically granted at that point, right?
Because the whole point of the experiment is you write code to put on this vehicle and they actually run it for you.
So that provides an interesting attack vector because you don't have to do all the getting into the ground or get up through the RF leak or whatever, like, hey, here, put your software on here.
But they have security things that they look through to see if the software is malicious.
So the whole point of this attack was, you know, after initial access was granted, what next?
So researchers were given the access to the payload to execute software, which is the design, but they get, like, low privilege access, right?
So what would a user do if you're a malicious user?
You're trying to escape the sandbox you're in, escalate, move, and do whatever.
So that's exactly what they did.
And what I did when I did the analysis is basically say, hey, listen, hey, if they weren't granted initial access, these are some of the TTPs that they would have to use to actually make that, you know, happen in real life.
But in this case, initial access was granted.
So what they did was the inject was a kind of a simulated supply chain injection.
So what they did was, all right, they're permitted to actually upload software to the vehicle and their security check's done.
So they'll basically, you know, I don't know exactly what they do, but I think they just run some static code analysis against it, right?
Or whatever.
Or analyze it for malware or something.
What they did was basically they just injected their own vulnerability into the software.
So they wrote unsecured code on purpose so that then they could just exploit their own code to get the escalation they needed to get.
So that's what they did.
So they injected a vulnerability into the software that they knew about and knew how to do it.
And it was just a basic Java deserialization vulnerability.
So it wasn't like super anything crazy in advance.
And what that allowed them to do was execute basically shellcode on the system.
And this specific offset has CAN bus.
So if you know anything about 1553 or CAN bus, no segmentation, no security, really.
So what they were able to do was execute, just send data across the CAN bus to laterally move across the thing.
And you'll see links and these are all links to TTPs that are in Sparta as we did the mapping.
And then they were able to get some sort of persistence through injection in the Java library.
And then they basically modified the imagery coming down.
So it's pretty interesting to kind of watch.
So we wrote this article and we did this analysis so we could answer this next question.
There's the link.
Like I said, all these charts are on Sparta's website already so you can grab them.
So this was the attack chain that they came up with, or attack flow, right?
They evaded the detection by injecting their own vulnerability.
They used the CAN bus to laterally move and they established a backdoor through Java library injections and they modified the imagery coming down.
So what we said was, you know, Thales when they demonstrated this event, you know, this was the slide that they put up.
Well, here's how you mitigate this risk.
And it was like I looked at that and I was like, okay that's, I mean, that's none of it's wrong, but it's not super, super helpful from a detailed granularity perspective.
And we wanted, our customers wanted to know, what exactly do I do?
It would be like oh yeah, just do supply chain risk management.
That'll solve your problem.
It's like, well, I need to know, like, what can we do?
So we threw all this stuff in the navigator tool.
We dumped all the countermeasures in there and then basically said, oh look, this actually works.
If you would have done proper analysis on the ground using these methods, you'd have probably caught that before it went up.
If they got past that security using the fits and depth, if you actually had some level of segmentation on the canvas they wouldn't have been able to move.
If you weren't running everything as root, they wouldn't have been able to escalate.
If you actually were looking for some sort of onboard malicious activity using intrusion detection, you probably would have found it.
So it was a good validation of that whole concept of like, alright, take an attack chain, throw it in a tool, dump out the countermeasures and go from there.
So basically what we did in the article was show look, these are the TTPs they used.
These are the countermeasures at the steps.
If you were implementing using the fits and depth as a concept, you can see where you can mitigate this attack from that perspective.
So what are some takeaways from this presentation I hope you got?
So countermeasures can be deployed anywhere to disrupt and degrade steps on the attack chain.
You really need to understand the importance of reconnaissance and resource development because it's usually a precursor to any attack.
Basically using that cyber and flight data, 60% of the things that they had analyzed had all been basically reconnaissance, early stages of attacks.
Or, conversely, maybe that was the attack.
It was exfiltration.
So you never know because there maybe hasn't been a carry on, a second phase of that attack chain, but it's just something to consider.
For you think about attacks that are focused on the space segment, initial access can be difficult and probably the most difficult if you're using proper authentication and encryption.
But I feel like with the prevalence of supply chain, the history we've seen with insider threat, getting access to a ground system, now a lot of our ground systems are going cloud, it's more interconnected, so getting access to the ground is a lot easier than it used to be.
I think the likelihood is increasing that these are going to happen.
And once initial access is granted, it's really I personally feel like our space vehicles aren't really resilient against basic execution, escalation, lateral movement types of things.
Because we're not doing proper segmentation, we don't have least privilege, everything runs root, there's no monitoring, a lot of times there's not secure boot, digital signatures aren't a thing, so it's like all this basic stuff that we know is actually good in an embedded systems world,
we're not doing it.
And we would be a lot better off if we did that.
And something that I don't want people to take away from some of these attack chains in this presentation, or what's going on with Moonlighter across the wall here, or what happened in SySat, yes, these are contrived experiments.
But that's how we advance.
We actually need to test these theories out.
What we've seen with the Sparta work as far as, all the things that we've seen, we went back to HackAsset 3.
We've actually analyzed all three HackAssets at this point, SySat, our own research, and basically we've covered every TTP that's been used already.
My biggest thing is we've got to be able to protect against the no-knowns.
We've got to know how to protect ourselves against things that we know can happen.
Everybody wants to say, well, there's a big zero-day crazy vulnerability, and gets all excited about it.
But it's like, we aren't even doing some of the basics.
So let's get the basics done.
Let's take care of the no-knowns.
Things like Sparta, things like ATT&CK, can really help tell us what the no-knowns are so that we can actually mitigate those.
Then we can maybe pivot and focus to some of the more harder things to solve.
Let's see...
I've already said this, but space vehicles must be able to protect itself.
Some people say zero-trust in space.
So if I was to say, what does zero-trust mean in space?
Well, in the context of one space vehicle, these are the countermeasures that you can easily pull out of Sparta that kind of support the zero-trust concept.
I think I've already shown a little bit of this type of slide, but basically if you throw in ATT&CK chains, you can dump out data on countermeasures.
You've seen several of those demonstrations at this point.
This is a chart that will be in here.
There's all sorts of articles, blogs, some coverage from CyberScoop and Dark Reading and CyberWire.
There's a lot of good information that's already out there.
Congressional testimony, that link might be on there too, I don't know.
I linked a lot of papers in here and resources.
This top link is actually Indiana University is putting together a space cybersecurity digital badge program.
If you want to go check that out, you can go to that URL.
All the past presentations, all these papers are all listed here.
Like I said, it's on the website.
You can go from there.
The one thing I wanted to do is
hopefully real quick I think I should have some time.
In preparation for DEF CON, we basically Oh, I'm not showing that screen.
How do I show this screen there?
Can you do that?
No?
Okay.
One of the things that you I sent out a notice to a lot of people on the list.
If you go to Sparta today, we launched a new release yesterday, two days ago.
One of the big things that we did is ISO 27,000.
So we had a lot of European customers asking for how do the countermeasures, how does Sparta actually interrelate with the ISO standard?
So that's now out there.
But I think the biggest thing we did, we kept having this question come up.
We said, hey, you have 150 TTPs in here.
How do I know which ones are the ones that I need to worry about the most?
Which ones will impact me the most?
So what we did was we used the threat model that we published two or three years ago.
And we went through and did a risk analysis of every single TTP that we had.
And we rated it on a 5 by 5 risk matrix.
So now you can go into Sparta and you can see if you're basically which ones are high in the red of the top right quadrant of a risk cube and on down the list.
And we based that on the threat model and a bunch of analysis that we did.
So you can go in there, just precursor some of the things.
Jamming, high on the list, supply chain, software, firmware corruption, high on the list, things like that.
If you go there, there's a blog on Medium that talks all about it, so go out there and give that a read if you can.
But with that, I think I'll take a question or two if there's a minute or two.
It looks like there's probably five minutes.
So any questions at this point?
No.
So the question was, are we getting logs or correlations?
No, we're not.
Just like MITRE ATT&CK and stuff like that, we don't get logs or anything.
What we do get is we continually work with partners across the world now that give us references of things.
Like if there's a new experiment that's happened or when Hack Sat 4 is over, we'll analyze all those TTPs and that'll get filled in.
So what you will notice, in every TTP that we have in there, at the bottom there's a thing called references.
So if there's some article, blog, tweet, something that has some level of assurance that's accurate, there'll be a reference in there that says this is kind of where we pulled it from.
So it's not like a real-time log perspective.
Sir?
Do you analyze the data yourself
?
Oh , okay.
Yeah, so the question is, do we counteranalyze the countermeasures with mission objectives?
So SPARTA and things like that are mostly, it's agnostic of the mission because it's a generic tool, not with context of the mission.
So what you would need to do, which is basically throw your TTPs or get your countermeasure list and then you as the user have to counteract that.
So for instance, something that might be on our list that says you should put onboard intrusion detection on your spacecraft.
Not a lot of people may do that.
They may not have the size, weight, power, compute to do it or the tech to do it.
So you're saying, well, I don't have that tech.
Can't do that.
What's something else I could do?
So what we're trying to do is give you a laundry list of potential countermeasures that could make sense for you and then you have to kind of down select based on your mission profile.
So what we did do though, in that published, the RISC-Q publication, we basically created a three-tier system in there.
It's basically high, medium, low.
So we said if you're a high criticality system, you know, military, intelligence, whatever, or national critical infrastructure, you're in that high category.
Medium category, you're doing weather, civil space, maybe commercial.
Low category is basically academic research, that type of thing.
So what that did was basically create a different bucket structure for like, as an academic researcher, you know, this TTV RISC is at this level for me, but it's going to be different for a critical infrastructure item.
So that's kind of how we're approaching it, and this is our first go at publishing that type of information , and we're going to hopefully get feedback from the community .
Is there another question?
I think there's time for one more maybe.
Screw me, I'll repeat it.
Yeah .
So yeah, the question is any noticeable differences with ISO 27000.
And we put this on the website.
So one of the things we did was, because ISO is a paid standard, there's very limited things you can publish about it, right?
So what we did do, late July , and NIST published an updated translation of NIST 853 -05 to ISO 27000 -2022.
So what we did was use that correlation between NIST and ISO and publish, because we don't want to publish things that we don't own, right?
So what I would say in a generic sense, ISO is a higher level of abstraction than NIST, right?
So there are let's say a thousand NIST controls that are in the 853 database, and I don't know the number, I'm making this up, 200 of those have some sort of translation to ISO.
So that immediately tells you right off the bat, it's like, NIST is a much more thorough analysis of that.
And I said 27000 really meant more so for organizational information security stuff.
I don't think it's really, it's not really meant for space systems, but I think on a European side, I think a lot of their laws or regulation all ties to ISO.
So it was kind of trying to bridge that gap to show, alright, well, how can we use we want to advance the state of practice on the space vehicle, but we only, the only hammer we have is ISO, so let's help them get to that point, was kind of there.
One more.
We're good?
One more.
Okay.
We're good.
Thanks.
I'll be around until Monday.
Come find me.
All my contact info is on the slides.
Go to the Sparta website.
Thanks for coming.
I appreciate it.