Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Security Needs To Focus On Architecture, Not Products

Based on current market trends, Gartner predicts security spending worldwide will reach $86 billion by 2016. But it doesn’t appear that increased spending is leading to better security. According to Tom Foremski of Silicon Valley Watcher, although security startups are plentiful, the general feeling is that we aren’t any more successful at protecting our organizations. Maybe the problem is that we’re too focused on products and not placing enough attention where it matters: good security architecture.

Enterprise security should take a cue from the building industry: form follows function. This expression is an article of faith for modern buildings and architecture. Basically, it’s the idea that the purpose should mandate the design.

In my work as a practitioner, I’m often asked for recommendations regarding the best tools to use for enhancing security. While many products can be useful as part of an overall design architecture, I try to resist giving advice out of context. This is because installing a device or application in a vacuum without considering the specific problems of the infrastructure is like answering the wrong question.

Would you want a builder to construct a house without a plan? Would you try to design it without understanding how many people were going to live in it or where the house will be located? Houses built for South Florida don’t have the same requirements as those made for the United Kingdom, so why do we create security architecture this way?

We do it all the time. I once worked on a project to replace a network access control (NAC) system that was considered a miserable failure in an academic environment. The user services group thought the problem was with the vendor and decided that a different system would solve things. However, the real problem was the inability to enforce any standards in an unrestrictive setting, making almost any type of NAC a poor match -- a perfect example of form not following function.

[Read why organizations might want to consider tapping third-party expertise for security incident response in "Digital Forensics: DIY Or Call An Expert?"]

The typical firewall sandwich consisting of a perimeter device, DMZ, then another internal hardware firewall with an IDS slapped on like a condiment, has served most enterprises well in the past. But this was when networks and applications were simple; it doesn’t seem to be the best option for mitigating risk in our increasingly complex infrastructures. Why has this “best practice” guideline become a prison?

I’ve worked with smart engineers who excelled in the federal space, only to be mystified by a service provider environment. We all seemed to speak the same language, but they couldn’t wrap their heads around the different set of requirements. Once outside of their familiar comfort zone, they stumbled.

What’s the fix? It's a return to the basics of good design. This means utilizing frameworks such as the Sherwood Applied Business Security Architecture (SABSA) or Open Security Architecture (OSA) to establish a common foundation for the infrastructure, then understanding the needs of the business and working in partnership with all the teams in IT.

But this type of effort doesn’t have the sex appeal and adrenaline rush of incident response or discovering the latest APT, so it will take a different type of security professional. It requires someone who understands strategy and the importance of cooperation, while resisting the blinky-lights of the latest technology.