With policy enforcement points such as those that reside on trusted, self-defending platforms, and intelligent intrusion detection systems as discussed above, it is important to have an overarching architecture that correlates distributed information, local decisions, and individual device actions so that we have a closed-loop for autonomic management. In this section we discuss the management building block of security autonomics for the enterprise–the adaptive policy management architecture. As shown in Figure 5, the main components of this adaptive, self-management architecture include a Manager of Managers (MOM), Intermediate Device Managers (IDM), a Policy Enforcement Point (PEP), and a Policy Feedback Point (PFP). The role of the MOM is to provide autonomic and centralized management of enterprise security policies, including translating business-driven policies into device-specific controls and pushing them to specific devices through IDMs. A main distinction of this architecture from the standard policy-based network management architecture [15] is the introduction of PFP and the control feedback loop. The PFP collects and processes intrusions, security alerts, violations, and other abnormal behaviors from a variety of systems (e.g., intrusion detection systems, system logs, etc.), and it sends such data as control feedback to the MOM. With such feedback information the MOM then determines the necessary control updates, which can either lead to automatic actions pushed to the network, or the feedback data and recommended actions can also be used to help the network administrator make corresponding human decisions on control updates.

The benefit of using the centralized MOM with adaptive feedback for automated response to a network condition is that it provides coverage for the entire network on a holistic level. This makes the autonomic response more intelligent than a "per security enforcement point" or even a "per security device type" detection and mitigation approach. These traditional per-device or per-device-type models, where each individual device only has knowledge of the local network events and will make a policy decision based on this limited information, has a potential to cause co-relation and conflicts, as there is no information sharing between the various enforcement points on the policies (both static and dynamic) and network events. Our approach ensures that all events are co-related and the action taken is applied at the most effective control point, which in our prototype example, was the network enforcement point closest to the source. Since the MOM has the knowledge of the capabilities for each enforcement point, it is able to make an intelligent decision on the placement of these dynamic controls.

Figure 5: Conceptual architecture
click image for larger view
 

Another distinguishing component of this architecture is the capability-based policy specification [14], which enables high-level policies to be implemented transparently on end-devices and common policies to be pushed from a central location to various network devices from different vendors. Compared to most existing policy specification models [16], our policy schema is a consistent and extensible data model for network security policy representation. The important notion of this schema is the ability to specify heterogeneous devices in terms of their capabilities. This approach allows the overall data model to be extensible, since newer devices can be added by describing their capability data models. This approach provides a platform that allows consistent security policy specifications and standard device capability specifications to be developed. Advantages of this policy specification include security policy specification independent of device differences, which allows for extensibility and algorithmic mapping; capability knowledge, which allows conflict resolution and threat analysis during security policy definition; data model that includes network and end-point nodes, which reduces the chances of lapses in security; a combined data model, which allows for co-related feedback events from the network and reduces the administrative (human) overhead of hand mapping a high-level security policy down to a heterogeneous set of devices, each with their own configuration methods and syntax.

Market survey on security policy management

We implemented a prototype of the above architecture with representative "real-world" operational enterprise IT use-cases to demonstrate the benefits of this architecture. We studied 15 commercial products/solutions from a broad variety of vendors, including the market leaders in network and security management, based on a survey by the Burton Group [17]. Based on our study we broadly categorized these products into three types: (1) vertical solutions with several desirable capabilities, but focused on single vendor devices and lacking support for management and integration in a multi-vendor enterprise environment; (2) multi-vendor network configuration and device management systems, most of which were designed for management, provisioning, automation for network configuration and Quality of Service (QoS), but not for security management; and (3) what we believe were the first-generation autonomic management solutions: these products have many of the required capabilities and can be evolved to cover for some of the missing capabilities necessary in today's enterprises. We selected two products from the third category for further operational validation against our use-cases, which are described in the following section.