The San Francisco papers continue to seek answers, along with safety regulators, about the San Bruno pipeline explosion. They say today PG&E employees are being held back from investigators because “they were too traumatized to be questioned”

This explosion should soon figure into every security for critical infrastructure review. Here is a good example why:

The safety board, which is leading the probe, said the pressure spike was caused by a power outage at an unmanned terminal in Milpitas, the end point of the 46-mile pipeline that runs through San Bruno.

An attack vector is now publicly open to discussion. Shutdown power in just one terminal, or increase flow by only ten pounds per square inch, and you can blow a high-risk natural gas pipeline. The threat profiles will now change in response, whether or not this was a one-time incident caused by a weakened line and the fact that it took PG&E 34 minutes after the explosion until crews were dispatched to manually close valves.

Now SIEM companies can talk all they want about detecting sophisticated malware that takes 8 months and 4 crack programmers from a powerful nation-state to create, with no known impact (e.g. Stuxnet), and I will have to say “let’s talk about San Bruno”. How and why did real-time dashboards fail on September 10, 2010?

Maybe my sense of humor needs an upgrade, but I find this amusing. The School of Computer Science, Carnegie Mellon University, has a page called Technical Report Abstracts. The top of this page has the following details:

CMU-CS-04-135

Making Security Usable

Alma Whitten

May 2004

Ph.D. Thesis

Unavailable Electronically

The last line could be anything from a real warning to a really dry piece of comedy.

Whatever it is meant to convey, Alma Whitten (Google’s privacy chief) has conveniently made usable her thesis on errors (made it available electronically). Let us hope it was not by error.

A US court has ruled a teen is not allowed to use encryption. TechDirt reports:

“[The accused] shall not use a computer that contains any encryption, hacking, cracking, scanning, keystroke monitoring, security testing, steganography, Trojan or virus software.” […] As for the oddities in banning him from using computers with viruses, trojans or keystroke monitors, which he could potentially violate without even knowing it, the court changed the terms to say that he can’t knowingly use a computer with any of those things on it. Unfortunately, they still include “encryption” on the list. I find it troubling that the court is okay with demonizing encryption (and, to a lesser extent, “hacking” tools) when there are plenty of legitimate reasons to do so. Does that mean he can’t even encrypt his email?

On the question of encryption for email, it goes back to the phrase: “shall not use a computer that contains”. It seems to me he can have his email encrypted unknowingly (e.g. as part of a service). More to the point the court should have been more clear with their term “use”. They could have qualified it with terms like “inappropriate”, “malicious”, “harmful”, etc. but instead their terms seem overly broad in leaving it open to ANY and ALL forms of use.

The obvious example of how this fails is the password. There is unlikely to be any way for the accused to prevent his password from being encrypted on any computer he uses. It also makes little sense for the court to rule that he must store all his passwords in clear text, thus placing him at much greater risk of harm.

Another example is HTTPS. He will use encryption on his computer every time he is redirected to a secure page. A secure connection is out of his control. Like the harm point made above with passwords it also makes no sense for the court to order him to transmit everything in the clear, especially as this violates other laws that require services to encrypt his sensitive data.