The insider threat isn’t easy to fix. We can fix it with Separation of Duty, but it requires planning ahead, discipline, and effort. But it’s essentially why banks can hire low-wage tellers and not worry about theft at the till (or at least not as much).

San Francisco lost control of their FiberWAN. It’s not clear how much this affected day to day operations, since the city appeared to still be working. And that in itself is a tribute to separation of duty.

The disgruntled administrator has locked people out of WAN administration. If he has given the passwords to malicious third parties, then things could be disagreeable. The actual risk depends on the degree to which existing systems “trust” the WAN backbone.

In a system with separation of duty, the applications won’t be trusting the backbone. So as long as it carries the traffic reliably, sniffing and network-based attacks shouldn’t matter. Individual application administrators, and network administrators, can fiddle with assets inside their system, but they can’t get away with manipulating data on other systems. Each system is vulnerable only to its own administrators, and not to those of other parts, even of network administrators.

On the other hand, if SF is using poorly designed Web 2.0 applications that haven’t addressed trust issues, then attackers could have a field day.

We can also talk about this as a “layered defense.” If you have your own, isolated network (like SF’s FiberWAN), that can give you a layer of protection, since attackers have to physically hook up to the network. But only one layer. If your applications implement their own end-to-end protection, that gives you another layer.

Physical control and administrative control

First of all, I can’t imaging what’s the matter with this FiberWAN system: if you have physical control of certain key devices, you ought to be able to take administrative control of it. Again there’s a separation of duty thing: you don’t want to lose control of the WAN simply because someone stole a single device. On the other hand, this design has gone too far.

The all-powerful administrator

It’s easy to make separate systems separate, but it’s hard to eliminate the One Admin To Rule Them All when dealing with a single server or application.

In the early 1990s, a team of us worked on the LOCK system for the US government. This was a Unix-compatible system intended for high security applications in the defense community. A couple dozen were eventually deployed in command centers to route e-mail between classified networks of different kinds.

A key part of the LOCK design was to separate administrative duties into different roles so that no single administrator was all powerful. This is easy to do in theory and really hard to do in practice.

We provided a set of separate administrator roles for the military e-mail guard. Almost immediately after deployment we were directed to make administration ‘as simple as possible.’ This meant combining the roles so that a military site only had to assign (and train) a single administrator to the system.

In practice, the government only uses separation of duty where it’s absolutely essential – in other words, only where they’ve been burned. This includes the handling of highly sensitive crypto keys (after the Walkers sold lots of keys to the Soviets), and in handling money (like the banks).