(Originally posted on LinkedIn November 10th 2014)

With the emergence of yet another widespread vulnerability, I’ve been spending some time reflecting on the ever evolving threat landscape that has prevailed over my career. I’ve come to the realization and opinion that we, as a group of professionals, have gotten distracted and as a consequence have focused on symptomatic issues.

Essentially we have chosen to hike down a wilderness trail that constantly bring us into contact with all manner of dangers rather than a trail that seeks to avoid these dangers as much as possible.

At the beginning of my career, we struggled with virus attacks like Code Red or Blaster. The answer there was email filtering and anti-virus protection. As the attacks became more sophisticated we added new tools to our toolbox and began a very complicated process of chasing the latest vulnerability of the week. This vulnerability of the week quickly became the vulnerability of the day and then the hour and now have emerged into a term we now call Zero-Day.

Many of the solutions that have emerged over the years have by necessity been reactions to one vulnerability or another; one new threat or another. As these are bad events we quickly focus on them and they quickly began to dominate our thinking. As we assess what went wrong that laid us open to these bad events we naturally looked for the easiest answer first and concluded that either we didn't’ have the right tools or that our tools were inadequate. Thus began an arms race to get the right tool in place before something bad happened again.

Don’t get me wrong though I’m not about to launch into a condemnation of the security industry. They are absolutely necessary and fill a vital role in helping us to keep our networks secure however I believe we have evolved into a situation where the tail is wagging the dog.

As I see it we have begun to frame our problems in terms of the existing solutions rather than independent of a solution. We have not spent the time and effort trying to fully understand the problem. We have decided that something must be done and therefore our response involves a good deal of reactive behavior.

There is a benefit to this technique. It looks good. It gives the false impression of progress and when the solution is chosen prior to the requirements being fully understood then we often miss the mark. Unfortunately this isn’t clear until the next vulnerability comes along and gets through our solution. This undermines our credibility in our organizations and is probably a very important factor why we are perceived by our C-Level colleagues as being a bit out of touch (see my previous posts.)

Our main problem is that we are so focused on finding the bad things that our perspective has become skewed. This perspective makes us reactive by nature even if we don’t realize it. We often fool ourselves that we are being proactive by looking for solutions that address problems we think may be coming but haven’t gotten here yet. This really isn’t being proactive though.

So what do we do to become proactive? We need to go back to basics.

Back at the beginning of my career I worked with firewalls and routers. At this time we wrote our access control lists by hand and this required knowing what information was supposed to pass and denying everything else. I allowed Port 80 through my firewall to access a web server. This web server would then need to communicate to a back end data base on Port 1434. I set rules to allow only that communication to happen and denied everything else. Simple right?

Well it was and it required that we knew who was suppose to be talking to whom and why. We started with known good and everything outside of this communication was bad and therefore denied.

As we all know - the number of bad things that could happen is rather large and I would argue ultimately unmanageable. By changing your perspective and focusing on the valid or good actions/communications that are taking place you have a much more manageable set of processes to oversee and anything that falls outside of this clearly delineated set of processes is bad.

Now begins the hard work. You could stop here and end up being reactive again. This is a valid response but it really doesn’t put you anywhere new.

Now that you have identified what is supposed to happen in your environment you can apply this concept to every system or process that you have.

Much of our software solutions are build in modules with each module taking in data/commands, performing a specific process, and then passing along their output to another module in the overall system. The incoming data should be clearly identified and anything not meeting the predetermined criteria should be rejected. Input Validation.

On the systems themselves we can focus on hardening them by removing or disabling all services that are not required for the system to perform its intended function. Again, another very simple concept that can reap great benefits. Yes, it is hard to do and it requires some level of vigilance to ensure that your configurations are maintained after patching cycles.

Now we can move on to our infrastructure. Is your environment segmented and do you know what is suppose to be occurring within each segment? You can group like systems and then lock down the segments to allow only approved communications both between devices on the segment as well as into and out of each segment itself. Should the servers in “Segment A” be talking with the devices in “Segment B?” Should your database servers be communicating with devices on the Internet? Identify what is permissible and deny everything else.

Do you see how this turns things around a bit? You identify what you expect and then engineer to ensure that it happens and nothing else. The number of bad things that could happen continues to grow at an almost exponential rate but the number of good things that you need to keep track of should be relatively stable and is ultimately more manageable.

At this point I haven’t even addressed tools. Where do all of our favorite security tools fit into this model. Just where they always have. If we approach our security programs from this perspective our tools become much more effective and we can more readily demonstrate the value that they provide to us and our organizations.

Would this approach have stopped the latest vulnerabilities du jour? Probably not but it would have been easier to identify that something unexpected was happening that warranted further examination.

I will admit thought that while this approach is conceptually simple and definitely effective, it requires diligence on everyone’s part to ensure that it works. Cross group collaboration and cooperation is essential to this approach being effective. If you have business groups who insist on getting something into production and then patching it later they will put you on a reactive footing that will be hard to change. You will never make it secure later - take the time to do it now.

At the end of the day there is no silver bullet. There will always need to be some manner of reactivity in our lives. Dangers will always seek us out no matter which trail we chose but if we make wiser choices we will be in a much better place to deal with them quickly so we can continue our journey.

What are your thoughts?

Tags: vulnerability, zero-day, security industry, assess, solution, solutions, Firewall, input validation, ROuter, patching cycles, segmentation