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?

Yes.

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?

Yes.

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?

Nope.

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:

Closed-loop
Compartmentalization
Segmentation
Classification

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.

Closed-loop.
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.

Compartmentalization
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.

Segmentation
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….

Classification
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: Network Security Tags:

7 Phrases Killing Our Industry (aka some Friday humor)

October 10th, 2014 No comments

So it’s Friday and the end of another work week for most.  It’s been another productive one here at Emagined.  However after some heads-down, hands-on technical work, I thought it’d be good to blog a light-hearted, tongue-in-cheek piece poking fun at our industry and the folks in it, such as me and my colleagues.  Security is often all too serious and sometimes stressful, so it’s nice to mix it up.

Again, this blog is written with affability, and not intended to offend.  Please do let us know your feedback and comments on the blog as always, but be forewarned, the piece was drafted in humor.  Best!  Read more…

Categories: Human Condition Tags:

To Ring or Not To Ring?

September 25th, 2014 No comments

So it’s been a few weeks since Def Con 2014 and I’m still impressed with the year-over-year draw in attendance for the Social Engineering CTF.  What started out a few years ago as a small “show and learn” regarding social engineering (aka hackers’ confidence game) and Corporate America’s general unpreparedness in the face of it, has blossomed into a busy hub of capture-the-flag comings and goings with few, if any, seats left available when a session is on-going.  And the sessions themselves?  Also better.  Perhaps it’s the practice and social maturity of the contestants, perhaps it’s the consistency and refinement from the contest organizers/sponsors, or perhaps it’s a bit of luck of the draw as some people “gush” after all, in any setting, especially those in certain organizations targeted every year for their information bounty.  Regardless, it got me thinking more about what I saw, what I’ve experienced in my own professional and personal life and where things are/might be headed.

First a quick diversion – a little bit about me to help set the stage about where I’m coming from in this blog perspective – I like ideas, especially when they’re still relatively new and not yet fads, especially those that pertain to the human condition, even the bad ideas.  So it was with phishing when most people *yawn*.  [Yeah, it’s still like that today. <smile>]  But I digress…. Read more…

Categories: Human Condition Tags:

What’s our Policy on That?

Companies of all sizes continue to struggle with information security policies or other rules designed to help protect their information. In 30 years of information security practice some issues come up time and time again that contribute to the problem of inadequate information security policies. While few would argue the need to have actual policies about information security, often that’s where agreement stops. The concept of having policies, defining policies and enforcing them is often more than a little controversial for many companies.

Most information security policies evolved out of the old familiar “do’s and don’ts” set of rules.  Often times the do’s and don’ts were the least controversial of policies and included such things as guidance on what not to say in an e-mail, how to handle confidential company information, what usage of the Internet is permissible, and so forth. Too often the do’s and don’ts policy was a clone of a year’s earlier article in an HR manager journal and has received almost no attention since then.  Companies often lack the resolve to use the do’s and don’ts policy as a basis for disciplinary measures of any kind, let alone as the basis for termination.  However, the one thing the do’s and don’ts policy did enable everyone to do was to righteously claim, “yes, Boss, we do have an information security policy.”

Read more…

RIM or Precipice

News of RIM’s apologies concerning the multiple-day outage of its services beginning Saturday morning October 8 illustrates a very important point. At the retail level it may be okay to remain silent or mumble about the circumstances of an outage (as my cell provider did in this case).  However, when dealing with enterprises which purchase services in mass quantities as part of a broader strategy of delivering services to their customers through a well-equipped employee base the reverse is true.  RIM had remained silent for five days about the details, causes – and most importantly – the estimates for remediation of this outage. This is inexcusable for anyone offering an enterprise class product. Read more…

The Changing Nature of Incident Response: Part 3

The ultimate test of the value of an incident response team is how that team handles crises. Crises are generally not everyday occurrences. In fact, most issues with which an incident response team must deal are not of a bona fide emergency nature. That is why from the very onset of computer incident response teams I have objected to any incident response team name that includes “emergency” or “crisis” in it, because these terms represent little more than massive embellishment of the true nature of most of their activities.

Read more…

Categories: Network Security Tags:

The Changing Nature of Incident Response: Part 2

Perhaps the biggest single step in the life cycle of an incident response team is going operational. The major problem with getting the Department of Energy’s incident response team operational was that there was nothing–no policies, no standards, and virtually no procedures concerning incident response at that time. The CERT/CC team claimed that it was operational at that time, but if that were true, there would have been some kind of indication that operations were taking place, and there was no indication whatsoever. One of the best ways that my management ever helped at that time was to inform me of other emergency response teams and to try to get me in touch with people who managed such efforts. One such team was the Nuclear Energy Search Team (NEST) at Lawrence Livermore National Laboratory. Discussions with the manager and some of the more senior staff members of this team helped me better understand the kind of procedures that would have to be performed, the kinds of communication that would have to occur, and how action priorities would have to be determined. Still, the nuclear arena is not all that closely aligned with the information security arena, and after I was finished meeting with NEST members I developed a kind of sinking feeling that there was much more to do than I had ever imagined. And at the time the team I managed consisted only of myself.

Read more…

Categories: Network Security Tags:

The Changing Nature of Incident Response: Part 1

I’ve been affiliated with incident response in one way or another since 1988. I am not saying this boastfully, as I’ve made many mistakes both in responding to incidents technically and in managing incident response efforts. At the same time, however, when I first entered the incident response arena, there were no policies, standards, and procedures, and not really any requirements, either, to guide incident response efforts. Everyone who played in this arena originally had to use a combination of intuition and learning from mistakes just to get by.

Read more…

Categories: Network Security Tags: