Guest Column - Policy-based networks: Why not further along?

Policy-based networking offers the ability for the network infrastructure to permit, deny, prioritize, rate limit, or otherwise provide visibility or control of the traffic traversing a network. These capabilities are typically a subset of features found in products like enterprise firewalls and packet shapers, usually employing a combination of MAC, protocol and transport layer rules, but seldom providing stateful inspection or application layer capabilities. In other words, it provides many of the features of enterprise security products, but at every point of entry for the users of that LAN.

In the past, simple filtering rules deployed at each point of user access would have had a significant impact on curbing the proliferation of events such as Slammer, Blaster and Welchia. Such rules, however, would not have kept users from opening the attachments that infected their workstations, but would have contained the infection to that workstation. There are mechanisms available today that can help protect against the proliferation of these events. The question is, “Why are they not being used more frequently?”

The answer is actually a combination of factors, from market confusion to shortcomings in vendor implementations, and, in some cases, misconceptions by enterprise organizations. Here are a few examples:

Absence of a market definition. The term “policy” has become a catch-all for functionality that controls user access, models business roles and provides guidelines for appropriate behavior. The result is that vendors cannot compete on the merits of their products/solutions compared to an industry norm but rather in a mismatched web of acronyms, marketing concepts and emerging industry standards.

Many enterprise infrastructure vendors have marketed basic VLAN capabilities as a policy, which is akin to positioning Tylenol as the cure for a serious medical condition. Useful policy rules need to be more granular than VLAN, and must be as close to the user as possible.

Inadequate management model. The policy-enabled network capabilities described here are designed to be deployed to every point of access into the LAN. This is significantly different than the model of configuring firewalls, for example, because there are far fewer interfaces, and they generally fit into one of a few categories (DMZ, external, internal).

The challenge is to provide an administrative model that allows the network administrator to both implement and troubleshoot these capabilities on hundreds or thousands of ports without incurring unreasonable costs or risk; in short, command line interface does not cut it. This conflicts with the efforts of most vendors to implement a configuration model that closely matches the market leader, and has delayed important areas of innovation in the manageability of large-scale networks.

False sense of security. If the recent past has taught us anything, it is that every IT component has a role to play, and must participate, in the overall security of the system. Following outages, many CIOs look to the network team to both explain why the system was down, as well as to figure how to keep it from happening again, even though the attacks were transmitted in e-mail and launched from workstations.

There are encouraging signs, however, in both enterprise adoption of the technology and in improving vendor implementations. Primarily, policy-based networking is no longer at risk of remaining a solution in search of a problem. Policy-based networking will be implemented because it is a tool that can help mitigate the flood of exploits that are not showing any sign of abating in the near term. This will give the market some clarity in matters of messaging and implementations, and allow enterprise organizations to finally pin down the features, benefits and shortcomings of a vendor’s solution.

For more information from Blue Spruce Technologies:
www.rsleads.com/407cn-256

Steve Pettit is a principal at Blue Spruce Technologies, Greenland, N.H. Send comments for publication to guest@comnews.com.