De-perimeterization is no longer an issue of debate; it's a fact. The hardened perimeter walls that are essential for network security are becoming more and more porous and will continue to do so over time.

And this is happening at the worse possible time... when the value of the data it is protecting is skyrocketing.

Identity theft is one of the fastest growing crimes worldwide. It has made personally identifying records, such as customer and employee data, a very valuable commodity, and an active target by organized crime. At the time of writing, black market prices for single data records range from $4-$100 depending on the information in them.

The perimeter is still a strong defense, but it is losing its effectiveness. The best security is proactive; identifying threats and dealing with them before they case harm. De-perimeterization has the potential to be the mother of all threats, and needs to be dealt with proactively.

Step 1: Defend the wall

The first focus for a lot of organizations is to improve their perimeter defenses. Actions here often include:

• Adding more firewalls;
• Limiting or prohibiting wireless LANs;
• Limiting or prohibiting partners and customers;
• Limiting consultants from internal connections; and
• Limiting mobile connections and access.

While some of this can help, these are all short-range actions. The factors causing de-perimeterization are long-term, and while this may help some organizations feel good, it is a little like trying to hold back the tide - ultimately you will get wet.

Step 2: Increase network segmentation

Most analysts agree that the first real step in fighting the declining effectiveness of the perimeter is to increase the use of network segmentation, or creating a series of "mini perimeters", that brings the perimeter into focus, makes it more manageable, and puts more wall in the way of potential attackers. Segmentation also helps to limit the effect of attacks by creating closed user groups - essentially subdividing users or systems into discrete "insider" categories. Network segmentation can act like the watertight bulkheads on a battleship, ensuring that a breach or attack is contained within the specific segment where it occurred. It also has additional advantages, providing simplified security management, closed user groups and better overall privacy.

But while segmentation is a much better option than just defending the wall, it is still really "more of the same", and by itself not really a long-term solution to de-perimeterization.

Step 3: Security redesign

We talk about de-perimeterization meaning the loss of the "wall", and indeed it does. But perhaps a bigger issue here is the loss of the gateway, which is a chokepoint for authorization, access control and authentication, as well as frequently being the termination point for encryption.

Since almost all security technologies today rely on a gateway to operate, a weakening of the perimeter also means that these existing security technologies in turn become less effective. As the effectiveness of the perimeter declines, and with it our ability to utilize gateways to control and monitor, the security model for the network will have to move inside the perimeter, and ultimately to node or device enforced security.

If we can no longer rely on gateways to route and control traffic, then our new security model will have to work the way a network works: point-to-point. This means that the mainstays of security; authentication access control and authorization, must occur at each end point and data-in-motion between end points must be encrypted to ensure privacy and integrity. The nature of the network itself reinforces this point.

TCP/IP was designed from the start as an open protocol which has always been its greatest strength. It was built to allow anyone on a network to quickly and easily move around, which was fine when the community inside the network was a trusted one. But in a world with porous perimeters this "Default Allow" becomes a significant challenge.

We need to move, at least in part, to a "Default Deny" environment - where only specifically authorized connections are allowed - at least for some of the security zones.

Securing Inside the Perimeter

Securing inside the perimeter is radically different from securing the perimeter and beyond. The environments are completely different and there are no convenient choke points or gateways for security to focus on.

Installing gateways inside the perimeter doesn't work very well. There are scale issues as well as the inevitable management, bottleneck and performance issues.

The internal network communicates point to point, and so any effective security solution for inside the perimeter has to work in the same way. This is an infrastructure problem and requires an infrastructure solution.

Table 1: Environmental differences between inside and outside the perimeter

As you can see from the table, the main differences in the environments revolve around scope, in terms of the numbers of systems, applications and volume of traffic.

This scope issue is repeated when it comes to protocols. Instead of just a few protocols to contend with as we do outside the perimeter, internal security needs to deal with hundreds of thousands of protocols. The application issue is probably the biggest challenge here. Not only does the number of applications increase dramatically inside the environment (the average large organization can have upwards of 1,800 applications that need to be protected, compared with only a dozen or so outside the perimeter), but there is also the issue of age and platforms.

Applications that are regularly accessed from outside the perimeter have incorporated a number of security functions over the years... these are in relatively good shape. But applications inside the perimeter run the gamut from new commercial applications, through older legacy systems, to homebuilt applications, many of which have limited security capability. And reworking or replacing older applications to accommodate security is not really feasible, especially in the short term. Additionally the task of managing security implementations within each application opens up a whole new can of worms; the dependability of security implemented by application developers, the resource implications of managing upwards of 1,800 different security implementations, and the need for network-wide integration.

Another "scope" difference between the two environments is the variety of operating systems that need to be supported inside the perimeter. Most systems outside the perimeter run Windows, with Linux and Apple completing the picture. Inside it's a lot messier, starting with older mainframe operating systems, all flavors of Linux, Windows, Unix, and even DOS.

Security Design Inside the Perimeter

It is clear that the only effective method here would be to push the security to the network layer, making it invisible to the application (and the user), while allowing it to be managed centrally. In this way the new security model could address the issue of interoperability between different operating systems and applications, as well as the need to interface with legacy systems.

The nature of traffic inside the perimeter is point-to-point, and as the perimeter becomes more porous, traffic flowing between systems will be more at risk of interception. Consequently, any security solution for inside the perimeter must secure this peer-to-peer traffic, including authentication, authorization, access control, and the ability to encrypt data-in-motion.

Most analysts agree that the evolution of network security will move from a "perimeter" model to a "bulkhead" (or segmentation), model to a "matrix" model where security is enforced at the endpoint, but controlled centrally.

Hardware is probably not a solution here. Quite apart from the challenges in managing hardware based segmentation today, as the model evolves it will have to incorporate the ability to maintain business flexibility. This is necessary since workgroups, applications and employees' access levels and indeed the demands from the business managers in an organization change frequently. Maintaining flexibility with a hardware solution will be a real challenge.

Perimeter-Based Security to Policy-Based Security

As we move from a perimeter-based model to a matrix model the role of the policy and policy management moves to the forefront.

Policy management at the perimeter is done primarily through gateways, using "global" policy sets, i.e., "if a device or individual connecting is known let it through", or "encrypt all traffic", etc. Not many policies are needed, as we are dealing with a "many to one" model here with many connections being managed at a single point.

As we move to the bulkhead model the number of individual perimeters increase - with a corresponding increase in the number of policies to be set up and managed. This is especially true if the segmentation incorporates security as well as separation.

Then as we move to a matrix model, where each device effectively manages its own perimeter, we will move to a "many to many" connection model where any device could connect to any other device - with the corresponding impact to the number of policies that would need to be managed.

The issue of de-perimeterization requires both immediate action and longer-term planning. In the short term, security can be improved and risk mitigated through the use of segmentation, but ultimately we need to move to security without the use of gateways - moving from a perimeter-based model to a policy-based model.

The perimeter will never disappear completely, but it is being compromised. And this is not going to change - other than to get worse over time. The "matrix level" technology to secure inside the perimeter is available today, and it covers all of the issues raised in the article. But the real answer to de-perimeterization is not just technology.

The real answer has to incorporate technology combined with a new security design, new ways of looking at security, new ways of thinking about security policy, and an increasing focus on large-scale policy management.

David M. Lynch is Vice President of World Wide Marketing at Apani Networks; email: dlynch@apani.com; web: www.apani.com.