Category Archives: Security

US to Require Automotive Black Boxes

Wired provides a detailed look at what’s down the road for drivers in America:

Next month, the National Highway Traffic Safety Administration is expected to declare that all vehicles must contain an event data recorder, known more commonly as a “black box.” The device, similar to those found in aircraft, records vehicle inputs and, in the event of a crash, provides a snapshot of the final moments before impact.

That snapshot could be viewed by law enforcement, insurance companies and automakers. The device cannot be turned off, and you’ll probably know little more about it than the legal disclosure you’ll find in the owner’s manual.

What is missing from their report is that these black boxes send data over wireless in real-time. It already has been tested in several cities.

The wireless is not just for incident response. Communication through existing vehicle monitoring infrastructure is under review as a means to enable traffic control (e.g. intersection light timings — yellow signals).

Of course a wireless interface to the event recorders on cars around you, and traffic signals, opens up the possibilities of data integrity and confidentiality loss. What are the chances that the system will be designed to be formally correct?

L4.verified: A Formally Correct Operating System Kernel

The L4.verified project has a beautifully written introduction. They eloquently argue (a good sign for their code) that it is possible to eliminate risk from specific areas of development.

Imagine your company is commissioning a new vending software. Imagine you write down in a contract precisely what the software is supposed to do. And then — it does. Always. And the developers can prove it to you — with an actual mathematical machine-checked proof.

Sounds to me like they’re making the case for compliance. It’s not just a check-list, it’s proof of something.

I have presented this in terms of cloud at conferences for the past few years and tried to make it clear but I have to give kudos to the L4.verified author: Their explanation is tight.

Here’s my spin on things:

  • When someone says to themselves they are secure, they are done.
  • When someone says they are secure to someone else, they then have to prove their statement and show the intervals of confidence (e.g. tests and error rate or deviation).

This is the difference between security and compliance. The latter requires proof with peer review. L4.verified says they can prove security through an automation system — compliance by design.

…the issue of software security and reliability is bigger than just the software itself and involves more than developers making implementation mistakes. In the contract, you might have said something you didn’t mean (if you are in a relationship, you might have come across that problem). Or you might have meant something you didn’t say and the proof is therefore based on assumptions that don’t apply to your situation. Or you haven’t thought of everything you need (ever went shopping?). In these cases, there will still be problems, but at least you know where the problem is not: with the developers. Eliminating the whole issue of implementation mistakes would be a huge step towards more reliable and more secure systems.

Sounds like science fiction?

The L4.verified project demonstrates that such contracts and proofs can be done for real-world software.

It looks something like this:

The goal of L4.verified apparently is to build a system of proof that a machine can handle on its own.

If this reminds you of “The number 42” or “I’m sorry Dave, I’m afraid I can’t do that“, then you obviously have been reading too much science fiction.

The machines will have to be able to handle these three tasks to be successful:

  1. Pose a correct audit question
  2. Answer within a reasonable time
  3. Prove that the answer is reliable

This translates directly into the future of audits, especially in cloud. Simplification and atomisation coupled with verification is a great model for security, but even better for compliance.

I will discuss this in more detail tonight at Cloud Camp, Silicon Valley at the IBM Innovation Center.

Skunkx DDoS Bot Nationality

Jose Nazario provides an excellent summary on the Arbor blog of a bot that spreads via USB and instant messenger. He starts with a note on anti-Sino bias often found in American security analysis.

Lest you think all of the DDoS bots we focus on come only from China, we found one that appears to be from the US.

It appears to be from the US, but it still has links to the countries where it is easier to evade law enforcement.

His servers that he has used go back to “Net-0x2a: Zharkov Mukola Mukolayovuch” in the Ukraine, and also “PIRADIUS” in Malaysia. This is someone familiar with underground hosting, it seems.

It sounds much less American now. Don’t let it slip away Jose.

Inspection of the bots we captured show a handful of user-agents (my favorite is the Cyberdog one!) and HTTP headers that appear distinctive, enabling us to detect its traffic selectively. The author appears to have imported Slowloris’ attack method without any modification.

We have also been sinkholing this botnet. Inspection shows hundreds of bots checking in from around the world, with most in the US.

Aha! I can’t overstate the importance of including the lineage in an attack analysis. But even more to the point, Cyberdog is an obviously American reference. I remember in the late 90s when Steve Jobs said he put a “bullet through the head” of Cyberdog.

And now Cyberdog is back, as a zombie! I bet Steve didn’t see that coming.

But seriously, a Chinese user-agent is unlikely to be Cyberdog. It might be ç‹—å±  or maybe called Sundog, if Chinese, but I doubt Cyberdog.

Even more seriously, the speculation about nationality just forces me to wonder if the common definition of a nation is being pushed too far to fit these scenarios.

It’s relevant to law enforcement and financial take-down operations but, when it comes to explaining where a bot is “from”, are we at risk of shoving a square peg into a round hole?

Maybe I’m getting stuck on this idea of nationality linked to a product because it brings to mind how some say Budweiser is from America, instead of the Czech Republic. I mean Cheddar cheese has to be from Cheddar, England, right?

Louder Than a Bomb

Louder Than a Bomb is a new documentary film about young spoken-word competitors — an intimate look at how they spin lessons from life into poetry.

Rather than emphasize individual poets and performances, the structure of Louder Than a Bomb demands that kids work collaboratively with their peers, presenting, critiquing, and rewriting their pieces. To succeed, teams have to create an environment of mutual trust and support. For many kids, being a part of such an environment—in an academic context—is life-changing.

The film centres around a team format. Yet, as with athletic teams, there are individual highlights like this 2008 performance by Nate Marshall.