Application Intrusion Detection Systems

As information systems have become more comprehensive and a higher value asset of organizations, intrusion detection systems have been incorporated as elements of operating systems, although not typically applications.  Intrusion detection involves determining that some entity, an intruder, has attempted to gain, or worse, has gained unauthorized access to the system.Intruders are classified into two groups.  External intruders do not have any authorized access to the system they attack.  Internal intruders have at least some authorized access to the system. 
Internal intruders are further subdivided into the following three categories.  Masqueraders are external intruders who have succeeded in gaining access to the system and are acting as an authorized entity.  Legitimate intruders have access to both the system and the data but misuse this access (misfeasors).  Clandestine intruders have or have obtained supervisory (root) control of the system and as such can either operate below the level of auditing or can use the privileges to avoid being audited by stopping, modifying, or erasing the audit records [Anderson80].

Intrusion detection systems (IDS) have a few basic objectives.  Among these objectives are Confidentiality, Integrity, Availability, and Accountability.

            Intrusion detection has traditionally been performed at the operating system (OS) level mostly by comparing expected and observed system resource usage.  OS intrusion detection systems (OS IDS) can only detect intruders, internal or external, who perform specific system actions in a specific sequence known to constitute an intrusion or those intruders whose behavior pattern statistically varies from a norm.  Internal intruders are said to comprise at least fifty percent of intruders [ODS99], but OS intrusion detection systems are frequently insufficient to catch such intruders since they neither perform the specific intrusive actions because they are already legitimate users of the system, nor significantly deviate from expected behavior.

            We hypothesize that application specific intrusion detection systems can use the semantics of the application to detect more subtle attacks such as those carried out by internal intruders who possess legitimate access to the system and its data and act within their bounds of normal behavior, but who are actually abusing the system.  This research will explore the opportunities and limits of utilizing application semantics to detect internal intruders through general discussion and extensive examples.  We will also investigate the potential for application intrusion detection systems (AppIDS) to cooperate with OS intrusion detection systems (OS IDS) to further increase the level of defense offered by the collective intrusion detection system.

            The rest of the paper is structured as follows.  The next section will describe OS intrusion detection and intrusion detection in general.  Then, two case studies will be presented that will be followed by a section describing the observations obtained from the case studies.  The last section will present general conclusions.
 

State of Practice – OS IDS

OS IDS that monitor resource usage of the operating system and the network represent the state of practice.  They only monitor the resource usage of the application and not the application activity itself.  OS IDS typically obtain the values necessary to perform intrusion detection from the existing audit records of the system.

Intrusion Detection Approaches

Currently there are two basic approaches to intrusion detection.  The first approach, anomaly detection, attempts to define and characterize correct static form of data and/or acceptable dynamic behavior.  In effect, it searches for an anomaly in either stored data or in the system activity.  IDS utilizing anomaly detection include Tripwire [Kim93], Self-Nonself [Forrest94], and NIDES [Anderson95].

The second approach, called misuse detection, involves characterizing known ways to penetrate a system in the form of a pattern.  Rules are defined to monitor system activity essentially looking for the pattern.  The pattern may be a static bit string or describe a suspect set or sequence of events.  The rules may be engineered to recognize an unfolding or partial pattern.  IDS utilizing misuse detection include NIDES [Anderson95], MIDAS [Sebring88], and STAT [Porras92].

Intrusion detection systems have been built to explore both approaches: anomaly detection and misuse detection.  In some cases, they are combined in a complementary way in a single intrusion detector.  There is a consensus in the community that both approaches continue to have value.  Systems also apply these same approaches to detect intrusions across a network of computers.  Representative systems include NADIR [Hochberg93], NSTAT [Kemmerer97], GrIDS [Staniford-Chen96], and EMERALD [Porras97].

Generic Characteristics of IDS

After analyzing the approaches taken by IDS at the operating system and network levels, some generic characteristics of intrusion detection became apparent.  To characterize OS ID and then compare it to Application Intrusion Detection (AppID), we first need to define some terminology that will allow us to discuss the characteristics of both more precisely.  This terminology is similar to that used for prior software and hardware error detection research.

A relation is an expression of how two or more values are associated.  An observable entity is any object, such as a user, data object, or system device, that has or produces a value in the monitored system that can be used in defining a relation.  Examples of operating system level observable entities include CPU time usage, the number of files associated with a user, and the timestamp of the last modification to a file.  There are two basic types of relations although some blending between the two is possible.  Statistical relations can be used to compare the current value of an observable entity to a profile, a collection of statistical and other relevant information characterizing normal or anomalous behavior.  These are most often used in anomaly detection.  Rule-based relations relate the immediate or accumulated value to a predefined expected value and are most often used in misuse detection.

Thresholds can be set for the relations regardless of whether they are statistical or rule-based.  Thresholds determine how the result of the relation will be interpreted; results outside of the threshold will be considered anomalous and results within the threshold will be considered normal.  Thresholds are normally characterized by a certain number of standard deviations for statistical distributions or by a range, either fixed in size or as a percentage of the expected value, for rule-based analysis.

Setting the thresholds will impact the effectiveness of the IDS in detecting intrusions.  Tighter thresholds, permitting less discrepancy, allow for greater detection but at the risk of more false alarms, an indication of an intrusion in the absence of an intrusion.  Looser thresholds produce fewer false alarms but potentially at the cost of diminished detection.

The frequency with which a relation is evaluated can also impact the effectiveness of the intrusion detection system.  It is possible for the IDS to evaluate all relations immediately after each event, the results of actions taken by users, processes, or devices that may be related to a potential intrusion.  However, this may place an intolerable processing burden on the IDS.  Therefore, events are typically collected in audit records over a period of time.  Audit records entries can be reduced by combining some events into a single entry for analysis.  For example, a single, failed log-in attempt is most likely insignificant, but many failed log-in attempts over a relatively short period of time may indicate a possible intrusion.  The period of time between audit record analysis may be determined using real time or logical time where the relations are evaluated after a certain number of events have occurred.  Audit records only deal with notions defined by the OS.  Many aspects of the application are not visible to the OS and thus are not in the audit records.

Case Studies of Application Intrusion Detection

OS IDS have matured since their inception.  However, the rate of improvements to their effectiveness in detecting intrusions has probably decreased as intruders have become increasingly savvy.  Therefore, a significant change in the approach to intrusion detection is needed to further increase the effectiveness of intrusion detection.  We hypothesize that major improvements may be made by incorporating intrusion detection into an application intrusion detection system (AppIDS).  We use three questions to guide the exploration of using the basic intrusion detection techniques and the additional knowledge of application semantics to improve the effectiveness of intrusion detection.

Opportunity – what types of intrusions can be detected by an AppIDS, especially those not visible to an OS IDS?

Effectiveness – how well can those intrusions be detected by an AppIDS?

Cooperation – how can an AppIDS cooperate with the OS IDS to be more effective than either alone?

Since the concept of intrusion detection at the application level is fairly new, there is a lack of established literature on the subject for use in answering these questions.  Therefore, we have decided to develop case studies.  From them, we hope to glean some general understanding about AppIDS and determine its viability.  By developing the examples, we also hope to develop a possible method of reasoning about such systems more generally.

Electronic Toll Collection

The first case study involves an electronic toll collection (ETC) system comprised of numerous devices interconnected to expedite toll collection on highways.  Despite being specific to transportation, we felt that ETC provides a particularly interesting example because of certain properties that it possesses.    We looked at several real ETC systems on which to base this case study, but to not increase the risk to any of the observed systems, this case study is based on a generic ETC system.  The system incorporates numerous devices distributed throughout the transportation infrastructure to collect ETC specific data such as vehicle identity, weight, number of axles, and license plate numbers.  These devices are configured in a hierarchical fashion.  The ETC system differs from an OS in that it has these independent, but linked, devices from which it gathers data about the external behavior that it monitors. 

The ETC system has a three level hierarchy.  At the lowest level are the individual toll booth lanes and the equipment installed in each lane.  A collection of adjacent toll lanes comprises a toll plaza, the middle level in the hierarchy.  The toll management center, the single node constituting the highest level in the hierarchy, is the central control headquarters that manages all of the system’s toll plazas as well as any other devices from the highway system that are not directly related to the toll lanes or toll plazas.

Application Specific Intrusions

Intrusion detection systems detect intrusions by evaluating relations.  Therefore, we need to identify the relations that an AppIDS could use to detect intrusions.  One possible way to determine which relations are relevant for intrusion detection is to consider potential specific hazards, real world harm caused by an intrusion(s), and find the relations that could possibly help detect those hazards.  To find the potential hazards, we found it useful to use the following threat categories to jog the mind: Denial of Service, Disclosure, Manipulation, Masqueraders, Replay, Repudiation, Physical Impossibilities, and Device Malfunctions.  Within each specific hazard there are different methods by which to execute the intrusion that causes the hazard.  Different relations may detect different methods, so the methods are useful in finding all the applicable relations that could detect an intrusion.  After deriving the specific hazards and their corresponding methods, the AppIDS designer can determine which of the possible relations could be used to detect each specific hazard using the various methods.  These relations are then considered for inclusion in the AppIDS.  Figure 1 gives a graphical representation of the basic steps in the process of identifying the relevant relations.

For this case study, we came up with the following five specific hazards caused by intrusions.  The threat category from which each method was derived is listed in parentheses.

Hazard:          Annoyance

Methods:        Modify a random or selected element of the database (Manipulation)

Flood network with bogus packets (Denial of Service)

Install a Trojan Device that performs its intended function but also performs some other, undesirable function (Disclosure)

Hazard:          Steal Electronic Money

Methods:        No tag and cover the license plate with a cover or dirt (Denial of Service)

Put a filter on the network that discards all of that tag’s packets (Denial of Service)

Copy another tag for use (Masquerader)

Obtain account number and/or balance (Disclosure)

Make customer transparent by removing enough parts of the database so that the system will recognize the vehicle but not be able to determine which account to deduct from (Denial of Service)

Make the account read-only so that it will not deduct (Manipulation)

Have the tag deduct from some other account (Manipulation)

Change the deduction amount (Manipulation)

Transfer money from one account to another (Manipulation)

Add money to the ETC account without having any real money deducted from some other (presumably bank) account (Denial of Service)

Hazard:          Steal Vehicle

Methods:        Change report of stolen vehicle (Manipulation)

No tag and cover the license plate with a cover or dirt (Denial of Service)

Put a filter on the network that discards all of that tag’s packets (Denial of Service)

Copy another tag for use (Masquerader)

Hazard:          Device Failure

Method:          Break a device either partially or totally (Denial of Service)

Hazard:          Surveillance

Methods:        Obtain personal information (Disclosure)

Obtain account number and/or balance (Disclosure)

Relation-Hazard Tables

After the specific hazards and their methods have been derived, the relations that could be evaluated in the context of the application in order to detect the hazards caused by an intrusion need to be identified.  The following table contains one specific hazard, Steal Electronic Money, of the ETC system as well as the relations that could be used to detect it.  Column one contains the name of the relation, and column two contains the description of the relation.  Looking ahead to implementation issues, the description also specifies whether or not the relation is more statistical (description concludes with “(stat)”) or rule-like (description concludes with “(rule)”) in nature.  The execution location column (column three) indicates at what level(s) in the hierarchy that the relation would be appropriate (TBL = Toll Booth Lane, TBP = Toll Booth Plaza, TMC = Traffic Management Center).  The last column contains the specific hazard.  The subdivisions of the last column (in the second row) indicate the different methods by which the intrusion causing the hazard could be executed.  An “X” in a box indicates that the relation from that row could potentially help detect the hazard caused by the intrusion carried out using the method of that column.

            For the ETC application, we defined five tables [Sielken99], one for each hazard, having a total of thirty-nine relations. Table 1 only shows a subset of the relations for one specific hazard, Stealing Electronic Money to use the road without ever having to really pay for the service.

This table yields many interesting observations.  The first is that making the customer transparent by removing parts of the database so that the system cannot determine which account to debit could cause any of the relations to have anomalous results.  This is consistent with the fact that any destruction, not just modification, of the database will cause the entire system to malfunction because of the unavailability of information that the AppIDS needs to evaluate the relations.

The main observation is that there are numerous relations that can be defined to detect a wide variety of hazards caused by intrusions executed by utilizing different methods.  Some of the relations can detect anomalous behavior of the ETC customers, and some can detect system administrators who are abusing the system.

There are more rule-based relations than statistical relations for the ETC example, but both types appear to be useful.  There are relations that can be evaluated at all the levels of the hierarchy and some relations that can be usefully evaluated at multiple levels.  Not surprisingly, some hazards caused by intrusions can be detected by more relations than others can.

Health Record Management

The second case study is of a hypothetical health record management (HRM) system that includes patient records, orders for drugs, tests, or procedures, and the schedules for filling these orders.  This system is representative of a non-hierarchical information collecting and scheduling application that exists in many businesses.

Application Specific Intrusions

Once again, we will follow the procedure illustrated for the ETC case study to identify the relations relevant to detecting intrusions.  Using the same threat categories as reminders, specific hazards and methods by which to execute the intrusion to cause the hazard are derived.  Then, the relations that could possibly detect each specific hazard using the various methods can be identified.

For this case study, we derived the following four specific hazards.  The threat category from which each method was derived is listed in parentheses after each method description.

Hazard:          Annoyance

Methods:        Order Inapplicable Tests (Denial of Service)

Order Inapplicable Procedures (Denial of Service)

Order Inapplicable Drugs (Denial of Service)

Schedule Conflicts (Denial of Service, Physical Impossibilities)

Hazard:          Steal Drugs

Method:          Order Drugs for a Bogus Person (Manipulation, Replay)

Hazard:          Patient Harm

Methods:        Administer Wrong Drug (Manipulation, Replay)

Administer Too Much of a Drug (Manipulation, Replay)

Administer an Allergic Drug (Manipulation)

Administer Improper Diet (Manipulation, Replay)

Order Unnecessary Drugs (Manipulation)

Perform an Unnecessary Procedure (Manipulation)

Hazard:          Surveillance

Methods:        Obtain personal information (Disclosure)

Obtain account number and/or balance (Disclosure)

Relation-Hazard Tables

The following table contains one specific hazard caused by intrusions of the HRM system together with the relations used to detect them.  The structure of the table is the same as that of the table from the ETC example except for the execution location column has been removed since this system is non-hierarchical.  The system is modular but identifying relations with modules did not provide the additional insight that identifying relations with an execution location level in the hierarchy did in the ETC example.  There are four tables [Sielken99], one for each hazard, having a total of thirty-one relations.  Table 2 only shows a subset of the relations for one hazard, Patient Harm.  Any intrusion that can cause patients harm is of the utmost concern because negligent harm, whether caused by an intrusion or not, is detrimental to a health care provider, not to mention the legal liability engendered.

Table 2  Specific Relations for the Patient Harm Hazard

Relation	Relation Description	Patient Harm
		Admin. Wrong Drug	Admin. Too Much of Drug	Admin. an Allergic Drug	Admin. Improper Diet	Order Needless Drugs	Perform Needless Procedure
Drug vs. Allergy	Certain drugs cannot be taken when a person has certain allergies (rule)	X		X
Drug vs. Diet	Certain drugs cannot be taken while consuming certain foods (rule)	X			X
Drug vs. Historical (dosage)	Drug dosage should be fairly similar to other prescriptions of the drug in either dosage amount or frequency (stat)	X	X
Patient Test Results vs. Test Results (Historical)	Test results should be related to previous test results for that patient (stat)	X	X			X	X

Although this hazard is critical to detect, there are many (thirteen in all, four shown) relations that can be used to detect the hazard caused by an intrusion.  Both rule-like and statistical relations are useful although a majority of the relations (not all shown here) are rule-like.  It is also interesting to note that relations reflect constraints of the real world such as constraints based on a patient’s medical history and general medical knowledge and practices.  While the HRM system is non-hierarchical, it has about as many relations as the ETC case study.

Application Intrusion Detection

After exploring these case studies, we were able to identify some similarities and differences between intrusion detection at the OS and application levels.  In this section, we discuss these differences as well as investigate how the AppIDS relies on the OS IDS for certain protections.  Because the two IDS detect intruders, we also explore how the two might cooperate to detect an intruder.

Similarities and Differences between OS IDS and AppIDS

The main similarity between an OS IDS and an AppIDS is that both can use statistical and rule-based relations with defined thresholds to detect intruders.  While an AppIDS could perform anomaly and misuse detection, it appears that an AppIDS will focus more on anomaly detection but use both statistical and rule-based relations to detect the anomalies.

AppIDS only detect internal intruders after they either penetrated the OS to gain access to the application or were given some legitimate access to the application.  The particular internal intruders of interest are the internal – legitimate [Anderson80] users who are basically abusers of the system.  A credit card defrauder utilizing a stolen card or account number to make purchases would be another example of an abuser.  The defrauder is considered an internal intruder because the card or account number serves as legitimate access to a portion of the credit card application.  Fortunately, the defrauder’s use of the card may vary from the rightful card owner’s usage enough in frequency of use, locations of use, or transaction amounts to be detectable by an anomaly detecting AppIDS.

More observable entities allow for more relations to be defined which may improve the effectiveness of the IDS.  Resolution of the observable entities in the IDS is the relative number of entities.  An IDS that subdivides the monitored system into a few observable entities is said to have lower resolution, while an IDS that subdivides the same monitored system into more observable entities is said to have higher resolution.  In the ETC example, the size of the traffic sensor database file would be the same to both an OS IDS and an AppIDS.  However, the AppIDS can define a relation on the different records or fields of the file while the OS IDS cannot.  The ability to define relations using resource usage and functional values and to subdivide the monitored system into more observable entities gives the AppIDS higher resolution than the OS IDS.  Given higher resolution than an OS IDS, the AppIDS can define relations with tighter thresholds, thereby increasing the overall effectiveness in detecting intrusions.

Because the AppIDS relies on relations to detect intrusions, there must be some mechanism by which the AppIDS acquires the information necessary to evaluate the relations. OS IDS use the operating system audit records.  Similarly, the AppIDS could build event records containing listings of all relevant events and, if possible, the associated event causing entities, the observable entities that brought about the events.  These event records could be generated in two ways.  The first involves periodically, such as hourly or daily, scanning the system values and recording all of those values that have changed as entries in an event record.  The second option involves inserting code triggers; code triggers are small segments of code inserted into the application itself such that when certain events occur in the application, indicated by the code trigger being executed, it causes an event record entry to be generated or a relation to be evaluated.  It is unclear at this juncture which of these methods would be preferable as each contains safety and performance issues.  Either way, given these event records, the AppIDS could evaluate the relations with a procedure similar to that which the OS IDS employs.

Dependencies between OS IDS and AppIDS

OS IDS have been deployed for years without AppIDS, so OS IDS are certainly not dependent on AppIDS.  Because all applications run on top of operating systems, the AppIDS will rely on the OS IDS to provide some basic security services such as access control protection of the application’s code, data, and communications.  Typically, only the OS IDS can detect and protect against the external intruders.  An AppIDS may be able to detect an external intruder but only after the intruder gains access to the system at which point the intruder is reclassified as an internal intruder.

Cooperation between OS IDS and AppIDS

If both OS IDS and AppIDS exist for a system and an application, it is logical to explore how the two IDS could cooperate to improve the overall effectiveness of detecting intrusions.  For example, an AppIDS may detect a manipulation intrusion but cannot determine the identification of the intruder.  The OS IDS may be able to identify the intruder.  Conversely, an OS IDS may detect that an application has had a sudden increase in the number of files created.  However, the OS IDS cannot determine whether this should be happening, but the AppIDS may be able to decide because it has the additional information of the application semantics.

If the OS IDS and AppIDS are to cooperate, there must be some mechanism and an interface for the two to communicate with one another.  Current interfaces between two OS IDS only pass information in the form of audit records.  They cannot explicitly request service or query each other for information [Porras97].  Since cooperative IDS will need to be able to not only pass information but also request services that may involve the return of information, they will need to have the bi-directional information flows that we explore here.  The initiating IDS, the one that makes the request, will need to create a bundle of application information to send to the servicing IDS, the one that receives the request.  A bundle is a collection of information to either request information from another IDS or to respond to another IDS’s request.  The request bundle may include the information request, event descriptions, event times, and possible identifications that the other IDS could use to determine the appropriate response.  The recipient IDS will then determine the answer to the request and form a response bundle to send back to the requesting IDS.  If the request was only for a service such as increased protection services, a response bundle may be omitted.

Although the communication between the two with bi-directional information flows seems simple enough, there are some complications.  The application and the OS operate at different semantic levels, so they must be able to communicate in terms that both can understand.  Without being able to express requests and interpret responses from the other domain, communications between OS IDS and AppIDS would be fruitless.  The lowest common denominator is resource usage, so this appears to be the simplest starting point for developing the communication interface.

Conclusions

By exploring the possibilities of intrusion detection at the application level, we hoped to explore the opportunities and limits of utilizing application semantics to perform intrusion detection.  From reviewing the state of practice for OS IDS and two extensive case studies, we determined that application semantics can be used to detect internal intruders of an application using similar techniques to those employed by OS IDS.  We found that the AppIDS will be mostly concerned with anomaly detection but use both forms of relations, statistical and rule-based, to detect intruders.  Although the threats may be similar for both IDS, the higher resolution of observable entities with which the AppIDS operates allows it to detect intrusions that the OS IDS cannot detect.  Because the AppIDS relies on the OS IDS for some basic protection and only the OS IDS can detect the external intruders, it is not reasonable to replace and OS IDS with an AppIDS, only to augment the OS IDS.  If both IDS are present, there is potential for the two to cooperate in detecting some intrusions using a bi-directional communication interface.

Little research has been done into performing intrusion detection at the application level, so there is a general lack of literature on the subject.  The construction of an actual AppIDS would also be beneficial in furthering these conclusions.  A possible structure for constructing multiple AppIDS has been discussed elsewhere [Sielken99].  We have shown that the approach of detecting intrusions at the application level appears to be fruitful.  The next step is an actual implementation of an AppIDS for representative applications.