And thank you.
How's everyone doing?
Awesome.
I hope everyone's having a fun time.
So yeah, that's my intro.
Let's go to the next one.
Title slide.
Of course, I'm with Lockheed Martin.
And a little bit more about me is I went to Embriddle Aeronautic University.
So I know there's quite a few of us here.
But I'm an alumni from 2019.
And Lockheed Martin is my third DoD contractor.
I worked at two others.
One as an intern for about five years.
Another one for two years.
Working on embedded avionics as well.
And currently I'm a senior cyber system security engineer at Lockheed Martin.
And we'll talk a little bit more about that.
And I have a bunch of hobbies.
So if you have a hobby, I probably have that hobby.
You can find me on Twitter.
I don't really use it.
I only use it for DEF CON.
Other than that, I'm on the internet.
And that's one of my cats.
So for those of you who don't know much about Lockheed Martin, we have four main business areas.
One of those, the business area that I'm in is aeronautics.
We also have missiles and fire control, rotary missions and systems, and space.
So within aeronautics, this is our portfolio.
So these are a lot of the cool things that we get to work on.
And hopefully we'll get to talk a little bit more about that.
So what is the ACR?
Well, of course, as you heard earlier, it stands for the aeronautics cyber range.
And what we do is given the purple color, we are essentially a purple team.
We are product focused.
So we get to think like adversaries and try and develop objectives for tests and go about those tests and come up with actionable mitigations and deliver those to teams and help them throughout their life cycle to patch those.
And basically at the bottom there, conduct cyber testing to ensure our aeronautics weapons systems are cyber survivable throughout their entire life cycle.
So here's a little bit about our methodology.
We have several competencies.
We have hardware, software, embedded networking, RF, and a little bit of simulation modeling.
So I focus mostly on software.
So we do a lot of dynamic and static code analysis and debugging and decompiling.
And as well as working with some exploits.
We also make a crap ton of in-house tools.
Of course, as we'll talk about later, there's not really tools open on the Internet for looking at the portfolio that we look at.
So this talk is about kind of some of the roadblocks that we've faced as starting up an aeronautic cyber range.
I think I'll piggyback on maybe some of the things from the last presentation, if you're here for that.
But hopefully a little bit different and maybe a little bit more elaborated.
So some of the big things, five things we'll talk about is threat intelligence, looking for system data, and the ostrich in the room, and making sure everyone is on the same page.
Communication is a big thing that leads to some of the biggest roadblocks that we've had.
And of course, we'll talk about everyone's favorite, silver bullets.
So hopefully we all like memes.
I have a lot of them.
So the first thing is threat intelligence.
If you can't read it, on the left side are going to be like the barriers, and on the right side are going to be kind of some of those solutions to those barriers.
And they'll be the same for every slide.
So this is an older version, so read them backwards from what I just said.
I fixed it, but this one's old.
That's okay.
So on the left side where it says barriers, those are actually our solutions, and on the right side, those are our barriers.
So while looking at that, so of course with threat intelligence, there's not a lot of public information about what we work with.
And if there is, it's very well safe-kept.
So especially when you compare it to traditional IT or Windows servers, there's a ton of information out there.
There's a million platforms, you can learn all sorts of information about that.
And given the safety-critical aspects of aviation just in general, that's what leads to those threats being kept secret.
Of course, we've gotten the question a lot, how do you inform your tests then?
And what kind of government threat feeds, or what threat feeds do you look at for this?
And to talk a little bit about this, a coworker, Theresa, who's here in the front row, she gave a presentation last year, if you were here, all about this.
So you can definitely reference that.
It should be online, I assume.
And essentially, the threat exists, and it's up to us to think like the adversary, and we need to do a good engineering analysis and ask better questions.
And I'll talk more about that with communication.
So one of the other things we do to help solve this is we like to go and talk to our engineers, and talk to our test teams, and ask them a lot of questions, and ask them about what they see, because what they see and what's on the ICD might be a little bit different.
And those are your people who are most intimate with the system, and that's definitely a great source for that, which I'll talk about in a little bit, too.
The next slide.
So that's where we talk about locating the truth.
Everyone's favorite, and hopefully, too many people don't run into this, but it does happen as the runaround.
Constantly, you'll be like, you'll be told, hey, this is the team that has the information for you, and you'll go contact that team, and then they'll point you to another team, and then you go to that team, and they point you back to the first team, and that sucks.
But what it does do for you is it helps you check off who doesn't have the information that you have, and then you can log down all those names, and hopefully, at some point, you'll have a list of names of who has some information, who has no information,
and hopefully, you get to the one person that has some information.
We also, in organizations, you have data in multiple places.
People will have, like, network shares with some documents, or they'll have SharePoint with some documents, or sometimes just printed copies, or it's all in someone's head, and hopefully, that person still works at your company, and so that definitely makes it difficult for tracking down a lot of that information.
And if that person leaves, that's when you leave into, or run into the SME leaving the company, and that always sucks.
So, we'll talk about the solutions, but part of our job is to make sure that we help with that documentation process, and making sure we can also capture as much as we can.
Sometimes, what happens to unintentional developer gaslighting?
Essentially, when you're talking to some people, their job is so narrow-focused that they might tell you a system works one way, and in reality, that's not exactly how it works, or not, like, the complete truth, and that can definitely be annoying when you're trying to look at the entire attack surface.
So, they're going to tell you that, you know, device A talks directly to device B, but, and from their perspective in software, maybe that is the case, but realistically in hardware, device A is going to talk to its network card, which has software, and then it's going to talk to a switch,
and then that's going to talk to another device, and then maybe it'll finally get to your B device.
So, that's where documentation comes in real handy, and a lot of times, once we're running tests, what will happen is we've gained all this information and put a better picture together than what we've seen in documentation, or combined multiple documents into one document,
and now you run into the situation where you're listening, and people, after you do your testing, will come to you for questions, knowing that you have interacted with that in a way that maybe some others haven't, or have kind of combined some of those pieces,
so instead of the same thing getting different pieces of information from two different groups, they can go to you for that source.
So, again, that's where your documentation really comes into play.
So, everything we do, we try and document as much as possible about the system, not only our tests, of course we're documenting exactly what we're doing in those results, but really about the system as a whole.
And another very important thing, leading into the next slide, is that when you are looking at a system to go test, likely those engineers don't even know who you are, or that a cyber team exists, and so you likely will have to bring those engineers in on what it is that you're doing,
and explain to them, hey, we're trying to send a message from device A to device B, and we want to mess with the size field, and how is your system supposed to handle that information, so that you can give them a better idea, and get hopefully a better answer back that will help you drive your test cases.
And the next thing is the ostrich in the room.
So, cyber is scary, right?
There's a lot of keywords, like cyber security, pen testing, that a lot of people get spooked by, and they don't want you touching their things, and a lot of that, I think, is, there's definitely a lot of negative attention, especially in the media, when big cyber crime happens,
and that's really unfortunate, because we're doing similar things, but we're on the same team here, like, we work at the same company, and I'm not trying to hurt you or your feelings, I'm just trying to help make better, secure products.
So, to do that, we really have to focus on a commutative, improvement-driven pen test, and a big thing is to, which I see a lot of red teamers do, is to not focus on wins, and what I mean by that is that you can't go to the product, and you can't have a competition,
and you can't have a bunch of different product owners bragging about owning their systems.
As fun as that is, obviously, yes, please do that on your teams internally, but when you're presenting your findings, it's not the best idea, because they're going to feel almost attacked and very defensive about it.
And so instead, you need to focus on how to help them improve their product and kind of educate them along with that process.
So this will definitely help you gain trust with those teams, which we've seen a lot.
We're able to really help and help drive some secure coding practices and have a continued relationship with programs based on our feedback.
And it just becomes a really good feedback loop.
So another big thing is communicating with everybody involved.
Like I said previously, a lot of times the program may not know who you are.
If you're not directly attached to a program and you sit maybe over several programs, they may have no idea that you exist.
And the testing may not be driven by them or your government customer.
And they may also not know that you exist.
So in a way...
Sorry.
In a way, you have to go brag about yourselves, right?
Once you do something great, you gotta go tell everyone and do what we call roadshows.
Invite people into your team and give them a presentation.
Tell them what you do and show them what it is that you can provide for them.
And then...
Sorry, I keep reading it backwards and getting confused.
And then another problem that you might see is that the customer didn't ask for your testing and it's internally driven.
And so when you show up and say, hey, we want to test your thing, they definitely will get super defensive about that and want to ask a lot of questions.
And that's, again, where it's important to bring them in and show them what it is that you're doing and why you're doing it so that you can get on the same page with them.
And the last one, hopefully it doesn't offend anybody, but silver bullets don't exist.
And there should be a dot, dot, dot at least yet.
And in embedded avionics, this becomes very difficult, again, because there's not a lot of public tools or information.
And essentially, defending against hackers is indescribable.
If it were, it would not be in a cyber war.
And a big thing is it's amazing that there's lots of companies pursuing AI, which is fantastic.
And that's something we need.
But there's a big emphasis, I see a lot, that it's a big thing to invest in securing your product first.
And what I mean by that is make sure that you basically find all you're looking for.
That's super important.
If you have a super fancy AI that maybe it is capable of everything you say it is.
And maybe it is the next best thing since sliced bread.
And if all of those are true, which is awesome.
If you're having an adversarial mindset, the first thing that an adversary is going to do is...
They're not going to look at your AI because that shit's complex and they don't want to spend the time to do that.
So instead, they're going to look for the low-hanging fruit.
And they're going to try to attack your system that way.
And if you spent all your money chasing this silver bullet and haven't patched the easy stuff, then your silver bullet isn't really a silver bullet.
And that's really sad.
So definitely follow an iterative approach where you want to find those low-hanging fruit and patch what you can.
And then look through it again and look at it in a different light and try to find those same issues or different ways to find those same issues.
And always keep going deeper.
And then of course, something, something, supply chain.
I don't want to talk too much about it because I feel like it always gets beaten like a dead horse.
But yeah, your supply chain is important.
And that goes back to no matter how secure you make your product, you have to make sure your supply chain is secure.
Because essentially it's just a quick, easy backdoor right into your product.
Alright, I know it was kind of short, but hopefully there's a lot of questions.
So before we get to questions though, I will say that we are running a CTF.
Hopefully you have seen it.
I don't believe anyone has solved it as of yet.
So we are, to the first solve, giving away this F35 Model B.
They're really cool and really nice if you haven't seen them.
And we should be running that until about 2pm tomorrow.
And also, as always, come to our booth and talk to us about jobs.
Thank you.