A Death Star the Rebels Won’t Destroy
Fourth time’s the charm
If you’ve seen more than one Star Wars movie, you’ve probably noticed a pattern. The villains spend a lot of time and money building a massive super-weapon (Death Star I, Death Star II, and then most recently Starkiller Base) only to have it destroyed in a few minutes by those meddling Jedis.
If you’re rooting for the Jedi and the forces of good in the universe, then this is awesome — if you’re a Sith, it probably sucks. Some amazing nerds did the math on how much the steel would cost for Death Star I (by far the smallest of the three), and it comes to about $852,000,000,000,000,000. Yeah, 852,000 trillion dollars. So it’s probably worth putting some resources towards keeping that thing from getting blown up, yeah?
Well let’s imagine we’re the Sith Death Star designers (the Geonosians led by Archduke Poggle the Lesser to be specific) and we want to build a fourth super-weapon. This time, let’s start with a threat model. Creating the threat model takes three steps:
- Break the super-weapon down into each of its parts
- Figure out how the Rebels could attack each part
- Make a strategy to defend against each attack
1. What makes a Death Star?
First, we need to think about all of the different pieces that it’ll take to build a Death Star in the first place, and it’s always worth drawing a diagram. We need to think about how people come and go, where our weak points are, and what we depend on to keep the weapon functional.
Our Death Star is composed of these five sections:
- Physical shell and body
- Reactor Core
- Protective Shields
- Station Schematics
- Storm Troopers
All of these are related, so is any of them is compromised, our Death Star is probably going down.
“An analysis of the plans provided by Princess Leia has demonstrated a weakness in the battle station.” ~General Dodonna
2. Check everything for weaknesses
We’ve already messed this up three times and had tons of money and hard work obliterated, so this time let’s use a framework to make sure we’re not forgetting anything. Thankfully, some company called Microsoft from a galaxy far far away created a framework for threat modeling called STRIDE. STRIDE stands for:
- S — Spoofing (pretending not to be someone you’re not)
- T — Tampering (modifying something you shouldn’t be able to)
- R — Repudiation (denying responsibility for some action, whether you did it or not)
- I — Information Disclosure (accessing information you shouldn’t have)
- D — Denial of Service (preventing something from operating correctly)
- E — Elevation of Privilege (gaining abilities you shouldn’t have)
If we think through all of those different kinds of attacks for every component, we’re way less likely to miss something.
Physical Shell and body
The outside of the Death Star is pretty tough, but its large size and crew give it some vulnerabilities.
Spoofing: The Death Star only allows certain ships to approach, so if you’re able to take over one of their ships, you might be able to get access to the Death Star.
Tampering:
Repudiation:
Information Disclosure: Where is the Death Star? How big is it? These are important questions for anyone who wants to destroy it.
Denial of Service: It would take a massive attack to destroy it, but what if the Rebels build their own Death Star ��
Elevation of Privilege:
Reactor core
This has been the achilles heel of the Death Stars. We have got to do a better job protecting this darn thing.
Spoofing:
Tampering:
Repudiation:
Information Disclosure: It’s really important that the rebels not know where the reactor’s thermal exhaust shafts are, or how to get to them. We already know they will use that information if they can.
Denial of Service: This is a highly volatile reactor, destroying it will blow up the whole Death Star
Elevation of Privilege:
Protective Shields
We use shields every time, but they keep getting through! It turns out there are a lot of ways to attack the shields.
Spoofing: These shields let some people through, so the rebels could pretend to be those people.
Tampering:
Repudiation: The shields are invisible, so it could seem like they’re online when they’re actually down.
Information Disclosure: Learning where the base that generates the shield is located is the first step to disabling the shield.
Denial of Service: Destroy the base, take down the shield.
Elevation of Privilege: If you take control of the base, you can turn the shield on or off
Station Schematics
The rebels always seem to know our weak spots. Maybe it’s because they keep getting our blueprints?
Spoofing:
Tampering:
Repudiation:
Information Disclosure: It takes millions of people to run this ship, so the crew to build it must have been huge too. That means a lot of copies of construction schematics, which keep getting into the wrong hands.
Denial of Service:
Elevation of Privilege:
Storm troopers
The crew of our ship, and the ones who are supposed to protect it. Equipped with lasers, which unfortunately always miss.
Spoofing: These uniforms make it impossible to know who’s inside them, so it’s really easy to steal a suit and spoof your way into almost any protected area. Seriously, who designed these things?
Tampering:
Repudiation:
Information Disclosure: The storm troopers don’t usually know that much, but what they do know, they give up easily.
Denial of Service: There are a lot of storm troopers, so this would take a massive army to pull off, but they are killable.
Elevation of Privilege: Put on the suit, get the privileges.
3. Learn from our mistakes
The biggest security problem is fundamental for a project like this. We are building a massive object which will be very hard to change quickly, and millions of people are going to know about it. That means that information about the ship is bound to get out, and it’ll probably still be relevant by the time the Rebels get it. That means we need to build our newest Death Star with the mindset that all information is public, we cannot rely on security through obscurity.
With that in mind, our primary vulnerabilities are still our reactor core and the base where we generate the protective shield. We already have tons of soldiers, but they do a terrible job of protecting our important targets. So first, we should invest in target practice for literally everyone. Seriously, we pay for millions of blasters and they’ve basically never hit one of the important targets. Second, we need uniforms that aren’t so easy to steal. How about an alarm that goes off when the suit is taken off without a commander present? Then the alarm can be turned off by any commander who has verified the identity of the person inside the suit.
Finally, is there a way for us to use smaller thermal exhaust ports for our reactor? We can have more of them, as long as the rebels can’t fly an X-Wing into them.
That’s a threat model
Now we’re much better equipped to build a Death Star that’s actually worth the quadrillions of dollars that we’re going to pour into it. It only takes a minute to break anything down into its pieces, run through STRIDE for each piece, and see where the vulnerabilities are, but it makes such a huge difference. That’s why, just like version control, threat models are a tool that should be in every engineer’s toolbox.
It doesn’t matter if you’re building a Death Star, the Westeros Wall, or an app to share photos with friends, someone’s going to try to break what you build. It’s up to you to defend it.
B is the CEO and co-founder at Clef. If two-factor authentication has been in your backlog for months, but still hasn’t gotten prioritized, check out Clef’s new product Instant2FA.com — it’s two-factor authentication that takes minutes to integrate instead of weeks.
