Application Intrusion Detection
Generic Characteristics of IDS
Download 499.99 Kb.
|
3.3Generic Characteristics of IDSAfter 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 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 the percentage of CPU time used in the last time quantum, the number of file blocks 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 compare the current value of an observable entity to a profile, a collection of statistical and other relevant information characterizing normal or anomalous behavior, and are most often used in anomaly detection. Rule-based relations relate the immediate or accumulated value to a predefined expected value. These relations require two or more values to be associated by some function. For example, one value may be required to be within a fixed range or some percentage of the other. The rule-based relations are most often used in misuse detection where the values of the observable entities are compared to the intrusion scenario that represents a specific intrusion. 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. A key question is how the discrepancy between the two values relates to the semantics of the system. For the operating system, below normal resource usage may be good in that the system is not being over worked or it may be bad in that the system should be doing work and it currently is not. Ideally, all intrusions would be detected without false alarms. Recall that a false alarm is an indication of an intrusion in the absence of an intrusion. However, this ideal is typically unattainable as many of the events indicative of an intrusion, such as those events of an intrusion scenario, are also legitimate events under certain circumstances. Processing of false alarms causes unnecessary time and resources to be diverted from achieving the mission of the system, and system administrators to dismiss reports of intrusions. Therefore, the values of the thresholds must be set to detect as many intrusions as possible without an intolerable amount of false alarms; this is commonly referred to as fine-tuning the intrusion detection system and determines the effectiveness of the IDS. Tighter thresholds, permitting less discrepancy, allow for greater detection but at the risk of more false alarms. Looser thresholds produce fewer false alarms but potentially at the cost of diminished detection. The tightness of the thresholds is largely a function of the system semantics. A relation involving an entity with consistent, well-defined behavior will allow for a tighter threshold value than a relation involving an entity with less consistent, potentially erratic behavior. The frequency with which a relation is evaluated can also impact the effectiveness of the intrusion detection system. It is possible for the intrusion detection system to evaluate all relations immediately after each event, but this may place an intolerable processing cost burden on the intrusion detection system that would cause the IDS to fall increasingly farther behind or require the monitored system to run at a slower pace to allow the intrusion detection system to process the events. 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. By reducing the total number of events that must be analyzed, the IDS has a higher probability of keeping pace with the monitored system. 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. The effectiveness of the IDS also depends on how many values are correlated to each other. With many values to correlate to each other, it is easier to determine which of the values are truly anomalous. If one value is anomalous, then most of the relations involving that value should have results that lie outside of their thresholds. With multiple relations involving the observable entities of the anomalous relation result, the IDS may be able to determine which value used in those relations is anomalous the anomalous one. Therefore, the more values or relation results that can be correlated to each other, the more effective the intrusion detection system will be at detecting intrusions or system device failures. From the previous discussion of the centralized and decentralized network intrusion detection systems, it is apparent that hierarchies may exist in the intrusion detection system. Centralized network IDS have only two levels in the hierarchy. The lower level consists of all the hosts being monitored who all pass their audit records to a single intrusion detection host where the analysis is performed. This single, analysis host is the upper level in the hierarchy. Decentralized network IDS may have more than two levels in the hierarchy. At the lowest level are the hosts that run single host intrusion detection analysis to catch local intrusions. A subset of the local audit record information is then passed to the next higher level. This level analyzes the records for all the hosts reporting to this level. This level may then pass even more general information to the next higher level, and so on until the highest level is reached which does high-level intrusion detection over the whole system. These hierarchies normally correspond to the hierarchy present in the monitored system, but this is certainly not a requirement. The hierarchy may be based on the physical location of the hosts, the administrative domains of the hosts, or some other characteristic such as machine or operating system type. OS IDS have been deployed for many years now and have had a chance to mature to some degree. We hypothesize that intrusion detection at the OS level will have characteristics of intrusion detection systems regardless of the level of the monitored system. Therefore, we will use these characteristics to provide the basis for analyzing the opportunity to perform intrusion detection at the application level. Directory: ~jones -> IDS-research -> Documents Documents -> Application Intrusion Detection Systems: The Next Step Download 499.99 Kb. Share with your friends:
|