Security Architecture, Part 1

I have been in this industry for a hell of a long time.

Pretty much since the beginning.

I remember sharing a cube with a guy that decided to write some software that he thought would identify when viruses made their way on to your computer. I remember looking forward to the clock speed increase to 5 MHz as a watershed event. I remember wondering what the hell I was going to do with 5MB of storage space on a hard disk drive and remember coining the phrase “on a clear disk you can seek forever”. I remember thinking that 5MB was huge. And I remember the BAUD speed debates with some folks saying that they could never break the 28.8K barrier. Those folks thought they had some sound engineering behind their claims. Thankfully, innovation and disruptive technology tend to ignore contemporary “sound engineering” principles.

And that’s where we find ourselves today – hampered by what our contemporaries consider “sound engineering” principles and what our industry has come to call “best practices”. So, “best practices” is defined in multiple ways by multiple sources but they all boil down to: “A method or technique that has consistently shown results superior to those achieved with other means, and that is used as a benchmark. See also best in class and leading practice.

I kinda like that definition. It implies RESULTS! It implies SUCCESS! And I like success. What security person doesn’t? If you go to any security conference you will most likely hear or see either a speaker or vendor referring to best practices as the basis for their process definition and the source of their success.

Let’s look at the word “success” for a minute. Achieving a goal! We achieve we win. Through the mathematical principle of substitution we can do some quick grammatical math and say that winning is success! Right? We equate success with winning. Beating the opposition! Forging ahead! RESULTS!! And, with a minor leap using the exact same reasoning, we get to, wait for it…..PROGRESS!

Bullshit. Pure self-deluding bullshit.

How we can even define our “success” in the security field as progress is beyond me. We continue to have “surprises” and we continue to fight a battle that can best be described as strategic compromise. Each day we see new vendors hawking new technology in the hopes that their solution is “The One”. The one that changes everything.

So, what’s missing? Why, in a world where we can do such amazing things and have such amazing technology, has a solution to the problem of enterprise security eluded us for so long?

Well, I think the answer is actually quite simple: we’re too selfish.

We all want privacy, but we don’t want to give up anything to get it. What I mean here is similar to wanting to be safe on the airlines while you have a cheap ticket and don’t have to wait in TSA lines. You can get it good, you can get it fast, you can get it cheap. Pick any two. The problem is that the solution requires us to integrate systems that normally don’t integrate with one another. Our personal lives don’t usually touch law enforcement systems because we’re law-abiding citizens. Unfortunately, the system is set up to deal with those that would ignore the law in order to hurt us or to gain ground in their objectives. For them, the lawbreakers, it’s a lifestyle and a war. They don’t care about the law and count on the fact that our systems don’t talk, don’t share information, and aren’t integrated as an engineered system.

If we want to win, we need to change how we think.

So, how do we do that?

Stay tuned…..





One thought on “Security Architecture, Part 1

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s