Category: Star Wars

In a memo issued Jan. 4 and rescinded about an hour later, Deputy Defense Secretary Pat Shanahan announced a new “Central Cloud Computing Program Office” — or “C3PO” — to “acquire the Joint Enterprise Defense Infrastructure (JEDI) Cloud.”

“C3PO is authorized to obligate funds as necessary in support of the JEDI Cloud,” Shanahan, a former Boeing Co. executive, wrote, managing to get a beloved droid from the space-themed movies and an equally popular fictional order of warriors into what otherwise would be a routine message in the Pentagon bureaucracy.

The memo was recalled because “it was issued in error,” according to Shanahan’s spokesman, Navy Captain Jeff Davis.

Thanks to MC for the story.

The Resistance Has Infiltrated This Base!

Pen Testing The Empire

[Updated with a leaked copy of the response from Imperial Security.]

To: Grand Moff Tarkin
Re: “The Pentesters Strike Back” memo
Classification: Imperial Secret/Attorney Directed Work Product


We have received and analyzed the “Pentesters Strike Back” video, created by Kessel Cyber Security Consulting, in support of their report 05.25.1977. This memo analyzes the video, presents internal analysis, and offers strategies for response to the Trade Federation.

In short, this is typical pen test slagging of our operational security investments, which meet or exceed all best practices. It is likely just a negotiating tactic, albeit one with catchy music.

Finding 1.3: “Endpoints unprotected against spoofing.” This is true, depending on a certain point of view. Following the execution of Order 66, standing policy has been “The Jedi are extinct. Their fire has gone out of the universe.” As such, Stormtrooper training has been optimized to improve small arms accuracy, which has been a perennial issue identified in after-action reports.

Finding 2.1: “Network Segmentation inadequate.” This has been raised repeatedly by internal audit, perhaps this would be a good “area for improvement” in response to this memo.

Finding 4.2: “Data at rest not encrypted.” This is inaccurate. The GalactiCAD server in question was accessed from an authorized endpoint. As such, it decrypted the data, and sent it over an encrypted tunnel to the endpoint. The pen testers misunderstand our network architecture, again.

Finding 5.1: “Physical access not controlled.” Frankly, sir, this battle station is the ultimate power in the universe. It has multiple layers of physical access control, including the screening units of Star Destroyers and Super SDs, Tie Fighters, Storm Trooper squadrons in each landing bay, [Top Secret-1], and [Top Secret-2]. Again, the pen testers ignore facts to present “findings” to their clients.

Finding 5.2: “Unauthorized mobile devices allows network access.” This is flat-out wrong. In the clip presented, TK-427 is clearly heard authorizing the droids in question. An audit of our records indicate that both driods presented authorization certificates signed by Lord Vader’s certificate authority. As you know, this CA has been the source of some dispute over time, but the finding presented is, again, simply wrong.

Finding 8.3: “Legacy intruder-tracking system inadequately concealed.” Again, this claim simply has no basis in fact. The intruder-tracking system worked perfectly, allowing the Imperial Fleet to track the freighter to Yavin. In analyzing the video, we expect that General Orgena’s intuition was “Force”-aided.

In summary, there are a few minor issues identified which require attention. However, the bulk of the report presents mis-understandings, unreasonable expectations, and focuses heavily on a set of assumptions that just don’t bear up to scrutiny. We are in effective compliance with PCI-DSS, this test did not reveal a single credit card number, and the deal with the Trade Federation should not be impeded.

Via Bruce Schneier.

Star Wars, Star Trek and Getting Root on a Star Ship

It’s time for some Friday Star Wars blogging!

Reverend Robert Ballecer, SJ tweeted: “as a child I learned a few switches & 4 numbers gives you remote code ex on a 23rd century starship.” I responded, asking “When attackers are on the bridge and can flip switches, how long a password do you think is appropriate?”

It went from there, but I’d like to take this opportunity to propose a partial threat model for 23rd century starships.

First, a few assumptions:

  • Sometimes, officers and crewmembers of starships die, are taken prisoner, or are otherwise unable to complete their duties.
  • It is important that the crew can control the spaceship, including software and computer hardware.
  • Unrestricted physical access to the bridge means you control the ship (with possible special cases, and of course, the Holodeck because lord forgive me, they need to shoot a show every week. Scalzi managed to get a surprisingly large amount from this line of inquiry in Red Shirts. But I digress.)

I’ll also go so far as to say that as a derivative of the assumptions, the crew may need a rapid way to assign “Captain” privileges to someone else, and starship designers should be careful to design for that use case.

So the competing threats here are denial of service (and possibly denial of future service) and elevation of privilege. There’s a tension between designing for availability (anyone on the bridge can assume command relatively easily) and proper authorization. My take was that the attackers on the bridge are already close to winning, and so defenses which impede replacing command authority are a mistake.

Now, in responding, I thought that “flipping switches” meant physically being there, because I don’t recall the episode that he’s discussing. But further in further conversation, what became clear is that the switches can be flipped remotely, which dramatically alters the need for a defense.

It’s not clear what non-dramatic requirement such remote switch flipping serves, and so on balance, it’s easy to declare that the added risk is high and we should not have remote switch flipping. It is always easy to declare that the risk is high, but here I have the advantage that there’s no real product designer in the room arguing for the feature. If there was, we would clarify the requirement, and then probably engineer some appropriate defenses, such as exponential backoff for remote connections. Of course, in the future with layers of virtualization, what a remote connection is may be tricky to determine in software.

Which brings me to another tweet, by Hongyi Hu, who said he was “disappointed that they still use passwords for authentication in the 23rd century. I hope the long tail isn’t that long! 😛” What can I say but, “we’ll always have passwords.” We’ll just use them for less.

As I’ve discussed, the reason I use Star Wars over Star Trek in my teaching and examples is that no one is confused about the story in the core movies. I made precisely this mistake.

Image: The Spaceship Discovery, rendered by Trekkie5000. Alert readers will recall issues that could have been discovered with better threat modeling.

Threat Modeling and Star Wars

IANS members should have access today to a new faculty report I wrote, entitled “Threat Modeling in An Agile World.” Because it’s May the Fourth, I thought I’d share the opening:

As Star Wars reaches its climax, an aide approaches Grand Moff Tarkin to say, “We’ve analyzed their attack pattern, and there is a danger.” In one of the final decisions he makes, Tarkin brushes aside those concerns. Likewise, in Rogue One, we hear Galen Urso proclaim that the flaw is too subtle to be found. But that’s bunk. There’s clearly no blow-out sections or baffles around the reactor: if there’s a problem, the station is toast. A first year engineering student could catch it.

You don’t have to be building a Death Star to think about what might go wrong before you complete the project. The way we do that is by “threat modeling,” an umbrella term for anticipating and changing the problems that a system might experience. Unfortunately, a lot of the advice you’ll hear about threat modeling makes it seem a little bit like the multi-year process of building a Death Star.

Kyber Crystal and the Death Star

Death star construction

This post has spoilers for Rogue One, and also Return of the Jedi.

We learn in Rogue One that the Death Star’s main gun is powered by Kyber crystal. We know from various sources that it’s rare.

Then the Death Star is tested, destroying Jedah, where they’re mining the crystals. Note that both times its fired, they give the order “single reactor ignition.” Are they testing the reactors and power systems, or conserving kyber crystal?

Really, how much “ammo” did the original Death Star have on board? How many times could they fire the main gun?

Was ten or fifteen shots considered sufficient, because after a demonstration, fear will keep the local systems in line? Where did they find enought kyber crystal for the second Death Star?