His presentation today is on a moving target defense, also known as MTD, Algorithm for Mitigating Data Exfiltration from an Adversary.
I've known a few targets to try and avoid me.
Now please give a warm welcome for Chris.
Thank you for that introduction.
So once again, my name is Chris Jenkins.
I am a Cybersecurity Reacher at Sandia National Labs.
And here is an internal research and development project that we worked on for about two years.
Focusing on space cybersecurity, and you can see the team up there.
And we also did some work with Purdue University with them trying to break our algorithm.
So here you have your typical agenda.
We're going to go over why this work is being done, the background, look at the algorithm in detail, experimentation that we've done, and then also what did Purdue do to try to potentially break this algorithm.
And so before I start, I actually wanted to go a little bit over about myself.
You can see the background of my education up there.
The big joke I always tell people is that from kindergarten to grad school, I didn't take a break from school.
So once I finished my master's, I decided to get away from school a little bit.
So I went to Taiwan for four months, went out to San Diego to work at Qualcomm for about a year, decided I wanted to finish up my PhD, went back to Madison, and been in Albuquerque ever since.
And so that shows you kind of my first job at Sandia, some of the work that came out of it, and right now I focus on high-performance computing, operational technology, and then also serve as a cybersecurity consultant for some of the programs that work.
So before COVID, I did a lot of Latin dancing, and then once the pandemic hit, we decided to start doing some RV trips.
So for those of you in the audience that have done any RV trips, I would definitely like some other spots to potentially go to in the nation.
And then I also do some work for some STEM programs, getting the youth interested in becoming an engineer and learning more about cybersecurity.
So just by a quick show of hands, how many people have heard of Sandia National Labs?
Oh, much more than I expected, perfectly.
So some of the things that we've done, the clean room was invented there, which I didn't know until I started.
And we've also done some work for COVID-19 as well as the Mars Lander.
So for those of you who know about DOE, we have 17 national labs, two of them for Sandia, one in Albuquerque, which is where I'm based out of, and then also one in Livermore, California.
So getting back to the talk.
So at DEF CON, I think everyone pretty much knows this, but really my one slide I show, just to say, hey, cybersecurity, someone gets in, there's a compromise, your mission is pretty much over with.
And we want to move into cyber resilience, where we can have degradation and potentially continue to operate through the mission.
So really looking at defensive strategies when we speak about cyber resilience.
And so the type of systems that I look at, so one of the things about the national labs, we tend to work on problems that commercial industry shouldn't, can't, or won't work on.
And so we look at a lot of high consequence systems, and for those of you who have watched the news in the last five years, as those systems get connected and become more connected, they become a chance for an attack.
So what I'm going to speak about today is really under the key results, the first three bullet points.
But the point of this slide is to hopefully show that we've put this algorithm through its paces.
We think it's a great moving target defense algorithm.
We're going to show the key results today, and I think the last bullet point there, number four, even though we had it for a particular application, we realized towards the end of this work that, in fact, it could be used for other applications and use it as a generalized algorithm or generalized approach.
So I'll go into the background, another show of hands, how many people here have heard of moving target defense?
Okay, so a lot less.
So the best way I like to describe it is that if you live in a house, and I want to case your house, I'm typically going to watch you, I'm going to watch how many doors, windows you have, what is the address of the house, color of the house, who's going in,
who's coming out.
And if I come back tomorrow and the house has a different address, a different color, maybe it's down the street, maybe it had two doors, now it has five doors or no doors, that's kind of moving target defense, is that me as the person trying to case your house,
the house itself is changing, and so the moving target is the fact that I don't know what it's going to look like tomorrow.
So you can apply that concept and that approach as a cyber security or a cyber resiliency mechanism that we did.
So in this particular graphic, you just have an attacker that's trying to attack a particular web server or server, it doesn't know the IP address, the server is hopping around, and if you are a legitimate user of the server, you know how it's going to hop so you can access the things you need to access,
and if you're an attacker, it's a lot harder.
And so a lot of moving target defense research that we've seen focuses on IP-based networking or cloud computing.
We wanted to look at something that's more on a real-time communication, command and control type of network, and so we chose MIL-STD-1553 based on a report from the Air Force Research Lab.
And so just at a very high level how it works, you have a bus controller, which controls the entire bus, you have up to 31 remote terminals, and so typically the bus controller is either sending data to the remote terminal, or the remote terminal is being requested to send data to the bus controller,
or potentially a different remote terminal, and you have a bus monitor which functions similarly to a flight recorder on your aircraft.
And so in terms of the actual message, we won't get into everything, but really for our particular work, if you look at where it says I guess in parentheses 3-R-1-32, the first number three is what we're interested in.
So that is the address of the remote terminal, and what we wanted to determine is if we change that address randomly, does that help prevent attacks?
And then two, how does that happen?
And how can you do that where you can still operate and continue to conduct your mission?
And so our particular hypothesis, like I said, once again, this is research, is the integration of moving target defence with a real-time protocol can increase cyber resilience of platforms using that protocol.
And so one, the two key research questions, how can you implement it such that it does not destroy the reliability of MIL-STD-1553?
And then two, can you actually provide quantitative as opposed to qualitative evidence that it does in fact improve cyber resilience?
And so, like I mentioned before, a lot of MTD research that I've seen focuses on cloud computing, and it focuses on IP networks, in particular IP version 4, and in this case we're focusing on real-time systems, those typically found in swap-constrained systems,
and we also don't require anomaly detection, which in and of itself is a very tough problem, which can be used in conjunction with anomaly detection, but we don't necessarily need it for this to work.
So now we're going to dive a little bit more into the algorithm.
So these are, I would say, the six aspects that we really looked at.
I think the first two are the ones that have to work, I believe, for the first of the four to matter.
And so, as I mentioned before, we wanted to keep the underlying protocol.
We thought about having a new protocol, but given that 1553 has started in 1973, it's used heavily in military weapons systems, it's something that's been around for such a long time, it's also used in spacecraft as well.
And so it's something that we didn't want to change, it's tried and true, we wanted to keep that.
And then the second point, which I think is probably more interesting, more to the research, if I have a bus that has five devices, and all those devices are changing, potentially at a millisecond level or faster, how do I make sure that I don't have address collisions,
right?
That's like the big thing.
If that doesn't work, then everything else is like whatever.
And so those are really the two that I'm going to harp on today, because if those work, I think everything else has been solved in other areas, and so we can probably borrow from them.
So the way that it works is that we start with a shared key and a nonce, or a number used once, and we feed it into a randomness primitive.
For the sake of brevity, we're just going to treat the randomness primitive as a single box, but there are some substeps to it, and we have this coded up into a DLL, and so we were able to show that what comes out of it is a randomized array, and our particular application,
n has a size of 31.
So we have a randomized array between the values of zero and 30, and then in a random order, and then we also produce, in this particular case, a 16-byte nonce which is fed back into this particular randomness primitive, and, as you can see, you can constantly keep doing this,
and you effectively produce a 2D matrix, but we call it the state matrix.
So, given that we have this matrix, or state matrix, I should say, how would we use it?
So, one particular way, the bus controller would send out an index value of three.
If a remote terminal has an address of zero, its new address would be four, and then for a remote terminal that has an address of four, excuse me, its new address would be 24, and because that particular every column is a randomized ordering, you guarantee that every single node is going to have a different address.
And so this particular method is called the static offset indexing method, meaning that for every index, the offset or the new address is always the same.
And we will see why, when we apply machine learning to defeat this, that was an issue.
Another way that we can do it, we call it the current offset method, so very similar concept, node starts with an address of zero, index of three comes out, the new address is four, but now, if an index of one comes out, its new address is five.
So now, with an address of five, you have an index of two that comes out, your new address is one, and in this case, if an index of four comes out, your new address is 16.
So hopefully you can see that between the static way and the current way, the current offset method allows a particular node, or really all the nodes, to move around the matrix a lot more, and once again, when we get to machine learning that Purdue did,
we will see why that matters.
So, once we actually saw that we have this algorithm, we know how we want it to work, we wanted to see can we look at some of the properties to see if it made sense to continue the research.
So, for this particular result, we generated a state matrix, one with 256 columns, one with 65,000 columns, and we just generated random indexes and figured out what is the next address, and we created a histogram with it, and the thing that stood out to us is that even though one state matrix is much larger,
you actually have similar entropy for both, and so it just told us that we didn't need to have a large state matrix for this idea to work.
This chart is probably a 30-minute presentation in its own right, but the gist of it is one of our machine learning experts on our team, she looked at three concepts in a state matrix.
The offset method, the size of the state matrix, in this case between 256 and 65,000, and she also looked at if you take a state matrix, use it for a certain amount of time, generate another one and use that for a certain amount of time, how does that affect unpredictability?
So looking at the chart, one being highly unpredictable, zero being highly predictable, we can see that really only the offset method changed a lot of the nine different unpredictability metrics.
And so, for us, it kind of gave us some insight that, hey, the size doesn't matter, that matches the previous slide, we can generate new state matrices, doesn't affect unpredictability which is good, but the way that we index into the state matrix actually matters.
Once again, once you get to the machine learning, we'll see how that affected the algorithm.
So now that we have the algorithm, we have it coded, what can we do to actually see if this really works on real hardware?
So we had two different phases.
So phase one is, I think we did this the first summer with two interns, a little bit of seed money, so we wanted something really simple for the interns to work on, and so we calculated the Fibonacci sequence with and without MTD.
We saw that to calculate it went pretty quick.
In this case, we calculated the 24th number.
And so, because of that, we wanted to say, well, we need to generate more messages, so we'll consider one time that you calculate the 24th number, that's a generation, and so we might do 50 generations, 5,000 generations, but just a way to generate more data,
just to really make sure that it does in fact work the way that we think it should work.
And then for phase two, we saw that, as I said, we read a report that highlighted some concerns regarding this bus, and one of those concerns was exfiltration.
And so we wanted to conduct an experiment to figure out if an adversary wanted to exfiltrate data from a particular node, could we quantify the reduction in the amount of information that adversary got?
And so here's a device we used.
It's made from a company called Out2DT, they're based in New Mexico, so a short drive from where we work at to go work with them, but it's kind of using the pen to show you the size of the device that we were using to conduct our experiments.
So how does it work?
So I mentioned earlier we conducted this on a 1553 bus, the algorithm could be used for other buses and other applications, but we started out with 1553, so in our case, the bus controller sends an MTD start command.
That start command has that nonce, and we also assume that the BC to RT has the shared key, but the nonce can't be sent on the bus.
The RT takes the nonce, takes the shared key, generates the state matrix, and then calculates a 512-bit keyed message authentication code, or HMAC, and sends that back to the bus controller.
The bus controller can conduct the same HMAC over its internal state, and as long as those two match, then it can guarantee that itself, and really any number of RTs share the same state matrix, because, without that, this really does not work.
So the bus controller sends out two numbers, the RT adds a month, sends back the answer, and we consider that a frame.
That happens a certain number of times.
And then we have what's called an MTD update command.
That update command sends out an index, the BC and the RT change to a new address, and then you continue calculating the Fibonacci sequence.
So this really proves that, if this doesn't work, then the algorithm doesn't work.
And so just to dive down a little bit more into it, you can see in the MTD start command, that's the nonce.
For the MTD verify command that has the keyed, excuse me, the HMAC, the update has the hexadecimal value of 17, and then, of course, when it finishes, it's at B520, which is the 24th Fibonacci number.
So we were able to show that, by having these indexes come out every so often, we can vary how frequently the indexes came out, we were still able to always calculate the 24th Fibonacci number as many times as we want.
So we were able to see that it did work.
And so, as I mentioned before, we wanted to see could this actually slow down exfiltration?
So a very similar concept.
We have a host node, which is effectively your BC, a listening node, which is your BM, participant node, which is an RT, and then we have an exfil node, which in terms of implementation is a bus monitor, but it only listens at a particular address.
So we're assuming the adversary potentially knows the device it wants to listen to, knows the commands that it wants to listen to, and it wants to just pull off commands to a particular node.
And so our question is, does the implementation of MTD reduce the fraction of messages of value that are exfiltrated?
And so looking at the left side of the slide, we can see that on the y-axis, resilience increases as we go down, which means you exfiltrate less information, and then on the x-axis, you have the frequency.
And so, as you go from left to right, the frequency decreases, which means you're just not sending an MTD update message that often.
So, if you see 70, for example, it means every 70 frames, we send out an MTD update.
If it's 60, for every 60 frames, we send out an MTD update.
And so what we saw is that we had a reduction of 97 per cent.
So, in this case, the bad guy or the exfil node would pick an address, we would conduct the experiment of doing the Fibonacci sequence, and any time the RT value had the address that matches the adversary, the adversary would pull out the information,
but once that address changes, then the adversary would gain no information.
That's how we set up the experiment.
And so that's the left side.
We move to the right side, same exact concept, except in this case, we assume the adversary knows the address to start with.
On the left side, it was a random address that was selected to start the experiment.
On the right side, the RT address and the exfil node is always at the same address.
And so what we saw, which makes sense, is that moving to the left side, when you have a higher frequency, the adversary spends less time at the correct address, and as you move to the right, which has a lower frequency, you can see that, in this case,
maybe looking at 70, 80, or 90, because the adversary is starting at the correct address, it's actually exfiltrating a lot of that data at the initial part of the experiment, but we only did it for 50 generations, and so we believe if we did it for 5,000,
50,000, a lot more, we would actually have the right side and the left side graphs be the same.
And so the last part of this is some work that we did with Purdue University with Professor Bhargava, Bharat Bhargava, and so we gave them the challenge of being able to try to defeat the algorithm.
So this may be a little hard for those to see in the back, but what I have circled is the actual part I want you to pay attention to.
And so if you see the 1-r-4-2, once again, as I said before, the first number is what you need to pay attention to.
So this message goes to remote terminal one.
And when you look at message number 15, that's the MTD update message.
It has the hexadecimal value 17.
And if you look at message number 16 and 17, now that first number is 27.
So the question is, can you take a data capture and say, if you have remote terminal one, a hexadecimal value of 17 that comes out, I know the next answer, your next address, as I said, is going to be 27.
Can you use machine learning to figure that out?
Since this was also during the pandemic, we also kind of reduced some of the things we wanted the students to figure out, but they used the LSTM model, they kept the test size at 20 per cent, and they varied the training set size for their experimentation.
And so, any guesses to the thing that they broke it or not?
Quick show of hands, how many people think they broke it?
Okay.
So the short answer is, in this configuration, the static configuration, they did break it.
So, if you have the F1 or the MCC score, as it gets closer to one, effectively, they are guessing the next address correctly.
So, as you go from the left side to the right side, the left side is just looking at the current address and the index value.
The next one over is looking at the previous address, the current address, and the index value, and then on the far side, the two previous addresses, the current address and the index value.
And so, in a static offset method, they actually broke the algorithm, and they were ecstatic, they were happy, I couldn't get them off the jubilation.
And then we made one change, one line of change in our C++ code, and they were not nearly as happy.
And they kept saying to us they wanted to get more data and they wanted to do different things, but what we really took away from it is that this particular machine, I think any machine learning algorithm, but this one in particular, figured out the one-to-one correlation that was present in the static offset method.
That correlation is not present in the current offset method, and so it made it a lot harder to predict the next address which matches what our unpredictability results showed as well.
And so, to finish up, there's a lot of standards that NIST has.
To my knowledge, it does not have a moving target defence standard, and so given that we have an algorithm where you can tweak different components to use for a variety of applications, this would be really cool to have actually as a NIST standard, or potentially one of many standards that could be.
We like to use some other machine learning algorithms, in this case, some state-of-the-art algorithms to see if we can defeat it.
LSTM, as I told you, is not necessarily state-of-the-art anymore, so let's see if we can look at some other algorithms to potentially defeat it.
There's some other technology at the lab that focuses on IPv4 networks, in this case, TCP port encryption, and originally, they used one static key for all messages between the devices communicating.
With adding this technology into it, we were able to use three separate keys per packet, so really add to the entropy and the dynamic nature of a technology that was developed before our project even started, which really shows that we use it for 1553,
we use it for IP networks, what else can we use it for?
So we have some other ideas that we have.
Transparent file system we thought about using could help with ransomware, and then also looking at rolling codes in different ways that we could do key rolling to potentially help out with key fobs as well.
So a lot of ideas that we have, I always welcome feedback, and so with that, I will say thank you for your time, and I will take some questions.
Yes.
And I can repeat the question if need be.
So the question is, if someone knows the algorithm, does it weaken the protection?
Yes.
Okay, cool.
The answer is no, because it's similar to cryptography.
So everyone knows AES, triple DES, two fish, blowfish, a variety of algorithms, SHA, but the key about encryption is that if you don't know the key, it should be impossible to decipher the message, and so we're going to go with that same assumption, since our randomness perimeter is based on cryptography,
that if you don't know the key, you cannot produce the same state matrix.
Good question, though.
So the question is, does this apply to other real-time networks outside of 1553, such as Spacewire, other kind of point-to-point networks?
So it's funny you say that, because Spacewire was on the agenda, but there's this thing called COVID, which reduced the funding we got, and so they said, well, since you already have something working for 1553, just keep moving forward.
But the fact that we have a way forward with our IP solution, we believe, yes, it could be used for Spacewire, but once again, there's going to be pros and cons, but the algorithm is not specific to 1553.
So thank you.
So if I understand it correctly, if you have a loss of connectivity, how does the algorithm perform?
So I would say we have not tested that directly.
I think we are looking for other partners to test scenarios that you have mentioned, but we don't have an answer right now for what happens if you lose connectivity.
My guess would be the system would, for that particular time, be a little bit more static, but then once you gain connectivity, you can go back to the dynamic environment, but we have not specifically tested that scenario.
So thank you.
I'll be around if you want to talk later, we can, but thank you again for coming to my presentation.