Emergent Chaos

"You have searched me for the last time"

Explanation and more pictures here.

Family Guy Does Usability

A funny clip for Saturday. I can't figure out how to embed the video here, so click on the picture to be taken to Gizmodo.

Fake Steve and Real Mackey

So with the small, literal men at the New York Times poking through the veil of anonymity that allowed Fake Steve to produce the best blog since "The Darth Side," we have a serious threat to the stability of the republic, which is the false hope that by assigning people names, we can control them. Prevent the random, the funny, the disrespectful. The powerful have always hated having fun poked at them by the anonymous. They forget that anonymity acts as an important social valve, allowing people to share ideas without retribution.

John Mackey took a different approach. He didn't blog, but engaged in conversation on a message board about his company.

I think it's a good thing to be able to hear from CEOs shedding their spin, from journalists freed of their need for access, and everyone else who wants to put forth their own words to stand or disappear on their own strength.

Fake Steve is a little less interesting since the unveiling. The posts about immortality were a nice touch, but, I thought, over-wrought.

"These aren't the civil liberties you're looking for"

Powerpoint Plans

It's the scenes Lucas was too scared to film! The actual presentation, with voice overs. At http://lay-uh.ytmnd.com/.

Han Shot First: DVDs, Debugged.

In response to overwhelming demand, Lucasfilm Ltd. and Twentieth Century Fox Home Entertainment will release attractively priced individual two-disc releases of Star Wars, The Empire Strikes Back and Return of the Jedi. Each release includes the 2004 digitally remastered version of the movie and, as bonus material, the theatrical edition of the film. That means you'll be able to enjoy Star Wars as it first appeared in 1977, Empire in 1980, and Jedi in 1983.

See "This September: Original Unaltered Trilogy on DVD," via Slashdot.

Han shooting image was their choice, too.

[Update: Via N., "Top 10 Other Things that Han Shot that Didn't Shoot at Him First."]

Relentless Walking

You two and your obsession with modern entertainment. Get out, and go for a walk to Rivendell. If you are going to insist on watching movies, at least go see some real ones.

(Image is "Descent to Rivendell, by John Howe, from theonering.net)

I find your faith disturbing

Adam,

I learned of the flick via a blog unrelated to either Star Wars or computing, so no need for Google. Not to get all "vi vs. emacs" on you, but I never understood the
fascination with Star Wars. :^)

Photo cred: kemikore

You Have Failed Me For the Last Time

Chris,

I can't believe you mentioned Snakes on a Plane, and failed to link to a blog called "I Find Your Lack of Faith Disturbing," whose article, "Snakes on a Motherfucking Plane" is like the 3rd hit on Google. I mean, really! Its not like you had to look hard to find that. Do I have to do all the Star Wars blogging around here? If I do, I should really get off my duff.

(Photo from the 501st New England Garrison.)

Happy Valentine's Day!

(From Something Awful, via Boing Boing.)

On Treatment of Prisoners and the Face of Evil

Establishing villainy is hard work. Too little, and your villains seem pathetic. Too much, and they're over the top. Even drawing deeply on Joseph Campbell and with the music of John Williams, Lucas still needs actions to show that Darth Vader is the embodiment of evil. What does he choose? The first time we see Vader act, he is strangling a rebel captive, looking for information.

The scene is carefully arranged, and no storm trooper blocks the camera's view of the strangling. There are rebels in the background, being allowed to observe what is being done. Moments later he orders that his officers lie to the Senate about there being no survivors. The next time we see him, he is strangling a member of the Death Star's executive committee. He leaves there to "discuss" the location of the rebel base with Princess Leia. The camera lingers on the torture droid and its syringe, while Vader looms.

Establishing moral authority is also hard work. Too little, and no one trusts you, too much and you can seem like a cartoon. Once it's established, it can be quickly lost by treating your prisoners as Darth Vader does. I was going to talk about intercepted communications and plans because that's in the news. Then I realized that while wiretaps are in the news, we're still hiding prisoners at black site prisons, we're still quibbling over when the Geneva Conventions apply, and no senior officer has been court-martialed for mistreating prisoners, or allowing the mistreatment of prisoners on their watch.

How you treat prisoners, people who are helpless and at your mercy, says quite a bit about you. That's why Lucas uses it to define Vader. It's a pity that such behavior can be used to define the United States.

"Contrasts in presentation style"

"Contrasts in presentation style: Yoda vs. Darth Vader" is brilliant! How can I not
love a mash-up of what you do and Star Wars?

Friday Star Wars and Psychological Acceptability

This week's Friday Star Wars Security Blogging closes the design principles series. (More on that in the first post of the series, "Economy of Mechanism.") We close with the principle of psychological acceptability. We do so through the story that ties the six movies together: The fall and redemption of Anakin Skywalker.

There are four key moments in this story. There are other important moments, but none of them are essential to the core story of failure and redemption. Those four key moments are the death of Anakin's mother Shmi, the decision to go to the dark side to save Padme, Vader's revelation that he is Luke's father, and his attempts to turn Luke, and Anakin's killing Darth Sideous.

The first two involve Anakin's failure to save the ones he loves. He becomes bitter and angry. That anger leads him to the dark side. He spends twenty years as the agent of Darth Sideous, as his children grow up. Having started his career by murdering Jedi children, we can only assume that those twenty years involved all manner of evil. Even then, there are limits past which he will not go.

The final straw that allows Anakin to break the Emperor's grip is the command to kill his son. It is simply unacceptable. It goes so far beyond the pale that the small amount of good left in Anakin comes out. He slays his former master, and pays the ultimate price.

Most issues in security do not involve choices that are quite so weighty, but all have to be weighed against the psychological acceptability test. What is acceptable varies greatly across people. Some refuse to pee in a jar. Others decline to undergo background checks. Still others cry out for more intrusive measures at airports. Some own guns to defend themselves, others feel having a gun puts them at greater risk. Some call for the use of wiretaps without oversight, reassured that someone is doing something, while others oppose it, recalling past abuses.

Issues of psychological acceptability are hard to grapple with, especially when you've spent a day immersed in code or network traces. They're "soft and fuzzy." They involve people who haven't made up their minds, or have nuanced opinions. It can be easier to declare that everyone must have eight character passwords with mixed case, numbers, and special characters. That your policy has been approved by executives. That anyone found in non-compliance will be fired. That you have monitoring tools that will tell you that. (Sound familiar?) The practical difficulties get swept under the rug. The failures of the systems are declared to be a price we all must pay. In the passive voice, usually. Because even those making the decisions know that they are, on a very real level, unacceptable, and that credit and its evil twin of accountability, is to be avoided.

Most of the time, people will meekly accept the bizarre and twisted rules. They will also resent them, and believe that small ways of getting back, rather than throwing their former boss into a reactor core. The story, so much in the news about NSA wiretapping, is in the news today because NSA officials have been strongly indoctrinated that spying on Americans is wrong. There's thirty years of culture, created by the Foreign Intelligence Surveillance Act, that you don't spy on Americans without a court order. They were ordered to discard that. It was psychologically unacceptable.

A powerful principle, indeed.

(If you enjoyed this post, you can read the others in the "Star Wars" category archive.)

Friday Star Wars: Open Design

This week and next are the two posts which inspired me to use Star Wars to illustrate Saltzer and Schroeder's design principles. (More on that in the first post of the series, Star Wars: Economy Of Mechanism.) This week, we look at the principle of Open Design:

Open design: The design should not be secret. The mechanisms should not depend on the ignorance of potential attackers, but rather on the possession of specific, more easily protected, keys or passwords. This decoupling of protection mechanisms from protection keys permits the mechanisms to be examined by many reviewers without concern that the review may itself compromise the safeguards. In addition, any skeptical user may be allowed to convince himself that the system he is about to use is adequate for his purpose. Finally, it is simply not realistic to attempt to maintain secrecy for any system which receives wide distribution.

The opening sentence of this principle is widely and loudly contested. The Gordian knot has, I think, been effectively sliced by Peter Swire, in "A Model For When Disclosure Helps Security."

In truth, the knot was based on poor understandings of Kerckhoff. In "La Cryptographie Militare" Kerckhoff explains that the essence of military cryptography is that the security of the system must not rely on the secrety of anything which is not easily changed. Poor understandings of Kerckhoff abound. For example, my "Where is that Shuttle Going?" claims that "An attacker who learns the key learns nothing that helps them break any message encrypted with a different key. That's the essence of Kerkhoff's principle: that systems should be designed that way." That's a great mis-statement.

In a classical castle, things which are easy to change are things like the frequency with which patrols go out, or the routes which they take. Harder to change is the location of the walls, or where your water comes from. So your security should not depend on your walls or water source being secret. Over time, those secrets will leak out. When they do, they're hard to alter, even if you know they've leaked out.

Now, I promised in "Star Wars and the Principle of Least Privilege" to return to R2's copy of the plans for the Death Star, and today, I shall. Because R2's copy of the plans--which are not easily changed--ultimately lead to today's illustration:

The overall plans of the Death Star are hard to change. That's not to say that they should be published, but the security of the Death Star should not rely on them remaining secret. Further, when the rebels attack with stub fighters, the flaw is easily found:

OFFICER: We've analyzed their attack, sir, and there is a danger. Should I have your ship standing by?

TARKIN: Evacuate? In our moment of triumph? I think you overestimate their chances!

Good call, Grand Moff! Really, though, this is the same call that management makes day in and day out when technical people tell them there is a danger. Usually, the danger turns out to go unexploited. Further, our officer has provided the world's worst risk assessment. "There is a danger." Really? Well! Thank you for educating us. Perhaps next time, you could explain probabilities and impacts? (Oh. Wait. To coin a phrase, you have failed us for the last time.) The assessment also takes less than 30 minutes. Maybe the Empire should have invested a little more in up-front design analysis. It's also important to understand that attacks only get better and easier as time goes on. As researchers do a better and better job of sharing their learning, the attacks get more and more clever, and the un-exploitable becomes exploitable. (Thanks to SC for that link.)

Had the Death Star been designed with an expectation that the plans would leak, someone might have taken that half-hour earlier in the process, when it could have made a difference.

Next week, we'll close up the Star Wars and Saltzer and Schroeder series with the principle of psychological acceptability.

Star Wars and Separation of Privilege

As we continue the series, illustrating Saltzer and Schroeder's classic paper, "The Protection of Information in Computer Systems," we come to the principle of separation of privilege.

Separation of privilege: Where feasible, a protection mechanism that requires two keys to unlock it is more robust and flexible than one that allows access to the presenter of only a single key. The relevance of this observation to computer systems was pointed out by R. Needham in 1973. The reason is that, once the mechanism is locked, the two keys can be physically separated and distinct programs, organizations, or individuals made responsible for them. From then on, no single accident, deception, or breach of trust is sufficient to compromise the protected information. This principle is often used in bank safe-deposit boxes. It is also at work in the defense system that fires a nuclear weapon only if two different people both give the correct command. In a computer system, separated keys apply to any situation in which two or more conditions must be met before access should be permitted. For example, systems providing user-extendible protected data types usually depend on separation of privilege for their implementation.

This principle is hard to find examples of in the three Star Wars movies. There are lots of illustrations of delegation of powers, but few of requiring multiple independent actions. Perhaps the epic nature of the movies and the need for heroism is at odds with separation of privileges. I think there's a strong case to be made that heroic efforts in computer security are usually the result of important failures, and the need to clean up. Nevertheless, I committed to a series, and I'm pleased to be able to illustrate all eight principles.

This week, we turn our attention to the Ewoks capturing our heroes. When C3-P0 first tries to get them freed, despite being a god, he has to negotiate with the tribal chief. This is good security. 3P0 is insufficiently powerful to cancel dinner on his own, and the spit-roasting plan proceeds. From a feeding the tribe perspective, the separation of privileges is working great. Gods are tending to spiritual matters and holidays, and the chief is making sure everyone is fed.

It is only with the addition of Luke's use of the force that it becomes clear that C3-PO is all-powerful, and must be obeyed. While convenient for our heroes, a great many Ewoks die as a result. It's a poor security choice for the tribe.

Last week, Nikita Borisov, in a comment, called "Least Common Mechanism" the 'Least Intuitive Principle.' I think he's probably right, and I'll nominate Separation of Privilege as most ignored. Over thirty years after its publication, every major operating system still contains a "root," "administrator" or "DBA" account which is all-powerful, and nearly always targeted by attackers. It's very hard to design computer systems in accordance with this principle, and have them be usable.

Next week, we'll discuss the principle of open design, and then close on that question of psychological acceptability.

Star Wars and Least Common Mechanism

Today, in Friday Star Wars Security blogging, we continue with Saltzer and Schroeder, and look at their principle of Least Common Mechanism:

Least common mechanism: Minimize the amount of mechanism common to more than one user and depended on by all users [28]. Every shared mechanism (especially one involving shared variables) represents a potential information path between users and must be designed with great care to be sure it does not unintentionally compromise security. Further, any mechanism serving all users must be certified to the satisfaction of every user, a job presumably harder than satisfying only one or a few users. For example, given the choice of implementing a new function as a supervisor procedure shared by all users or as a library procedure that can be handled as though it were the user's own, choose the latter course. Then, if one or a few users are not satisfied with the level of certification of the function, they can provide a substitute or not use it at all. Either way, they can avoid being harmed by a mistake in it.

The reasons behind the principle are a little less obvious this week. The goal of Least Common Mechanism (LCM) is to manage both bugs and cost. Most useful computer systems come with large libraries of sharable code to help programmers and users with commonly requested functions. (What those libraries entail has grown dramatically over the years.) These libraries are collections of code, and code that has to be written and debugged by someone.

Writing secure code is hard and expensive. Writing code that can effectively defend itself is a challenge, and if the system is full of large libraries that run with privileges, then some of those libraries will have bugs that expose those privileges.

So the goal of LCM is to constrain risks and costs by concentrating the security critical bits in as effective a fashion as possible. Which, if you recall that the best defense is a good offense, leads us to this week's illustration:

This is, of course, the ion cannon on Hoth destroying an Imperial Star Destroyer, and allowing a transport ship to get away. There is only one ion cannon (they're apparently expensive). It's a common mechanism designed to be acceptable to all the reliant ships.

That's about the best we can do. Star Wars doesn't contain a great example of minimizing common mechanism in the way that Saltzer and Schroeder mean it. Also hard to find good examples of is separation of privilege. Unless someone offers up a good example, I'll skip it, and head right to open design and psychological acceptability, both of which I'm quite excited about. They'll make find ends to the series.

If you like the concept, why not check out the Star Wars category archive?

Star Wars and the Principle of Least Privilege

In this week's Friday Star Wars Security Blogging, I'm continuing with the design principles from Saltzer and Scheoder's classic paper. (More on that in this post.) This week, we look at the principle of least privilege:

Least privilege: Every program and every user of the system should operate using the least set of privileges necessary to complete the job. Primarily, this principle limits the damage that can result from an accident or error. It also reduces the number of potential interactions among privileged programs to the minimum for correct operation, so that unintentional, unwanted, or improper uses of privilege are less likely to occur. Thus, if a question arises related to misuse of a privilege, the number of programs that must be audited is minimized. Put another way, if a mechanism can provide "firewalls," the principle of least privilege provides a rationale for where to install the firewalls. The military security rule of "need-to-know" is an example of this principle.

In a previous post, I was having trouble choosing a scene to use. So I wrote to several people, asking for advice. One of those people was Jeff Moss, who has kindly given me permission to use his answer as the core of this week's post:

How about when on the Death Star, when R2D2 could not remotely deactivate the tractor beam over DeathNet(tm), Obi Wan had to go in person to do the job. This ultimately lead to his detection by Darth Vader, and his death. Had R2D2 been able to hack the SCADA control for the tractor beam he would have lived. Unfortunately the designers of DeathNet employed the concept of least privilege, and forced Obi Wan to his demise.

Initially, I wanted to argue with Jeff about this. An actual least privilege system, I thought, would not have allowed R2 to see the complete plans and discover where the tractor beam controls are. But R2 is just playing with us. He already has the complete technical readouts of the Death Star inside him. He doesn't really need to plug in at all, except to get an orientation and a monitor to display Obi Wan's route.

But even if R2 didn't have complete plans, note the requirement to have the privileges "necessary to complete the job." Its not clear if you could operate a battle station without having technical plans widely available for maintenance and repair. Which is a theme I'll return to as the series winds to its end.

If you enjoyed this post, a good way to read more of the series is the Star Wars category archive.

Friday Star Wars and the Principle of Complete Mediation

This week in Friday Star Wars Security Blogging, we examine the principle of Complete Mediation:

Complete mediation: Every access to every object must be checked for authority. This principle, when systematically applied, is the primary underpinning of the protection system. It forces a system-wide view of access control, which in addition to normal operation includes initialization, recovery, shutdown, and maintenance. It implies that a foolproof method of identifying the source of every request must be devised. It also requires that proposals to gain performance by remembering the result of an authority check be examined skeptically. If a change in authority occurs, such remembered results must be systematically updated.

(From "The Protection of Information in Computer Systems," by Saltzer and Schroeder.) The key bit here is that every object is protected, not an amalgamation. So, for example, if you were to have a tractor beam controller pedestal in an out of the way air shaft, you might have a door in front of it, with some access control mechanisms. Maybe even a guard. I guess the guard budget got eaten up with the huge glowing blue lightning indicator. Maybe next time, they should have a status light on the bridge. But I digress.

The tractor beam controls were insufficiently mediated. There should have been guards, doors, and a response system. Such protections would have been a "primary underpinning of the protection system."

But that was easy. Too easy, if you ask me. In start contrast to last week's post, "Friday Star Wars: Principle of Fail-safe Defaults," which, as certain ungrateful readers (yes, you, Mr. assistant to...) certain ungrateful readers did have the termacity to point out that we have high standards here, and so we offer up a second example of insufficient mediation.

After they get back to the ship, there's nothing else to do. They simply fly away. The bay is open and the Falcon can fly out. Where's the access control? (This is another example of why firewalls need to be bi-directional.) Is it an automated safety that anything can just fly out of a docking bay? Seems a poor safety to me.