Proposed Framework

Consider for example, a simple website which links page A to either page B, page C or any other page. This depends on the logic encoded in the application. Transition from page A to page B may be valid only if some conditions are satisfied, such as ‘the user must be logged in’ to transit from page A to page B. If this condition is not satisfied, the transition is considered as anomalous.

Considering only a single feature, ‘transition sequence of web pages’ may not be sufficient to detect attacks. Other features such as ‘the result of authentication module’ are significant for decision making. Neglecting such features result in false alarms. This is because; the encoded logic cannot be modeled by analyzing the web accesses alone. However, when the system is made aware of the data access pattern via features such as ‘the number of requests generated by a particular page’, ‘the corresponding next page’ and other features, it can effectively model the user-application interaction, thereby resulting in better attack detection.

Similarly, monitoring the data access queries alone without any knowledge of the web applica-tion which requests the data is insufficient to detect attacks since they lack the necessary contextual information. Hence, to detect attacks reliably, we propose monitoring web accesses together with the corresponding data accesses using our unified logging framework.

5.3 Proposed Framework

In order to detect malicious data accesses, the straight forward approach is to audit every data access request before it is processed by the application. However, this is not the ideal solution to detect data breaches due to the following reasons:

1. In most applications, the number of data accesses per unit time is very large as compared to the number of web accesses and, thus, monitoring every data request in real-time severely affects system performance.

2. Assuming that we can somehow monitor every data request by using a signature based system; the system is application specific because the attack signatures are defined by encoding application specific knowledge.

3. The system must be regularly updated with new signatures to detect attacks. As with any signature based system, it cannot detect zero day attacks.

Thus, monitoring every data request is not feasible in high speed application environment. We also observe that the real world applications follow the three tier architecture [129] which ensures

application and data independence, i.e., data is managed separately and is not encoded into the application. To access application data, an attacker has no option but to exploit the application. To detect such attacks, an intrusion detection system can either monitor the application requests or (and) monitor the data requests. When a system monitors the application accesses alone, it cannot detect attacks such as the SQL injection since the system lacks useful information about the data accessed. Similarly, analyzing every data access in isolation limits the attack detection capability of an intrusion detection system. Further, using two separate systems does not capture application-data interaction which affects attack detection. As discussed earlier, previous approaches either consider only the application accesses or the data accesses or consider both in isolation and, hence, unable to correlate the events together resulting in a large number of false alarms. We, thus, propose a unified logging framework which generates a single audit log that can be used by the application intrusion detection system to detect a variety of attacks including the SQL injection, cross site scripting and other application level attacks. Before we describe our framework in detail, we define some key terms which will be helpful in better understanding of the remaining of the chapter.

1. Application: Application is a software by which a user can access data. There exists no other way in which the data can be made available to a user.

2. User: User is either an individual or any other application which access data.

3. Event: Data transfer between a user and an application is a result of multiple sequential events. Data transfer can be considered as a request-response system where a request for data access is followed by a response. An event is such a single request-response pair. We use the term event interchangeably with the term request. A single event is represented as an ‘N’ feature vector which is denoted as:

e_i = f₁, f₂, f₃... f_N

4. User Session: A user session is an ordered set of events or actions performed, i.e., a session is a sequence of one or more request-response pairs. Every session can be uniquely identified by a session id. A user session is represented as a sequence of event vectors as:

s_i =start, e₁, e₂, e₃..., end

5.3 Proposed Framework 83

5.3.1 Description of our Framework

We present our unified logging framework in Figure 5.1 which can be used for building effective application intrusion detection systems.

Control

Web Server with Deployed Application

Data

Intrusion Detection System User / Client

Web Server Log

Data Access Log

Unified Log Session

Figure 5.1: Framework for Building Application Intrusion Detection System

In our framework, we define two modules; session control module and logs unification module, in addition to an intrusion detection system which is used to detect malicious data accesses in an application. The logs unification module provides input audit patterns to the intrusion detection system and the response generated by the intrusion detection system is passed on to the session control module which can initiate appropriate intrusion response mechanisms. We have already discussed that the three tier architecture restricts data access only via the application. Hence, user access is restricted via the application and, thus, the application acts as bridging element between the user and the data. In our framework, every request first passes through the session control which is described next.

Session Control Module

The prime objective of an intrusion detection system is to detect attacks reliably. However, it must also ensure that once an attack is detected, appropriate intrusion response mechanisms are activated in order to mitigate their impact and prevent similar attacks in future. The session control module serves dual purpose in our framework. First, it is responsible for establishing new sessions and for checking the session id for previously established sessions. For this, it maintains a list of valid sessions which are allowed to access the application. Every request to access the application is checked for a valid session id at the session control and anomalous requests can be blocked depending upon the installed security policy. Second, the session control also accepts input from the intrusion detection system. As a result, it is capable of acting as an intrusion response system.

If a request is evaluated to be anomalous by the intrusion detection system, the response from the application can be blocked at the session control before data is made visible to the user, thereby preventing malicious data accesses in real-time. The session control can either be implemented as a part of the application or can also be implemented as a separate entity.

Once the session id is evaluated for a request, the request is sent to the application where it is processed. The web server logs every request. All corresponding data accesses are also logged.

The two logs are then combined by the logs unification module to generate unified log which is described next.

Logs Unification Module

In Section 5.2, we discussed that analyzing the web assess logs and the data access logs in isolation is not sufficient to detect application level attacks. Hence, we propose using unified log which can better detect attacks as compared to independent analysis of the two logs. The logs unification module is used to generate the unified log. The unified log incorporates features from both the web access logs and the corresponding data access logs. Using the unified log, thus, helps to capture the user-application interaction and the application-data interactions. However, very often, the number of data accesses is extremely large when compared to the number of web requests.

Hence, we first process the data access logs and represent them using simple statistics such as ‘the number of queries invoked by a single web request’ and ‘the time taken to process them’ rather than analyzing every data access individually. We then use the session id, present in both, the