Given a network that deploys multiple firewalls and network intrusion detection systems (NIDSs), ensuring that these security components are correctly configured is a challenging problem. Although models have been developed to reason independently about the effectiveness of firewalls and NIDSs, there is no common framework to analyze their interaction. This paper presents an integrated, constraint-based approach for modeling and reasoning about these configurations. Our approach considers the

more »

... pendencies among the two types of components, and can reason automatically about their combined behavior. We have developed a tool for the specification and verification of networks that include multiple firewalls and NIDSs, based on this approach. This tool can also be used to automatically generate NIDS configurations that are optimal relative to a given cost function. Keywords: Formal specification and analysis, network intrusion detection, firewalls, network configuration and security Introduction Correctly configuring a network that includes multiple servers, routers, firewalls, and other security mechanisms is a challenging task, particularly when the intended properties are never defined, or only vaguely specified. To address these problems, a number of methods for formalizing network configurations and policies have been proposed, together with tools for ensuring that a particular configuration satisfies a given policy specification (e.g., [12, 13] ). We build on this work, extending it by including specifications and requirements for the network intrusion detection systems (NIDSs). We can then reason about network topology, filtering, and NIDS placement and configuration, within a single framework. To our knowledge, this is the first attempt to reason about joint NIDS and firewall configurations using a formal framework. An example of the questions we want to answer is: For a given topology, NIDS, and firewall configurations, is a particular class of "bad" events always detected? Can false alarms be raised for a given set of "good" events? How should the NIDSs be configured to minimize false alarms, maximize the number of detected bad events, and minimize a given deployment cost? The effectiveness of the proposed method, and the cost of applying it, must be considered. One of our goals is to produce a "lightweight" formal tool, whose cost ranges from minimal (a "one-click" sanity check of the network that will report inconsistencies, redundancies, and incomplete configurations) to moderate (automatically checking security policies specified by a designer). As with any formal method, the guarantees that it provides are relative to the accuracy of the models and specifications, and the level of abstraction used. For example, we note that our IDS model does not characterize low-level NIDS behavior such as packet/stream reassembly and payload encoding normalization, used to counter NIDS evasion and denial of service attacks (e.g., [19] ). Instead, we assume that the NIDS's used are robust against these attacks and can keep up with the traffic load. However, even an idealized model can help uncover design flaws, or find improvements. Formalizing network behavior can help make systems more secure, by identifying potential weaknesses in the configuration. It can also be used to minimize the allowed services and connections, while still maintaining needed functionality, making the system less vulnerable to novel exploits and attacks [21] . Redundancy can increase the robustness of a network, but also presents difficulties for network intrusion detection. For instance, if a server has multiple network interfaces for failover or load balancing, attack packets may reach a target through multiple paths. By considering connectivity, firewall configuration, and NIDS placement, we can ensure that these packets are detected. Path: allied->allied_eng_router->engineering. Undetected: packet with [service:smtp, payload:smtp_attack_payload, from_ip:allied_host, to_ip:[eng_mail_server, fin_mail_server]]. When the location of the NIDS is moved from periphery to engineering, our tool reports that there is no violation of policy detect_smtp. 9