« Mulligan: Recasting "Dowsing Your Way Through Enterprise Risk" | Main | How NOT to Build a Security Program »

Sometimes Changing the Problem Helps Solve the Problem

When I was studying Physics in college, one of the more common tricks was to take a problem with weird units and use various conversions to get the equation into something with units you knew how to handle. For a basic understanding of this treatment consider a story problem where you're told that you need to travel X kilometers at a constant rate of Y miles-per-hour in a straight line, how many seconds will it take you to get there? Convert mph to kph, then kph to kps, and viola! you can pull the answer out of your hat with basic arithmetic.

Information security oftentimes has this same general quality about it. Think of the whole cloud security scene as a primary example. Yes, it is absolutely new technology representing new challenges. However, that being said, it's also using a lot of old technologies, and there are known good ways to solve many of the "new" problems presented. Fundamentally, it all devolves back to the traditional C-I-A model (as much as people might hate that). What I find most interesting, though, is how often the elephant in the room seems to be ignored.

Case-in-point, I love reading guys like Hoff and Gunnar and Schneier, because it's fascinating to see all the intelligent banter on this "cloud security" topic (or, the mythology that is "cloud" and all things related). What I think is perhaps most interesting, however, is how we can hear the same old axes being ground without seeing the problem transformed into something more meaningful and solvable (in essence, giving us those spoonfuls of elephant that allow us to consume the whole thing).

Now, before you get all bent out of shape and misconstrue that I'm attacking any of these venerable experts, let me make something very clear: there are a lot of unique challenges posed by this amalgam of "known" technologies. I think the threat landscape is markedly different in many areas, not the least of which stemming from the extensive use of virtualization. However, again, the solutions all devolve to the C-I-A model in terms of discussion. ANYway...

Here's what I don't understand: why are we not talking at length about data encryption? Do you want to eliminate or transform a key set of concerns about putting data out in "the cloud" (whatever the heck that is)? Encrypt the data. Encrypt it as close to the source as possible, and only decrypt it temporarily at the point closest to the instance that requires the clear data for use. Never have cleartext data in storage, ever, ever, ever.

By moving to a model where the data is encrypted by default, you then transform the security problems dramatically, for the most part (let's put aside availability concerns for a moment, since the nines is a very interesting topic that seems to be oft misunderstood). Instead of trying to solve protecting your data in "the cloud" and how to implement adequate access controls on someone else's premises, you now get to control all of that. Instead, you now get to look at key management solutions - a problem that is increasingly solved by the major vendors, backed by emerging standards from the OASIS KMIP and the IEEE P1619.3 technical committees.

The point here is quite simple: if you eliminate one of the key areas of concern - cleartext data not fully in your control - then you can transform the problem into something we know better how to solve. And, if your transform creates new problems that are more difficult, either back-step, or keep converting until you get to a problem that is better solved.

In many ways, this approach provides the foundation for much of Science and Engineering. Frankly, it's the basis of the evolution of language and everything we know. Everything new must be recast in ways that we understand and comprehend. In essence, we transform everything we see, hear, taste, touch, or smell. When we lack corollaries or analogs, our brains then bookmark or discard what has been sensed as out of scope. One could go so far as to argue that this is the fundamental failing of humans adapting to online threats and risks, but I digress. The point here is that, as Buddha teaches, the mere act of articulating our enlightenment transforms it into something that is not the enlightenment. Transformation is, then, a fundamental part of life, of Nature, of Science, of Music, of Math, and of Essence.

We need to be mindful that we not get on rabbit trails that take us down winding, convoluted paths to solutions that don't make sense, when in fact we could transform out thinking - our approach - our mentality - in a manner so as to find a better solution. Take the old axiom that in a tie between you and a brick wall, the brick wall tends to win. This is true until you transform the problem from collision to circumvention and find that you can in fact jump or side-step the wall. A lock on a door with the windows wide open is no solution at all. :)

In information security I believe that much of our current troubles stem from failing to transform problems. As I've said many times before, the industry has atrophied from staying on a faulty rabbit trail. It's time to roll back to an earlier state where we can transform problems in a manner that better lends itself to solutions.


TrackBack URL for this entry:

Comments (2)

Andrew Yeomans:

Keep an eye on Jericho Forum work. "By default, data must be appropriately secured both in storage and in transit and in use".

Having all data encrypted (unless it's public) seems a good way forward. Two major issues to solve:
a) open file formats for encrypted/protected data;
b) manageable key management, since trying to implement fine-grained access control through encryption keys is likely to lead to grief.


@Andrew -

Thanks! Check out the OASIS KMIP TC, IEEE P1619.3, and OASIS EKMI TC. EKMI in particular might be in a good position to take up that call. Better yet, join us! :)


Post a comment


This page contains a single entry from the blog posted on June 15, 2009 12:53 PM.

The previous post in this blog was Mulligan: Recasting "Dowsing Your Way Through Enterprise Risk".

The next post in this blog is How NOT to Build a Security Program.

Many more can be found on the main index page or by looking through the archives.

Creative Commons License
This weblog is licensed under a Creative Commons License.