So, here we are. The end of day one. Our final talk. Something that I've been super excited to hear about.
But before we get to that, again, if you haven't gotten a t-shirt, head out to the AppSecVillage website.
You can pick up a shirt there. And let's give a big thumbs up to everybody who helped to put this on this year.
This is fantastic. Definitely want to thank everyone.
The next speaker, Mario Arias, is going to talk about Threat Modeling the Death Star.
Which, what a better model can we use, right?
Mario is a software developer with 10 years of experience in four different countries.
His expertise involves security, DevOps, and Agile practices.
Mario helps teams to deliver value quickly while keeping applications, infrastructure, and data safe.
With that, let's welcome Mario to the stage.
Hello, everyone. Welcome to my talk, Threat Modeling the Death Star.
My name is Mario. I have been a software developer for over 10 years.
And recently, I have moved to be a full-time security engineer two or three years ago.
And today, nowadays, I'm a software engineer at Canva.
Today, I want to talk about Threat Modeling.
Threat Modeling is a subject that is very important and is very dear to my heart for many different reasons.
But the main reason is a reason that was shown on the State of DevOps report from last year.
So, the State of DevOps report is a report done by Puppet and different companies
where they look at different companies and they try to get information about how efficient they are in the DevOps world.
And one of the things they look at is security.
And they have, like, looking at all different companies on all different sizes.
The most effective way to improve your security posture is to do collaborative Threat Models
with the security team and the development teams.
That's really, really important to improve your security posture.
And that's what I have seen in my experience as well as a security engineer.
Every time I introduce Threat Modeling to a company or to a team, I could see the benefits of it very quickly.
Like, the improvement of the security posture.
But before we're going to jump in and go into more advanced details about Threat Modeling,
I want to talk a little bit about what the definition is, right?
And if you look, if you try to Google it, you're going to see, like, many different definitions.
But this one I like the best.
It's that Threat Modeling is a process to identify and enumerate threats.
That's what Threat Modeling is at the end of the day, right?
And that makes a lot of sense for security people.
But then when you try to go to non-security people or non-Threat Modeling nerds,
they don't get very impressed, right?
It's a very dry concept. It's a very abstract concept.
And it's really hard to engage people who are not from security to actually understand and get involved with Threat Modeling.
And that's a hard situation, isn't it?
Like, where you have Threat Modeling brings so much benefits to the organization.
But on the other hand, it's really hard to get other people to do it.
And that was my position a few years ago.
And I tried to introduce Threat Modeling in a company.
And I really knew that Threat Modeling is quite important.
But I also knew that it's not very engaging at all.
So I was trying to find a balance where I could reap the benefits of Threat Modeling
while making sure people were motivated enough to engage and participate in the process.
It's not only one checkbox that you need to do at the end of the day, right?
Anyway, then I came up with a list of requirements.
What the requirements are?
The requirements are something like, I felt, if it wasn't there for the Threat Modeling process,
it wouldn't be very successful.
I wouldn't think that actually it's something that's valuable to the company.
And I came up with three different requirements, right?
One is, it needs to be engaging. Threat Modeling definitely needs to be engaging.
It shouldn't be another boring meeting people need to attend.
It should be something more fun and more engaging,
so people can go and have a good time, at least in the Threat Modeling session.
It needs to be highly collaborative.
Again, the magic of the Threat Modeling happens when you get the security team doing it,
and the development team is doing it as well, together.
And collaborating gets the process done.
It's not like a process for me, it was like a no-go,
a process where the security team did it behind the scenes,
and they just returned a report to the development team.
It definitely wasn't something I wanted to do.
And finally, it needs to be valuable for everyone.
And it sounds a bit silly, but it's very easy for people to think,
like, I'm doing this Threat Modeling just to make sure the security team is happy,
and then I can do my stuff.
That's not the idea that I want to do for the Threat Modeling.
I want something that if people are participating, collaborating,
they could get something out of it.
They could understand the process, and see the value of it,
and then do it again and again.
Not only because the security team wants to have the software more secure,
because they also see value, and they also want to get their software more secure.
And then I look at very different methodologies.
I look at Stride, I look at Pasta, I look at many others.
But the software methodology that I like the most is Attack Trace.
I think that resonates well with me, my experience,
and resonates very well with the teams and companies I have worked for,
where I introduced that.
I really like the way, because it's very simple, and it's very easy to do it.
That doesn't mean it's the best methodology for everyone,
like, different people have different styles, different companies have different cultures.
You might find something different for yourself.
But for me, when I saw Attack Trace, I really understood the concept.
I really could see that being rolled out to the company.
But before I actually tried to do the rollout for the company,
I did a pilot first.
I chose a few selected teams.
They were doing some interesting work,
and they were trying to model the aggregate value at that phase of the work.
And with that, I talked to them, I did some pilots,
I did a few training models,
and then I did a survey at the end of it,
to see what people think about the process.
And I really asked them to be very honest,
because if it wasn't working for them,
chances are it wouldn't work for other people in the company,
so it wouldn't be successful,
and we should just start from scratching in,
rather than try to roll out that process.
And the numbers I got were very positive, let's say this.
80% of developers found it useful, they found it valuable,
and they would participate again.
And for me, the participation again was the ultimate metric.
If they would participate again, it's because I hit the three requirements.
They saw value in it, it was collaborative, and it was engaging.
And they saw value, they actually saw value for them,
and they wanted to do it again.
So that made me feel confident,
and then I did roll out that to the rest of the company.
And I'm going to talk about that,
what's the process I did roll out,
but I want to use Star Wars for that.
Because, again, thread modeling is very dry,
it's a very abstract concept.
So I always try to get different ways to make thread modeling a bit more engaging.
And Star Wars is one of the funniest ways that I have seen so far.
So let's start with Star Wars.
And that story starts with yourself, in the audience, watching this at this point,
where you are the new CSO of the Galactic Empire,
Chief Security Officer.
Well done.
You started as a low-level Stormtrooper,
fighting the trenches against the rebellion,
and you made all your way to the top.
Now you're a Chief Security Officer.
Well, well done.
But not everything is perfect, isn't it?
That guy now is your new boss.
Yeah, and...
How can I say this?
He has a very different style of leadership.
This whole thing you learned about today,
blameless culture or servant leadership,
is definitely not something he believes in.
He's more like an old-school kind of guy.
He really thinks high accountability is the way moving forward.
But that's okay.
Everybody had some problematic boss at some point in their careers.
I'm pretty sure you can work around the guy.
And you, as being a CSO,
you start to look at the crowd use of the Empire.
What's the most important assets?
And what do you need to protect first before everything else?
And the answer was very easy and very big as well.
The answer was the Death Star.
It's the most expensive project in the whole Galactic Empire.
It costs around 2 trillion credits.
It's been 20 years in the making.
It's the biggest weapon of the galaxy.
And a major strategic asset for the Galactic Empire.
So definitely, that's the asset you need to focus on.
However, it's a project that's been like any waterfall project.
They are like over budget and overdue.
And the business is not happy with it.
And the business would like to release that as quickly as they can to production.
It's been delayed, delayed, delayed for over too many years.
So your boss and the Emperor, they're not very happy.
But that's fine.
You can work with that.
You're a professional, right?
Okay, so you've identified already what you need to protect.
That's the Death Star.
It's a good first step.
But you need to have some sort of understanding what kind of adversaries are going to happen.
Like what kind of attackers are going to happen.
And you use a simple exercise called evil personas.
The Galactic Empire has been attacked for too many years already.
So you kind of know exactly what kind of attackers the Empire can have.
So let's talk about it because we need to protect the Death Star against them.
And the fourth one is very interesting.
It's Jar Jar Binks, right?
Jar Jar Binks just represents a class of attackers where they don't know very well what they are doing.
They don't have too many resources.
They're also very competitive.
So they keep trying to show their colleagues how good they are.
Sometimes it can be annoying for the Empire.
But honestly, when it comes to the Death Star, they are not very important personas.
So although it's good to list them, but it's not very good for your modeling for the Death Star.
So we'll just move to the next persona.
Now we're going to talk about Han Solo, right?
And Han Solo is a very interesting persona because Han Solo has a lot more expertise.
Han Solo knows what they're doing like any other Bolt Hunters.
They know what they're doing.
They have more resources as well.
They have their own ship.
They might have different weapons.
But then again, they are there for the money and they don't organize themselves very well.
Bolt Hunters are very competitive as well.
They keep trying to go to the easy prey and get some easy money.
But they don't try anything too big or anything like that.
When it comes to the Death Star, it can be annoying.
But on the other hand, they're probably not a big threat as well.
But these people...
These people can be problematic.
Jedis.
First, their expertise is huge.
Well, not only because they have been training for many, many years.
But because they have magic in their favor.
How can you defend against magic?
If you have a guard and they're like, you didn't see me or whatever.
It's really, really hard to defend against them.
Lucky you, since your boss managed to kill most of them years and years ago.
And the ones that are out there, they're probably hidden and they're not much of a threat anyway.
So although you list them as a threat, because they're very unlikely to show up.
And it's very hard to protect against these people.
You also don't focus them very much.
You trust that your boss did a very good job and eliminated them.
Then we start talking about more interesting personas when it comes to the Death Star.
And here we talk about insider threats.
But honestly, insider threats should be many different personas.
Because the Empire has many different levels, ranking levels, right?
A Stormtrooper that's an insider threat is not as dangerous.
Whereas a Sea Lab executive like yourself is becoming an insider threat.
Regardless of their position though, they have been trained by the Galactic Empire, right?
So they have a strong training and they know what they need to do.
They are very good at what they do.
They might have, again, resources.
It's a bit of an interesting thing.
If you're a Stormtrooper, you don't have much money.
Whereas a Sea Lab executive like yourself has lots of money, lots of resources.
But regardless, again, of their position, they organize themselves pretty well.
The Galactic Empire is a military organization.
So they organize all the insider threats.
They can join terrorist groups.
They can form their own terrorist groups.
So they can't become a problem because they organize themselves very well.
Even if you're at a low level Stormtrooper.
But the most important persona for the Death Star is Princess Leia, right?
Princess Leia represents the Rebellion.
The Rebellion, as you all well know, is a terrorist organization trying to bring trouble to the Galactic Empire.
Whereas the Empire is just trying to make the galaxy stable, you know?
A bit of order here and there.
But although they are a terrorist organization, they have lots of expertise.
They have pilots, they have diplomats, they have spies.
And they are very good.
They can sometimes go toe-to-toe with the Galactic Empire.
So they do have a lot of expertise.
Even for a terrorist organization, they have lots of resources.
You're not quite sure where they get the money from.
But they have lots of money.
They have a small army.
They have ships.
They have bases across the galaxy.
So they have lots of resources.
And for a terrorist organization, they organize themselves pretty well.
They have become a major pain for the Galactic Empire in the last few years.
Sometimes shut down Empire operations or shut down entire armies.
So definitely Princess Leia is your most important persona.
And the one you need to look after.
Cool. So that's the summary of your personas, right?
From Skipped Kitty, going through Bounty Hunter, Inside the Threat,
Jedis, and even Princess Leia, the Rebellion.
Now going back a little bit to the real world.
Personas, if you want to do that in your own organization,
for a large organization, it shouldn't be very hard for you
because your organization probably has been attacked before.
So you just talk to the security team in your company,
the ones who look more incident response.
They might have an idea of the kind of attackers you have.
If you, on the other hand, are working for a smaller company,
you might try to look at other websites and find places where they define generic attackers.
You start with them, and then as you grow, as you scale,
and then have real attacks, you can tweak your personas as you go.
But it's important to have a kind of understanding of what the attackers are
and not keep only on the abstract level of an imaginable attacker.
Cool. So now you have the asset that's a Death Star.
You have the personas. So now it's time to build the attack tree.
And the first thing you need to do is get the right people in the room.
I remember when my first slide was talking about how TreadMoney should be a collaborative exercise
and everybody should participate together.
So that's what you try to do.
You try to get everybody in the room so you could run the exercise.
You got the Death Star designers and architects.
You got your own team.
You took so much trouble to go through that.
Because imagine, it's really hard already to go into the time zones
and book everybody at the same time when you're across the galaxy
where time zones are not even a thing.
But somehow you managed to put everyone in the room.
You even got Darth Vader to do an introduction for the meeting,
to give some motivation for people, you know, like the kind of C-level introduction.
And then you start to run the attack tree session.
And the attack tree session starts with the root node.
It's kind of the attacker role, right?
What the attacker wants to do against your asset.
And you could look at very different kind of attacks.
For example, if you look at Han Solo, a bounty hunter.
When he looks at the Death Star, he's probably trying to make some money out of it.
He might steal some weapons, he might steal food, I don't know.
He might steal a lot of stuff.
But then you need to look and focus on what's most damaging for the Galactic Empire.
Even if Han Solo manages to steal a bunch of weapons or a bunch of food,
that really doesn't impact very much the Galactic Empire.
It's annoying for sure, but it's not much of a big problem.
So you come up with two different attacker roles.
If the attacker manages to accomplish this, it can be really damaging for the Galactic Empire.
So you're going to focus on that one.
And there are two kinds of goals that you need to look at.
Take control of the Death Star or take the Death Star out of action.
And taking control of the Death Star would be really, really bad.
Imagine going to 20 years of project, release that to production,
just for some kind of attacker to get that weapon from you and use against the Empire.
That would be terrible.
But as well, it would be very unlikely for the kind of attackers you have,
because none of them have the resources to actually manage a ship like the Death Star.
You need to have like one million crew inside the Death Star to manage the whole thing.
You need to have a very specific expertise and there's lots of proprietary technology.
So even Princess Leia wouldn't be able to take the Death Star out of the Galactic Empire and use it against the Empire.
But they definitely, definitely can take the Death Star out of action.
That's probably what would be the first goal.
As soon as they know about the Death Star, they try to take it out of action and take this advantage,
the Galactic Empire's beauty, out of the game.
So we're going to focus on that.
And we're also going to focus on Princess Leia as a persona,
because she's probably the one who can actually accomplish this.
So we chose to take the Death Star out of action.
Now we need to think about how would you try to do this, right?
How would you accomplish taking the Death Star out of action?
So that's where the collaboration and the magic happens.
The security team throws some ideas, the developers throw other ideas,
and then you try to figure out which one of these nodes are more likely to happen.
And when you've got everybody in the room, there are two kinds of nodes that show up.
They're really important, and then they're more likely to happen.
One is disable the Death Star.
I'm not talking about a 15-minute disablement or maybe turn off the power for 15 minutes or something like that.
I'm talking about some sort of disablement that is so dangerous, it's so problematic,
that probably the Death Star is not usable anymore.
You need to rebuild the Death Star from scratch so you can re-enable again.
So it's kind of a disablement, where it's probably better to just create another one rather than fix it.
Same like you break your iPhone screen, for example.
It's so expensive, they're most likely to just buy a new one.
And the other one is destroy the Death Star.
Literally destroy the whole thing, exploding PCs or whatever.
So that's the two main ways you can take the Death Star out of action.
So let's focus a little bit on disable the Death Star.
To disable the Death Star, you'd have two kinds of nodes as well.
Two different ways to do this.
One is what we call a system failure and the other one is a mechanical failure.
And a system failure is mostly like, for example, you disable the navigation system,
you disable the heating system, you disable the engine system.
You disable in such a way these core critical systems that they might cause a chain reaction
in the other systems and shut down the Death Star.
Or it can cause some sort of mechanical failure.
And then it can cause some problem on the hardware itself.
And the hardware can cause, again, another kind of chain reaction
that's going to cause the whole Death Star to shut down.
So how would you accomplish these things?
And then for system failure, you need to compromise a critical IT system.
And for the mechanical failure, you need to overload the critical infrastructure.
So let's elaborate that a little bit.
So there are many systems running inside the Death Star, right?
And they manage some sort of critical infrastructure.
So if you have access, if an attacker has access to this kind of systems,
they can do some damage.
But usually the system protects against problematic parameters,
problematic variables, or any dangerous kind of action.
So what you want to do is, what an attacker needs to do,
is not only have access to these systems,
they need to compromise so they can bypass these kind of protections
to cause a system failure.
When it comes to mechanical failure, you might overload some critical infrastructure.
So you might overload the heating system somehow.
And to overload the heating system, you might cause all the hardware to have problems, right?
Or you can cause the Death Star to be very uncomfortable to stay with,
and people need to leave the ship.
So there are different ways you can do that.
But the interesting thing is, regardless if you're trying to compromise
the critical IT system or overload the critical infrastructure,
you need to have access to the internal network.
That's no other way. So either to have access to sensitive areas of the Death Star,
you need to have this kind of action, you need to have this kind of privilege,
or to compromise the critical IT system, you need to be inside the network
so you can interact with the system.
And it's internal network, because if you think about it,
Death Star is just a weapon, right?
It's not like they make their system public so people can access it.
They are not a service, right? They are a weapon.
And as a weapon, they hide everything as much as they can.
So in order to get privilege access, you need to be inside the internal network.
Anything that's public is probably not very important
and segregated from the other internal network.
And in order to get access to the internal network,
you need to be inside the Death Star. There is no other way.
And then again, Death Star is a weapon,
and they don't expose systems to the outside world.
And they segregated that stuff very well.
So you need to be inside the Death Star.
So maybe you can go to a server room or steal some kind of employee badge
or biometrics or whatever.
So in order to get your privilege access.
The interesting thing is, we could go in more detail
and like, how would you get physical access to the Death Star?
But as I said before, the Death Star has one million crew, right?
Like, it's very likely that an attacker like Princess Leia
is going to be able to do that.
Even if that's not true, another attacker that we have
is an internal attacker.
So it might be a person who actually has rights to be inside the Death Star
and inside the Death Star to try to do some malicious.
So we're going to stop this part of the attack tree here
and go to the next step.
So that's all we have so far.
So we have like, take the Death Star out of action.
You have disabled the Death Star
and then you have system failure and mechanical failure
and so on and so forth.
But this is only one part of the attack trees, right?
We have the other one where you want to destroy the Death Star.
So how would you do that?
How would you destroy the Death Star?
And there are basically two ways to do this.
One is a big military attack.
The Death Star is a big weapon.
It's a huge weapon.
It can cause a lot of damage.
But also, it's still vulnerable to kind of military attacks.
So yeah, that's a way to do it.
And there is another way that you figure out on the training modeling.
And you are so proud that you actually got that.
There is a reactor inside the Death Star.
In the very core of the Death Star, there is a reactor
which controls everything and provides energy for the whole ship.
But the reactor is very, very hot.
So it needs to send this heat to the space.
And the way to do that, they build ventilation tunnels
that go from the core straight to the top of the ship.
So then the heat can dissipate.
But this is also a vulnerability.
Because now we have a straight path to the core.
And the core is very unstable.
So anything that goes there, any kind of explosion,
can cause a chain reaction that can explode the whole Death Star.
It's a really big problem in case an attacker can exploit this.
But there are some sort of protections, let's say.
The first one is obscurity.
This kind of port is not very...
You need to know where the port is, for one.
The Death Star is huge.
There is no easy way for an attacker from outside to know where they should hit.
And second, the port is very small.
It's only two meters wide.
So it's really hard for any kind of pilot to send a bomb over there.
So it's not like it's very likely that to happen.
But still, not really great.
So in order to destroy the reactor, you need to shoot the thermal port.
And to shoot the thermal port, you need to know where the port is, right?
So you need to obtain the Death Star plans.
You need to somehow know what the port is so you can go there and shoot it.
And that's the second piece of the attack tree.
So together with the first part of the attack tree and the second part of the attack tree,
that's what we found out about the main problems with the Death Star design
or the procedures we have at the moment.
And these are the main goals
the attacker can try to accomplish.
So if you get access to privilege,
privilege access to network,
that's going to be a problem.
They have different ways where they can accomplish the disabling of the Death Star.
A military attack, really huge,
but something that a rebellion can pull out.
So if you're not prepared,
the rebellion can try to destroy the Death Star by a huge military attack.
And finally, the thermal port.
If somehow an attacker can shoot the thermal port,
they cause a chain reaction
and it can destroy the reactor and the Death Star altogether.
That's good.
So that was part of the threat modeling.
And then you figure out some threats.
And the way I like it,
why I like the attack trees is because it's a problem solving exercise.
And everyone in 90 has this kind of mindset of problem solving.
We have a problem and try to solve it.
That's how we do, right?
That's how we operate.
But rather than like use this to build stuff,
now we have to change the mindset and say like,
now rather than use your problem solve to build,
you're going to use your problem solving skills to attack.
That's really, really powerful to get this kind of people,
who usually don't think about attackers or attacks at all,
thinking about these things.
And it's interesting to see how they can find vulnerabilities on their own design.
And it's very interesting as well, because they are collaborating on the session.
When you need to go back to them and say,
hey, remember the vulnerability we found, we need to fix it.
They already know the context.
They were there.
Maybe they were the ones who found out anyway.
And they are the ones who know how to fix it easily as well.
So it's a really interesting exercise.
And it's really, really powerful the way we can get people who never think about attackers,
try to think like this.
It makes them look at their system in a very different way.
And they only can cause good things,
because they know how to fix the problems and make the system more secure.
Cool.
Now you have identified the risks and the threats.
So now we need to mitigate those.
And the first risk we need to mitigate is privileged access to the internal network.
And the impact for that is high.
If an attacker actually manages to do this,
it can be really problematic for the Empire.
The likelihood we put as a medium,
because it's not very easy, you need to be inside the Death Star.
But the Death Star and the network of the Death Star is not very secure.
The Rebellion has been hacking the Galactic Empire for many years.
But you are a good security professional, aren't you?
So you come up with some measures that you can implement in the network,
some quick wins, some testing.
And then you harden the network and make it a lot harder for the attacker
to get privileged access to this.
So after this work has been done,
you actually managed to improve the likelihood from medium to low.
The impact is too high, though.
It's really hard to make sure the impact is going to go down.
But at least it's unlikely that it's going to happen.
Next one.
The next one is a military attack.
And then again, the impact is really high.
If Rebellion can pull out an attack,
then it can destroy the Death Star.
That's a really, really high impact.
But the likelihood is also high.
Why is that? Because if you are Princess Leia,
and you get to know that your biggest adversary has such a big weapon,
you probably want to go and try to attack them first.
But there are a few things you can do to mitigate that risk.
The first thing is you need to come up with ways for the crew
to respond to attacks very easily and very efficiently.
So you define the runbooks,
you make sure people keep on the call,
and keep on training,
and make sure this exercise has been running.
So when the actual real thing comes,
the response works very well.
But not only that, the Death Star is going to need some support, right?
So that's why you get Star Destroyers.
Star Destroyers are very big, other big ships of the Galactic Empire.
And if they are close by when the Death Star is being attacked,
they can provide really helpful and strong support.
And probably less likely for Rebellion to attack the Death Star
when they have strong support as the Star Destroyers.
And finally, try to monitor the Rebellion activities, right?
If they try to pull out that kind of attack,
it's a huge movementation,
and they need to talk to so many different people,
and a lot of coordination.
So if you get some sort of signal out of them,
and then you interpret that,
you can prepare before they actually pull out the attack.
So you'll be a lot more prepared when they come.
So for this, you manage to get impact from high to medium.
Because even if the Rebellion tries to attack with a strong military attack,
you'll be a lot more prepared,
and maybe you can either defeat them,
or at least buy enough time to get the Death Star out of them.
So that's a good outcome.
And the likelihood is also medium.
Because if the Rebellion cannot actually destroy the Death Star,
they'll most likely not try to attack.
They'll only go for the victory, right?
So if the victory is not certain,
they'll probably not be able to do it.
But regardless, you need to be prepared,
and then that's what you did.
Very well done.
And finally, shoot at the thermal port.
And the impact, again, is as high as the other risks.
If somebody manages to shoot at the thermal port,
you destroy the reactor, you destroy the Death Star.
And the likelihood was low.
And you didn't like how this outcome was low.
And why is that?
People were saying the likelihood is low
because you need to know where the port is.
And even if you do, it's a really difficult and hard shot, right?
So you wanted to do a little bit more.
You wanted to do some sort of protections,
and maybe cause, like, if an attacker is coming,
just close down the door,
or open different ones, or have different levels of protection.
You try to argue for that.
But remember, I was talking in the beginning.
The project was being delayed for so many years already.
The budget has been, like, over for many years as well.
So the business didn't want to, like, go back to the design,
redesign the kind of ports to make sure it's more secure,
and then implement it.
That delayed the project for a few more years.
And so the business decided to accept the risk.
So, but yet, you're going to try to do something, right?
So at least you're going to try to hide the DevStar plans.
So if one of the things they need to do
in order to shoot the terminal port,
they need to know where the port is.
So if at least you try to hide it and make it harder
for an attacker to find out about the DevStar plan,
sorry, about the DevStar port,
then it wouldn't be a problem anymore, right?
At least you would mitigate to a certain level.
That's the only thing you could have done, so you did.
And then you went on with your life, right?
You did the best you could,
then you look at different other areas of the security
of the Galactic Empire, and you hope for the best.
And then eventually, the DevStar has been released,
and the DevStar has been like a cause of joy for the Empire.
They caused lots of trouble for the Galactic Empire,
and that happened.
The DevStar was destroyed,
which is not a good outcome for anyone in the Galactic Empire.
But you're a professional, right?
So what do you do in that situation?
Forensic analysis.
So you try to figure out what went wrong,
how the Rebellion managed to destroy such an important weapon.
And the answer is this guy, Luke Skywalker.
He was the one who managed to shoot the Determinant port.
But there are some interesting things about Luke Skywalker.
The first thing is, he's a Jedi,
which is interesting, because they were supposed to be hiding,
not actually attacking the Empire.
And before he actually managed to shoot the Terminal port,
he was about to be shot down,
but the person who actually helped Luke Skywalker
was a bounty hunter.
He came up at the last minute and saved Luke from being destroyed,
and then Luke managed to shoot the Terminal port.
Which is interesting, because bounty hunters only help...
they only work for money, right?
They don't organize themselves very well,
so why a bounty hunter is helping a Jedi?
There's another thing that's quite interesting.
Luke Skywalker is actually Princess Leia's brother,
which makes him a high-level ranking Rebellion official, too.
So he's not only a Jedi,
he's a Rebellion official.
So, yes, interesting.
And the worst part of it all, the worst part...
Luke Skywalker is the son of your boss, right?
Which makes this whole lot more complicated,
because Luke Skywalker is considered an internal attacker now?
You don't know.
But definitely, like, not a problem,
and you don't have a good feeling about it, right?
That's a problem for your boss,
to take care of his family and his own boss.
But yeah, Luke Skywalker is definitely a problem,
and he was the one who managed to pull the shot.
But how did Luke Skywalker actually manage to find out about the port, right?
And the answer is these two people here.
They managed to hack the Galactic Empire and get the plans.
And you did a good job.
You put the Death Star plans in a very secure location,
at least the most secure you had in the Galactic Empire.
So these two people managed to go to this location,
hack into the data centers,
install the hard drive,
and then send the copy of it to the Rebellion.
You know what's worse?
The worst thing about that is there was no encryption arrest!
So they only got a copy of the hard drive and sent it to the Rebellion.
That's not really good.
But that's how they did it.
So they stole the plans, they sent the plans to the Rebellion,
the Rebellion quickly attacked the Death Star,
and for a miracle they managed to shoot to the Terminal port,
and everything was destroyed, right?
Well, I wish good luck for you,
because now you need to deliver your report for the forensic analysis to your boss.
Good luck!
Now let's talk a little bit about lessons learned, right?
Lessons learned of this story.
And the interesting thing is,
I used this analogy where you found out about the problem of the Terminal port
at the very end of the design,
at the very end of the building of the software,
at the very end, before going to production.
And then there's a problem that happens in all companies.
You find a security problem at the very end,
and then you need to fix it,
but nobody wants to fix it before release to production.
So thread modeling is something that you should do early and often.
So in the case of the Death Star,
if you have done the thread modeling at the design level,
and people are like,
design this Death Star and come up with this design of the Terminal port,
you could have seen it, or someone from your team,
seen the problem, and then you fix the design.
Right there.
It's a lot cheaper to fix at the design level,
or the beginning of the construction,
or in the case of software, the beginning of the coding,
than actually at the very end, right?
And that's a problem that happens all the time.
So if you want to do thread modeling, do it early and do it often.
Because things change, right?
Especially for software, things change all the time.
We pivot, we implement new features, we scope certain features.
So we need to look at that a certain amount of time.
There are always unknowns, right?
In this case, Luke Skywalker was a very unknown.
He was at least three different personas, right?
So even though you have thread modeling,
and you have covered some of the risks,
you always need to think about that you might have not seen something.
Or there's some sort of information that you don't have it.
Or the attacker can act in a very different way.
So it's not because you haven't done thread modeling, it means you're secure.
It means you covered some of the worst threats,
but that doesn't mean you are very secure.
So you still need to do some work on top of it.
Thread modeling is just the beginning.
And finally, thread modeling must be engaging.
And then again, if people go to a meeting that's very boring,
and they don't like it, and it's complicated,
or it's on a checkbox, they don't engage.
If they don't engage, they don't collaborate.
If they don't collaborate, you don't have the magic of the thread modeling.
The modeling doesn't work as well, as good as they would if people are engaging.
So in this case, I have been using attack trees.
I think it's been very successful where I have been done it.
But it doesn't need to be attack trees.
Regardless of what you do for thread modeling,
you need to make sure the people involved are engaging,
they are engaged, they have a good time,
and they see value in it, so they can keep coming back
and keep doing this exercise over and over again.
Cool. That's all I have to talk about today.
Thank you very much. May the force be with you.