What insights can Wolverine bring to security?

I had the privilege of spending a couple of invigorating hours at MIT last week, discussing Smart Grid security practicalities with a couple of brilliant guys who combined deep roots in power, software, and control systems with a very forward-looking view on improving the security, efficiency, reliability, and scalability of our national power grid. In the course of that discussion, I learned a good deal about how challenging it can be to design software for space missions, where software, hardware, and sensor failures must be mitigated by other software, hardware, and sensors, without the guiding hand of their creator.

As I was driving back from MIT to Waltham, I naturally began the translation of all of that information into the context of security, and began to ask myself some questions about the real nature and purpose of security, particular for systems and services for which predictable performance are key and about the possibility of re-orienting some of my thinking. A good, legal, definition of information security can be found in the US Legal Code, Section 44, which says (in part):

The term “information security” means protecting information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction in order to provide:

• Integrity


• Confidentiality


• Availability

The revelation for me, from those discussions, was that the ultimate goal for many systems is just to be able to do what they are supposed to do, undeterred by security problems. These systems don't want to have to protect themselves, they would rather just endure the attacks and continue to function as they should. It would be as though they were potentially impervious, but more likely imperishable. That line of thought brought me to Wolverine.

Wolverine is a character in the X-Men series, and as this image (Taken from the LA-Times site) shows, he has some unusual accessories built into him, mainly a skeleton and claws made from a fictional and indestructible metal called adamantium. So what does this have to do with security? While his metal pieces and corresponding strength are important, the only reason that it was possible for him to have these accessories installed was because he is self-healing. Basically, he regenerates all the time, so that installing a bonded skeleton, or hacking him up, won't end him. He heals and he moves on. Sure, he fights back, he does his own hacking of others, and he attempts to defend himself, but at the end of the day, he mainly endures because his system knows how to put him back together, pretty much no matter what the comic book or movie writers throw at him.

Isn't that much of what we want from software? When we discuss security, whether it is of the electrical grid or of our credit card providers, we would like the system to consistently behave the way we expect it to. This means that I want to be able to turn on the switch, or to swipe my card, and have the right things happen. I want the lights to go on, I want to buy something, and I don't want to get zapped, and I don't want to get robbed.

Creating software that is capable of this level of reliability is obviously a very difficult challenge, but it is one that has seen very little innovation outside the design of high-reliability systems and the application of high-quality software programming practices. There are some areas which occur to me that are ripe for consideration in presenting this more regenerative, less defensive, approach to security. Here are a couple:

Network-based Data Exfiltration and Malcode Insertion

In the case of many system hacks, (see a good recent piece by Byron Acohido) attacks involve the presentation of unexpected data causing either disgorgement of extra data or changes to the underlying system. Were the application to know more about how it was supposed to function, it would be unlikely to allow itself to execute this kind of instruction, whether that meant recognizing that it was inappropriate for a Login screen to return scads of data, or for a Point-of-Sale application to execute commands to change the system configuration. Instead of, or in addition to, attempting to filter out these attacks, the application could be more aware and active in interdicting the outcome.

Promiscuous-mode Sniffer Installations

A few of the recent high-profile breaches have been enabled through the insertion of traffic sniffers on unencrypted internal networks. These largely passive drivers are very difficult to locate on the wire, and provide a clear channel to otherwise trusted network traffic. If the software which either drives or monitors the operating system would recognize that reconfiguring network adapters on non-system/network management machines to view all traffic, and not just traffic intended for their viewing, was out of line, those adapter changes would not be allowed. Or at very least, if the change was made, it could be discovered, flagged, and rolled-back, by a system that understood how it should function.

This is not meant to call for a complete recasting of our thinking on security, but to introduce some additional fodder. Thinking about "What should I expect?", "What other data can I use to recalibrate myself?", and "What should I never do?", are realistic intelligence that can and should be brought to our construction of software and systems. This is especially true when the failure of the system will cause the failure of something much larger, whether it is a transaction service, a communication system, or our power. By looking past Wolverine's ability to actively battle and defend, and focusing on the character's real strength, the innate ability to recover, we can potentially re-evaluate some of our own thinking about security.