Archive for February, 2015

Architecture Through Thoughtful Design

February 4th, 2015 No comments

H. James Harrington once said… “Measurement is the first step that leads to control and eventually to improvement. If you can’t measure something, you can’t understand it. If you can’t understand it, you can’t control it. If you can’t control it, you can’t improve it.”

After over 30 years in the business I’ve come to the conclusion that information security should be treated like any other engineering discipline. The days of living by the seat of your pants because you’re forging new “horizons” has long past. This is not to say that there are no new horizons, but that the fundamentals for our profession have been established and we should embrace them, believe in them, and live by them. My portion of this blog is going to be about that, highlighting the sound engineering principles that help create a foundation of trust and security.

As an engineering discipline we need to measure, understand, control, and improve.

Architecture through thoughtful design.

What the hell does that mean?
Well, there are many definitions of architecture. The ones that come to mind (thank you Merriam-Webster) that are relevant to us are:

  1. Formation or construction resulting from or as if from a conscious act
  2. A unifying or coherent form or structure
  3. The manner in which the components of a computer or computer system are organized and integrated.

Unfortunately, the last definition seems to be in conflict with the first two as far as security solutions are concerned.

For too long the security world has relied on obfuscation, magic, and fear to get their message across. Unfortunately, security people have had to wait for a “teachable moment” in order to get people to listen. In our world a “teachable moment” translates into being hacked, breached, or generally suffering some kind of data loss. By then it’s too late. What architecture adds is the dimension of engineering discipline to process. This blog is going discuss how security architecture can positively impact your ability to leverage new technology while protecting your data. Over time we will cover different aspects of security architecture and how you can apply it to your security designs.

Organic means what?
When I visit a customer and I hear the statement “our network has evolved organically” I smile and instantly know a few things. First, they have no idea what their network looks like or what’s really on their network. Second, the notion of a standard is as foreign to them as compromise is to Congress. My personal belief is that people have adopted the term “organic” because saying that your network architecture is based on user motivated adoption of the technology de jour sounds like you’re lazy. Sure, some folks will spin that to say “well, our user community is very important to us and their opinion matters”, but what they’re really saying is that they have neither the resources nor expertise needed to create a network environment that anticipates their needs or the technology trends that their users are following. For example, remember when WiFI was new and exciting?

I do. As I’m sure quite a few security people remember vividly complete with flashbacks.

How did we react to this new and wonderful technology? With fear and a dig-your-heals-in approach that forced users to push their WiFi APs under desks and in drawers. Why? Because it solved a problem that the user community had and screw security if they think they’re going to ruin my ability to get my job done I’ll do what I want damn it!

Result? Networks got constantly attacked and an entire new industry (rogue wifi detection) popped up over night. Is there a lesson here? Well, yes there was and it was promptly ignored.

Flash forward 15 years to our mobile environment. What are security people doing? Yep, you guessed it: they were forbidding mobile devices from being on the network. Sure, you can get on the guest network, but, for the most part, there wasn’t anything useful you could do. Now, a multitude of vendors have provided solutions to “our” problem. In the mean time, folks figured out ways to get their devices on the network with the expected results – valuables have been stolen and secrets have been lost.

Now, I’m not going to bore you with lots of examples of stolen secrets and compromised networks. One has only to pop the query into a search engine of choice in order to see a long and star studded list of The Hacked.

This brings me to my present and most favored rant: architecture. But how can architecture solve the problems we as security people have? Don’t the vendors offer solutions that deal with our security issues? Don’t we have enough technology to address the problem?


It’s just not put together right.

Back in the old days, like really old days. Like, in the 1930’s, many an enterprising engineer thought they could design an airplane. Trouble was, they were right. They could in fact design an airplane and to many people’s surprise, the airplane would actually fly. Not fast. Not high. And for gods sake, not well, but it would in fact fly. The same design principle works today. Just about anybody can design a network. It may not be reliable. It may not be fast. And for gods sake, it may not even be secure, but it will work.

Is there a lesson to be learned here?


It’s just not put together right.

Case in point: how many people have metrics that reliably anticipate when they have a security issue? Can you accurately identify when a security incident has occurred while it’s occurring?


Why? Because our networks are comprised of a series of open-looped systems that don’t talk to each other much less process information in a way that enables them to anticipate required or desired actions. In an effort to create this feedback loop we developed security event managers and security information management systems but the shear load of data that they have to process is obscene. Most people that have implemented them will tell you that it was money wasted. Changes to the network require changes to the SEM if you expect to continue to get meaningful data out of it. That’s a form of job security no doubt, but it’s also a frustrating effort that consumes money and time with a questionable result.

If you don’t believe me, look at our history.

Antivirus. Well, that problem is solved.
How about firewalls? Sure. They work GREAT!
Intrusion detection? Can you say Sony?
Encryption? Seems to make the PCI and HIPAA folks happy.

I can go on an on, but I think you get the picture here. These are all stand alone solutions that don’t integrate with our security or network infrastructure. Some vendors will tell you that they have an integrated solution, but that just adds credibility to my position. Oh, but something that I’m sure that the vendors feel is important is it also adds “lock in” to theirs!

So, now that I’ve gone on for a page and a half about the problem, what is the solution? To start with, lets begin our architecture with a known working set of design principles:


We want our architecture to support these principles because each one of them provides us with a path to a faster, more reliable, more secure solution.

Closing the loop provides us with the ability utilize a process control methodology that has proven to be fast and reliable in the past. By using such a process we can employ control mechanisms that will tell us how fast the network is changing and what our errors are as they happen.

This principle can take many forms in our design but at the very least we should consider creating different enclaves of services, data types, or user communities. For example, perhaps you want your finance people to have their own network where they can frolic in the way that finance people do.

Some folks will see segmentation in the same light as compartmentalization but that wouldn’t be accurate. For example, I can have a campus network that has various IP segments for each building while each building has various compartments based upon group membership or data classification. Which brings us too….

I like the idea of being able to classify people, data, and resources. You wouldn’t have a low level technician delving into the financial details of your most acquisition now would you? You can overlay classification upon compartments.

These are just a few design principle and this is just the beginning of the process. There are many principles and more steps that must be accomplished in order to incorporate infrastructure and security services into an integrated solution.

Categories: Uncategorized Tags: