Over the past ten years, technological change and evolving business models have made the very idea of an enterprise perimeter obsolete. VPN technology, the use of protocols (like http) that are allowed to pass through firewalls, and the extension of networks to encompass outside service providers and business partners, illustrate this point. Rather than thinking about "the perimeter", most organizations are better served by thinking in terms of zones of risk, or zones of trust.
In a zone model, the primary concern is about information assets. Instead of attempting to design a system that keeps everyone out, applications and supporting infrastructure are designed to make sure that resources are accessed only by the appropriate people (or processes), at the appropriate times, and through the approved methods of access.
Containing failure
This understanding provides a better foundation for implementing a defense-in-depth security architecture. In other words, the system is built in layers, which anticipate failure of your perimeter, your servers, and security mechanisms and contain those failures, so that one compromise does not lead to a cascading set of information exposures.
An apt analogy is how medieval warriors protected themselves. One way of thinking of a firewall is as a suit of armor that protects the most vulnerable parts of the enterprise. A firewall allows an organization to protect large parts of its system that are difficult to secure or would be especially vulnerable if they were exposed. But just as a suit of armor must allow warriors to breath, see, move, and defend themselves, firewalls must allow various types of interactions with employees, partners and customers. Like the warrior, the enterprise needs to devise other mechanisms to defend against attacks on these targets.
In many organizations, application service providers (ASPs) are an integral part of the IT environment, performing data intensive and mission-critical roles. When ASPs are allowed to connect to certain systems and extract data themselves, the zone model implies that ASPs be authenticated and authorized to tightly control their activities after they have passed the perimeter.
Remote access further demonstrates that the old notion of a secure perimeter is obsolete. VPN technology is often used to provide a secure way for staff to remotely access company resources. This effectively extends the company's perimeter out to wherever each remote employee is located. It has the unintended consequence of making overall security dependent on the security of each remote local environment. For example, homeworking spouses who are employed by different companies could inadvertently bridge the two organizations via their home network.
Enterprises attempt to deal with problems like these by requiring the use of a company-supplied computer that is running a firewall, and prohibiting the use of split tunneling (in this way, the remote employee will not be connecting to the company and also directly connecting to the internet).
As corporations grow larger through mergers and acquisition or expand their offices to branches at remote locations, the once smal,l trusted corporate network, where everyone trusted everyone else, simply does not exist. The staff, the systems and the network often do not operate by the same policies or follow the same security and administration procedures. It is not uncommon for outlying offices to be less physically secure than headquarters, and for them to employ outsiders for system administration and maintenance. With such a marked difference in security, it is hard to justify a security policy based on a hostile outside and a secure and trusted inside defined by a strong perimeter.
To further illustrate the limitations of perimeter security, let's look at web applications. By their very nature, these allow access to resources inside your environment. Typically, this access is limited to a DMZ environment which is specifically designed to separate the outside world from the inside. These systems often have trust relationships with internal systems, including database servers that store sensitive data.
However, the internet-exposed systems in the DMZ could eventually fall victim to attack. Now the question becomes 'What is the internet perimeter if the DMZ is compromised?'. By compromising a legitimate system, leapfrogging is now possible, since the access will appear to come from a legitimate source.
This example illustrates why the concept of zones of trust is so important. It forces organizations to implement multiple sets of security controls. To develop these zones of trust, enterprises judge which DMZ systems need to access which internal systems, and then they control the communication by network segmentation and authentication.
The transition to defense-in-depth
Organizations find themselves in the early stages of a transition state to defense-in-depth when a small number of people within them begin to think about security architecture in terms of zones of risk and zones of trust, and they start to put plans in place to monitor what had previously been considered the "inside" to detect security problems. However, the vast majority still perform their day-to-day roles as if the outside is hostile and the inside is safe.
Typically, application developers focus on functionality and time to market. It is no exaggeration to say that many application developers view security as a necessary evil at best, and as something that will slow down their projects and reduce their bonuses at worst. As a result, the old notion of inside and outside remains comforting to an application developer. They can think "My application will run inside the firewall and is not accessed from the internet, so I don't really have to worry about security."
Applications designed with assumptive authentication – if you are here, you must belong – are the litmus test that an organization is still changing over to a defense-in-depth posture.
The transition to defense-in-depth requires a change of mindset – in the designers of applications and networks, in the developers of applications, in the administrators of the applications systems and networks.
First, they need to accept the notion that, if a system or application is accessible, it can be compromised. Second, the enterprise must be designed to contain failures and compromises.
Functions such as application services and web applications, and corporate services such as email, should be separated into zones so that compromising one does not compromise the other. Further, the organization needs to accept that mechanisms such as authentication, authorization, and intrusion detection should be used inside the firewall to provide interior defenses that pick up where the perimeter leaves off.
This relatively simple change in the way people look at the enterprise can make a significant difference to the effective security of an enterprise.
Jonathan Gossels and Dick Mackey are founder members of the security consultancy SystemExperts
