13.2. Static Decision-Making Systems

The characteristic that defines this class of IRSs is that they respond to attacks defined exactly, prior to deployment, and using responses that are enumerated and completely configured. They are in generally simple to understand and deploy and work well for a large class of systems that have determinism in the kinds of workload and where the attack modes are enumerable a priori. However, they are not very effective for dynamic systems with changing workloads, new kinds of services installed, and new vulnerabilities introduced due to hardware or software changes.

13.2.1. Generic Authorization and Access Control—Application Programming Interface

Introduction

The Generic Authorization and Access Control—Application Programming Interface (GAA-API), developed by the Information Sciences Institute [3], is a signature-based intrusion detection and response system that provides a dynamic authorization mechanism at the application layer of a computer system. The basic idea is to integrate access control policy with intrusion detection and some countermeasure according to policy, such as generating audit records. GAA-API supports access control policies and conditions defined by a BNF-syntax language. It is a generic tool that has been integrated with many applications, including Apache, SSH, SOCKS5, and FreeS/WAN (IPSec VPN), running on Linux and Sun Solaris platforms. It is designed as a generic interface based on standard C language APIs, so it can be easily ported to other platforms and applications.

Details

GAA-API extends the access control capabilities from an application, while providing the opportunity to identify application-level attacks and specify different types of real-time responses to intrusions (Figure 13.1). A key component of the API is its Extended Access Control List (EACL) language, which allows the formulation of policies for the API to evaluate, decide, and respond to possible attack scenarios. Each object in the application is associated with an EACL, where the access rights are defined along with a set of conditions necessary for the rights to be matched. The conditions can state the requirements necessary to grant or deny access (preconditions), determine what to do when an access request arrives (request-result), what must hold while the access is granted (mid-conditions), and what to do after the access ends (postconditions).

The conditions allow for the API to interact with IDSs, modify existing policy rules, and trigger a response. As an example of the interaction with an IDS, the API can report attack information such as a violation of threshold conditions and access requests with parameters that do not comply with a site’s policy. The API can also request an IDS for network-based attack information, such as spoofed addresses. The API can deploy responses according to the conditions previously defined. The API might, for example, limit the consumption of resources, increase the auditing level, or request user authentication to access a certain application. Nevertheless, it is unclear as to which type of language or protocol is used for the framework to exchange messages with an IDS.

GAA-API defines two types of policies: system-wide policies, which can be applied to all the objects in an application, and local policies, which are selectively applied to individual objects. The final policy application to an object, for which both system-wide and local policies exist, depends on the composition mode selected. There are three alternatives: expand, which provides access to an object if either system or local policy allows it; narrow, where mandatory access control rules defined by system-wide policies overrule any discretionary rule defined at the local policy level; and stop, where local policies are ignored if a corresponding system-wide policy exists.

The policies defined and implemented allow for the GAA-API framework to also interact with system administrators. An administrator can receive messages and validate the impact and effectiveness of the response actions taken by the framework. An example would be a rule defined for an Apache web server that states updating the list of malicious Internet provider (IP) addresses after a potential attack is detected and sending an email with the IP address of the potential attacker, the URL attempted, and the reported time of the attack. The administrator would later validate the effectiveness of the response.

The authors at USC [22] report that GAA-API functions introduce a 30% overhead for an Apache web server function call when email notification to administrators is disabled. If the email notification is enabled, the overhead rises to 80%.

Significance

The authors at USC [22] present an extended approach to the regular access control model found in popular Unix-based applications. The access control policies interact with other important security mechanisms such as IDS and firewalls, allowing for a richer set of potential responses in the presence of attacks. More recently, the authors further developed the concepts presented in GAA-API with the introduction of dynamic detection and response mechanisms during the trust negotiation phase between two parties, usually client and server, and the support they can provide for stronger access control. A potential drawback to this model could be the complexity introduced by such policies, with many variables and the interaction among them, making it hard to administer in a large environment.

13.2.2. Snort Inline

Introduction

Snort Inline is a mode of operation for Snort, the popular open-source IDS. Originally developed as an independent, modified version of Snort, it was integrated in version 2.3.0 RC1 of the Snort project to provide intrusion prevention capabilities. It requires the Netfilters/IPtables software developed by the same project. Snort Inline provides detection at the application layer to the IPtables firewall so it can dynamically respond to real-time attacks that take advantage of vulnerabilities at the application level.

Details

Snort Inline is the intrusion prevention component of Snort, a popular network intrusion detection and prevention system capable of real-time IP network traffic analysis. Snort was originally developed by Martin Roesch and is currently owned and developed by Sourcefire, a company founded by Roesch. Snort Inline started as a separate project that used Snort for its packet logging and traffic analysis capabilities, but has since been included in the Snort distribution, providing the intrusion response capabilities that the popular IDS had hitherto lacked.

The Netfilter/IPtables software allows for the implementation of the response mechanism while Snort Inline provides the policies based on which IPtables make the decision to allow or deny packets. After an incoming packet to a network is provided by IPtables, Snort performs the rule matching against the packet. There are three new rule types included in Snort for Snort Inline to define the actions that IPtables might take after receiving an incoming packet. All three rule types drop the packet if it matches a predefined rule. The second type of rule also logs the packet and the third type sends a control message back. The rules are applied before any alert or log rule is applied. The current version of Snort also allows a system to replace sections of a packet payload when using Snort Inline. The only limitation is that the payload selected must be replaced by a string of the same length. For example, an adversary that is looking to propagate malicious code through the PUT command could have it replaced by the TRACE command, thus halting further propagation of the code.

In order for Snort Inline to interface with IPtables, two C libraries are needed: libipq and libnet. Libipq [23] is a library for IPtables packet queuing that allows Snort Inline to exchange messages with IPtables. Libnet is the popular networking interface to construct, handle, and inject packets into a network.

Significance

The inclusion of Snort Inline to the popular Snort project is a good example of the evolution of IDSs as more proactive—dynamic capabilities are necessary to assist systems against today’s attacks. However, the rule matching is against a statically created rule base and thus needs a prior estimate of the kinds of attacks that will be seen and the action is taken at the site of detection.

13.2.3. McAfee Internet Security Suite

Introduction

The McAfee Internet Security Suite (ISS) is a commercial product developed for the Windows operating system platform that integrates many security technologies to protect desktop computers from malicious code, spam, and unwanted or unauthorized access. The suite also includes monitoring and logging capabilities as well as backup, file and print sharing, privacy, spam filtering, and file wiping utilities. The interaction between several of these technologies allows for prevention, detection, and response of various types of attacks, chief among them being attacks related to malicious code. However, for this system, it is impossible to find detailed technical material while there is an overabundance of documents listing the features of the solution.

Details

The two main components of ISS are an anti-virus subsystem and a firewall subsystem. The anti-virus subsystem allows for the detection of viruses, worms, and other types of malicious code by using a signature-based approach along with a heuristic engine for unknown attacks. The firewall subsystem can be configured to scan multiple points of data entry, such as email, storage devices, instant messaging, and web browser. An intrusion detection module allows the firewall to interact with the anti-virus, providing a limited set of automatic responses to ongoing attacks. Another component of the ISS that is relevant to intrusion response is a system monitor. The system monitor detects and blocks changes on important components of the operating system, such as configuration files, browser settings, startup configuration, and active protocols and applications.

Significance

The evolution from an anti-virus product to an all-in-one security solution is a natural transformation that vendors such as McAfee and Symantec have experimented with in the last few years. The increase in complexity, speed, and variety for malicious code, along with the requirement to respond to attacks in real time, have led these vendors to integrate multiple security mechanisms. The response mechanisms implemented are still static and limited but one could expect more dynamic responses in future versions of these suites.

13.2.4. Other Systems

McAfee IntruShield Intrusion Prevention System

This forms part of the Network Intrusion Prevention product offering from McAfee. There is no technically rigorous publication describing the product. Our discussion is based on the documents put on the specific McAfee web page [24]. This system can be described as a network intrusion prevention system (IPS). It provides real-time prevention of encrypted attacks, while its ASIC-based architecture provides deep packet inspection and shell-code detection leading to zero-day protection. It employs purpose-built appliances (i.e., specialized hardware). The hardware is of different types depending on deployment—at the core of the network or the perimeter of the corporate network. It claims to prevent a wide variety of attacks, such as botnets, voiceover IP (VoIP) vulnerability-based attacks, and encrypted attacks.

In terms of response, it provides hints for creating some offline response in the manner of forensics. It delivers unique forensic features to analyze key characteristics of known and zero-day threats and intrusions. IntruShield’s forensic capabilities provide highly actionable and accurate information and reporting related to intrusion identification, relevancy, direction, impact, and analysis. There is a host-based intrusion prevention system also from McAfee [25].